Revert PSTN change
-
Layering is very important for making electronics smaller and more efficient. People will never stop doing it. It's not too hard to change things without breaking layering. The only thing that will really affect layered stuff is when you move some code from one element to another.
-
The PSTN change did not involve moving code from one element to another, and still broke layered things. Despite me specifically attempting to write it in such a way that layered PSTN continued to work.
If people will never stop layering, then I believe the future of TPT will be either:
- Almost no updates whatsoever, or
- Saves will never stop breaking, or
- A rewrite.
Compatibility is one of the two main things making TPT development difficult and unenjoyable, and hence slow (the other being the terribleness of some of the code).
I recommend finding better ways to make electronics smaller. Layering is almost always the worst way to achieve something. PSTN being a perfect example - adding an extra layered particle to make it extend further makes the save run slower (so not very efficient), and can be difficult to do. Temperature control is much easier.
Layering wouldn't be quite so bad if TPT was designed to cope with it better. But it isn't, and rewriting TPT to handle layered particles better would break saves, because they rely on the current glitchy (and frequently particle order dependent) behaviour. Unless a complete copy of the current simulation code to run old saves was included in the rewrite. (This is what I'm doing in my fork, though the work is going very slowly.)
Edited once by jacksonmj. Last: 22nd Oct 2015 -
you just said that you moved code from PSTN to SPRK...
anyway, an update that better supported layering would be nice, if it did more good things than bad.
At least layering is much better than sub-frame things, because it's much more reliable, since it never breaks when saving.
-
Oh I think I get what happened. Instead of checking all the pixels 1 pix away for PSTN it now checks in a 3x3 area centered on itself for the PSTN. Therefore when it gets to it's own pixel and sees that there is no PSTN, it would leave the loop. Or something like that. I think. Mabye.
Edited once by mecha-man. Last: 25th Oct 2015 -
@mecha-man (View Post)
Uh, not sure what you are talking about so probably not :P
the PSTN update function does a search for spark, if it finds one it extends or retracts. It looks in 4 directions to see if there is PSTN that way. It checks the temperature of each of these for the new temperature function.
The thing that broke it is that it started by checking itself. But if it wasn't on top, then it wouldn't find itself and it would give up. The fix was adding another check, if this is the first PSTN then check parts[i].temp instead of parts[pmap[ything][xthing]>>8].temp. That way the very first piston doesn't have to be on top, but all the rest do. -
How does the PSTN temp thing work? does the PSTN just extend temp-10 spaces? what if parts of the PSTN are different temperatures?
-
Tens of degrees above 0 C, rounded to nearest ten degrees. Can be negative. Summed over all PSTN particles from the one that gets sparked to the one before the start of the piston arm, then subtract 1.
E.g. 1 x 40 C PSTN and 1 x 20 C PSTN would cause it to extend by 4+2-1=5 pixels.
Edited once by jacksonmj. Last: 28th Oct 2015
