RobertBColton
commented
5 years ago This is best solved by starting with the development of a CI test for paths to verify the correct behavior. That way we can be sure that nothing else breaks while fixing them. I was going to do some fixes to them several months ago when I ran onto these bugs, but got discouraged with the legacy code. I also didn't want to sink too much time into it when we have higher-level goals.
Regardless, I'd love to see somebody work these problems out. I also at some point want ENIGMA to support full graphs and branching paths through composition.
Edit: I've amended your issue with a 4th bullet point from one of your earlier tickets. These are all closely related to paths. If you check back on #1040 too I did a small investigation on that and provided test cases which could be part of the CI test.
when an object is on a path via path_start() or whatever, the direction variable should be changed to the direction the object is moving on the path
getting/setting the variable path_position should be a value between 0-1. If you have the path_start() path speed value to a negative number, the path_position will also be a negative number, and the absolute value of that number will often be greater than 1 when speed is negative (to go backwards).
setting path_position is completely broken, it doesn't go to the correct position, it seems to always go to position zero, unless you use a negative number like explained in the previous point, but even then it is not behaving like GM.
When assigning a relative path to an object the path plays with what was made in LGM's path editor, only it is flipped on the y-axis. This only happens with relative paths. Absolute paths aren't flipped and work as intended. (originally #1040)