See attached script, red particles are unmoved, blue are shifted. Relevant lines are 69 and 89, as labelled by Notepad++.
Also see test map attached. (Side note: Blue emitter destruction doesn't have an event tag, unlike red.)
Note: It seems that the same bug happens for ships, I'm not sure about units. The ship-bug is, I seem to recall, present in that test map.
Added to the TODO list... thanks.
On line 69 you have this:
<-BadParticle.ParticlePosition swap <-DelX sub swap <-DelY sub ->BadParticle.ParticlePosition
On line 89 you have this:
<-NiceParticle <-NiceParticle.ParticlePosition swap <-DelX sub swap <-DelY sub SetParticlePosition
Line 89 deals with the blue particles and line 69 deals with the red particles. Look like you want what is on line 89 to also be on line 69 if you want the red particles to be moved like the blue particles. Could just be a copy paste error.
The two lines should (assuming the AcNot works as it seems to elsewhere) have the same effect, one assigning using AcNot, the other with SetParticlePosition. The fact that the AcNot did not have the same (any?) effect seemed a bug.
I left that in intentionally, so you had both cases at your disposal. I used SetParticlePosition in the other half as an example of intended behaviour.
Thanks for taking the time to let me know. :)
Side note: You are, I think, the gold standard for what a lone dev might do after release.
Ahh, ok I was focused on the wrong thing.
Acnot notation for setting only works for single arguments. You can use for to replace a "Get" call when the Get function returns more than one thing, but for setting the function can only take 1 argument. Acnot does this when used for a Set.
Ex:
1 2 add ->var.Property
Becomes
1 2 add <-var swap SetProperty
In your code, SetParticlePosition needs two arguments, so it can't be used with AcNot notation. Not very clear or obvious, I know. I always add something late in the process (like AcNot) and then regret it months later :) But next game I hope to address all of these edge issues with a sweeping change.
Interesting. So you have implemented AcNot parsing by seeking a property token and then prepending Get/Set?
Time to do a light test of whether <-PID <-Y ->X.ParticlePosition works. Or perhaps better not to, as it would generate some of the worst code ever written in RPL.
Given that it is not designed to work, I ask that you have the compiler choke on it, so that poor fools such as I do not bumble along thinking it will.
Also, I'll make a note to reduce use of AcNot, because a heavyweight script does not need any additional commands, even those as lightweight as swap.
Thanks again.
By the way, line 65:
<-Dist 1 pow
I'm like... whaaat? Why not give asfloat (https://knucklecracker.com/wiki/doku.php?id=prpl:asfloat) some love.
As for the AcNot, I think it would be best at this point to create a list of "Safe" properties/getters/setters to use with AcNot, and if you use it with anything that is not on that list, you get a warning, if not outright compile error.
This was part of a tuning effort, set to be ineffective at the time of thread creation.
If it does not work, it should break cleanly and immediately. A list of safe property tokens would be overkill, when some tokens are already asymmetrical between AcNot get and set.
Quote from: GoodMorning on March 26, 2017, 06:12:58 PM
If it does not work, it should break cleanly and immediately
Completely agree. However, how are you going to achive that without creating a list of usable functions that take exactly 1 argument? Also having a setter that would work and getter that wouldn't is easy - just put the final function names into the list - with Get or Set.
Given the nature of PRPL (you can't step debug for example, or at least I am not aware of it), you would like to have as little confustion and disabiguity as possible. However I understand there are more importatnt issues, like
let players rate the map they have just played.