I will preface this by disclosing some information about my testing environment. I'm running this in a 1.19.2 PrismLauncher instance alongside a number of other mods, though I believe the likelihood of this behavior being affected to be minimal and am too lazy to create a new instance.
While the mechanics of the signal minecart are working as intended, its visuals are often incorrect. When the entity is displaying a flag the piston_display_block's variant blockstate is 1 lower than expected. Notably this bug does not extend to cases where there is no signal flag selected; in that state the programmable_cart_empty texture is used like one would expect. the best way of describing the failure cases is that instead of the flags covering a blockstate range from 7 (white) to 22 (black) they range from 6 (empty) to 21 (red).
While I haven't messed around with the forge API before, I generally understand what's going on under the hood after poking around this repository. What I can't seem to understand is how this bug is happening. At a glance the FlagUtil class converts the selected item into a value from 0 to 16 with 0 being no flag and 1 through 16 representing the 16 possible colors. When updating its visuals, the block inside the minecart changes its default blockstate to that 0-to-16 value raised by 6. If this is the code controlling both the empty state AND the flag state, I would expect the empty state to ALSO have a blockstate 1 lower than expected. However, what I'm seeing in-game runs counter to that expectation.
I've used openloader to mess with assets/moreminecarts/blockstates/piston_display_block.json and can confirm that each flag is in fact using the wrong blockstate. an empty signal minecart uses the moreminecarts:block/programmable_cart_empty model as expected, but after placing an orange signal inside the moreminecarts:block/programmable_cart_white model is used (that's variant 7 instead of the expected 8). when replacing the item with a white signal (the lowest-index color), the model displayed is moreminecarts:block/programmable_cart_empty (variant 6 instead of the expected 7). While I didn't actually see anything wrong with the code, assuming that somewhere along the line the variant is being lowered by 1 I would have predicted that the first of those cases, an empty signal minecart, would use variant 5 (the moreminecarts:block/transport_battery model). Since that's not what I observe in-game, that suggests to me that I missed some function in the code that handles empty signal minecarts separately. it's at this point that I figured I'd just submit an issue since your programming style is pretty different from mine and you'll know how the mod's logic is organized far better than I do.
I'll leave a mostly unhelpful image showcasing the behavior I've described. If you aren't seeing the same bug manifest on your end just let me know and I'll test things in a fresh instance for you.
I will preface this by disclosing some information about my testing environment. I'm running this in a 1.19.2 PrismLauncher instance alongside a number of other mods, though I believe the likelihood of this behavior being affected to be minimal and am too lazy to create a new instance.
While the mechanics of the signal minecart are working as intended, its visuals are often incorrect. When the entity is displaying a flag the
piston_display_block'svariantblockstate is 1 lower than expected. Notably this bug does not extend to cases where there is no signal flag selected; in that state theprogrammable_cart_emptytexture is used like one would expect. the best way of describing the failure cases is that instead of the flags covering a blockstate range from 7 (white) to 22 (black) they range from 6 (empty) to 21 (red).While I haven't messed around with the forge API before, I generally understand what's going on under the hood after poking around this repository. What I can't seem to understand is how this bug is happening. At a glance the
FlagUtilclass converts the selected item into a value from 0 to 16 with 0 being no flag and 1 through 16 representing the 16 possible colors. When updating its visuals, the block inside the minecart changes its default blockstate to that 0-to-16 value raised by 6. If this is the code controlling both the empty state AND the flag state, I would expect the empty state to ALSO have a blockstate 1 lower than expected. However, what I'm seeing in-game runs counter to that expectation.I've used openloader to mess with
assets/moreminecarts/blockstates/piston_display_block.jsonand can confirm that each flag is in fact using the wrong blockstate. an empty signal minecart uses themoreminecarts:block/programmable_cart_emptymodel as expected, but after placing an orange signal inside themoreminecarts:block/programmable_cart_whitemodel is used (that's variant 7 instead of the expected 8). when replacing the item with a white signal (the lowest-index color), the model displayed ismoreminecarts:block/programmable_cart_empty(variant 6 instead of the expected 7). While I didn't actually see anything wrong with the code, assuming that somewhere along the line the variant is being lowered by 1 I would have predicted that the first of those cases, an empty signal minecart, would use variant 5 (themoreminecarts:block/transport_batterymodel). Since that's not what I observe in-game, that suggests to me that I missed some function in the code that handles empty signal minecarts separately. it's at this point that I figured I'd just submit an issue since your programming style is pretty different from mine and you'll know how the mod's logic is organized far better than I do.I'll leave a mostly unhelpful image showcasing the behavior I've described. If you aren't seeing the same bug manifest on your end just let me know and I'll test things in a fresh instance for you.
good luck and happy bug fixing!