You should try emitting the enemies in some way and destroying them when dead /not visible.
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.
Suggest you upvote this feedback suggestion here to push for more trig functions:
I'm the one who posted the suggestion for built-in trig functions in the first place.
I've remixed MrOobleck's sine bhaskara chip, and managed to reduce its thermo quite a bit. It's called 'Cheap Sine (degrees) (Bhaskara)'. Each chip now costs about 0.11%, whereas the original was around 0.24%. From my testing it gives the same results (at least up to 2 decimal places). I've also put in a chip which is accurate only between 0 and 180 degrees, which is down under 0.05%.
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?
I can't think of any particularly good reason why trigonometric functions aren't implemented. From a programming point of view it's pretty equivalent to raising something to an arbitrary power.
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.
What is this bug you are talking about? I've had some weird behaviors with fat wires and I was wondering if there were no bug with them too. Although it's a common mistake I make believing there's a bug in the software I use when most of the time I am the one doing something stupid :).
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.
As a lousy student of math who is interested in programming, I'm curious as to what you--any of you--are using trig functions for in Dreams. One of my greatest struggles is understanding ways to implement the mathematics I've learned, so I'd be very interested in hearing about possible applications.
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.