Support for pipe-like models

[cameronleger]

First, getConfigNodeValue now works with the data attribute instead of an index. Second, a Pipe model has been added that works by using a provided 'thickness' (i.e. 8 would be half of a block, 8 / 16) and connecting to nearby blocks of the same type or those specified with the 'connect' config option.

This provides better exports of modded blocks such as Buildcraft Pipes and IndustrialCraft wires.

[Moonlight63]

seems like an interesting update. So I am assuming this works by putting each pipes information into the blocks config file, and specifying a scale for it?

[Moonlight63]

I think for now this should go into it's own branch, just until it can be thoroughly tested, and make sure it works with everything it needs to. I don't think I can change the merge request to move to a different branch from the web, but if you re-request it, I have made a new branch for it.

[cameronleger]

Like other models implemented in jMc2Obj's source, the Pipe model can be selected with <model>Pipe</model>. The scale of the pipes is configured with another tag: <thickness>4</thickness>. Due to IC2 using the same block for all cables - and I guess, it determines how to render them in its own code - the thickness tag also accepts a data attribute to further configure the thickness. The thickness is specified as an integer out of 16 for easier configuration (can be set by counting the pixels on a copper wire, for example). Here's an example for those wires in my setup:

<block id="462" name="ic2.blockCable"> <occlusion>none</occlusion> <model>Pipe</model> <thickness data="0">6</thickness> <thickness data="1">4</thickness> <thickness data="2">2</thickness> <materials data="0">ic2_wiring_cable_blockCable_1</materials> <materials data="1">ic2_wiring_cable_blockCableO_1</materials> <materials data="2">ic2_wiring_cable_blockGoldCable_1</materials> </block>

This will require manual entry on the user's end. But, I am also working on a mod for Minecraft that dumps the block data into jMc2Obj compatible config files, so that's a more automated approach that would work across modded Minecrafts. Unfortunately some mods don't like to use things such as block render types to make this process easier, so for now a decent bit of my code is figuring those things out and then adding 'cases' to set the right information for the right blocks.

I concur regarding a separate branch. I'm working in general on getting better modded-Minecraft exports, so I expect to have a few more things like this that I would want to open for implementation. Should each goto their own branch, or do you think we should have a separate 'mod' branch to work those through and merge into master later, if ever?

[Moonlight63]

We can make 1 "modded exporter" branch. That seems fine.

[mmdanggg2]

Closing as this is mostly redundant now.