<<Prev
Next>>
Scroll to Bottom
Stuff goes here
L1[00:42:39] ⇦
Quits: PitchBright
(PitchBright!~PitchBrig@cpef81d0f9c5943-cmf81d0f9c5940.cpe.net.cable.rogers.com)
(Quit: brb)
L2[00:42:53] ⇨
Joins: PitchBright
(PitchBright!~PitchBrig@CPEf81d0f9c5943-CMf81d0f9c5940.cpe.net.cable.rogers.com)
L3[01:26:33] ⇨
Joins: Noppes
(Noppes!~Noppes@ip56530f2e.direct-adsl.nl)
L4[02:00:03] <MCPBot_Reborn> [TEST CSV]
Pushing snapshot_20180617 mappings to Forge Maven.
L5[02:00:07] <MCPBot_Reborn> [TEST CSV]
Maven upload successful for mcp_snapshot-20180617-1.12.zip
(mappings = "snapshot_20180617" in build.gradle).
L6[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/
L7[03:12:48] ⇨
Joins: Ipsis
(Ipsis!~Ipsis@82-69-71-184.dsl.in-addr.zen.co.uk)
L8[03:18:33] ⇨
Joins: Nedelosk
(Nedelosk!~Nedelosk@ip-109-91-130-36.hsi12.unitymediagroup.de)
L9[03:55:00] <TechnicianLP> i think the
bridge is broken again?
L10[04:03:40] ⇦
Quits: Searge (Searge!~Searge@c83-251-224-78.bredband.comhem.se)
(Read error: Connection reset by peer)
L11[04:04:02] ⇨
Joins: Searge
(Searge!~Searge@c83-251-224-78.bredband.comhem.se)
L12[04:22:57] ⇨
Joins: moony
(moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net)
L13[04:59:04] ⇦
Quits: Yamakaja (Yamakaja!~yamakaja@vps.pub.yamakaja.me) (Remote
host closed the connection)
L14[05:02:28] ⇨
Joins: Yamakaja
(Yamakaja!~yamakaja@vps.pub.yamakaja.me)
L15[05:38:08] ⇨
Joins: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:bde7:63ab:9596:7cff)
L16[05:42:25] ⇦
Quits: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:bde7:63ab:9596:7cff) (Client
Quit)
L17[06:23:28] ⇨
Joins: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
L18[06:26:35] ⇦
Quits: immibis
(immibis!~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) (Ping
timeout: 202 seconds)
L19[07:07:40] ⇨
Joins: Brokkoli
(Brokkoli!~Brokkoli@p5B23C437.dip0.t-ipconnect.de)
L20[07:27:13] ⇨
Joins: ollieread
(ollieread!~ollieread@exia.ollieread.com)
L21[07:29:17] ⇦
Quits: IdleGandalf
(IdleGandalf!~IdleGanda@anquietas.harting.hosting) (Quit:
Leaving)
L22[07:29:43] ⇨
Joins: IdleGandalf
(IdleGandalf!~IdleGanda@anquietas.harting.hosting)
L23[08:00:10] <TechnicianLP> .
L24[08:06:04] ⇨
Joins: ForgeDiscord
(ForgeDiscord!~ForgeDisc@cerberus.minecraftforge.net)
L25[08:06:04]
MineBot sets mode: +v on ForgeDiscord
L26[08:06:34] ⇨
Joins: CryptoSiD (CryptoSiD!SiD@Beast.DonSiD.net)
L28[08:07:02] <ForgeDiscord> <cpw>
poke
L29[08:07:10] <cpw> ok. working now
:D
L30[08:07:43] <ForgeDiscord>
<TechnicianLP> thanks
L31[08:08:21] <CryptoSiD> Hi there, I tried
finding the setting to let non-registered user login to my forge
server but i can't find it. I have a legit copy of minecraft.
Anyone would care sharing the setting (variable to set)?
L32[08:09:30] <TechnicianLP>
server.properties
L33[08:09:32] <TechnicianLP> strings -a -f
-e s ./Assembly* | grep alp
L34[08:09:43] <TechnicianLP> almost
L35[08:11:37] <CryptoSiD> Ok got it, I only
have to set onlinemode to false.
L36[08:14:23] ⇦
Quits: CryptoSiD (CryptoSiD!SiD@Beast.DonSiD.net) ()
L37[08:17:43] ⇦
Quits: progwml6 (progwml6!~progwml6@104.168.20.187) (Ping timeout:
198 seconds)
L38[08:18:47] ⇨
Joins: progwml6 (progwml6!~progwml6@104.168.20.187)
L39[08:24:52] ⇨
Joins: h404bi (h404bi!~h404bi@58.62.52.195)
L40[09:08:08] ⇦
Quits: AforAnonymous (AforAnonymous!bitch2k@212.108.50.182) (Ping
timeout: 182 seconds)
L41[09:32:07] ⇦
Quits: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
(Quit: Javaschreiber)
L42[09:42:28] ⇨
Joins: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
L43[10:22:42] ⇦
Quits: ssblur (ssblur!~Thunderbi@cpe-65-184-138-23.ec.res.rr.com)
(Quit: ssblur)
L44[10:37:40] ⇨
Joins: ssblur
(ssblur!~Thunderbi@cpe-65-184-138-23.ec.res.rr.com)
L45[10:37:51] ⇦
Quits: ssblur (ssblur!~Thunderbi@cpe-65-184-138-23.ec.res.rr.com)
(Client Quit)
L46[10:38:28] ⇨
Joins: ssblur
(ssblur!~Thunderbi@cpe-65-184-138-23.ec.res.rr.com)
L47[10:47:02] ⇨
Joins: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:8437:b2a9:6252:16a1)
L48[10:49:01] ⇦
Quits: ollieread (ollieread!~ollieread@exia.ollieread.com) (Quit:
ZNC 1.6.5 - http://znc.in)
L49[10:54:18] ⇨
Joins: AforAnonymous
(AforAnonymous!bitch2k@212.108.50.182)
L50[11:05:11] ⇦
Quits: moony (moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net) (Ping
timeout: 202 seconds)
L51[11:12:24] <ForgeDiscord>
<Keridos> @tterrag could I get a bit of help from you
regarding chisels getQuads?
L52[11:12:55] ***
mumfrey is now known as Mumfrey
L53[11:15:04] ⇦
Quits: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:8437:b2a9:6252:16a1) (Quit:
computer gone to sleep)
L54[11:30:46] ⇨
Joins: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:6853:a8f1:2a2d:694e)
L55[11:35:34] ⇦
Quits: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
(Ping timeout: 194 seconds)
L56[11:36:35] ⇦
Quits: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:6853:a8f1:2a2d:694e) (Quit:
computer gone to sleep)
L57[11:41:45] ⇨
Joins: moony
(moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net)
L58[11:42:13] ⇦
Quits: moony (moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net) (Read
error: -0x7880: SSL - The peer notified us that the connection is
going to be closed)
L59[11:42:30] ⇨
Joins: moony
(moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net)
L60[12:12:45] ⇨
Joins: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
L61[12:22:22] ⇦
Quits: Cazzar (Cazzar!~cayde@2403:5800:a001:bc00::1337) (Ping
timeout: 194 seconds)
L62[12:23:20] ⇨
Joins: Cazzar (Cazzar!~cayde@2403:5800:a001:bc00::7d1)
L63[12:35:40] ⇨
Joins: shadowfacts
(shadowfacts!~shadowfac@pool-100-15-106-161.washdc.fios.verizon.net)
L64[12:44:43] <ForgeDiscord>
<tterrag> Ask away
L65[13:04:50] ⇦
Quits: shadowfacts
(shadowfacts!~shadowfac@pool-100-15-106-161.washdc.fios.verizon.net)
(Quit: Textual IRC Client: www.textualapp.com)
L66[13:12:44] ⇨
Joins: Hgrebnednav__
(Hgrebnednav__!~Hgrebnedn@d8D872A6E.access.telenet.be)
L67[13:36:41] ⇦
Quits: Ipsis (Ipsis!~Ipsis@82-69-71-184.dsl.in-addr.zen.co.uk)
(Ping timeout: 194 seconds)
L68[13:38:46] ⇦
Quits: Yamakaja (Yamakaja!~yamakaja@vps.pub.yamakaja.me) (Quit:
Bye)
L69[13:40:45] ⇨
Joins: Yamakaja
(Yamakaja!~yamakaja@vps.pub.yamakaja.me)
L70[14:37:14] ⇨
Joins: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:b59c:cd80:6fe8:5c54)
L71[14:41:32] ⇦
Quits: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:b59c:cd80:6fe8:5c54) (Client
Quit)
L72[14:49:53] ⇨
Joins: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:1db1:59b4:dd64:7725)
L73[14:50:35] ⇦
Quits: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:1db1:59b4:dd64:7725) (Client
Quit)
L74[14:53:43] ⇨
Joins: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:9845:8930:65c5:4264)
L75[15:00:51] <ForgeDiscord>
<Keridos> Are you using extended states?
L78[15:04:38] <ForgeDiscord>
<Keridos> this was my attempt at debugging it
L79[15:04:54] <ForgeDiscord>
<Keridos> but it seems like it uses
"chisel:andesite1[variation=3]"
L80[15:05:00] <ForgeDiscord>
<Keridos> as the state, which seems to be valid
L81[15:05:31] <ForgeDiscord>
<Keridos> and then uses minecrafts blockrendererdispatcher to
get the modelshapes and from that the model for the supplied state
and then getquads on that model
L82[15:05:50] <ForgeDiscord>
<Keridos> with the supplied state and side/rand from our
methods parameters
L83[15:12:41] <ForgeDiscord>
<Keridos> @tterrag do I need to use getExtendedState on
chisels mods to get the complete state needed for rendering?
L84[15:13:02] <ForgeDiscord>
<tterrag> of course
L85[15:13:10] <ForgeDiscord>
<tterrag> that's true for ALL blocks
L86[15:14:49] <ForgeDiscord>
<Keridos> ah
L87[15:15:24] <ForgeDiscord>
<Keridos> so something like this when I want to use it from
an itemblock:
heldItemBlock.getExtendedState(heldItemBlock.getStateFromMeta(heldItem.getMetadata()),
world, pos))
L88[15:15:57] <ForgeDiscord>
<tterrag> no, what?
L89[15:16:04] <ForgeDiscord>
<tterrag> items don't have extended states
L90[15:16:11] <ForgeDiscord>
<Keridos> well the itemblock
L91[15:16:15] <ForgeDiscord>
<tterrag> still no
L92[15:16:19] <ForgeDiscord>
<tterrag> items have model overrides
L93[15:16:27] <ForgeDiscord>
<tterrag> getItemModelWithOverrides
L94[15:16:39] <ForgeDiscord>
<Keridos> nevermind
L95[15:16:41] <ForgeDiscord>
<Keridos> its a block
L96[15:16:44] <ForgeDiscord>
<Keridos> not an itemblock
L97[15:16:52] <ForgeDiscord>
<Keridos> i need to rename this, this is confusing
L98[15:19:42] ⇨
Joins: Doty1154
(Doty1154!~Doty1154@c-73-189-164-179.hsd1.ca.comcast.net)
L99[15:24:55] ⇦
Quits: moony (moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net) (Ping
timeout: 198 seconds)
L100[15:25:01] ⇦
Quits: Doty1154
(Doty1154!~Doty1154@c-73-189-164-179.hsd1.ca.comcast.net) (Ping
timeout: 194 seconds)
L101[15:26:57] ⇦
Quits: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:9845:8930:65c5:4264) (Quit:
computer gone to sleep)
L102[15:27:36]
⇨ Joins: moony
(moony!~moony@tx-76-4-56-242.dhcp.embarqhsd.net)
L103[15:31:07]
⇨ Joins: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:588a:3027:2aca:92b4)
L104[15:41:15] ⇦
Quits: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:588a:3027:2aca:92b4) (Quit:
computer gone to sleep)
L105[15:42:50] ⇦
Quits: Hanii (Hanii!~textual@2a00:23c4:484:d100:17d:5b50:af99:7116)
(Quit: Textual IRC Client: www.textualapp.com)
L106[15:46:08]
⇨ Joins: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:9193:29d3:49f9:1c1a)
L107[15:58:33]
⇨ Joins: immibis
(immibis!~chatzilla@222-155-160-32-fibre.bb.spark.co.nz)
L108[16:00:46] ⇦
Quits: h404bi (h404bi!~h404bi@58.62.52.195) (Ping timeout: 194
seconds)
L109[16:00:58]
⇨ Joins: Doty1154
(Doty1154!~Doty1154@c-73-189-164-179.hsd1.ca.comcast.net)
L110[16:08:37] ⇦
Quits: srs_bsns (srs_bsns!blk@107.190.101.30) (Read error:
Connection reset by peer)
L111[16:08:55] ⇦
Quits: Noppes (Noppes!~Noppes@ip56530f2e.direct-adsl.nl) (Read
error: Connection reset by peer)
L112[16:08:55]
⇨ Joins: Nedelosk_
(Nedelosk_!~Nedelosk@ip-109-91-130-36.hsi12.unitymediagroup.de)
L113[16:08:55]
⇨ Joins: srs_bsns (srs_bsns!blk@107.190.101.30)
L114[16:11:03] ⇦
Quits: Nedelosk
(Nedelosk!~Nedelosk@ip-109-91-130-36.hsi12.unitymediagroup.de)
(Ping timeout: 198 seconds)
L115[16:19:41] ***
Mumfrey is now known as mumfrey
L116[16:22:13] ⇦
Quits: immibis
(immibis!~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) (Ping
timeout: 194 seconds)
L117[16:34:55]
⇨ Joins: arlyon_
(arlyon_!~arlyon@host86-151-230-178.range86-151.btcentralplus.com)
L118[16:35:26] ⇦
Quits: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:9193:29d3:49f9:1c1a) (Ping
timeout: 194 seconds)
L119[16:41:38] ⇦
Quits: Nedelosk_
(Nedelosk_!~Nedelosk@ip-109-91-130-36.hsi12.unitymediagroup.de)
(Read error: Connection reset by peer)
L120[16:42:03]
⇨ Joins: millerti
(millerti!~millerti@cpe-66-24-91-119.stny.res.rr.com)
L121[16:56:28]
⇨ Joins: Hanii
(Hanii!~textual@2a00:23c4:484:d100:ec46:388b:89fd:ac26)
L122[17:00:44]
⇨ Joins: h404bi (h404bi!~h404bi@119.129.119.51)
L123[17:11:16] ⇦
Quits: Javaschreiber
(Javaschreiber!~Thunderbi@88-209-32-73.nga.highspeed-baumann.de)
(Quit: Javaschreiber)
L124[17:20:17] ⇦
Quits: Hgrebnednav__
(Hgrebnednav__!~Hgrebnedn@d8D872A6E.access.telenet.be) (Ping
timeout: 194 seconds)
L125[17:23:01] ⇦
Quits: Upthorn
(Upthorn!~ogmar@108-204-125-173.lightspeed.frokca.sbcglobal.net)
(Ping timeout: 182 seconds)
L126[17:25:22] <ForgeDiscord>
<Keridos> wow the camo stuff is really annoying with extended
states
L127[17:28:17] <ForgeDiscord>
<Keridos> it seems that the correct extended state is somehow
lost on the way to my getQuads function
L128[17:28:18] <ForgeDiscord> Command sent
by Keridos
L129[17:28:19] <ForgeDiscord> ....
L130[17:38:56] <ForgeDiscord>
<Keridos> Is this the correct syntax to get the correct
extended blockstate for a held block (heldblock is the block,
helditem the item form of the block)?
heldBlock.getExtendedState(heldBlock.getStateFromMeta(heldItem.getMetadata()),
world, pos)
L131[17:41:23] <gigaherz> wait why are you
calling that yourself?
L132[17:41:45] <ForgeDiscord>
<Keridos> well I need the correct blockstate that block would
have if placed in the pos of my block
L133[17:41:50] <gigaherz> also no, you
can't assume that item meta == block meta
L134[17:41:56] <gigaherz> there is no way
to map items to blocks like that
L135[17:42:04] <gigaherz> it might work
for some
L136[17:42:13] <gigaherz> but you'll need
special handling for others
L137[17:42:26] <ForgeDiscord>
<Keridos> can I get the placed block state somehow?
L138[17:42:53] <gigaherz> not reliably...
you'd need to createa fake player and fake world, and run the
onItemUse
L139[17:43:06] <gigaherz> (on a copy of
the stack, to prevent damage/stack use)
L140[17:43:14] <gigaherz> and even then,
randomness could change the outcome
L141[17:43:14] <ForgeDiscord>
<Keridos> wow
L142[17:43:31] <ForgeDiscord>
<Keridos> how can I get the blocks rendering then?
L143[17:43:43] <ForgeDiscord>
<Keridos> the old just blockstate based approach worked with
most blocks
L144[17:43:58] <gigaherz> I was going to
say "ideally you'd keep the blockstate, not the
itemstack"
L145[17:43:59] <gigaherz> :P
L146[17:44:01] <ForgeDiscord>
<Keridos> we just check if block is a normalcube and if its
opaque
L147[17:44:10] <ForgeDiscord>
<Keridos> I do just keep the blockstate
L148[17:44:29] <ForgeDiscord>
<Keridos> the functions for storing and using that are
implemented
L149[17:44:30] <gigaherz> oh wait
L150[17:44:36] <gigaherz> you are tryingto
render stuff from an item
L151[17:44:39] <ForgeDiscord>
<Keridos> its just that chisel needs an extended block
state
L152[17:44:48] <gigaherz> i'm
confused
L153[17:44:55] <ForgeDiscord>
<Keridos> yeah, the block should render like it was another
block
L154[17:45:00] <gigaherz> is it YOUR
item?
L155[17:45:09] <ForgeDiscord>
<Keridos> it is my block, not item
L156[17:45:26] <ForgeDiscord>
<Keridos> the code snippet is from onBlockActivated
L157[17:45:38] <gigaherz> right
L158[17:45:38] <ForgeDiscord>
<Keridos> I have a block that should be disguisable
L159[17:45:55] <ForgeDiscord>
<Keridos> just calling getStateForMeta worked for most
blocks
L160[17:46:02] <gigaherz> yes it will for
many
L161[17:46:12] <ForgeDiscord>
<Keridos> but tterag pointed out I probably want the full
extended state
L162[17:46:26] <gigaherz> but, in some
cases, the block meta won't match the item meta
L163[17:46:32] <ForgeDiscord>
<Keridos> which should work
L164[17:46:37] <gigaherz> in thsoecases,
the block will override getStateForPlacement
L165[17:46:54] <ForgeDiscord>
<Keridos> I could just call the latter always, can't I?
L166[17:46:58] <gigaherz> which receives
the number returned by item#getMetadata(int)
L167[17:47:08] <gigaherz> which gets
called by the default implementation of ItemBlock
L168[17:47:31] <gigaherz> so, yes you
could call getStateForPlacement, and that would work for some more
items
L169[17:47:44] <gigaherz> but in the end,
any item which has a custom onItemUse, you can't trust
L170[17:49:32] <ForgeDiscord>
<Keridos> well I do not care if a small subportion of
complicated set up blocks
L171[17:49:35] <ForgeDiscord>
<Keridos> does not work
L172[17:58:19] <gigaherz> okay in that
case use block.getStateForPlacement, with the meta value returned
by item.getMetadata(int)
L173[17:58:25] <gigaherz> in place of
getStateFromMEta
L174[17:58:46] <gigaherz> the int passed
into getMetadata(int) is the actual item metadata value
L175[17:59:24] <gigaherz> so
block.getStateForPlacement(blah blah,
item.getMetadata(item.getMetadata()), blah blah);
L176[18:01:42] <ForgeDiscord>
<Keridos> yeah
L177[18:08:43] <ForgeDiscord>
<Keridos>
Minecraft.getMinecraft().getBlockRendererDispatcher().getBlockModelShapes().getModelForState(camoState).getQuads(camoState,
side, rand);
L178[18:08:59] <ForgeDiscord>
<Keridos> is that not the correct way to get the quads for a
give blockstate?
L179[18:11:10] <ForgeDiscord>
<quadraxis> not for an extended state
L180[18:11:35] <ForgeDiscord>
<quadraxis> you have to pass the non-extended state to
getModelForState, but the extended state to getQuads
L181[18:11:46] <gigaherz> not really --
the dispatcher uses the normal ... what quad said.
L182[18:13:09] <ForgeDiscord>
<quadraxis> you can use IExtendedBlockState#getClean
L183[18:13:39] <ForgeDiscord>
<Keridos> should I pass extended states all the way through
to my rendering then?
L184[18:13:42] ⇦
Quits: arlyon_
(arlyon_!~arlyon@host86-151-230-178.range86-151.btcentralplus.com)
(Quit: computer gone to sleep)
L185[18:15:01]
⇨ Joins: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:5d0d:6b1:382c:619b)
L186[18:17:11] <ForgeDiscord>
<Keridos> is there code somewhere to save an extended state
to nbt?
L187[18:18:34] ⇦
Quits: arlyon
(arlyon!~arlyon@2a00:23c5:be9b:ad00:5d0d:6b1:382c:619b) (Ping
timeout: 194 seconds)
L188[18:21:20] <ForgeDiscord>
<Keridos> @tterrag it seems chisel blocks do not give an
actual extended state when using getStateForPlacement or when
calling state.getBlock().getExtendedState(state, world, pos)
L189[18:22:17] <ForgeDiscord>
<tterrag> do you not have CTM installed?
L190[18:22:20] <ForgeDiscord>
<tterrag> CTM does all that
L191[18:22:35] <ForgeDiscord>
<Keridos> I have
L192[18:22:37] <ForgeDiscord>
<tterrag> and no getStateForPlacement will never return an
extended state
L193[18:22:49] <ForgeDiscord>
<Keridos> I get an extended chisel state
L194[18:22:56] <ForgeDiscord>
<tterrag> and stop trying to convert items to blocks. if you
are drawing a blockstate you should store a blockstate
L195[18:23:02] <ForgeDiscord>
<Keridos> that says, isExtended=false
L196[18:23:14] <ForgeDiscord>
<Keridos> i only do that when right clicking the block
itself
L197[18:23:24] <ForgeDiscord>
<Keridos> my entire saving and rendering system is blockstate
based
L198[18:23:36] <ForgeDiscord>
<tterrag> extended=false is internal
L199[18:23:41] <ForgeDiscord>
<Keridos> I just have the issue that chisels blocks give me a
transparent block
L200[18:23:43] <ForgeDiscord>
<tterrag> it's info about the wrapped state
L201[18:23:45] <ForgeDiscord>
<tterrag> don't worry about it
L202[18:23:59] <ForgeDiscord>
<tterrag> ChiselExtendedState is an extended state
L203[18:24:00] <ForgeDiscord>
<tterrag> that's it
L204[18:24:15] <ForgeDiscord>
<Keridos>
Minecraft.getMinecraft().getBlockRendererDispatcher().getBlockModelShapes().getModelForState(camoState.getClean()).getQuads(camoState,
side, rand);
L205[18:24:54] <ForgeDiscord>
<tterrag> are you setting the render layer properly?
L206[18:25:09] <ForgeDiscord>
<Keridos> how would I do that in getQuads?
L207[18:25:18] <ForgeDiscord>
<tterrag> this is in your own model?
L208[18:25:21] <ForgeDiscord>
<Keridos> yes
L209[18:25:24] <ForgeDiscord>
<tterrag> nevermind then
L210[18:25:40] <ForgeDiscord>
<tterrag> you get no quads as a result of that call?
L211[18:25:55] <ForgeDiscord>
<Keridos> I get transparent ones apparently
L212[18:26:08] <ForgeDiscord>
<tterrag> that's not even a possible case...
L213[18:26:22] <ForgeDiscord>
<tterrag> a quad has a texture, and we don't have any
transparent textures
L214[18:26:27] <ForgeDiscord>
<Keridos> yeah
L215[18:26:36] <ForgeDiscord>
<Keridos> it does not show the missing texture thing
L216[18:26:43] <ForgeDiscord>
<Keridos> the block is just completely transparent
L217[18:27:04] <ForgeDiscord>
<tterrag> again are you sure it's returning any quads?
L218[18:27:13] <ForgeDiscord>
<tterrag> what layer does your block draw on?
L219[18:27:37] <ForgeDiscord>
<Keridos> It is a default block model, just a custom baked
one
L220[18:27:50] <ForgeDiscord>
<tterrag> idk what "default block model
"means
L221[18:27:52] <ForgeDiscord>
<Keridos> Implementing IBakedModel
L222[18:28:01] <ForgeDiscord>
<tterrag> yes but models don't control layers
L223[18:28:02] <ForgeDiscord>
<tterrag> blocks do
L224[18:28:13] <ForgeDiscord>
<Keridos> BlockRenderLayer.CUTOUT
L225[18:28:24] <ForgeDiscord>
<tterrag> okay...well then a solid chisel model isn't going
to give any quads
L226[18:28:31] <ForgeDiscord>
<tterrag> have you tried...glass?
L227[18:29:03] <ForgeDiscord>
<Keridos> well we only accept opaque blocks
L228[18:29:16] <ForgeDiscord>
<tterrag> then why do you render on CUTOUT?
L229[18:29:24] <ForgeDiscord>
<Keridos> I think I set it to cutout once because some blocks
were borked
L230[18:29:58] <ForgeDiscord>
<tterrag> ideally you should draw on both and check the camo
state's canRenderInLayer
L231[18:30:13] <ForgeDiscord>
<Keridos> Can I draw on multiple ones?
L232[18:30:55] <ForgeDiscord>
<Keridos> with the extended state it may be able to do CTM,
correct?
L233[18:31:23] <ForgeDiscord>
<tterrag> what layers your model is called for is based on
the block's canRenderInLayer
L234[18:31:35] <ForgeDiscord>
<Keridos> ah
L235[18:31:44] <ForgeDiscord>
<tterrag> since the block it emulates is arbitrary you should
render on all layers and filter it down in the model
L236[18:31:45] <ForgeDiscord>
<Keridos> was using getBlockLayer()
L237[18:31:57] <ForgeDiscord>
<tterrag> they are both valid, but obviously that one only
works for a single layer
L238[18:32:52] <ForgeDiscord>
<Keridos> how can I check on which layer I am on in
getQuads?
L239[18:33:19] <ForgeDiscord>
<tterrag> BlockRenderLayer layer =
MinecraftForgeClient.getRenderLayer();
L240[18:35:31] <ForgeDiscord>
<Keridos> And then check on the model from the state and
check if it should render on the layer?
L241[18:36:29] <ForgeDiscord>
<Keridos> use getBlock to check for that?
L242[18:36:58] <ForgeDiscord>
<Keridos> nvm found it
L243[18:37:00] <ForgeDiscord>
<Keridos> thanks a lot
L244[18:37:04] <ForgeDiscord>
<Keridos> to all of you
L245[18:37:25] <ForgeDiscord>
<tterrag> it works now?
L246[18:42:37] <ForgeDiscord>
<Keridos> seems so
L247[18:42:52] <ForgeDiscord>
<Keridos> can I give back an empty list of quads when not in
correct layer?
L248[18:43:58] <ForgeDiscord>
<tterrag> yes
L249[18:46:54] <ForgeDiscord>
<Keridos> yay, seems to work fine now
L250[18:47:05] <ForgeDiscord>
<Keridos> I guess connected textures are blockstate
based?
L251[18:51:04] <ForgeDiscord>
<tterrag> yes, though you can "fake it" by
providing the methods your own IBlockACcess that pretends the block
in question is actually at the position
L252[18:51:11] <ForgeDiscord>
<tterrag> and implement IFacade from our API
L253[18:51:50] <ForgeDiscord>
<Keridos> ah proxy IBlockAccess and filter out the
block?
L254[18:52:16] <ForgeDiscord>
<Keridos> getBlockState? and then just return the camo
state?
L255[18:53:55] <ForgeDiscord>
<tterrag> pretty much
L256[20:11:16] <ForgeDiscord>
<Keridos> hm, now I am trying to replicate the light level,
translucency and light opacity of the camo states
L257[20:11:34] <ForgeDiscord>
<Keridos> but apparently my getLightLevel is called over and
over again with a lot of different states
L258[20:13:02] <ForgeDiscord>
<skyboy> correct, Blocks are singletons, as are
BlockStates
L259[20:16:45] <ForgeDiscord>
<Daomephsta> Flyweights is the correct term I believe.
Singletons are similar though.
L260[20:17:59] <ForgeDiscord>
<Daomephsta> The important difference is that a flyweight
class can have more than one instance.
L261[20:20:36] <ForgeDiscord>
<skyboy> that's ... an odd name, but fair enough
L262[20:20:49] <ForgeDiscord>
<Keridos> well when I do not get the correct state, what do i
do then?
L263[20:21:03] <ForgeDiscord>
<skyboy> the state is correct
L264[20:21:49] <ForgeDiscord>
<skyboy> just because it's not the one you want, doesn't mean
something is wrong - the design of your code just isn't handling
the normal case
L265[20:22:02] <ForgeDiscord>
<Keridos> hm, I try to get my extended state in here
L266[20:22:06] <ForgeDiscord>
<Keridos> but sometimes that seems to fail
L267[20:22:16] <ForgeDiscord>
<Keridos> what could be the issue there?
L268[20:23:01] <ForgeDiscord>
<skyboy> depends on where it's failing, some methods are
called prior to the state existing in the world; such as to check
if the block can exist in the world at that location
L269[20:23:34] <ForgeDiscord>
<Keridos> I see in debugging that most of the time the method
runs correctly
L270[20:23:35] <ForgeDiscord>
<skyboy> also, you said "in here" but didn't
provide the "here"
L272[20:25:54] <ForgeDiscord>
<Keridos> with this the block never emits light
L273[20:26:01] <ForgeDiscord>
<Keridos> even when it has glowstone as camo
L274[20:26:18] <ForgeDiscord>
<Keridos> it looks like glowstone but does not emit light
like it
L275[20:26:57] <ForgeDiscord>
<skyboy> you do not override getActualState, nor
getExtendedState, so those values aren't ever properly
assigned
L276[20:27:15] <ForgeDiscord>
<Keridos> getExtendedState is overriden in super
L277[20:27:37] <ForgeDiscord>
<skyboy> it's not like i can see that from this file
L278[20:28:11] <ForgeDiscord>
<Keridos> was no accusation ?
L279[20:28:57] <ForgeDiscord>
<Keridos> do I also need to implement getActualState?
L280[20:29:07] <ForgeDiscord>
<skyboy> it looks like you're saving the other block's block
state into your tile or something, then? and then asking it to
check your block for the values it needs?
L281[20:29:14] <ForgeDiscord>
<Keridos> yes
L282[20:29:28] <ForgeDiscord>
<Keridos> the blockstate is also used in a baked model to
render the block differently
L283[20:29:30] <ForgeDiscord>
<skyboy> that'll crash in the best case
L284[20:30:02] <ForgeDiscord>
<Keridos> well the camostates blocks never has a tile
entity
L285[20:30:12] <ForgeDiscord>
<skyboy> like your block, most blocks read data from the
world to get their final state
L286[20:30:25] <ForgeDiscord>
<skyboy> the data they're reading is not theirs, but
yours
L287[20:30:35] <ForgeDiscord>
<Keridos> yeah I know
L288[20:30:50] <ForgeDiscord>
<Keridos> is there not a nice way to get the light level the
block would emit ?
L289[20:30:59] <ForgeDiscord>
<Keridos> when just being placed in the world
L290[20:31:29] <ForgeDiscord>
<skyboy> not really
L291[20:32:11] <ForgeDiscord>
<skyboy> even if you limit to blocks without tiles, things
may be reading state you can't even guess at - like data stored
off-world
L292[20:32:18] <ForgeDiscord>
<Keridos> yup
L293[20:32:30] <ForgeDiscord>
<Keridos> hm, maybe just let the block have a configurable
light level output
L294[20:34:51] <ForgeDiscord>
<Keridos> thanks ?
L295[20:36:21] <ForgeDiscord>
<skyboy> you should still be able to steal a block's model
from it's getActualState for rendering at least
L296[20:36:52] <ForgeDiscord>
<Keridos> yes that works fine already
L297[20:37:12] <ForgeDiscord>
<Keridos> but apparently stealing other stuff means I have to
do nasty things
L298[20:37:31] <ForgeDiscord>
<Keridos> like modifying the iblockaccess to pretend the
block on my blocks position actually is the block
L299[20:37:38] <ForgeDiscord>
<Keridos> using a block placed by a fake player
L300[20:38:06] <ForgeDiscord>
<skyboy> pretty much
L301[20:38:16] <ForgeDiscord>
<skyboy> welcome to minecraft, it's hacks all the way
down
L302[20:39:31] <ForgeDiscord>
<skyboy> heh
L303[20:39:38] <ForgeDiscord>
<skyboy> and i opened the glowstone block class
L304[20:39:46] <ForgeDiscord>
<skyboy> it doesn't define a light level anywhere
L305[20:39:49] <ForgeDiscord>
<Keridos> yup
L306[20:39:56] <ForgeDiscord>
<skyboy> i wonder what magic location that's assigned at
now
L307[20:40:00] <ForgeDiscord>
<Keridos> it is fairly minimalistic
L308[20:40:12] <ForgeDiscord>
<Keridos> man, in 1.7.10 everything was so easy
L309[20:40:24] <ForgeDiscord>
<Keridos> ?
L310[21:47:52] ⇦
Quits: MikrySoft
(MikrySoft!~mikrysoft@89-71-96-37.dynamic.chello.pl) (Ping timeout:
194 seconds)
L311[21:48:58]
⇨ Joins: MikrySoft
(MikrySoft!~mikrysoft@89-71-96-37.dynamic.chello.pl)
L312[22:09:24] <ForgeDiscord>
<KnightMiner> Its typically in Block where the block is
registered
L313[22:09:38] <ForgeDiscord>
<KnightMiner> For some reason Mojang does half the stuff in
the constructor and the other half when registering
L314[22:10:37] <ForgeDiscord>
<KnightMiner> My favorite is slabs and stairs
useNeighborLighting. Instead of setting it in the constructor, they
do a registry scan for anything instanceof BlockSlab or instanceof
BlockStair then set the flag.
L315[22:20:41] ⇦
Quits: Brokkoli (Brokkoli!~Brokkoli@p5B23C437.dip0.t-ipconnect.de)
(Remote host closed the connection)
L316[22:28:27] ⇦
Quits: millerti
(millerti!~millerti@cpe-66-24-91-119.stny.res.rr.com) (Ping
timeout: 198 seconds)
L317[22:46:24] ⇦
Quits: Doty1154
(Doty1154!~Doty1154@c-73-189-164-179.hsd1.ca.comcast.net) (Read
error: Connection reset by peer)
L318[23:00:07] ⇦
Quits: Lathanael|Away
(Lathanael|Away!~Lathanael@p5496035C.dip0.t-ipconnect.de) (Ping
timeout: 202 seconds)
L319[23:01:39]
⇨ Joins: Lathanael|Away
(Lathanael|Away!~Lathanael@p549602AE.dip0.t-ipconnect.de)
L320[23:15:20] ⇦
Quits: Coaster3000
(Coaster3000!~coaster30@2601:83:8001:f8e3:559:c9fa:190c:5702)
(Quit: Leaving)
L321[23:27:39]
⇨ Joins: ZephyrWolf_
(ZephyrWolf_!~ZephyrWol@101.174.199.73)
L322[23:33:10] ⇦
Quits: ZephyrWolf_ (ZephyrWolf_!~ZephyrWol@101.174.199.73) (Quit:
Leaving)
L323[23:40:36] ⇦
Quits: armed_troop
(armed_troop!~armedtroo@pool-173-59-20-178.phlapa.fios.verizon.net)
(Ping timeout: 182 seconds)