simple as

+1, usecases range from simple math that changes how the gauge's needle displays something, to feeding in multiple variables into one animation, or dynamically altering the result (personally wondered about this such that my instruments could do a gauge sweep on startup + always display 0 when the vehicle is off, without jittery jankiness)

Not going to do this. In general, I'm wanting to move away from VMs into something else that less limiting. And even if I wasn't, the fact an instrument can change how a vehicle behaves isn't ideal. Unless you're wanting to to more fancy display things with instruments? In which case I'll see what I can do about better display stuff, but not with the overhead that comes with clunky VM code. It already mucked with the UNU Turbofire engine line.

I mainly want this to convert data internally. VMs are way more than just tweaking values on vehicles.

ngl, I have a pretty neat feature that will require instrument VMs in order to work.

Also, how did VMs mess up the UNU Turbo-Fire? I'm not aware of any VM-related issues. If you mean the lag, I've determined the lag to be caused by the number of subparts, not VMs.

This! Neither of us intend to have instruments change your vehicle trim, how fast it goes, etc. but rather we want to run math operations using them, to display the value afterwards! Particularly with textObjects which leaves you with variableFactor for multiplication, but nothing for offsetting the value before displaying it. (Say, a VF of 1.8 and an offset of 32 on engine_temp to display the engine's coolant temperature in fahrenheit)