<<Prev
Next>>
Scroll to Bottom
Stuff goes here
L1[00:06:15] ⇨
Joins: Hunterz
(~hunterz@2001:af0:8000:1c01:6af7:28ff:fe37:5d6a)
L2[00:22:00] ⇨
Joins: ben_mkiv
(~ben_mkiv@p57972568.dip0.t-ipconnect.de)
L3[01:00:54] ⇦
Quits: Neal (~Neal@47.146.41.184) (Ping timeout: 186
seconds)
L4[01:07:25] ⇦
Quits: Brokkoli (~Brokkoli@p5B23CE53.dip0.t-ipconnect.de) (Remote
host closed the connection)
L5[01:37:00] ⇦
Quits: Darkhax (~darkhax@d205-206-157-117.abhsia.telus.net) (Ping
timeout: 207 seconds)
L6[01:48:52] ⇨
Joins: Hgreb (~Hgrebnedn@d8D872A6E.access.telenet.be)
L7[02:00:03] <MCPBot_Reborn> [TEST CSV]
Pushing snapshot_20171123 mappings to Forge Maven.
L8[02:00:07] <MCPBot_Reborn> [TEST CSV]
Maven upload successful for mcp_snapshot-20171123-1.12.zip
(mappings = "snapshot_20171123" in build.gradle).
L9[02:00:18] <MCPBot_Reborn> Semi-live
(every 10 min), Snapshot (daily ~3:00 EST), and Stable (committed)
MCPBot mapping exports can be found here:
http://export.mcpbot.bspk.rs/
L10[02:04:52] ⇦
Quits: Dark (~MrDark@2607:fcc8:d48b:eb00:4444:83e5:6356:4a2d) (Read
error: Connection reset by peer)
L11[02:12:06] ⇦
Quits: iPixeli (~iPixeli@5.80.48.58) (Ping timeout: 207
seconds)
L12[02:13:11] ⇨
Joins: iPixeli (~iPixeli@5.80.48.58)
L13[02:13:11]
MineBot sets mode: +v on iPixeli
L14[02:18:12] ⇨
Joins: Noppes (~Noppes@ip56530f2e.direct-adsl.nl)
L15[02:29:01] ⇨
Joins: gigaherz|work (~gigaherz@84.89.63.25)
L16[02:29:49] ⇦
Quits: Noppes (~Noppes@ip56530f2e.direct-adsl.nl) (Read error:
Connection reset by peer)
L17[02:46:50] ⇨
Joins: mallrat208 (~mallrat20@107.145.144.41)
L18[02:53:42] ⇦
Quits: Hgreb (~Hgrebnedn@d8D872A6E.access.telenet.be) (Ping
timeout: 207 seconds)
L19[02:57:23] ⇦
Quits: mallrat208 (~mallrat20@107.145.144.41) (Quit:
Leaving)
L20[03:03:18] ⇦
Quits: ben_mkiv (~ben_mkiv@p57972568.dip0.t-ipconnect.de) (Ping
timeout: 383 seconds)
L21[03:05:43] ⇦
Quits: Hunterz (~hunterz@2001:af0:8000:1c01:6af7:28ff:fe37:5d6a)
(Ping timeout: 383 seconds)
L22[03:23:31] ⇨
Joins: Hunterz (~hunterz@194.213.62.154)
L23[03:59:34] ⇦
Quits: iPixeli (~iPixeli@5.80.48.58) (Ping timeout: 198
seconds)
L24[04:00:47] ⇨
Joins: iPixeli (~iPixeli@5.80.48.58)
L25[04:00:48]
MineBot sets mode: +v on iPixeli
L26[04:03:10] ⇦
Quits: immibis (~chatzilla@122-59-204-185.jetstream.xtra.co.nz)
(Ping timeout: 198 seconds)
L28[04:21:35] ⇨
Joins: Seiver (~Seiver@65.118.189.175)
L29[04:21:39] <gigaherz|work> 1.8 modding
X
L30[04:21:41] <gigaherz|work> XD*
L31[04:22:06] <Seiver> o/ i need a hane
reading a crash report
L32[04:22:12] <Seiver> hand*
L34[04:25:34] <gigaherz|work> there isn't
much to say about it
L35[04:25:44] <gigaherz|work> binnie's core
mod is crashing
L36[04:26:36] <Seiver> i know its working
in the DW20 1.12 though, thats what bugs me
L37[04:27:41] <gigaherz|work> seems to be
this line
L39[04:27:54] <gigaherz|work> something
doesn't have a "species root" for whatever reason
L40[04:28:57] <gigaherz|work> broken item,
broken entity, no idea
L41[04:29:18] <gigaherz|work> (and i'm not
going to dig any deeper)
L42[04:30:23] <Seiver> ok ty, thats enough
info i can toss it onto the github issues and not be compleatly
clueless
L44[05:15:20] ⇨
Joins: Redfoxmoon
(~Red@177.92-221-236.customer.lyse.net)
L45[05:17:58] ⇨
Joins: drcrazy (~drcrazy@86.57.255.90)
L46[05:27:02] ⇦
Quits: Backslash_ (~Backslash@ip-94-114-160-58.unity-media.net)
(Quit: Leaving)
L47[05:29:42] ⇦
Quits: drcrazy (~drcrazy@86.57.255.90) (Quit: Leaving)
L48[05:37:17] ⇨
Joins: RichardG (~richardg8@201.37.246.64)
L49[05:37:18]
MineBot sets mode: +v on RichardG
L50[05:48:44] ⇨
Joins: Backslash
(~Backslash@ip-94-114-160-58.unity-media.net)
L51[05:59:15] ⇦
Quits: Kuraron
(~DUX@HSI-KBW-46-223-0-70.hsi.kabel-badenwuerttemberg.de) (Remote
host closed the connection)
L52[06:05:15] ⇨
Joins: Kuraron
(~DUX@HSI-KBW-46-223-0-70.hsi.kabel-badenwuerttemberg.de)
L53[06:16:30] ⇨
Joins: Nedelosk
(~Nedelosk@ip-109-90-75-57.hsi11.unitymediagroup.de)
L54[07:22:14] ⇨
Joins: Dark
(~MrDark@2607:fcc8:d48b:eb00:218e:15ce:2665:76a6)
L55[07:43:40] ⇨
Joins: quadraxis
(~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
L56[07:51:58] ⇨
Joins: Cast0077
(~Cast0077@24-151-68-108.dhcp.nwtn.ct.charter.com)
L58[08:18:28] ⇦
Quits: Hunterz (~hunterz@194.213.62.154) (Remote host closed the
connection)
L59[08:19:04] <Sephiroth> Cast0077, One of
the mods you have installed is throwing up a debug crash to print
system info. Not sure which one it is but disabling that should
allow the game to load.
L60[08:24:11] <Cast0077> strange i have
this pack on 3 other systems here and it works fine
L61[08:24:41] <Cast0077> so that mod just
doesn't like that system?
L62[08:26:50] <gigaherz|work> the system
info isn't the crash
L63[08:27:53] <gigaherz|work> there's
nothing in that log that indicates why it's closing itself
L64[08:38:54] <Cast0077> where should I
look
L65[08:40:18] <gigaherz|work> OH
L66[08:40:20] <gigaherz|work> I missed
something!
L67[08:41:05] ⇨
Joins: sinkillerj
(~sinkiller@nc-67-238-185-39.dhcp.embarqhsd.net)
L68[08:41:33] <gigaherz|work> [07:57:21]
[main/ERROR] [LaunchWrapper/]: A critical problem occurred
registering the ASM transformer class
L69[08:41:53] <gigaherz|work> doens't
specify which
L70[08:41:59] <gigaherz|work> but one of
the coremods is doing something wrong
L71[08:42:37] <Cast0077> but just on 1 of 4
computers
L72[08:42:43] <gigaherz|work> but, that
error doesn't prevent launch
L73[08:42:54] <gigaherz|work> it just means
that stuff is likely to fail later
L74[08:43:14] <gigaherz|work> I hate that
people release mods with missing models
L75[08:43:27] <gigaherz|work> I hate having
unnecessary log spam
L76[08:43:39] <Cast0077> my son has been
asking about his pack for while to
L77[08:43:57] <Cast0077> he would pick the
one that doesn't work lol
L78[08:44:15] <Cast0077> its always on 5/7
part
L79[08:47:13] <UnRealDinner> i hate that to
gig
L80[08:47:34] ⇦
Quits: p455w0rd (p455w0rd@c-98-220-249-33.hsd1.in.comcast.net)
()
L81[08:49:20] ⇦
Quits: npe|office (~NPExcepti@bps-gw.hrz.tu-chemnitz.de) (Remote
host closed the connection)
L82[08:51:22] ⇨
Joins: RichardG_ (~richardg8@201.37.246.64)
L83[08:51:22]
MineBot sets mode: +v on RichardG_
L84[08:51:46] ⇦
Quits: RichardG (~richardg8@201.37.246.64) (Ping timeout: 198
seconds)
L85[09:05:27] <Cast0077> how can I figure
out which mod it is
L86[09:09:40] ⇨
Joins: ben_mkiv
(~ben_mkiv@p57972568.dip0.t-ipconnect.de)
L87[09:20:54] ***
RichardG_ is now known as RichardG
L88[09:53:10] ⇦
Quits: gigaherz|work (~gigaherz@84.89.63.25) (Ping timeout: 186
seconds)
L89[09:57:34] ⇨
Joins: Brokkoli
(~Brokkoli@p5B23CE53.dip0.t-ipconnect.de)
L90[10:03:58] ⇦
Quits: sinkillerj (~sinkiller@nc-67-238-185-39.dhcp.embarqhsd.net)
(Remote host closed the connection)
L91[10:13:15] ⇨
Joins: Hunterz (~hunterz@62.182.234.189)
L92[10:17:35] ⇦
Quits: An_Angry_Brit (~AngryBrit@90.255.41.31) (Ping timeout: 200
seconds)
L93[10:27:33] ⇦
Quits: Redfoxmoon (~Red@177.92-221-236.customer.lyse.net) (Read
error: Connection reset by peer)
L94[10:27:46] ⇨
Joins: Redfoxmoon
(~Red@177.92-221-236.customer.lyse.net)
L95[11:00:22] ⇨
Joins: SanAndreasP
(~SanAndrea@mue-88-130-48-198.dsl.tropolys.de)
L96[11:07:08] ***
PaleOff is now known as PaleoCrafter
L97[11:08:05] ⇨
Joins: Javaschreiber
(~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
L98[11:08:34] ***
PaleoCrafter is now known as PaleOff
L99[11:09:17] ⇦
Quits: ben_mkiv (~ben_mkiv@p57972568.dip0.t-ipconnect.de) (Ping
timeout: 200 seconds)
L100[11:09:33]
⇨ Joins: malte0811 (~malte@185.134.128.197)
L101[11:19:01]
⇨ Joins: Neal (~Neal@47.146.41.184)
L102[11:43:37]
⇨ Joins: Darkhax
(~darkhax@d205-206-157-117.abhsia.telus.net)
L103[11:48:04] ⇦
Quits: quadraxis
(~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
(Ping timeout: 183 seconds)
L104[11:58:25]
⇨ Joins: ben_mkiv
(~ben_mkiv@p57972568.dip0.t-ipconnect.de)
L105[12:00:26] ⇦
Quits: Javaschreiber
(~Thunderbi@88-209-32-73.nga.highspeed-baumann.de) (Quit:
Javaschreiber)
L106[12:00:34]
⇨ Joins: Javaschreiber
(~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
L107[12:18:02] ⇦
Quits: Redfoxmoon (~Red@177.92-221-236.customer.lyse.net) (Read
error: -0x1: UNKNOWN ERROR CODE (0001))
L108[12:18:17]
⇨ Joins: Redfoxmoon
(~Red@177.92-221-236.customer.lyse.net)
L109[12:20:17]
⇨ Joins: Raycoms (~Raycoms@200.135.87.140)
L110[12:22:45] ⇦
Quits: Raycoms (~Raycoms@200.135.87.140) (Client Quit)
L111[12:23:02] <barteks2x> is there an
event for when I should register IDataFixer?
L112[12:58:18] ⇦
Quits: Hanii (~textual@2a00:23c4:484:d100:794e:decc:c184:dff9)
(Quit: Textual IRC Client: www.textualapp.com)
L113[13:07:58]
⇨ Joins: Hgreb
(~Hgrebnedn@d8D872A6E.access.telenet.be)
L114[13:08:49]
⇨ Joins: McJty
(~jorrit@ptr-9197ufndwubhryxrcjc.18120a2.ip6.access.telenet.be)
L115[13:14:12] ⇦
Quits: Cast0077 (~Cast0077@24-151-68-108.dhcp.nwtn.ct.charter.com)
(Quit: Poof)
L116[13:20:35]
⇨ Joins: Raycoms
(~Raycoms@2804:14d:baa0:9612:211:f974:13b9:be92)
L118[13:21:13] <Raycoms> Is there anything
we could do to avoid this?
L119[13:22:22] <Ordinastie> yeah, that
won't cause issues... private static final double
ONE_HUNDED_EIGHTY_DEGREES = 270D;
L120[13:22:30] <barteks2x> where is
renderStructure called from?
L121[13:23:02] <Raycoms> I think the dev
who coded that var adapted it but forgot to change the name
L122[13:23:17] <Raycoms> It's called from
an event
L123[13:23:19] <barteks2x> and the name is
wrong anyway, it should state what ot's used for
L124[13:23:25] <barteks2x> which
event?
L125[13:23:43] <Raycoms>
RenderWorldLastEvent
L126[13:23:59] <barteks2x> ...
L127[13:24:11] <barteks2x> That method is
pretty slow
L128[13:24:19] <barteks2x> I can see even
just looking at it
L129[13:24:59] <barteks2x> at the very
least you should cache the models
L130[13:25:02] <Raycoms> I do
L131[13:25:14] <barteks2x> and cache the
fake worlds
L132[13:25:51] <barteks2x> ok I see
L133[13:26:07] <Ordinastie> well, if you
want to gain some perf, first, move out of loops everything you
can
L134[13:26:08] <barteks2x> so you should
probably create VBO/display list for all the block models
L135[13:26:23] <Ordinastie> but tbh, you
shouldn't be rendering that stuff each frame
L136[13:26:24] <barteks2x> or actually use
somethign like RenderChunk
L137[13:26:27] <barteks2x> if you can
figure out hiw
L138[13:26:36] <Ordinastie> so yeah, what
barteks2x says
L139[13:26:42] <barteks2x> which handles
VBOs/display lists for you
L140[13:27:18] <Raycoms> Is there some
example on that?
L141[13:27:21] <barteks2x> the reason MC
uses VBO/display list for each chunk is exactly because doing it
the easy way is slow
L142[13:27:40] <barteks2x> I don't think
so... you are on your own there. See how vanilla uses it and try
similar way
L143[13:28:12] <barteks2x> And I don't
mean "blindly copypaste the code". You should understand
what it's doing
L144[13:28:58] <barteks2x> is there any
example of using DataFoxers in mods?
L145[13:31:33] ⇦
Quits: Darkhax (~darkhax@d205-206-157-117.abhsia.telus.net) (Ping
timeout: 200 seconds)
L146[13:45:27] <barteks2x> @Deprecated
//Modders do not use this, this will register you as vanilla. Use
the ModID version below.
L147[13:45:34] <barteks2x> but there is no
other register() method
L148[13:45:36] <barteks2x> WHY!?
L149[13:54:33] <LexMobile> interesting,
could of sworn I added it, the comment even says I did. Guess
nobody out there ever gives a fuck about world compatibility to
look
L150[13:59:22] <barteks2x> I found
it..
L151[13:59:25] <barteks2x> it's called
init()
L152[14:00:12] <barteks2x> because it's
really an *obvious* name for something that allows to register data
fixers. And it's actually above and not below like the comments
say
L153[14:00:34] <barteks2x> I guess the
comment needs to be updated then
L154[14:04:14] <barteks2x> also, is fix
version 0 going to be used when updating from no-fix-before to
version with fixer?
L155[14:05:55]
⇨ Joins: Darkhax
(~darkhax@d205-206-157-117.abhsia.telus.net)
L156[14:08:26] <LexMobile> yes it
should
L157[14:08:35] <LexMobile> also feel free
to suggest API
L158[14:08:45] <LexMobile> 1.13 will be
breaking changes all over the place so we can upgrade it
L159[14:09:22] <LexMobile> The current
state is my first hack that I wanted people to look at and give me
suggestions
L160[14:09:30] <LexMobile> Those
suggestions/comments never came
L161[14:10:23] ***
Santa|afk is now known as SatanicSanta
L162[14:10:30] <barteks2x> Right now I'm
using it just to keep compatibility with old generator
customization json, when I'm redesigning the way ores are handles.
So far the design looks fine
L163[14:12:31] <barteks2x> also looks like
mod fixes run before vanilla...
L164[14:12:49] <barteks2x> I think it
would be more useful to have them run after. Noone sane wants to
handle old versions of vanilla NBT
L165[14:13:33] <barteks2x> nvm
L166[14:13:48]
⇨ Joins: quadraxis
(~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
L167[14:16:48] <barteks2x> where does it
actually call vanilla fixers?
L168[14:18:41] <barteks2x> the holder only
ever calls mod fixes
L169[14:21:45] <barteks2x> oh...
this.vanilla = init("minecraft", vanilla.version);
L170[14:22:33] <barteks2x> except... with
hashmap the iteration order isnt defined
L171[14:23:07]
⇨ Joins: Ipsis
(~Ipsis@82-69-71-184.dsl.in-addr.zen.co.uk)
L172[14:23:07] <barteks2x> and it would be
way nicer if vanilla was guaranteed to run first
L173[14:25:53] <barteks2x> or in general
would be nice to have a way to register my mod fixes after specific
mod, so that it's safe to use NBT of dependencies
L174[14:26:29] <barteks2x> (or I guess
using NBT of dependencies is never safe. But using vanilla NBT
should be)
L175[14:27:33] ⇦
Parts: malte0811 (~malte@185.134.128.197) ())
L176[14:33:08] <LexMobile> the problem is
deciding a 'run after this version of vanilla but before this
one'
L177[14:33:22]
⇨ Joins: immibis
(~chatzilla@122-59-204-185.jetstream.xtra.co.nz)
L178[14:33:34] <LexMobile> and you do have
the way to register your stuff after another mod
L179[14:33:38] <LexMobile> @Mod deps
L180[14:33:57] <barteks2x> yes but the
hashmap the stuff is stored in has NO order
L181[14:34:21] <barteks2x> so the
registration order is not preserved
L182[14:34:30] <LexMobile> meh, could be
changed
L183[14:34:41] <LexMobile> but the idea
was you dont care about other mods interacting with YOUR data
L184[14:34:47] <LexMobile> because you
should only transform YOUR data
L185[14:34:48] <barteks2x> but you do care
about vanilla
L186[14:34:53] <barteks2x> and vanilla IS
a mod here
L187[14:35:09] <barteks2x> because your
mod data is probably somewhere in vanilla NBT compound
L188[14:35:17] <LexMobile> Yes which is
the whole "the problem is deciding ...."
L189[14:35:34] <barteks2x> it should just
run after all vanilla fixers...
L190[14:35:44] <LexMobile> except
no.
L191[14:35:47] <barteks2x> because you
always want to deal with latest vanilla NBT
L192[14:35:54] <LexMobile> No you
dont
L193[14:36:04] <LexMobile> You want to
deal with the version of the vanilla NBT that has your stuff
L194[14:37:02] <LexMobile> or more
exactly, you want to deal with the version of vanilla that is in
the format you think it is.
L195[14:38:59] <barteks2x> This is getting
messy really quickly... do vanilla fixers ever discard some old
NBT? like modded NBT?
L196[14:39:16] <LexMobile> yes
L197[14:39:26] <barteks2x> well then
vanilla should probably run last
L198[14:39:44] <LexMobile> You're very
black and white arnt you?
L199[14:39:56] <LexMobile> The entire
fucking point is not to run 'first'
L200[14:39:57] <LexMobile> or 'last'
L201[14:40:00] <LexMobile> but WHEN
NEEDED
L202[14:40:57] <barteks2x> that's harder
than it seems to be... maybe mod fixers should also have mc
version?
L203[14:41:08] <LexMobile> maybe
L204[14:43:23] ⇦
Quits: Redfoxmoon (~Red@177.92-221-236.customer.lyse.net) (Read
error: -0x1: UNKNOWN ERROR CODE (0001))
L205[14:43:50]
⇨ Joins: Redfoxmoon
(~Red@177.92-221-236.customer.lyse.net)
L206[14:44:11] <barteks2x> actually i
can't think of a situation where rtunning vanilla fixers last would
be bad
L207[14:44:26] <LexMobile> other issue is
what happens if you come across a chunk that has Vanilla 5, And Mod
2, but Mod 3 needs to be run on vanilla 4
L208[14:45:21] <barteks2x> well, if the
chunk has mod 2, then that mod version existed for vanilla 5
L209[14:45:34] <barteks2x> so mod 3 can't
require the chunk to be in vanilla 4 format
L210[14:45:37] <LexMobile> I''ll give you
a case, One where you're screwing with entities, and wanting to
translate your old name to the new name. It could be in one tag in
vanilla X, but in another in vanilla Y
L211[14:46:01] <barteks2x> but you should
know which vanilla version your mod fixer version X was for
L212[14:46:21] ⇦
Quits: McJty
(~jorrit@ptr-9197ufndwubhryxrcjc.18120a2.ip6.access.telenet.be)
(Quit: Leaving)
L213[14:46:34] <barteks2x> the only issue
could be mod developed for multiple MC versions concurrently
L214[14:46:58] <LexMobile> if we run all
of vanilla in a batch then its quite possible the chunk would start
with M2 V1, and Then have V5 before M3 runs.
L215[14:48:14] <Ordinastie> so you
basically want the same dep sorter as for mods
L216[14:48:15] <LexMobile> Or have V1 when
M3 runs but it thinks the format is V4
L217[14:48:21] <Ordinastie> like
after:vanillaX
L218[14:48:28] <LexMobile> Sorta, but a
lot less complex.
L219[14:48:42] <LexMobile> I DO NOT want
to make you able to dep on other mods data fixes
L220[14:48:45] <barteks2x> I see the issue
now... and the only solution may be for the mod fixer to know
before/after which vanilla fixer versions it wants to be run
L221[14:48:46] <Ordinastie> don't think it
would need the before, that should help for complexity
L222[14:48:50] <LexMobile> because you
should fuck with your own shit not others.
L223[14:49:36] <barteks2x> sadly vanilla
fixer versions don't correspond to vanilla MC versions in any nice
predictable way
L224[14:49:41] <LexMobile> but ya you guys
are free to make proposals, but please think of the cases
carefully
L225[14:49:50] <barteks2x> so it can;t
just say "I want to run before/after MC versions"
L226[14:50:28] <LexMobile> well it kinda
can. They match up 1:1 Because MC only ever releases one version of
a version
L227[14:50:32] <Ordinastie> I guess MC
<-> fixer version could be hardcoded by forge
L228[14:50:34] <LexMobile> but you can't
predict it no
L229[14:50:56] <LexMobile> No, thats just
dumb because its more workf or me for no change on modders
end.
L230[14:51:05] <LexMobile>
s/1.11.2/1234/
L231[14:52:31] <barteks2x> so adding a
vanilla fixer version to mod fixers would probably work. And
running them right before vanilla fixers for that vanilla fixer
version
L232[14:53:15] <barteks2x> then there is
the issue of mods released for multiple MC versions at once
L233[14:53:53] <barteks2x> which I guess
could be solved with the mod fixer version being mcVersionCounter
<< 16 | modFixVersion
L234[14:54:21] <LexMobile> not sure where
you're pulling that from...
L235[14:54:34] <LexMobile> but the thing
about data fixers is it really sint for specific mc versions
L236[14:54:34] <barteks2x> wait nvm
L237[14:54:39] <LexMobile> its all
verisoned by the data itself
L238[14:54:58] <barteks2x> yes but modded
fixers really do need to interact with vanilla data
L239[14:55:12] ⇦
Quits: Cornelia (~Nel@c-75-71-231-133.hsd1.co.comcast.net) (Ping
timeout: 207 seconds)
L240[14:55:35] <LexMobile> yes but again
they know what version they are in data wise before they are fun
{or atleast they should}
L241[14:56:06] <barteks2x> well what if
they are updating a few versions at once?
L242[14:56:14] <LexMobile> Explain
L243[14:56:15] <barteks2x> going back a
few MC versions
L244[14:56:25] <barteks2x> say updating
from 1.10 to 1.13
L245[14:57:09] <barteks2x> and let's say
there are 3 mod fixer versions in between. If you first run mod
fixers, you have all the mod fixers dealing with MC version 1.10
data, where the last fixer may expect 1.12 data
L246[14:58:05] <LexMobile> and you're
making a backported release for 1.10?
L247[14:58:14] ⇦
Quits: immibis (~chatzilla@122-59-204-185.jetstream.xtra.co.nz)
(Ping timeout: 186 seconds)
L248[14:58:32] <barteks2x> I actually am
but it's not currently an issue for me as I don't really store much
data that needs to be updated.
L249[14:58:49] <barteks2x> most of the
data I need updated that I store is in vanilla-compatible
format
L250[14:59:00] <barteks2x> so I rely on
vanilla fixers there
L251[14:59:22] <LexMobile> Until 1.13 but
thats a different thing.
L252[14:59:46] <LexMobile> So basically
you're trying to figure out how to run your fixer
L253[14:59:51] <barteks2x> I still may be
able to rely strictly on vanilla fixers as long as they dont change
how the ExtendedBlockStorage array is stored
L254[14:59:58] <LexMobile> and figure out
if its V5 of vanilla or V8?
L255[15:00:24] <LexMobile> Now remember
its not MC 1.10 or MC 1.12
L256[15:00:37] <LexMobile> It's 'Data
Version X' and 'Data Version Z'
L257[15:00:59] <LexMobile> And when the
chunk is loaded it says "Hey I'm data version Y, so don't run
X, but do run Z"
L258[15:00:59] <barteks2x> ideally mod
fixers should get the data in predictable vanilla data
version
L259[15:01:49] <barteks2x> and again, I
don't strictly need it now because the part of NBT I rely on hasn't
changed since mojang added world customization
L260[15:02:28] <barteks2x> I will probably
need it in the future when I change some important stuff
L261[15:03:48] <LexMobile> But ya this
isnt a simple system. And there is a lot of caviots if you try and
make it to complex.
L262[15:04:06] <LexMobile> So.. ya have
fun thinking about it. Hope to see your PR in a while.
L263[15:04:18]
⇨ Joins: nallar
(~nallar@cpc134854-cani4-2-0-cust141.know.cable.virginm.net)
L264[15:04:19] ⇦
Quits: Ipsis (~Ipsis@82-69-71-184.dsl.in-addr.zen.co.uk) (Ping
timeout: 200 seconds)
L265[15:04:57] <barteks2x> maybe this
weekend because today I really want to get that GUI I wanted to do
finished... and so far I got stuck on data fixer to convert old
worlds to new data format needed for the GUI
L266[15:06:24] ⇦
Quits: Hunterz (~hunterz@62.182.234.189) (Quit:
Leaving.)
L267[15:09:03] ⇦
Quits: md_5 (~md_5@marius.md-5.net) (Ping timeout: 183
seconds)
L268[15:09:18]
⇨ Joins: md_5 (~md_5@marius.md-5.net)
L269[15:19:36] <barteks2x> is there some
relatively future proof way to serialize/deserialize blockstates to
string?
L270[15:21:33] ***
PaleOff is now known as PaleoCrafter
L271[15:25:50] <gigaherz> barteks2x: don't
they have a method for it?
L272[15:26:22] <barteks2x> I can't find
any
L273[15:26:56] <barteks2x> best I can come
up with for now for serializing to json is putting the registry
name and value of each property
L274[15:26:59] <PaleoCrafter>
State->String is just toString, iirx :P
L275[15:27:03] <gigaherz> the official
vanilla way to deserialize blockstates is
"domain:name{var1:value1,var2:value2,...}"
L276[15:27:10] <barteks2x> but
String->State is less obvious
L277[15:27:14] <gigaherz> I mean the 1.13
command syntax
L278[15:27:27] <gigaherz> so given that
they have a command that parses blockstates... use that
format?
L279[15:27:29] <barteks2x> I need
String->State and State->String
L280[15:27:53] <PaleoCrafter> The setblock
command should do, shouldn't it?
L281[15:28:08] <barteks2x> and
state.toString produces output in compatible format?
L282[15:28:09] <gigaherz> does the 1.12
setblock command accept blockstate strings?
L283[15:28:19] <barteks2x> also is that
command there in 1.10?
L284[15:28:23] <gigaherz> nope
L285[15:28:25] <barteks2x> :(
L286[15:28:28] <barteks2x> I need it to
work in 1.10
L287[15:28:33] <barteks2x> and 1.11 and
1.12
L288[15:28:49] <gigaherz> write it
yourself
L289[15:28:58] <PaleoCrafter> You *choose*
to need it to work in 1.10 :P
L290[15:28:58] <gigaherz> it will still be
future-proof if it uses compatible syntax
L291[15:29:14] <barteks2x> does the
toString at least exist in 1.10 and work the same way?
L292[15:29:20] <quadraxis>
state->nbt->json
L293[15:32:49] ⇦
Quits: Darkhax (~darkhax@d205-206-157-117.abhsia.telus.net) (Ping
timeout: 183 seconds)
L294[15:38:29]
⇨ Joins: KGS
(~KGS@h-158-174-9-50.NA.cust.bahnhof.se)
L295[15:44:40] ⇦
Quits: Javaschreiber
(~Thunderbi@88-209-32-73.nga.highspeed-baumann.de) (Quit:
Javaschreiber)
L296[15:50:13]
⇨ Joins: Darkhax
(~darkhax@d205-206-157-117.abhsia.telus.net)
L297[16:13:45] ⇦
Quits: Baughn (~Baughn@2a01:4f8:172:3065::2) (Quit: ZNC 1.6.2+deb1
- http://znc.in)
L298[16:13:49] <LexMobile> Future proof
way? Not really.
L299[16:13:55] <LexMobile> 1.13 changes a
lot of names.
L300[16:14:01] <LexMobile> So anything you
write will break in it
L301[16:14:41] <gigaherz> I assumed he
meant the syntax, not that the actual names of things would be
available
L302[16:14:54] <gigaherz> if that's the
case, then yeah no way to make it future-proof
L303[16:19:01]
⇨ Joins: cjm721
(~cjm721@2601:647:4502:c72d:49a6:cb36:be2b:d4a9)
L304[16:21:13]
⇨ Joins: Hgrebnednav
(~Hgrebnedn@d8D872A6E.access.telenet.be)
L305[16:24:46] ⇦
Quits: KklyAq (~Umbraco@121-87-222-159f1.nar1.eonet.ne.jp) (Ping
timeout: 198 seconds)
L306[16:26:07] ⇦
Quits: Hgreb (~Hgrebnedn@d8D872A6E.access.telenet.be) (Ping
timeout: 383 seconds)
L307[16:35:29] ⇦
Quits: Blarghedy (Blarghedy@50.90.116.51) (Quit:
WOOPWOOPWOOPWOOPWOOPWOOPWOOPWOOPWOOPWOOPWOOPWOOP)
L308[16:40:56]
⇨ Joins: SuperCoder79 (webchat@71.59.23.150)
L309[16:43:37] ***
PaleoCrafter is now known as PaleOff
L310[16:45:21]
⇨ Joins: Baughn (~Baughn@madoka.brage.info)
L311[16:51:43]
⇨ Joins: Cornelia
(~Nel@c-75-71-231-133.hsd1.co.comcast.net)
L312[17:01:33] ⇦
Quits: Redfoxmoon (~Red@177.92-221-236.customer.lyse.net) (Read
error: Connection reset by peer)
L313[17:01:45]
⇨ Joins: Redfoxmoon
(~Red@177.92-221-236.customer.lyse.net)
L314[17:07:49]
⇨ Joins: AforAnonymous (bitch2k@212.108.51.183)
L315[17:09:10] ***
AforAnonymous is now known as lolinternet
L316[17:14:39] ⇦
Quits: SanAndreasP (~SanAndrea@mue-88-130-48-198.dsl.tropolys.de)
(Quit: Leaving)
L317[17:34:02] ⇦
Quits: Nedelosk
(~Nedelosk@ip-109-90-75-57.hsi11.unitymediagroup.de) (Read error:
Connection reset by peer)
L318[17:35:13]
⇨ Joins: Lunatrius` (~Lunatrius@77.38.21.155)
L319[17:35:31] ⇦
Quits: Umbraco (~Um4096@p30032-ipngnfx01osakakita.osaka.ocn.ne.jp)
(Quit: Leaving)
L320[17:36:49] ⇦
Quits: Lunatrius (~Lunatrius@77.38.21.155) (Ping timeout: 183
seconds)
L321[17:36:50] ***
Lunatrius` is now known as Lunatrius
L322[17:37:22] ⇦
Quits: Delaxarnyazer
(~Delaxarny@2a02:a44e:91ce:1:50a3:ad04:9869:2e0f) (Ping timeout:
198 seconds)
L323[17:37:23] ⇦
Quits: Redfoxmoon (~Red@177.92-221-236.customer.lyse.net) (Read
error: Connection reset by peer)
L324[17:37:39]
⇨ Joins: Redfoxmoon
(~Red@177.92-221-236.customer.lyse.net)
L325[17:38:34] ⇦
Quits: Hgrebnednav (~Hgrebnedn@d8D872A6E.access.telenet.be) (Ping
timeout: 198 seconds)
L326[17:52:20]
⇨ Joins: Doty1154
(~Doty1154@2601:648:8000:134f:b4f9:6930:4d16:e1da)
L327[17:59:02] ⇦
Quits: Doty1154 (~Doty1154@2601:648:8000:134f:b4f9:6930:4d16:e1da)
(Ping timeout: 183 seconds)
L328[18:00:30]
⇨ Joins: Doty1154
(~Doty1154@2601:648:8000:134f:f1b3:73b1:2862:b892)
L329[18:06:24] ⇦
Quits: UnRealDinner (uid60473@id-60473.tooting.irccloud.com) (Quit:
Connection closed for inactivity)
L330[18:06:29] ⇦
Quits: Raycoms (~Raycoms@2804:14d:baa0:9612:211:f974:13b9:be92)
(Quit: Leaving)
L331[18:36:46]
⇨ Joins: Backslash_
(~Backslash@ip-94-114-160-58.unity-media.net)
L332[18:38:49] ⇦
Quits: Backslash (~Backslash@ip-94-114-160-58.unity-media.net)
(Ping timeout: 183 seconds)
L333[18:40:37] ***
gigaherz is now known as ghz|afk
L334[18:51:14] ⇦
Quits: Redfoxmoon (~Red@177.92-221-236.customer.lyse.net) (Read
error: Connection reset by peer)
L335[18:51:30]
⇨ Joins: Redfoxmoon
(~Red@177.92-221-236.customer.lyse.net)
L336[19:12:38] ⇦
Quits: ben_mkiv (~ben_mkiv@p57972568.dip0.t-ipconnect.de) (Ping
timeout: 186 seconds)
L337[19:20:15] ⇦
Quits: RichardG (~richardg8@201.37.246.64) (Ping timeout: 200
seconds)
L338[19:25:21]
⇨ Joins: ben_mkiv
(~ben_mkiv@p57972407.dip0.t-ipconnect.de)
L339[19:59:43] ***
SatanicSanta is now known as Santa|afk
L340[20:06:59]
⇨ Joins: Delaxarnyazer
(~Delaxarny@ip56572345.direct-adsl.nl)
L341[20:22:05] ⇦
Quits: Redfoxmoon (~Red@177.92-221-236.customer.lyse.net) (Read
error: -0x1: UNKNOWN ERROR CODE (0001))
L342[20:22:21]
⇨ Joins: Redfoxmoon
(~Red@177.92-221-236.customer.lyse.net)
L343[20:24:53] ⇦
Quits: CorexTech
(~edmonds@99-108-142-68.lightspeed.sntcca.sbcglobal.net) (Read
error: Connection reset by peer)
L344[20:25:03]
⇨ Joins: CorexTech
(~edmonds@99-108-142-68.lightspeed.sntcca.sbcglobal.net)
L345[20:30:55]
⇨ Joins: RichardG (~richardg8@201.37.246.64)
L346[20:30:55]
MineBot sets mode: +v on RichardG
L347[20:31:15] ⇦
Quits: quadraxis
(~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
(Ping timeout: 207 seconds)
L348[21:07:45] ⇦
Quits: Redfoxmoon (~Red@177.92-221-236.customer.lyse.net) (Read
error: -0x1: UNKNOWN ERROR CODE (0001))
L349[21:08:03]
⇨ Joins: Redfoxmoon
(~Red@177.92-221-236.customer.lyse.net)
L350[21:11:02] ⇦
Quits: KGS (~KGS@h-158-174-9-50.NA.cust.bahnhof.se) (Ping timeout:
186 seconds)
L351[21:19:41]
⇨ Joins: Blarghedy (Blarghedy@50.90.116.51)
L352[21:27:18]
⇨ Joins: UnRealDinner
(uid60473@id-60473.tooting.irccloud.com)
L353[21:28:58] ⇦
Quits: ben_mkiv (~ben_mkiv@p57972407.dip0.t-ipconnect.de) (Ping
timeout: 198 seconds)
L354[22:21:26] ⇦
Quits: Lathanael|Away (~Lathanael@p54960D1F.dip0.t-ipconnect.de)
(Ping timeout: 186 seconds)
L355[22:23:05]
⇨ Joins: Umbraco
(~Um4096@p30032-ipngnfx01osakakita.osaka.ocn.ne.jp)
L356[22:27:34]
⇨ Joins: Lathanael|Away
(~Lathanael@p54960166.dip0.t-ipconnect.de)
L357[22:29:46]
⇨ Joins: ben_mkiv
(~ben_mkiv@p57972407.dip0.t-ipconnect.de)
L358[22:29:50]
⇨ Joins: McJty
(~jorrit@ptr-9197ufp67xmfpqej9it.18120a2.ip6.access.telenet.be)
L359[23:28:29] ⇦
Quits: SuperCoder79 (webchat@71.59.23.150) (Ping timeout: 180
seconds)
L360[23:30:29] ⇦
Quits: McJty
(~jorrit@ptr-9197ufp67xmfpqej9it.18120a2.ip6.access.telenet.be)
(Quit: Leaving)
L361[23:34:52] ⇦
Quits: Doty1154 (~Doty1154@2601:648:8000:134f:f1b3:73b1:2862:b892)
(Ping timeout: 183 seconds)
L362[23:37:13]
⇨ Joins: Doty1154
(~Doty1154@2601:648:8000:134f:c956:42f:9bd6:f902)
L363[23:38:20]
⇨ Joins: immibis
(~chatzilla@122-59-204-185.jetstream.xtra.co.nz)