Allow setting ETRD min and max distance with tmp and tmp2

[catsoften]

This idea was from a suggestion on the forum. It makes ETRD much more useful since arcing can be controlled to make less of a mess. Even though the current implementation finds the nearest particle, it will still arc to any other ETRD on the screen. Preventing that may be another solution to the usability problem, but it would completely break compatibility. Using INSL to prevent arcing isn't a great solution either since INSL is flammable, and finding the exact center pixel is difficult (assuming it's even in a place it won't burn).

I was not able to find any negative performance impacts changing abs(x) + abs(y) to hypot(x, y) (It actually seems to run slightly better, but I may missing something there).

[Jakav-N]

I'm not sure if it's too late for 97.0 at this point, but it would be nice to have this merged if possible. I don't want this to have to wait a few months for the next version of TPT.

[jacob1]

Another idea I had to make ETRD more controllable is to make it link up to the closest ETRD, regardless of whether it can currently accept spark or not. One reason it goes haywire today is that it searches the entire sim for any unsparked ETRD. If it were to give up the moment it finds a close, already sparked ETRD, then it wouldn't make beams across the entire sim anymore.

I just tested that change and not sure I like the results. It definitely gets rid of all the plasma spam, but is that a defining feature of ETRD? Also, it means all ETRD has to be in a group of 1 to function. So if it works this way then perhaps it needs to find the closest ETRD not in its own group. Maybe this isn't a good solution overall.

But basically, I was just thinking of ways to make ETRD more controllable naturally, being able to do what you want without fiddling with tmp and tmp2 properties.

[catsoften]

But basically, I was just thinking of ways to make ETRD more controllable naturally, being able to do what you want without fiddling with tmp and tmp2 properties.

That would definitely be better, although there are already quite a few elements that need such fiddling. I feel like I may have found a good compromise however.

Setting the tmp2 value during creation could allow individual particles to be linked automatically, but (similar to your idea) it does have problems with groups of particles. Erasing particles would also cause broken links. I think it would at least be an improvement, even with the feature limited to single particles. Keeping the manual distance options there for anyone that wants to put in a little extra effort can't hurt either. Let me know your opinion and I can push that.

Side note:
I did some tests combining the previous idea with flood filling to make it work with multiple particles, but ran into problems seeming to come from brush creation order, making things difficult without messing with the brush tool. Other than that it seemed close to perfect. I may look into that again when/if I have more time.

[jacob1]

I think manual distance options are a bit better than WIFI-style linking. Because at that point it's just a WIFI that creates PLSM in the middle. If an ETRD's partner is deleted, then it will have to find a new ETRD somehow.