OCLogs: 2017-12-21.log

Stuff goes here

L1[00:05:06] ⇦ Quits: cpup (~cpup@24-151-98-142.dhcp.nwtn.ct.charter.com) (Ping timeout: 383 seconds)

L2[00:18:58] ⇨ Joins: cpup (~cpup@24-151-98-142.dhcp.nwtn.ct.charter.com)

L3[00:26:17] ⇦ Quits: cpup (~cpup@24-151-98-142.dhcp.nwtn.ct.charter.com) (Ping timeout: 194 seconds)

L4[00:26:28] ⇨ Joins: cpup (~cpup@24-151-98-142.dhcp.nwtn.ct.charter.com)

L5[01:05:05] ⇦ Quits: Commoble (~Commoble@mnpl-04-3331.dsl.iowatelecom.net) (Quit: Leaving)

L6[01:21:12] ⇨ Joins: Ipsis (~Ipsis@82-69-71-184.dsl.in-addr.zen.co.uk)

L7[01:28:44] ⇦ Quits: covers1624 (~covers162@ppp122-232-6.static.internode.on.net) (Read error: -0x1: UNKNOWN ERROR CODE (0001))

L8[01:29:08] ⇦ Quits: airbreather (~airbreath@d149-67-99-43.nap.wideopenwest.com) (Read error: Connection reset by peer)

L9[01:29:30] ⇨ Joins: airbreather (~airbreath@d149-67-99-43.nap.wideopenwest.com)

L10[01:30:53] ⇨ Joins: covers1624 (~covers162@ppp122-232-6.static.internode.on.net)

L11[01:59:34] ⇦ Quits: Larry1123 (Larry1123@irc.larry1123.net) (Ping timeout: 198 seconds)

L12[02:00:03] <MCPBot_Reborn> [TEST CSV] Pushing snapshot_20171221 mappings to Forge Maven.

L13[02:00:07] <MCPBot_Reborn> [TEST CSV] Maven upload successful for mcp_snapshot-20171221-1.12.zip (mappings = "snapshot_20171221" in build.gradle).

L14[02:00:17] <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/

L15[02:16:23] ⇨ Joins: Larry1123 (Larry1123@irc.larry1123.net)

L16[02:29:45] ⇦ Quits: Doty1154 (~Doty1154@2601:648:8000:134f:8d3:9a8:d76e:8b94) (Quit: Leaving)

L17[02:29:54] ⇨ Joins: gigaherz|work (~gigaherz@84.89.63.25)

L18[02:37:24] ⇨ Joins: Hunterz (~hunterz@2001:af0:8000:1c01:6af7:28ff:fe37:5d6a)

L19[03:03:29] ⇨ Joins: ssblur (~Thunderbi@cpe-65-184-138-23.ec.res.rr.com)

L20[03:05:34] ⇦ Quits: Neal (~Neal@47.146.41.184) (Ping timeout: 198 seconds)

L21[03:45:19] ⇦ Quits: Hanii (~textual@2a00:23c4:484:d100:7cd1:6b79:b356:3324) (Quit: Textual IRC Client: www.textualapp.com)

L22[04:38:47] ⇨ Joins: malte0811 (~malte@185.134.128.197)

L23[04:42:54] ⇨ Joins: mallrat208 (~mallrat20@107.145.144.41)

L24[05:01:55] ⇨ Joins: Raycoms (~Raycoms@2804:14d:baa0:9612:211:f974:13b9:be92)

L25[05:16:57] ⇨ Joins: Nedelosk (~Nedelosk@ip-37-201-253-118.hsi13.unitymediagroup.de)

L26[05:30:46] ⇨ Joins: gigaherz_ (~gigaherz@84.89.63.25)

L27[05:32:22] ⇦ Quits: quadraxis (~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net) (Ping timeout: 186 seconds)

L28[05:33:33] ⇦ Quits: gigaherz|work (~gigaherz@84.89.63.25) (Ping timeout: 200 seconds)

L29[05:43:04] ⇦ Quits: gigaherz_ (~gigaherz@84.89.63.25) (Remote host closed the connection)

L30[05:43:28] ⇨ Joins: gigaherz|work (~gigaherz@84.89.63.25)

L31[05:48:51] ⇦ Quits: gigaherz|work (~gigaherz@84.89.63.25) (Remote host closed the connection)

L32[05:49:22] ⇨ Joins: gigaherz|work (~gigaherz@84.89.63.25)

L33[06:02:46] ⇦ Quits: Delaxarnyazer (~Delaxarny@ip56572345.direct-adsl.nl) (Ping timeout: 186 seconds)

L34[06:04:55] ⇨ Joins: Delaxarnyazer (~Delaxarny@2a02:a44e:91ce:1:50a3:ad04:9869:2e0f)

L35[06:10:02] ⇨ Joins: quadraxis (~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net)

L36[06:20:38] ⇨ Joins: KGS (~KGS@h-158-174-9-50.NA.cust.bahnhof.se)

L37[06:27:43] ⇨ Joins: Umbraco (~Umbraco@121-87-222-159f1.nar1.eonet.ne.jp)

L38[06:36:44] ⇦ Quits: gigaherz|work (~gigaherz@84.89.63.25) (Remote host closed the connection)

L39[07:03:48] ⇦ Quits: Raycoms (~Raycoms@2804:14d:baa0:9612:211:f974:13b9:be92) (Remote host closed the connection)

L40[07:09:24] ⇨ Joins: Javaschreiber (~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)

L41[07:31:59] ⇦ Quits: cjm721 (~cjm721@2601:647:4502:c72d:49a6:cb36:be2b:d4a9) (Read error: Connection reset by peer)

L42[07:40:22] ⇦ Quits: KGS (~KGS@h-158-174-9-50.NA.cust.bahnhof.se) (Ping timeout: 186 seconds)

L43[07:48:28] ⇨ Joins: Lepidora (~Lepidora@host86-137-175-78.range86-137.btcentralplus.com)

L44[07:48:32] ⇦ Quits: Lepidora (~Lepidora@host86-137-175-78.range86-137.btcentralplus.com) (Client Quit)

L45[07:52:36] ⇨ Joins: Lepidora (~Lepidora@host86-137-175-78.range86-137.btcentralplus.com)

L46[07:52:40] ⇦ Quits: Lepidora (~Lepidora@host86-137-175-78.range86-137.btcentralplus.com) (Client Quit)

L47[08:01:11] ⇦ Quits: quadraxis (~quadraxis@cpc77293-basf12-2-0-cust699.12-3.cable.virginm.net) (Ping timeout: 383 seconds)

L48[08:41:10] ⇦ Quits: Javaschreiber (~Thunderbi@88-209-32-73.nga.highspeed-baumann.de) (Quit: Javaschreiber)

L49[08:48:38] ⇨ Joins: MalkContent (~MalkConte@p4FDCD018.dip0.t-ipconnect.de)

L50[09:00:25] ⇨ Joins: Protected (~Join@at.discworld.eu)

L51[09:12:32] *** PaleOff is now known as PaleoCrafter

L52[09:21:01] ⇨ Joins: Searge|Work (~Searge@h-85-24-130-18.NA.cust.bahnhof.se)

L53[09:21:01] ⇨ Joins: Lynndissed (~Lynn@c-75-71-231-133.hsd1.co.comcast.net)

L54[09:21:01] ⇦ Quits: Hunterz (~hunterz@2001:af0:8000:1c01:6af7:28ff:fe37:5d6a) (Quit: Leaving.)

L55[09:21:08] ⇨ Joins: PitchBright_ (~PitchBrig@CPE00fc8d8a3ce3-CM00fc8d8a3ce0.cpe.net.cable.rogers.com)

L56[09:21:10] ⇦ Quits: blackgem (~blackgem@ip72-204-2-70.fv.ks.cox.net) (Ping timeout: 198 seconds)

L57[09:21:10] ⇦ Quits: romibi (~quassel@cable-static-7-174.rsnweb.ch) (Ping timeout: 198 seconds)

L58[09:21:18] ⇨ Joins: romibi (~quassel@cable-static-7-174.rsnweb.ch)

L59[09:21:46] ⇦ Quits: PitchBright (~PitchBrig@CPE00fc8d8a3ce3-CM00fc8d8a3ce0.cpe.net.cable.rogers.com) (Ping timeout: 198 seconds)

L60[09:21:46] ⇦ Quits: phroa (~phroa@173.254.236.155) (Ping timeout: 198 seconds)

L61[09:21:46] ⇦ Quits: maxanier (~maxanier@server2.maxgb.de) (Ping timeout: 198 seconds)

L62[09:21:46] ⇦ Quits: masa (~masa@86.60.225.191) (Ping timeout: 198 seconds)

L63[09:21:46] ⇦ Quits: progwml6 (~progwml6@104.168.20.187) (Ping timeout: 198 seconds)

L64[09:21:46] ⇦ Quits: SkySom (~SkySom@162.243.21.185) (Ping timeout: 198 seconds)

L65[09:21:46] *** PitchBright_ is now known as PitchBright

L66[09:21:52] ⇨ Joins: Lunatrius` (~Lunatrius@77.38.21.155)

L67[09:22:22] ⇦ Quits: auenf (~David@120.154.64.171) (Ping timeout: 198 seconds)

L68[09:22:22] ⇦ Quits: Kuraron (~DUX@HSI-KBW-46-223-0-70.hsi.kabel-badenwuerttemberg.de) (Ping timeout: 198 seconds)

L69[09:22:22] ⇦ Quits: Lynndis (~Lynn@c-75-71-231-133.hsd1.co.comcast.net) (Ping timeout: 198 seconds)

L70[09:22:22] ⇦ Quits: Searge|Office (~Searge@h-85-24-130-18.NA.cust.bahnhof.se) (Ping timeout: 198 seconds)

L71[09:22:22] ⇦ Quits: Lunatrius (~Lunatrius@77.38.21.155) (Ping timeout: 198 seconds)

L72[09:22:22] ⇦ Quits: rebecca (~rebecca@192.40.89.42) (Ping timeout: 198 seconds)

L73[09:22:22] ⇦ Quits: Luck (~Luck@unlucky.lucko.me) (Ping timeout: 198 seconds)

L74[09:22:22] ⇦ Quits: DemonWav (~DemonWav@69.197.179.106) (Ping timeout: 198 seconds)

L75[09:22:22] ⇦ Quits: sww1235 (~sww1235@ferrari.cs.colostate.edu) (Ping timeout: 198 seconds)

L76[09:22:22] ⇦ Quits: Marenthyu (~Marenthyu@marenthyu.de) (Ping timeout: 198 seconds)

L77[09:22:57] *** Lunatrius` is now known as Lunatrius

L78[09:24:36] ⇨ Joins: progwml6 (~progwml6@104.168.20.187)

L79[09:24:40] ⇨ Joins: SkySom (~SkySom@162.243.21.185)

L80[09:24:47] ⇨ Joins: DemonWav (~DemonWav@69.197.179.106)

L81[09:24:58] ⇨ Joins: sww1235 (~sww1235@ferrari.cs.colostate.edu)

L82[09:25:10] ⇨ Joins: phroa (~phroa@173.254.236.155)

L83[09:25:16] ⇨ Joins: rebecca (~rebecca@192.40.89.42)

L84[09:25:24] <Protected> Hello there. Is there any way to shrink the radius of always-loaded chunks around the spawn point?

L85[09:25:40] ⇨ Joins: Luck (~Luck@unlucky.lucko.me)

L86[09:25:42] ⇨ Joins: auenf (~David@120.154.64.171)

L87[09:26:17] ⇨ Joins: Kuraron (~DUX@HSI-KBW-46-223-0-70.hsi.kabel-badenwuerttemberg.de)

L88[09:29:21] ⇨ Joins: Mickelus (~Mickelus@94.234.187.247)

L89[09:29:33] ⇦ Quits: Mickelus (~Mickelus@94.234.187.247) (Remote host closed the connection)

L90[09:29:35] ⇨ Joins: Mickelus (~Mickelus@95.204.35.199)

L91[09:33:38] ⇨ Joins: Commoble (~Commoble@mnpl-04-3331.dsl.iowatelecom.net)

L92[09:33:38] ⇦ Quits: Mickelus (~Mickelus@95.204.35.199) (Read error: Connection reset by peer)

L93[09:43:08] <barteks2x> Protected, as a user or as modder?

L94[09:47:13] <Protected> As a modder

L95[09:47:34] <barteks2x> The only way is probably a coremod. Unless it's a custom dimension

L96[09:47:44] <Protected> It is not

L97[09:49:03] <barteks2x> a way without a coremod would be to replace the overworld WorldProvider

L98[09:49:28] <barteks2x> but that I'm sure will be incompatible with mod yunomakegoodmap

L99[09:50:13] <barteks2x> you can override canDropChunk to calculate spawn area differently then

L100[09:50:48] <barteks2x> that also won't affect the initially loaded chunks during "preparing spawn area". That part is hardcoded

L101[09:51:11] <Protected> What do you mean by spawn area, then?

L102[09:51:22] <barteks2x> the part that won't be unloaded

L103[09:51:27] <Protected> Ok, that's fine

L104[09:52:11] <barteks2x> you could also do DimensionType.setLoadSpawn(false) and then do what chunkloaders do

L105[09:52:40] <barteks2x> that I think would be the best approach

L106[09:52:54] <barteks2x> and why do you actually need to do that anyway?

L107[09:54:28] ⇨ Joins: Uristqwerty (~chatzilla@modemcable128.165-177-173.mc.videotron.ca)

L108[09:56:46] ⇨ Joins: Glitcher (webchat@host165-120-10-16.range165-120.btcentralplus.com)

L109[09:58:47] *** Lynndissed is now known as Lynndis

L110[10:06:08] ⇨ Joins: Lepidora (~Lepidora@188.29.165.46.threembb.co.uk)

L111[10:07:40] ⇨ Joins: Neal (~Neal@47.146.41.184)

L112[10:16:10] ⇦ Quits: Lepidora (~Lepidora@188.29.165.46.threembb.co.uk) (Quit: Lepidora)

L113[10:20:29] ⇦ Quits: Glitcher (webchat@host165-120-10-16.range165-120.btcentralplus.com) (Ping timeout: 180 seconds)

L114[10:24:53] ⇨ Joins: Raycoms (~Raycoms@2804:14d:baa0:9612:211:f974:13b9:be92)

L115[10:42:23] *** PaleoCrafter is now known as PaleOff

L116[10:43:28] <Raycoms> How do I get an blockState from an itemStack?

L117[10:45:14] <ghz|afk> you do not.

L118[10:45:25] <ghz|afk> I mean you can TRY

L119[10:45:37] <Raycoms> I actually know it is an ItemBLock

L120[10:46:20] <ghz|afk> the DEFAULT way to place a block is that the ItemBlock#onItemUse calls getMetadata(int) and passes the resulting number to getStateForPlacement

L121[10:46:31] <ghz|afk> but you can't ensure that an ItemBlock didn't customize onItemUSe

L122[10:48:30] <Commoble> i.e. Different items have different ways of setting the block's itemstack when placed; for example, wool blocks use the item's damage value, while log blocks set their orientation when placed

L123[10:48:46] <Commoble> *setting the block's blockstate

L124[10:49:16] <Raycoms> I don't need it for placement I need it to compare if it's the same leave or the same log, independend from the orientation

L125[10:49:20] <Raycoms> Or the same ore

L126[10:52:02] <Commoble> You could just compare the two blocks, that'll work for most things

L127[10:52:37] <Commoble> i.e. make sure the itemstack's item is an ItemBlock, then get the block from the ItemBlock and check if block == otherblock

L128[10:53:08] <Raycoms> but does that work for the leaves for example?

L129[10:53:16] <Raycoms> Leave_1 has oak, birch ....

L130[10:53:22] <Commoble> mm, lemme check

L131[10:53:24] <Raycoms> and oak != birch but the block is probably the same

L132[10:56:05] <ghz|afk> there's no direct way to test for equivalence in mc

L133[10:56:29] <ghz|afk> specially not between items and blocks

L134[10:56:43] <ghz|afk> so any solution, will only work for some cases and not for others

L135[10:57:06] <Commoble> You'd have to handle individual cases for each relevant block, essentially

L136[10:57:15] <ghz|afk> or set of blocks

L137[10:57:45] <ghz|afk> and probably separate cases for comparinb 2 items, 2 blocks and 1item+1block

L138[10:58:05] ⇦ Quits: Umbraco (~Umbraco@121-87-222-159f1.nar1.eonet.ne.jp) (Ping timeout: 194 seconds)

L139[10:59:50] <Protected> barteks2x: There are two issues I'm trying to improve

L140[11:00:04] <Commoble> an example: planks, leaves, and (I think) logs use one block with different metadata for the different wood types, while stairs, doors, fences, and fence gates have separate blocks for the different wood types

L141[11:00:43] <Protected> First, some of my server's users have lossy connections that crap out when dealing with intense network traffic, and minecraft is very sensitive to packet loss (read timeout errors)

L142[11:01:40] <Protected> Since those users complained the problem is worse around spawn, I was wondering if forcing the server to load those chunks anew if no one else is around would break down the databomb those players receive on connection into more manageable portions?

L143[11:01:45] <barteks2x> reducing the amount of chunks loaded serverside sin't going to fix that

L144[11:01:51] <Protected> Ok, good to know

L145[11:01:55] <Protected> Is there anything that will?

L146[11:02:02] <Protected> As long as you're informed on the subject

L147[11:02:14] <barteks2x> it most likely happens closer to spawn because there simply is more stuff there

L148[11:02:19] <Protected> No, it's a new server

L149[11:02:50] <barteks2x> hm... could actually be the seerver trying to send a ton of chunks all at once

L150[11:02:59] <barteks2x> it definitely does that when they are already loaded

L151[11:03:02] <Protected> Right

L152[11:03:03] <Commoble> Is it only happening when the players log in?

L153[11:03:13] <Protected> If they survive the login they're usually good to go

L154[11:03:21] <barteks2x> Can you verify that is also happens when 2 players are close to each other?

L155[11:03:24] <Protected> Of course, this is ultimately an issue with their ISP or router dropping packets

L156[11:03:39] <barteks2x> oh.. you say it's good if they survuve login?

L157[11:03:43] <barteks2x> then I know what is the issue

L158[11:03:47] <Protected> Usually that seems to be the case

L159[11:03:52] <Protected> They don't immediately disconnect on login

L160[11:03:57] <Protected> It can take up to... let's say 30 seconds?

L161[11:04:05] <barteks2x> I actually had to fix it in my cubic chunks mod

L162[11:04:39] <Protected> (I was going to say, being close to other players doesn't seem to disconnect these people)

L163[11:04:54] <barteks2x> basically, when the chunk is already loaded, the server will IMMEDIATELY send it without waiting. This means all $VIEW_DISTANCE chunks all at once being sent for spawnpoint\

L164[11:05:04] <Protected> Yes, that's what I figured

L165[11:05:12] <Protected> And our view distance is 15 :D

L166[11:05:16] <barteks2x> the correct fix is to make it not send them all at once

L167[11:05:23] <Protected> Is that possible?

L168[11:05:53] <Protected> I'm very new to forge

L169[11:05:56] <barteks2x> which involves modifying one of the most fragile classes in MC: PlayerChunkMap. Any error in it usually fails catastrophically, spamming the log but not crashing

L170[11:06:12] <Protected> Sounds like fun

L171[11:06:36] <barteks2x> I'm rewriting that class in cubic chunks. I debugged it many times. Sure is "fun"

L172[11:09:50] <Protected> The second issue I was trying to tackle has to do with mob and creature spawning

L173[11:10:21] <Protected> We have mob spawning inhibited on the surface, and there don't seem to be a lot of animals in the spawn chunks, but there are a ton of monsters underground

L174[11:10:48] <Protected> I was wondering if by not having surface "daily" spawning I was preventing mobs from essentially rotating, making room for animals to spawn

L175[11:11:07] <Protected> It's all conjecture, of course

L176[11:11:08] <barteks2x> if you notice PlayerChunkMap#getOrCreateEntry, it does this: if (!playerchunkmapentry.sendToPlayers()). PlayerChunkMapEntry#addPlayer also calls it. This will actually send the chunk packet immediately to the player. I'm not sure if it won't break things, but you may attempt to fix it by modifying PlayerChunkMap#addPlayer and PlayerChunkMap#getOrCreateEntry. The first one to just add it to pendingSendToPlayers, the

L177[11:11:08] <barteks2x> second one - replace that sendToPlayers call with reflectively accessing sentToPlayers field

L178[11:12:09] <barteks2x> Protected, animal spawning has never really worked ever since beta 1.8 and I was never able to figure out why exactly.

L179[11:12:17] <Protected> Oh, really?

L180[11:12:26] <Protected> The last time we played the latest version was 1.6

L181[11:12:35] <Protected> Wait, *beta* 1.8

L182[11:12:44] <Protected> Maybe I fixed it with a bukkit plugin last time, I don't recall

L183[11:12:58] <barteks2x> they spawn once on world generation, and very very rarely later

L184[11:13:12] <barteks2x> so rarely you may very well never see one spawn

L185[11:13:36] <barteks2x> again, looking at the code - I don't see a reason for it

L186[11:14:11] ⇦ Quits: Neal (~Neal@47.146.41.184) (Ping timeout: 200 seconds)

L187[11:41:20] <Raycoms> I have 2 blockStates and I want to compare them, but I want to ignore things like enumFacing or leaveDecay

L188[11:41:23] <barteks2x> is there a safe way to render a TileEntity before any world is created?

L189[11:41:33] <Commoble> why would you need to do that

L190[11:41:36] <barteks2x> GUI

L191[11:41:42] <barteks2x> world customization gui

L192[11:41:57] <barteks2x> I want the user to be able to select any blockstate from a list

L193[11:42:05] <Commoble> hmmmmmmm

L194[11:42:39] <barteks2x> tesr is the only thing with issues

L195[11:42:48] <barteks2x> TileEntityStructureRenderer crashes because there is no player

L196[11:43:34] <Commoble> you might have to do a lot of manual fudging

L197[11:44:31] <barteks2x> this should include modded TESR blocks..

L198[11:44:34] <Raycoms> I want to check if a leave is the same leave

L199[11:44:56] <Commoble> Raycoms: You'll need to compare the metadata

L200[11:45:16] <Commoble> like check if the tree type of one leaf block is the same as the other

L201[11:45:22] <barteks2x> you can also get a specific property

L202[11:45:28] <Commoble> yeah that

L203[11:45:48] <Corosus> state.getValue(comparable) == state2.getValue(comparable) should work

L204[11:45:54] <Raycoms> Yeah I know but a) Then I can't store them in a map and retrieve them nicely and b) Different mods implement different properties sometimes

L205[11:46:17] <Commoble> Right, you'll need to handle each block separately

L206[11:46:21] <Raycoms> Especially for leaves and trees

L207[11:46:23] <Corosus> id love a way to filter out certain properties then just do a comparison against anything that remains, but for now im just storing each comparable i need to compare

L208[11:47:43] <barteks2x> screw this, I'm not allowing tile entities.

L209[11:48:07] <barteks2x> if a mod has an ore that is a tile entity, it's doing it wrong anyway

L210[11:48:41] <Commoble> You really don't want a world made entirely out of chests anyway

L211[11:48:51] <Commoble> tileentities have way more overhead than regular blocks

L212[11:50:33] <barteks2x> I'm going to exclude all blocks with TESR from the list

L213[11:55:53] ⇦ Parts: malte0811 (~malte@185.134.128.197) ())

L214[12:02:21] <Raycoms> Oh I'd love to use getStateFromMeta

L215[12:02:21] <Raycoms> =D

L216[12:02:41] <Raycoms> that would filter all the blockState shit which isn't affecting the meta out of it

L217[12:05:44] ⇨ Joins: Brokkoli (~Brokkoli@p2E5B1E0E.dip0.t-ipconnect.de)

L218[12:09:50] <barteks2x> well, I do use that way. It's a hack but it works

L219[12:10:01] <barteks2x> *I do it that way

L220[12:10:46] <barteks2x> I use if (state != block.getStateFromMeta(block.getMetaFromState(state))) to check if a state has it's corresponding meta

L221[12:11:06] <Raycoms> Yeah, will see if our other devs will approve it that way =D

L222[12:11:12] ⇨ Joins: MonkeyTyrant (~MonkeyTyr@142.163.129.161)

L223[12:11:25] <Raycoms> Anyone is interested in contributing to the minecolonies mod? We have a few open tasks =D

L224[12:12:30] <barteks2x> I would be more interested in taking some devs for my mod than giving time to other mod, unfortunately

L225[12:12:59] <Raycoms> What is your mod? =D

L226[12:13:07] ⇦ Quits: MonkeyTyrant (~MonkeyTyr@142.163.129.161) (Client Quit)

L227[12:13:08] <barteks2x> cubic chunks

L228[12:21:00] ⇦ Quits: PitchBright (~PitchBrig@CPE00fc8d8a3ce3-CM00fc8d8a3ce0.cpe.net.cable.rogers.com) (Quit: PitchBright)

L229[12:23:36] ⇨ Joins: PitchBright (~PitchBrig@CPE00fc8d8a3ce3-CM00fc8d8a3ce0.cpe.net.cable.rogers.com)

L230[13:00:18] ⇨ Joins: maxanier (~maxanier@server2.maxgb.de)

L231[13:07:31] ⇨ Joins: Foghrye4 (~Foghrye4@94.25.229.227)

L232[13:12:43] <Foghrye4> Hi! I need help again. A question related to using OBJ models in entity renderers.

L233[13:13:12] <Foghrye4> Here I baked model: https://github.com/Foghrye4/Labyrinth/blob/MC_1.12/src/main/java/labyrinth/client/model/ObjModelBoxExtended.java#L31

L234[13:13:25] <Foghrye4> (And render it)

L235[13:13:45] <Foghrye4> Here is how it looks: https://imgur.com/5i1IyHV

L236[13:14:01] <Commoble> Is that what Enderman do to render their held blocks? You could try looking at that

L237[13:14:22] <Foghrye4> Will try.

L238[13:15:26] <Foghrye4> Nope, not my case.

L239[13:15:32] <Foghrye4> Here is how it looks in Blender: https://imgur.com/8aY6hjo

L240[13:15:52] <Commoble> that still doesn't look right

L241[13:16:03] <Foghrye4> Thats just for test.

L242[13:17:15] <Foghrye4> A problem is that instead of normal UV model render quads with constant UV, or UV difference between verticles really small.

L243[13:18:51] ⇨ Joins: McJty (~jorrit@ptr-9197ufq1155c4acnibz.18120a2.ip6.access.telenet.be)

L244[13:25:38] ⇨ Joins: Hanii (~textual@2a00:23c4:484:d100:7513:6fa5:fe48:8896)

L245[13:35:12] ⇨ Joins: Mickelus (~Mickelus@188.120.166.83)

L246[13:35:14] ⇦ Quits: Mickelus (~Mickelus@188.120.166.83) (Remote host closed the connection)

L247[13:35:22] ⇨ Joins: Mickelus (~Mickelus@188.120.166.83)

L248[14:00:36] <Foghrye4> A solution: When I bake quads, UVs rescaled to LOCATION_BLOCKS_TEXTURE. I should've bind it instead of regular texture and register it on TextureStitch event.

L249[14:04:32] ⇦ Quits: romibi (~quassel@cable-static-7-174.rsnweb.ch) (Quit: romibi)

L250[14:04:44] ⇨ Joins: romibi (~quassel@cable-static-7-174.rsnweb.ch)

L251[14:16:03] ⇨ Joins: KGS (~KGS@h-158-174-9-50.NA.cust.bahnhof.se)

L252[14:17:31] ⇦ Quits: Foghrye4 (~Foghrye4@94.25.229.227) (Quit: Leaving)

L253[14:20:52] ⇦ Quits: McJty (~jorrit@ptr-9197ufq1155c4acnibz.18120a2.ip6.access.telenet.be) (Quit: Leaving)

L254[14:22:17] ⇨ Joins: masa (~masa@86.60.225.191)

L255[14:24:21] *** Santa|afk is now known as SatanicSanta

L256[14:31:31] ⇨ Joins: moony (~moony@tx-76-4-60-239.dhcp.embarqhsd.net)

L257[14:32:42] ⇨ Joins: Lepidora (~Lepidora@188.29.164.173.threembb.co.uk)

L258[14:47:37] ⇦ Quits: Commoble (~Commoble@mnpl-04-3331.dsl.iowatelecom.net) (Quit: Leaving)

L259[14:50:20] ⇦ Quits: Mickelus (~Mickelus@188.120.166.83) (Quit: sleep)

L260[14:51:10] ⇦ Quits: moony (~moony@tx-76-4-60-239.dhcp.embarqhsd.net) (Ping timeout: 198 seconds)

L261[15:07:42] ⇦ Parts: Upthorn (~ogmar@108-85-88-44.lightspeed.frokca.sbcglobal.net) ())

L262[15:07:54] ⇨ Joins: Upthorn (~ogmar@108-85-88-44.lightspeed.frokca.sbcglobal.net)

L263[15:07:57] ⇨ Joins: Mickelus (~Mickelus@188.120.166.83)

L264[15:13:45] <barteks2x> a perfect TODO I found in my unit test code :D // TODO: make this test code easier to understand

L265[15:13:58] <Raycoms> =D

L266[15:14:29] <barteks2x> now trying to actually understand that code again...

L267[15:14:44] ⇦ Quits: Mickelus (~Mickelus@188.120.166.83) (Ping timeout: 383 seconds)

L268[15:16:45] <ghz|afk> XD

L269[15:17:07] <Raycoms> You could add "Really try it the next time"

L270[15:17:10] <Raycoms> and leave it there

L271[15:17:26] ⇦ Quits: Lepidora (~Lepidora@188.29.164.173.threembb.co.uk) (Quit: Lepidora)

L272[15:24:24] ⇦ Quits: Nedelosk (~Nedelosk@ip-37-201-253-118.hsi13.unitymediagroup.de) (Read error: Connection reset by peer)

L273[15:25:02] ⇨ Joins: Nedelosk (~Nedelosk@ip-37-201-253-118.hsi13.unitymediagroup.de)

L274[15:26:05] ⇦ Quits: Nedelosk (~Nedelosk@ip-37-201-253-118.hsi13.unitymediagroup.de) (Read error: Connection reset by peer)

L275[15:30:27] ⇦ Quits: rebecca (~rebecca@192.40.89.42) (Ping timeout: 207 seconds)

L276[15:34:31] ⇦ Quits: Ipsis (~Ipsis@82-69-71-184.dsl.in-addr.zen.co.uk) (Ping timeout: 200 seconds)

L277[15:43:41] ⇨ Joins: rebecca (~rebecca@82.102.20.167)

L278[15:45:42] ⇦ Quits: ssblur (~Thunderbi@cpe-65-184-138-23.ec.res.rr.com) (Quit: ssblur)

L279[16:06:38] ⇨ Joins: Umbraco (~Umbraco@121-87-222-159f1.nar1.eonet.ne.jp)

L280[16:13:19] ⇦ Quits: romibi (~quassel@cable-static-7-174.rsnweb.ch) (Quit: romibi)

L281[16:21:35] ⇨ Joins: romibi (~quassel@cable-static-7-174.rsnweb.ch)

L282[16:27:43] ⇦ Quits: Umbraco (~Umbraco@121-87-222-159f1.nar1.eonet.ne.jp) (Ping timeout: 383 seconds)

L283[16:53:44] ⇦ Quits: Uristqwerty (~chatzilla@modemcable128.165-177-173.mc.videotron.ca) (Quit: ChatZilla 0.9.93 [Firefox 56.0a1/20170801100311])

L284[16:54:41] ⇨ Joins: Mickelus (~Mickelus@188.120.166.83)

L285[16:54:44] ⇦ Quits: Mickelus (~Mickelus@188.120.166.83) (Remote host closed the connection)

L286[16:54:50] ⇨ Joins: Mickelus (~Mickelus@188.120.166.83)

L287[17:01:44] *** mikeprimm is now known as zz_mikeprimm

L288[17:07:08] *** zz_mikeprimm is now known as mikeprimm

L289[17:23:48] ⇦ Quits: Raycoms (~Raycoms@2804:14d:baa0:9612:211:f974:13b9:be92) (Quit: Leaving)

L290[17:31:07] ⇦ Quits: XDjackieXD (~XDjackieX@navi.chaosfield.at) (Ping timeout: 200 seconds)

L291[17:31:17] ⇨ Joins: XDjackieXD (~XDjackieX@navi.chaosfield.at)

L292[17:31:37] <Protected> How can I find out what func_71190_q is?

L293[17:33:02] <Ordinastie> !!gm func_71190_q

L294[17:33:03] <MCPBot_Reborn> === MC 1.12: net/minecraft/server/MinecraftServer.updateTimeLightAndEntities (MinecraftServer.D) UNLOCKED ===

L295[17:33:03] <MCPBot_Reborn> Name : D => func_71190_q => updateTimeLightAndEntities

L296[17:33:04] <MCPBot_Reborn> Descriptor : ()V

L297[17:33:05] <MCPBot_Reborn> Comment : None

L298[17:33:06] <MCPBot_Reborn> Last Change: 2012-08-05 00:27:05-04:00 (TehKittyCat)

L299[17:35:27] <Protected> Thanks

L300[18:01:33] ⇦ Quits: RichardG_ (~richardg8@201.37.246.64) (Ping timeout: 200 seconds)

L301[18:01:39] ⇨ Joins: RichardG (~richardg8@201.37.246.64)

L302[18:01:39] MineBot sets mode: +v on RichardG

L303[18:01:41] ⇦ Quits: auenf (~David@120.154.64.171) (Read error: Connection reset by peer)

L304[18:02:00] ⇨ Joins: auenfx8 (~David@120.154.64.171)

L305[18:05:36] ⇦ Quits: MalkContent (~MalkConte@p4FDCD018.dip0.t-ipconnect.de) (Quit: Leaving)

L306[18:17:08] ⇦ Quits: auenfx8 (~David@120.154.64.171) (Remote host closed the connection)

L307[18:17:41] ⇨ Joins: auenf (~David@120.154.64.171)

L308[18:49:02] ⇦ Quits: Mickelus (~Mickelus@188.120.166.83) (Quit: sleep)

L309[18:57:10] ⇦ Quits: TvL2386 (~tom@ip206-57-176-143.adsl2.static.versatel.nl) (Ping timeout: 186 seconds)

L310[18:57:26] ⇨ Joins: TvL2386 (~tom@ip206-57-176-143.adsl2.static.versatel.nl)

L311[19:05:17] ⇦ Quits: brandon3055 (~Brandon@pa49-199-66-134.pa.vic.optusnet.com.au) (Read error: Connection reset by peer)

L312[19:20:06] ⇨ Joins: brandon3055 (~Brandon@pa49-199-66-134.pa.vic.optusnet.com.au)

L313[19:32:28] *** SatanicSanta is now known as Santa|afk

L314[19:51:02] ⇦ Quits: KGS (~KGS@h-158-174-9-50.NA.cust.bahnhof.se) (Ping timeout: 186 seconds)

L315[20:12:47] ⇨ Joins: moony (~moony@tx-76-4-60-239.dhcp.embarqhsd.net)

L316[21:07:31] ⇨ Joins: c233 (~c233@164.40.195.151)

L317[21:09:17] ⇦ Quits: c233_ (~c233@164.40.203.255) (Ping timeout: 200 seconds)

L318[21:34:13] ⇦ Quits: moony (~moony@tx-76-4-60-239.dhcp.embarqhsd.net) (Ping timeout: 200 seconds)

L319[22:03:12] ⇨ Joins: McJty (~jorrit@ptr-9197ufpwl3aycyl33r5.18120a2.ip6.access.telenet.be)

L320[22:03:50] ⇦ Quits: Lathanael|Away (~Lathanael@p5496093A.dip0.t-ipconnect.de) (Ping timeout: 186 seconds)

L321[22:09:58] ⇨ Joins: Lathanael|Away (~Lathanael@p54960001.dip0.t-ipconnect.de)

L322[23:01:27] ⇦ Quits: Lathanael|Away (~Lathanael@p54960001.dip0.t-ipconnect.de) (Ping timeout: 186 seconds)

L323[23:03:10] ⇨ Joins: cjm721 (~cjm721@2601:647:4502:c72d:5c44:49de:67ce:e35e)

L324[23:07:34] ⇨ Joins: Lathanael|Away (~Lathanael@p54960346.dip0.t-ipconnect.de)

L325[23:24:57] ⇦ Quits: McJty (~jorrit@ptr-9197ufpwl3aycyl33r5.18120a2.ip6.access.telenet.be) (Quit: Leaving)

L326[23:28:02] ⇨ Joins: Commoble (~Commoble@mnpl-04-3331.dsl.iowatelecom.net)