04-05-2017, 08:37 PM
Considering this has to do with QC maths, code logics, and other painful but fun stuff... I thought I'd post about it here as well. It involves the custom HUD panel responsible for listing players in a tree view, based on who's nomming who... something far more complex to do than one would at first imagine:
After 3 days of non-stop work on code algorithms, I was finally able to piece together a seemingly working mechanism for player list sorting. I had no idea this specific part of the code would prove to be such a problem, dwarfing my early concerns on the difficulty of reading player entity fields. Right now I feel like a mathematician or high level programmer for succeeding in finding a way to get it all working... obviously I am neither. As an update, I thought I'd explain a bit of what went on:
The first problem was that players are added to the table in a random order, as the base loop iterates through their entity numbers. This means that players can be detected in any order at all! So how would you make sure that each prey is listed under their predator, who in turn might be listed under another predator? Let's say you first notice that prey A belongs to predator B, so you list A below B and move on... then you detect that predator B is getting gobbled up by predator C, so you move B under C next... however prey A is already set in stone, so now it's left floating in an invalid position as B was pulled away from over it! One solution is running the sorting mechanism multiple times until it no longer detects any changes, which I actually went ahead and tried at first... however that's not only inefficient, but also prone to creating infinite loops that easily crashed the game once ran.
I ultimately managed to find a smart solution yesterday, by separating the process into two separate loops: One for columns and one for rows. The first only detects how far the predator chain of a player goes, and sets the column based on that knowledge. The second then goes through each column, and for each entry in that column (prey player) goes through the previous column and finds the matching entry (pred player) then positions the prey under the pred. This way preys are always positioned after their predators in order, and the random manner in which players are discovered no longer poses a concern.
After figuring this out, I thought all my problems had ended. But I was wrong... for there was another, far more problematic circumstance: Recursive vore loops. Suppose you have player A swallowing player B, player B swallowing player C, and player C swallowing player A: In a system where each prey is analyzed to detect its predator, A sees B, B sees C, C sees A, A sees B again, and we have an infinite loop! Not only that, but you logically cannot create a tree view in this case, as each player needs to be listed under the next forever!
The solution was ultimately to detect vore loops, then cause a break in the chain at one point. The code for this still isn't optimal and has several TODO notes attached to it, but for now it works. If it's only two players swallowing each other, the one with the most swallow progress will always be listed on top... if the chain goes further than two players however, it may be cut at a random position, and I fear that more than just one cut may currently occur in certain conditions.
All in all, Git master now has a decent listing system that does the job right most of the time. It will need to be optimized over time... both to account for every possible circumstance, and to be more loop efficient. For now I think I might take a few days break, as dealing with the maths involved left my brain a little bit fried. After that, the easy part should come last: Creating the icons and rings, and adding more details to the entries.
If by change anyone's curious to see the code in cause, and for bonus points tell me how the same result could be achieved with half the code using a different approach I wouldn't have thought about just to make me suffer, here are the highlights and my own solutions:
After 3 days of non-stop work on code algorithms, I was finally able to piece together a seemingly working mechanism for player list sorting. I had no idea this specific part of the code would prove to be such a problem, dwarfing my early concerns on the difficulty of reading player entity fields. Right now I feel like a mathematician or high level programmer for succeeding in finding a way to get it all working... obviously I am neither. As an update, I thought I'd explain a bit of what went on:
The first problem was that players are added to the table in a random order, as the base loop iterates through their entity numbers. This means that players can be detected in any order at all! So how would you make sure that each prey is listed under their predator, who in turn might be listed under another predator? Let's say you first notice that prey A belongs to predator B, so you list A below B and move on... then you detect that predator B is getting gobbled up by predator C, so you move B under C next... however prey A is already set in stone, so now it's left floating in an invalid position as B was pulled away from over it! One solution is running the sorting mechanism multiple times until it no longer detects any changes, which I actually went ahead and tried at first... however that's not only inefficient, but also prone to creating infinite loops that easily crashed the game once ran.
I ultimately managed to find a smart solution yesterday, by separating the process into two separate loops: One for columns and one for rows. The first only detects how far the predator chain of a player goes, and sets the column based on that knowledge. The second then goes through each column, and for each entry in that column (prey player) goes through the previous column and finds the matching entry (pred player) then positions the prey under the pred. This way preys are always positioned after their predators in order, and the random manner in which players are discovered no longer poses a concern.
After figuring this out, I thought all my problems had ended. But I was wrong... for there was another, far more problematic circumstance: Recursive vore loops. Suppose you have player A swallowing player B, player B swallowing player C, and player C swallowing player A: In a system where each prey is analyzed to detect its predator, A sees B, B sees C, C sees A, A sees B again, and we have an infinite loop! Not only that, but you logically cannot create a tree view in this case, as each player needs to be listed under the next forever!
The solution was ultimately to detect vore loops, then cause a break in the chain at one point. The code for this still isn't optimal and has several TODO notes attached to it, but for now it works. If it's only two players swallowing each other, the one with the most swallow progress will always be listed on top... if the chain goes further than two players however, it may be cut at a random position, and I fear that more than just one cut may currently occur in certain conditions.
All in all, Git master now has a decent listing system that does the job right most of the time. It will need to be optimized over time... both to account for every possible circumstance, and to be more loop efficient. For now I think I might take a few days break, as dealing with the maths involved left my brain a little bit fried. After that, the easy part should come last: Creating the icons and rings, and adding more details to the entries.
If by change anyone's curious to see the code in cause, and for bonus points tell me how the same result could be achieved with half the code using a different approach I wouldn't have thought about just to make me suffer, here are the highlights and my own solutions:
- Column sorting (client): https://gitlab.com/voretournament/data_v...in.qc#L256
- Row sorting (client): https://gitlab.com/voretournament/data_v...in.qc#L275
- Chain cutting (server): https://gitlab.com/voretournament/data_v...ain.qc#L58
