That was the plan. Keep in mind that each enemy is likely going to cost around 4-5% of gameplay thermo. Which assuming there's literally nothing else in the level would allow for maybe 20 enemies active at a given time, and I'm likely going to need around 15. If I went through with using the workarounds I'd be cutting it seriously close with the thermo even then.
I'm the one who posted the suggestion for built-in trig functions in the first place.
Oh, sweet. That'll definitely help. Thank you. I'm definitely not the best at math, so I don't know, but do you think it might be possible to calculate the cosine of x from the sine of x in a way that's cheaper than calculating it directly from x? Or a way to calculate both at once in a way that's cheaper than calculating them separately?
My guess is that it's because somebody with either a lot of clout or loud opinions at MM hates math and programming and thinks adding features like this to logic will over-complicate things and scare away the normies.
It seems to me that when sending a fat wire that contains fat wires as its values (such as a transform fat wire from a tag) through the receiver to transmitter backchannel (might happen the other way around too, I haven't checked) the data inside the nested fat wires (with the exception of the first nested fat wire) gets garbled. So in the case of a transform fat wire, the position data is fine, but the rotation and scale data becomes garbled when sent through the receiver. The solution here being to split the transform wire into its constituent position, rotation, and scale fat wires, split those fat wires into their 9 total values, pick which ones you need, then combine them into a single 8-valued fat wire to be sent through the receiver. Stupid, but workable.
One thing I need it for is moving an object in a different object's local Z axis. Or in other words: move an object in the direction of a vector that needs to change based on the rotation of a different object.
