"The system is down. I dunno what you did, moron, but you sure screwed everything up good."


crash-2022-10-07_18.14.37-client.txt

Either the system for registering that animation variable is borked, or whoever made the wiki entry didn't test that example before putting it there. Whichever one, that møøse needs to get sacked!

It would appear there needs to be some sort of suffix on that variable. Indeed, variables with a _X suffix designate part-specific variables, of which the engine_pistion variable is not. So there is a wiki entry there.

Are you using that variable on a vehicle, or a part?

Just like every other variable listed on the wiki, you'll need to suffix the part number if you are referencing a part with a part variable.

With engine_gearshift, if you are using it on a vehicle to reference a part, you need to make it engine_gearshift_1 So if you are using that on a vehicle, you need it to be engine_piston_2_3_1 to return engine_piston_2_3 from engine number 1.

The wiki entry is consistent with how all other variables are listed.

I'm going to refute the claim of consistent naming. As per the Animation Hierarchy page.

The first thing MTS checks is if the animation has a number on the end of it. If so, MTS will try to get the part of that number as defined in the order of the [part slots](https://github.com/DonBruce64/MinecraftTransportSimulator/wiki/Pack-Making-JSON-Part-Slots). So, if you have a variable engine_rotation_2, MTS will attempt to get the second engine and return the value of engine_rotation for that engine. The same goes for things like gun_ammo_1 to get the ammo count of the first gun and propeller_pitch_percent_3 to get the propeller pitch of the third propeller, and part_present_22 to check if the 22nd part is present. If MTS can't find the part with the specified index, it will assume that it simply hasn't been placed yet, and will return a value of 0 for the animation.

Therefore, the variable as defined should always return a value of 0, since there won't be any engine-indexes to use if used on an engine, a the hierearchy will look for the Nth part number attached to the engine on which that variable is defined. If the variable works as defined, then it's more of a happy accident, than properly compliant.

Said variable was used on a part, specifically the engine itself. So it shouldn't'a needed a number-selector-suffix thingy. But that's all fixed and a-gooden.

It won't need one, but in the crash report you gave me the code wanted something as a suffix. Coulda been a number, coulda been a _randomword, or whatever. But, the fact of the matter is, variables should never end with a number, as that implies a part-slot variable.

That's the weird thing though, before this change it worked just fine! I didn't need no suffixes and it could end with a number were it on an engine itself rather than a vehicle.

That's the weird thing though, before this change it worked just fine! I didn't need no suffixes and it could end with a number were it on an engine itself rather than a vehicle.

The reason it crashes is because when you suffix with the part number, but only have three numbers total, it assumes that last number is the offset and that you have no part number.

I updated the wiki to require the suffix _crank or _cam. Technically you don't need to suffix the variable with _crank, and removed mention of Z being optional (although it still is).

This will require my PR gets approved to have the safety of not including a Z value but having a _crank suffix, but if the wiki is followed properly, then it will be fine.

Further, this allows full backwards compatibility with the old piston cam variable.