Closed Epik95mkw closed 2 years ago
hlorenzi
commented
2 years ago Hmm, this might be the final nail in the coffin for the app. 😅 Fixing this would probably mean rewriting big portions of the app, since it works under the assumption that the final graph can be generated automatically, and there's no dedicated UI to modify groups manually.
Where have you heard this from? Is there a page where I can read more about this bug?
Epik95mkw
commented
2 years ago I found out about this issue myself, since I do a lot of bug testing for CTGP.
On tracks with multiple checkpoint paths, each checkpoint path is "worth" a certain amount of race completion. The amount each path is worth is determined by the height of a DFS tree of the paths starting from path 0. For example, in the image below, the height of the tree is 3, so each path constitutes 100/3 = 33% race completion (sorry for bad drawing lol).
However, in situations like the one below, the left path is now 2 different checkpoint paths while the right remains as 1. This sort of arrangement is common on tracks with many different paths, such as N64 Yoshi Valley. The issue is that each path here will be worth the same amount of race completion, let's say 25%. So driving the left path will raise your race completion 50%, while driving the right path will raise it only 25%, and then it will suddenly jump another 25% when you exit the path. This will cause players to be shown in the wrong position, which is especially problematic if there are item boxes in the area.
The solution would be to split the right path into 2 checkpoint groups, which would each be worth 25%, making the entire path worth 50% like the other one and avoiding the jump in race completion. This bug only affects checkpoint paths as far as I know, so item and enemy paths would not need to be changed.
As for fixing the editor, I think I've come up with a fairly simple solution. I added a boolean property to checkpoint nodes that is true if the node is the beginning of a new checkpoint group, which can be changed using a checkbox in the GUI. I'm still making adjustments to it but I'll commit it to my fork when I'm done so you can take a look.
It was recently found that certain arrangements of checkpoint paths will cause race completion to be calculated incorrectly, meaning players in a race will not be shown in the correct position. This can be fixed by dividing one checkpoint path into multiple; as in, keeping the checkpoints themselves the same but separating them into different groups. However, the way the editor processes checkpoint paths automatically merges them if there are no other outgoing/incoming paths. Not only can the editor not be used to fix this checkpoint problem, it will actually un-fix it if it was previously fixed in a different editor. It would be ideal if the user was able to control checkpoint paths directly, rather than doing it automatically.