[Bug] Part variables all go to zero when part_1 of that type is removed
gyrohero opened this issue ยท 6 comments
For example, if you have multiple guns (with ammo counters to represent them) that all have ammo, then remove whatever was considered "gun_1", all of the other gun_ammo_counts go to zero. However, removing gun_2 does not zero out subsequent guns. Replacing gun_1 restores the correct ammo counts.
I'll try to see if I can figure out a fix to this, but if not I may need some help.
Does this happen with all parts, or just guns? Because from what I recall, engines don't have this issue.
Hrm, does it only happen on guns with muzzle numbers, or those without muzzle numbers on them?
Okay, so I know what's happening.
When you put an instrument into the HUD, MTS assume that instrument doesn't go to any particular engine. However, the same logic extends to all parts, not just engines. So guns and wheels, and propellers get the same treatment. When you put such an instrument in the panel, however, you can specify which part the instrument goes to. This is done because instruments such as tachometers and pitch indicators work for each component, but you don't know how many of such components a vehicle will have. You might have only one propeller and two guns on one plane, but two propellers and 5 guns on another. This is why, when you specify the optionalPartNumber, MTS assumes you have an instrument that goes to a particular part.
On this note, the actual call to render said instrument is here:
On that line, MTS will pass-in the instrument JSON definition to the renderer, plus the optionalPartNumber that was in the vehicle JSON. Because you didn't specify one to have your instrument on the HUD, that defaults to 0.
Once the instrument is told to render, it goes through the motions to do that. Because MTS knows the instrument is for a gun, it knows that you need to find a specific gun. Since you didn't specify which gun with optionalPartNumber, it defaults to part 1, as seen here.
However, since your variable definition already had a suffix, you now have two suffixes. The first is the actual gun you want, while the second is the auto-generated _1 suffix. MTS sees the suffix in the VAS, and goes to strip it out and find the part with that number. Since it's looking for part 1, it'll put that part as the actual part and call the VAS again with the part as a parameter if it finds it. If it doesn't find the part, it'll just return 0, as you're seeing.
The thing is, MTS checks if there's a suffix before it checks if the optionalPart parameter is non-null. So what happens is if MTS finds gun 1, then it'll go back into that code call and find another suffix. In this case, the suffix you specified on the instrument JSON variable name. It then strips that suffix, and goes to the VAS for a third time and finally gets the correct value.
While MTS isn't really set up to have instruments that link to specific part numbers on the HUD, you could do such a thing. However, the way you go about it can come in many ways. I see two:
- Have MTS not auto-add a suffix on a variable in the instrument render code if one exists. This would somewhat break convention, as part-specific variables belong on the panel, but for guns, I can see this being annoying, and I'm okay with breaking conventions for usability.
- Split the instrument so it's only one per gun, but put a parameter to force rendering on the HUD. Something like oppositePanel, where if the instrument was going to be on the HUD it goes to the panel, and if it was going to be on the panel it would go on the HUD. This would require changing your gun instruments, but would make them more dynamic for vehicles with odd numbers of guns.