<<Prev
Next>>
Scroll to Bottom
Stuff goes here
L1[00:45:44] ⇦
Quits: Doty1154 (Doty1154!~Doty1154@67.215.244.186) (Ping timeout:
182 seconds)
L2[00:46:22] ⇨
Joins: Doty1154
(Doty1154!~Doty1154@2601:648:8000:134f:a840:7792:fe16:f22c)
L3[00:56:59] ⇦
Quits: MikrySoft
(MikrySoft!~mikrysoft@89-71-101-248.dynamic.chello.pl) (Ping
timeout: 207 seconds)
L4[01:07:56] ⇨
Joins: caseif_
(caseif_!~caseif@c-73-128-6-239.hsd1.md.comcast.net)
L5[01:28:48] ⇦
Quits: caseif_ (caseif_!~caseif@c-73-128-6-239.hsd1.md.comcast.net)
(Ping timeout: 186 seconds)
L6[01:50:17] ⇦
Quits: Rokiyo (Rokiyo!~Rokiyo@101.167.173.217) (Ping timeout: 207
seconds)
L7[01:52:22] ⇦
Quits: Doty1154
(Doty1154!~Doty1154@2601:648:8000:134f:a840:7792:fe16:f22c) (Quit:
Leaving)
L8[02:00:04] <MCPBot_Reborn> [TEST CSV]
Pushing snapshot_20180209 mappings to Forge Maven.
L9[02:00:07] <MCPBot_Reborn> [TEST CSV]
Maven upload successful for mcp_snapshot-20180209-1.12.zip
(mappings = "snapshot_20180209" in build.gradle).
L10[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/
L11[02:55:33] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L12[02:55:38] ⇨
Joins: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net)
L13[03:23:59] ⇦
Quits: immibis
(immibis!~chatzilla@122-59-200-50.jetstream.xtra.co.nz) (Ping
timeout: 383 seconds)
L14[03:30:30] ⇨
Joins: quadraxis
(quadraxis!~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
L15[03:34:37] ⇨
Joins: ben_mkiv
(ben_mkiv!~ben_mkiv@p57972312.dip0.t-ipconnect.de)
L16[03:43:12] ⇨
Joins: Umbraco
(Umbraco!~Umbraco@121-87-222-159f1.nar1.eonet.ne.jp)
L17[03:44:54] ⇨
Joins: abab9579 (abab9579!~Abastro@175.117.182.109)
L18[03:49:36] ⇦
Quits: Abastro (Abastro!~Abastro@175.223.27.147) (Ping timeout: 383
seconds)
L19[04:07:04] ⇦
Quits: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L20[04:07:09] ⇨
Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L21[04:12:42] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L22[04:12:47] ⇨
Joins: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net)
L23[04:45:29] ⇦
Quits: auenfx8 (auenfx8!~David@139.168.57.55) (Read error:
Connection reset by peer)
L24[04:46:32] ⇨
Joins: auenfx8 (auenfx8!~David@139.168.57.55)
L25[05:16:55] ⇦
Quits: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L26[05:17:00] ⇨
Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L27[05:18:32] ⇨
Joins: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net)
L28[05:19:04] ⇦
Quits: jackmcbarn (jackmcbarn!jackmcbarn@gateway02.insomnia247.nl)
(Ping timeout: 195 seconds)
L29[05:20:48] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Ping
timeout: 186 seconds)
L30[05:35:11] ⇦
Quits: quadraxis
(quadraxis!~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
(Ping timeout: 207 seconds)
L31[05:48:25] ⇦
Quits: Hunterz
(Hunterz!~hunterz@2001:1528:107:0:6af7:28ff:fe37:5d6a) (Quit:
Leaving.)
L32[05:49:22] ⇨
Joins: quadraxis
(quadraxis!~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
L33[06:04:56] ⇦
Quits: ben_mkiv (ben_mkiv!~ben_mkiv@p57972312.dip0.t-ipconnect.de)
(Ping timeout: 383 seconds)
L34[06:13:36] ⇦
Quits: quadraxis
(quadraxis!~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
(Ping timeout: 186 seconds)
L35[06:42:26] ⇨
Joins: ben_mkiv
(ben_mkiv!~ben_mkiv@p57972312.dip0.t-ipconnect.de)
L36[06:44:36] ⇨
Joins: Unh0ly_Tigg
(Unh0ly_Tigg!~Unh0ly_Ti@c-24-21-196-226.hsd1.or.comcast.net)
L37[06:56:03] ⇦
Quits: slowpoke (slowpoke!sid38552@id-38552.ealing.irccloud.com)
()
L38[06:56:29] ⇨
Joins: slowpoke
(slowpoke!sid38552@id-38552.highgate.irccloud.com)
L39[06:59:45] ⇨
Joins: Raycoms
(Raycoms!~Raycoms@2804:14d:baa0:96af:7926:c992:f9b3:df17)
L40[07:06:35] ⇦
Quits: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L41[07:07:04] ⇨
Joins: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net)
L42[07:10:05] ⇦
Quits: Watchful1 (Watchful1!sid67384@id-67384.ealing.irccloud.com)
()
L43[07:10:24] <gigaherz> new snapshot is
out
L44[07:10:28] <gigaherz> includes the new
worldgen code
L45[07:10:55] ⇨
Joins: Watchful1
(Watchful1!sid67384@id-67384.highgate.irccloud.com)
L46[07:16:42] <Ivorius> More structure
additions
L47[07:16:44] <Ivorius> Meh :P
L48[07:17:20] <Ivorius> Though it's high
time for them for me it means less use case for my mod lol
L49[07:27:56] <gigaherz> yeah
L50[07:28:04] <gigaherz> "Furnace
recipe book is in! Data driven furnace recipes! Enjoy!"
L51[07:28:06] <gigaherz> nice
L52[07:29:51] ⇦
Quits: lp (lp!~lordpipe@66.109.211.167) (Quit: WeeChat
2.0.1)
L53[07:42:40] <ben_mkiv> "new worldgen
code" is that the new chunk system?
L54[07:44:00] <gigaherz> I don't know the
implementation details
L55[07:44:30] <gigaherz> only that it WILL
be faster (it is faster already but will be even faster in the
future when it's more stable)
L56[07:44:50] <gigaherz> and that they
apparently have been working on this new worldgen implementation
for years
L57[07:45:02] <ben_mkiv> sounds good, map
generation was allways bottleneck for multiplayer servers
L58[07:45:10] <ben_mkiv> loool for
years
L59[07:45:22] <ben_mkiv> sure that. if they
only work 1day of each year
L60[07:45:27] <Ivorius> I wonder what it's
about
L61[07:45:31] <Ivorius> What makes it
faster
L62[07:45:46] <Ivorius> ben worldgen code
can take a while
L63[07:45:52] <Ivorius> Maybe not years but
certainly months
L64[07:46:11] <gigaherz> writing worldgen
isn't hard per se
L65[07:46:12] <gigaherz> but
L66[07:46:15] <ben_mkiv> yea, but it
evolves because of new ideas, not because someone codes months on
it
L67[07:46:23] <gigaherz> writing a worldgen
implementation that works BETTER than the current one
L68[07:46:25] <gigaherz> that's not
easy.
L69[07:46:33] <gigaherz> I know, I tried.
:P
L70[07:46:40] <ben_mkiv> but many mods
did
L71[07:46:47] <gigaherz> I was coding a
sortof minecraft clone
L72[07:46:50] <ben_mkiv> not sure about
speed
L73[07:47:05] <gigaherz> and I had to
resort to multithreading
L74[07:47:12] <gigaherz> to even get close
to java minecraft's speed
L75[07:47:13] <gigaherz> using C#
L76[07:47:34] <gigaherz> yes, java
minecraft is sloooow compared with bedrock-based ones
L77[07:47:45] <gigaherz> but even so --
it's not easy to make it faster.
L78[07:53:13] ⇦
Quits: TamasHenning
(TamasHenning!uid154987@id-154987.ealing.irccloud.com)
()
L79[07:53:31] ⇨
Joins: TamasHenning
(TamasHenning!sid154987@id-154987.highgate.irccloud.com)
L80[07:56:58] <Raycoms> Is there a way to
make an: PropertyEnum<Boolean>
L81[07:57:55] <gigaherz> what
L82[07:57:59] <gigaherz> why would you want
that?
L83[07:58:02] <gigaherz> jnust use
PropertyBool
L84[07:58:36] <Raycoms> that was what I was
searching
L85[07:58:37] <Raycoms> =D
L86[08:05:37] <ben_mkiv> giga you may know
how to use a tool as fakeuser?
L87[08:05:52] <ben_mkiv> or how to use it
at all in first place, as i cant even get that working
L88[08:07:09] <ben_mkiv>
e.setHeldItem(EnumHand.MAIN_HAND, stack);
e.swingArm(EnumHand.MAIN_HAND);
L89[08:07:14] <ben_mkiv> didnt work for me
on a sheep
L90[08:07:31] <ben_mkiv> neither does
stack.getItem().onItemUse(foobar) do anything useful
L91[08:10:32] <Raycoms> Hmm, still too much
states for the meta, damnit, how does the nbt thing work if I want
to store the axis
L92[08:11:48] <ben_mkiv> ray, how do your
workers use tools? do they really use them or is it actually fake
use?
L93[08:13:50] <Raycoms> Fake use, we have
them swing the item and we edit the block =D
L94[08:22:42] ⇦
Quits: Umbraco (Umbraco!~Umbraco@121-87-222-159f1.nar1.eonet.ne.jp)
(Ping timeout: 383 seconds)
L95[08:24:02] <gigaherz> Raycoms: nbt is
nbt... just store it.
L96[08:24:45] <gigaherz> I wrote myself
some helpers in my item class
L98[08:25:09] ⇦
Quits: Shawn|i7-Q720M
(Shawn|i7-Q720M!~shawn156@c-76-25-73-212.hsd1.co.comcast.net) (Read
error: Connection reset by peer)
L99[08:26:07] <gigaherz> or
L101[08:26:25] <gigaherz> the idea for me
is that I was able to write like
L102[08:26:57] <gigaherz>
MyMod.wand.getStack(gemstone, quality) or similar
L103[08:28:02] <Arcan> so basically NBT
helpers?
L104[08:28:19] <gigaherz> yup.
L105[08:28:31] <Raycoms> The problem I
have is that I have a block with 10 variants and I want it to
behave like a log
L106[08:28:37] <Raycoms> and I don't want
a tileEntity
L107[08:28:38] <Raycoms> =D
L108[08:28:41] <gigaherz> well
L109[08:28:45] <gigaherz> sucks to be you,
then
L110[08:28:51] <gigaherz> there's no
"nbt" in a block
L111[08:28:59] <Raycoms> Yeah i thought
that
L112[08:29:02] <gigaherz> either split it
up into more than one registry name
L113[08:29:05] <Raycoms> someone told me
there is, so I wanted to double check
L114[08:29:16] <gigaherz> or use a
non-ticking tileentity
L115[08:29:44] <Raycoms> I probably wait
for 1.13 then =P
L116[08:29:49] <gigaherz> why?
L117[08:29:50] <ben_mkiv> so how does
stuff figure out their variants? do they get mapped from NBT when
placed?
L118[08:29:54] <gigaherz> it won't change
anything for you
L119[08:30:09] <ben_mkiv> because they
have NBT as stacks
L120[08:30:24] <gigaherz> 1.13 removes
metadata, meaning it will be even more necessary to use different
registry names, or tileentities
L121[08:30:33] <gigaherz> ben_mkiv:
yes
L122[08:30:46] <gigaherz>
getStateForPlacement, which gives you the itemstack
L123[08:30:54] <Raycoms> Ahh I thought
1.13 gives another approach to solve this, so in 1.13 we basically
have to move all of that over to registry names or
tileEntities?
L124[08:31:00] <gigaherz> yes.
L125[08:31:05] <Raycoms> Darn it
L126[08:31:17] <gigaherz> actually not
really
L127[08:31:21] <gigaherz> you can have
many blockstates
L128[08:31:36] <gigaherz> and the chunk
stores the blockstate ID not the block id
L129[08:31:39] <gigaherz> but
L130[08:31:51] <gigaherz> vanilla itself
is moving away from subblocks and subitems
L131[08:31:58] <gigaherz> so instead of
minecraft:dye
L132[08:32:04] <gigaherz> there will be
separate registry names
L133[08:32:15] <gigaherz> for
minecraft:lapis, minecraft:orange_dye, etc
L134[08:32:19] <ben_mkiv> forgot about
that when making my recipes -.-
L135[08:32:25] <gigaherz> this means that
in 1.13,
L136[08:32:40] <gigaherz> having
mymod:genericblock{variant=subblock1} will be bad practice
L137[08:32:42] <ben_mkiv> tons of recipes
need updates xD
L138[08:32:46] <gigaherz> even if it will
work just fine
L139[08:33:24] <gigaherz> instead, you
should consider something like
L140[08:33:34] <gigaherz>
mymod:subblock1{other values}
L141[08:33:41] <ben_mkiv> i mean, it was
bad practice before, too. wasnt it?
L142[08:33:48] <gigaherz> it was
necessary
L143[08:33:55] <ben_mkiv> was nbt allways
a thing? or did that whole thing evolve before nbt?
L144[08:33:57] <gigaherz> due to having
only 4096 block IDs
L145[08:34:03] <ben_mkiv> ah, right
L146[08:34:07] <gigaherz> note also
L147[08:34:12] <gigaherz> 4096 block IDs
is a forge thing
L148[08:34:13] <Raycoms> Hmm, but that
also means I'll need one blockState implementation each state, so
the assets are going to be huge
L149[08:34:20] <ben_mkiv> the limit is
already removed or will be with 1.13?
L150[08:34:21] <gigaherz> vanilla only has
255 block IDs
L151[08:34:38] <gigaherz> and before 1.5
or so, those IDs were *shared* with items
L152[08:34:54] <gigaherz> (or maybe that
was during the beta, can't remember)
L153[08:35:12] <gigaherz> Raycoms: if you
only have 10 states, it won't be huge ;P
L154[08:35:31] <Raycoms> I have 8 blocks *
10 states =D
L155[08:35:40] <Raycoms> + a few other
blocks we add
L156[08:35:44] <Raycoms> we get easily
over 100 states
L158[08:36:36] <gigaherz> and that's using
the "lightweight" design
L159[08:36:41] <gigaherz> at one point I
wanted a more flexible design
L160[08:36:46] <gigaherz> but it had over
a million states per variant
L161[08:38:32] <Raycoms> But currently we
can get those in a few files
L162[08:38:37] <Raycoms> in 1.13 we need
an own file for each
L163[08:38:47] <Raycoms> which will blow
things up a bit and make it more difficult to organize it
L164[08:39:05] <gigaherz> uh, why?
L165[08:39:14] <gigaherz> it's not like
you havve to have one registry name for each combination
L166[08:39:17] <gigaherz> the idea is
like
L167[08:39:34] <gigaherz> if you have a
tool
L168[08:39:42] <gigaherz> that has iron
level, gold level, diamond level
L169[08:39:58] <gigaherz> don't use
mymod:mytool{level=gold}
L170[08:40:02] <Raycoms> I understood it
like I need one registry name each or a tileEntity.
L171[08:40:05] <gigaherz> use
mymod:gold_mytool
L172[08:40:10] <gigaherz> but
L173[08:40:19] <gigaherz>
mymod:mylog1{direction=X}
L174[08:40:22] <gigaherz> that's ok!
L175[08:40:59] <ben_mkiv> because its the
same item
L176[08:41:06] <gigaherz> yep
L177[08:41:41] <gigaherz> so
L178[08:42:00] <gigaherz> if you have a
number of new log types
L179[08:42:09] <gigaherz> give each log
type its own name
L180[08:42:14] <gigaherz> but don't give
each DIRECTION its own name
L181[08:42:18] <gigaherz> that's what
blockstates are for
L182[08:42:39] <ben_mkiv> yea, i've used
it for my interfaces, which are all named like
"mod:interface_redstone",
"mod:interface_energy"
L183[08:42:45] ⇦
Quits: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L184[08:42:47]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L185[08:42:54] <gigaherz> you have a crop,
make it yourcrop{stage=1}
L186[08:42:59] <gigaherz> not
yourcrop_stage_1
L187[08:43:11] <ben_mkiv> yea,
gotcha
L188[08:43:13] <Raycoms> okay got it, will
adapt that later, players will hate me, have to rebuild those
blocks again xD
L189[08:43:25] <ben_mkiv> you got any
experience on using tools out of player context?
L190[08:43:29] <gigaherz> of course you
can ignore my advice
L191[08:43:36] <gigaherz> and use
blockstates like now
L192[08:43:45] <gigaherz> if it's going to
make porting too annoying
L193[08:43:49] <Arcan> is 16*16*128
falling sand entities too many
L194[08:43:51] <gigaherz> it just won't be
best practice :P
L195[08:43:57] <gigaherz> Arcan:
definitely.
L196[08:44:01] <Arcan> um
L197[08:44:03] <Arcan> mistakes were
made
L198[08:44:24] <gigaherz> 128 falling sand
entities are already a lot
L199[08:44:30] <gigaherz> 16*128 would
already be too many
L200[08:44:36] <gigaherz> 16*16 also
L201[08:44:43] <gigaherz> let alone
16*16*128 :P
L202[08:45:28] <Arcan> i may have /fill
the max area with sand and accidentally overwrote the floor
L203[08:45:37] <Arcan> i also didn't
expect it to give a block update
L204[08:45:38] <gigaherz> XD
L205[08:47:33]
⇨ Joins: quadraxis
(quadraxis!~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
L206[09:02:19] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L207[09:02:30]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L208[09:16:56]
⇨ Joins: Brokkoli
(Brokkoli!~Brokkoli@p2E5B1E0E.dip0.t-ipconnect.de)
L209[09:36:52] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L210[09:37:05]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L211[09:51:30]
⇨ Joins: Nedelosk
(Nedelosk!~Nedelosk@ip-109-90-121-64.hsi11.unitymediagroup.de)
L212[09:53:53] ⇦
Quits: quadraxis
(quadraxis!~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
(Ping timeout: 207 seconds)
L213[10:01:40] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L214[10:01:59]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L215[10:22:29]
⇨ Joins: quadraxis
(quadraxis!~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
L216[10:25:40] ⇦
Quits: Spottedleaf
(Spottedleaf!~Spottedle@node-1w7jr9qqos9fzyq9p278r5i3x.ipv6.telus.net)
(Killed (NickServ (GHOST command used by
Spottedleaf_!~Spottedle@d75-155-207-106.bchsia.telus.net)))
L217[10:25:46]
⇨ Joins: Spottedleaf
(Spottedleaf!~Spottedle@d75-155-207-106.bchsia.telus.net)
L219[10:28:52] <ben_mkiv> so actually it
swings the weapon but doesnt attack
L220[10:29:10] <ben_mkiv> so i guess thats
handled somewhere out of the swing stuff?
L221[10:47:30] <ben_mkiv>
Item.hitEntity(...);
L222[11:09:04]
⇨ Joins: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net)
L223[11:10:48] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Ping
timeout: 186 seconds)
L224[11:12:19]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L225[11:14:00] ⇦
Quits: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net) (Ping
timeout: 186 seconds)
L226[11:15:57]
⇨ Joins: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net)
L227[11:16:04] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L228[11:31:55] <Raycoms> There is a field
I set each time on readFromNbt for an entity, but for some reason
it appears to cause NPE crashes in some cases
L229[11:32:06] <Raycoms> I kill the entity
in readFromNBT if I detect I can't set it to nonNull
L230[12:04:00] <ben_mkiv> does it have a
nbt in first place?
L231[12:24:02] ⇦
Quits: Raycoms
(Raycoms!~Raycoms@2804:14d:baa0:96af:7926:c992:f9b3:df17) (Remote
host closed the connection)
L232[12:27:05]
⇨ Joins: McJty
(McJty!~jorrit@ptr-9197ufq2w80dqd4ewgc.18120a2.ip6.access.telenet.be)
L233[12:35:33] ***
Santa|afk is now known as SatanicSanta
L234[12:38:54]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L235[12:40:48] ⇦
Quits: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net) (Ping
timeout: 186 seconds)
L236[13:19:09] ⇦
Quits: McJty
(McJty!~jorrit@ptr-9197ufq2w80dqd4ewgc.18120a2.ip6.access.telenet.be)
(Quit: Leaving)
L237[13:26:22] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L238[13:26:46]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L239[13:41:51] <ben_mkiv> does anyone know
how minecraft calculates the swingtime to mine a block?
L240[13:41:55] <ben_mkiv> is it just based
on hardness?
L241[13:46:05] <Arcan> ben_mkiv: "The
base time in seconds is the block's hardness multiplied by 1.5 if
the player can harvest the block with the current tool, or
multiplied by 5 if the player cannot. "
L242[13:46:08] <Arcan> - the MC wiki
L244[13:46:23] <ben_mkiv> thanks
L245[13:46:51] <ben_mkiv> just reading
this, didnt expect it to hold such technical stuff :)
L246[14:01:41]
⇨ Joins: Ipsis
(Ipsis!~Ipsis@82-69-71-184.dsl.in-addr.zen.co.uk)
L247[14:04:50] ⇦
Quits: justJanne (justJanne!~justJanne@2001:bc8:33e7:200::1) (Quit:
So, if you care to find me, look to the western sky. As someone
told me lately, everyone deserves a chance to fly.)
L248[14:06:42] <ben_mkiv> isnt there any
method which calculates that for a specific block?
L249[14:06:50]
⇨ Joins: justJanne
(justJanne!~justJanne@lithium.kuschku.de)
L250[14:07:01] <ben_mkiv>
stack.getDestroySpeed(blockState) seems to ignore enchants
L251[14:14:08] ⇦
Quits: srs_bsns (srs_bsns!blk@107.190.101.30) (Quit: Ping
timeout)
L252[14:15:29] <ben_mkiv> well. looks like
theres a helper... which is bound to use with players -.-
L253[14:16:56]
⇨ Joins: srs_bsns (srs_bsns!blk@107.190.101.30)
L254[14:18:01] <gigaherz> !mh
getMapColor
L255[14:18:14] <gigaherz> !more
L256[14:18:42] <gigaherz> that was
disappointing... apparently I'm looking for getColorValue instead
XD
L257[14:18:56] <gigaherz> (the bot didn't
provide the answer though)
L259[14:22:03] <gigaherz> well I was using
enumdye.getMapColor().colorValue
L260[14:22:13] <gigaherz> it's now just
.getColorValue without the intermediate step
L261[14:22:13] <gigaherz> :P
L262[14:32:26] ⇦
Quits: abab9579 (abab9579!~Abastro@175.117.182.109) (Ping timeout:
383 seconds)
L263[14:32:31] ⇦
Quits: RichardG (RichardG!~richardg8@201.37.50.6) (Read error:
Connection reset by peer)
L264[14:34:34]
⇨ Joins: RichardG
(RichardG!~richardg8@201.37.50.6)
L265[14:34:34]
MineBot sets mode: +v on RichardG
L266[15:23:40] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L267[15:23:53]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L268[15:39:42]
⇨ Joins: moony
(moony!~moony@tx-76-4-58-88.dhcp.embarqhsd.net)
L269[15:41:37]
⇨ Joins: Raycoms
(Raycoms!~Raycoms@2804:14d:baa0:96af:7926:c992:f9b3:df17)
L270[15:45:53] <ben_mkiv> why is raytrace
annotated clientside only?
L271[15:48:28] <gigaherz> because when
mojang prepares their code for release
L272[15:48:35] <gigaherz> they optimize
the jar to reduce the filesize
L273[15:48:41] <gigaherz> which includes
removing all unused methods
L274[15:48:50] <gigaherz> since client and
dedicated server are different jars
L275[15:48:58] <gigaherz> there's methods
that end up existing only on one or the other
L276[15:49:02] <ben_mkiv> ok, thanks
L277[15:49:06] <gigaherz> when forge
merges things back
L278[15:49:17] <gigaherz> it will put
@SideOnly on the methods that didn't exist in both
L279[15:51:43] ⇦
Quits: Ipsis (Ipsis!~Ipsis@82-69-71-184.dsl.in-addr.zen.co.uk)
(Ping timeout: 383 seconds)
L280[15:52:05]
⇨ Joins: Noppes
(Noppes!~Noppes@ip56530f2e.direct-adsl.nl)
L281[16:17:18]
⇨ Joins: immibis
(immibis!~chatzilla@122-59-200-50.jetstream.xtra.co.nz)
L282[16:44:28] ⇦
Quits: auenfx8 (auenfx8!~David@139.168.57.55) (Read error:
Connection reset by peer)
L283[16:44:51]
⇨ Joins: auenf (auenf!~David@139.168.57.55)
L284[16:45:11]
⇨ Joins: lp (lp!~lordpipe@66.109.211.167)
L285[16:46:24] ⇦
Quits: auenf (auenf!~David@139.168.57.55) (Remote host closed the
connection)
L286[16:46:25] ***
SuperCoder79 is now known as CopyPasteGod
L287[16:48:57]
⇨ Joins: auenf (auenf!~David@139.168.57.55)
L288[16:51:26] ***
CopyPasteGod is now known as SuperCoder79
L289[16:52:15] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L290[16:52:40]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L291[16:56:58]
⇨ Joins: UnRealDinner
(UnRealDinner!uid60473@id-60473.tooting.irccloud.com)
L292[17:03:41] ⇦
Quits: HassanS6000
(HassanS6000!sid159234@id-159234.tooting.irccloud.com)
()
L293[17:03:56]
⇨ Joins: HassanS6000
(HassanS6000!sid159234@id-159234.ealing.irccloud.com)
L294[17:07:44] ⇦
Quits: Noppes (Noppes!~Noppes@ip56530f2e.direct-adsl.nl) (Read
error: Connection reset by peer)
L295[17:26:55]
⇨ Joins: Umbraco
(Umbraco!~Umbraco@121-87-222-159f1.nar1.eonet.ne.jp)
L296[17:31:52] ***
SatanicSanta is now known as Santa|afk
L297[17:33:30] ⇦
Quits: UnRealDinner
(UnRealDinner!uid60473@id-60473.tooting.irccloud.com)
()
L298[17:33:42]
⇨ Joins: UnRealDinner
(UnRealDinner!uid60473@id-60473.ealing.irccloud.com)
L299[17:47:18] ⇦
Quits: Dark (Dark!~MrDark@2607:fcc8:d48b:eb00:c06d:8d23:3404:e694)
(Read error: Connection reset by peer)
L300[17:48:58]
⇨ Joins: Dark
(Dark!~MrDark@2607:fcc8:d48b:eb00:1d05:d73e:7e27:2265)
L301[18:16:11] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L302[18:16:31]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L303[18:18:00] ⇦
Quits: Raycoms
(Raycoms!~Raycoms@2804:14d:baa0:96af:7926:c992:f9b3:df17) (Quit:
Leaving)
L304[18:52:24] ⇦
Quits: Dark (Dark!~MrDark@2607:fcc8:d48b:eb00:1d05:d73e:7e27:2265)
(Ping timeout: 186 seconds)
L305[19:08:26] ⇦
Quits: ben_mkiv (ben_mkiv!~ben_mkiv@p57972312.dip0.t-ipconnect.de)
(Ping timeout: 383 seconds)
L306[19:37:33]
⇨ Joins: zxc (zxc!blk@107.190.101.30)
L307[19:37:33] ⇦
Quits: srs_bsns (srs_bsns!blk@107.190.101.30) (Killed (NickServ
(GHOST command used by zxc)))
L308[19:41:26] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L309[19:41:32]
⇨ Joins: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net)
L310[19:43:20] ⇦
Quits: RichardG (RichardG!~richardg8@201.37.50.6) (Read error:
Connection reset by peer)
L311[19:45:54]
⇨ Joins: RichardG
(RichardG!~richardg8@201.37.50.6)
L312[19:45:54]
MineBot sets mode: +v on RichardG
L313[20:29:45] ⇦
Quits: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L314[20:47:21]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L315[20:47:47] ⇦
Quits: quadraxis
(quadraxis!~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)
(Ping timeout: 207 seconds)
L316[20:57:02] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L317[20:57:40]
⇨ Joins: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net)
L318[21:08:38] ⇦
Quits: moony (moony!~moony@tx-76-4-58-88.dhcp.embarqhsd.net)
(Remote host closed the connection)
L319[21:17:49] ⇦
Quits: Nedelosk
(Nedelosk!~Nedelosk@ip-109-90-121-64.hsi11.unitymediagroup.de)
(Read error: Connection reset by peer)
L320[21:21:52]
⇨ Joins: Abastro
(Abastro!~Abastro@211.246.69.222)
L321[22:15:56] ⇦
Quits: Unh0ly_Tigg
(Unh0ly_Tigg!~Unh0ly_Ti@c-24-21-196-226.hsd1.or.comcast.net) (Quit:
Leaving)
L322[22:17:29]
⇨ Joins: McJty
(McJty!~jorrit@ptr-9197ufoxgnqm4end6f7.18120a2.ip6.access.telenet.be)
L323[22:46:45] ⇦
Quits: covers1624
(covers1624!~covers162@ppp122-232-6.static.internode.on.net) (Read
error: Connection reset by peer)
L324[22:46:50]
⇨ Joins: covers1624_
(covers1624_!~covers162@ppp122-232-6.static.internode.on.net)
L325[22:51:12] ⇦
Quits: Lathanael|Away
(Lathanael|Away!~Lathanael@p54960808.dip0.t-ipconnect.de) (Ping
timeout: 186 seconds)
L326[22:52:59]
⇨ Joins: Lathanael|Away
(Lathanael|Away!~Lathanael@p549603D7.dip0.t-ipconnect.de)
L327[23:04:37]
⇨ Joins: abab9579
(abab9579!~Abastro@218.48.215.92)
L328[23:09:36] ⇦
Quits: Abastro (Abastro!~Abastro@211.246.69.222) (Ping timeout: 383
seconds)
L329[23:31:18] ⇦
Quits: Brokkoli (Brokkoli!~Brokkoli@p2E5B1E0E.dip0.t-ipconnect.de)
(Remote host closed the connection)
L330[23:36:48] ⇦
Quits: Neal (Neal!~Neal@47.146.41.184) (Ping timeout: 186
seconds)
L331[23:42:24] ⇦
Quits: rebecca (rebecca!~rebecca@60-241-180-77.static.tpgi.com.au)
(Ping timeout: 186 seconds)
L332[23:43:12]
⇨ Joins: rebecca
(rebecca!~rebecca@60-241-180-77.static.tpgi.com.au)