Switch motors not rendering
brisingraerowing opened this issue ยท 14 comments
I did a custom build from the repository to test out some of the new features (I had to disable the fingerprint check to get MC to load. I tried to figure out how to create a self-signed certificate, but got all befuddled while researching that), and quickly found that the switch motors render in the inventory, but not as a block. They still have a hitbox and they work perfectly fine, they just can't be seen. Are the block models for them not done yet? Or is there a bug?
Overall, though, the switches and junctions are quite cool. I am going to use them in a completely automated super factory thing (Crafting, Brewing, Smelting, Mining, etc) to route carts to various places. I always hated the Vanilla T-Switches, they are way too limited for any decent automation / rail system.
This is an awesome mod. Keep up the good work!
Works here, they were broke at one point in the described manner, but I don't even know if I ever committed that version to the repo.
No idea what you mean. You are supposed to just lay out the track how you want and use the Spike Maul on the track in the middle.
The version with the fixed rendering was only one I think I committed.
I'll get a screenshot of what I am seeing (or not seeing) and a list of my mods up soon. Just have to wait for MC to load.
Here is a screenshot and here is my modlist.
The switch actuator works perfectly fine. It just is invisible.
I am guessing you didn't. I also noticed that switches only want to point towards the east, and can't be rotated to point any other direction. Same goes for Wye tracks. Is that by design? Seems to be rather limiting.
A quick test with just Railcraft and JEI confirms that this is a compatibility issue. I am going to go through my modlist and see what is broken.
@CovertJaguar Would you mind pointing me to the Block class for switches? I have an idea of what may cause this, but I need to read through the code.
I found the issue, you are relying on states passed into your model being non-extended, which is a bad assumption
Before doing a lookup in getQuads, check for IExtendedBlockState and call getClean
@tterrag1098 you are going to have to back up why that is a bad assumption, as I control the creation of the BlockStateContainer and I know for a fact that it is not ExtendedBlockState.
BlockStateContainer is not part of it, fact is that all rendering states come from Block.getExtendedState, where a return of IExtendedBlockState is expected. Chisel uses this expectation to implement custom model data, and unfortunately doesn't have any way to apply it selectively without a lot of overhead.
Point is, there is always a possibility that a state coming into a model will be extended, so it's a good idea to play it safe and call getClean(). Or just rely on something else for a model state key.
So are the states generated by the statemappers clean then? And just the one passed to getQuads() wrong?
