Somehow, im trying to figure out how this happened. I disabled every trigger in my map and tested to see if i could get the integers to read as default (player 1 being integer 1) and it still wouldnt work.
it started when I was getting errors of player array of -1, and 16, on triggers that didnt even call on these players and for some reason those triggers still worked. I spent hours doing a work around just for those errors not to show up and now i noticed my banked career stat library which calls on player integers doesnt catch any of my players.
i tested the exact triggers in new maps and they work.
Is it possible to fix this problem? perhaps game variants?
something within your map changed without you wanting it to.
check everything, Dependencies, Map Textures, Player Properties, etc etc and make sure absolutely everything is how is should be.
if it is and nothing is wrong with your set up then you might have to start over.
Sometimes shit happens, it is easy enough to copy triggers over, copy terrain and your data should be in a mod anyways. Something similar happened twice (I think) over the course of Tofu's development where the engine just "broke" and I couldn't fix it ... everything was correct but it was still throwing errors, so I had to get an old backup and redo all the work again ...
If you added computers it may have moved the player positions ...
Otherwise there should never be a negative index for an array, it should always be 0 (neutral) to 15 (hostile) ... so it seems like you have gone one integer too much both ways.
I ran into this problem too when creating a system to track kills and bounty. I had to create a very long winded work around involving creating a backup array of player index references. It mostly worked, but still had a problem once every few thousand times the trigger was called. In the end, I just had to trap the error and then make the code ignore it.
I have found that this happens when you have a trigger fire that pulls a player index, then fires again before the first trigger iteration has finished. Something maybe about the player index array not being accessible by 2 copies of the same trigger at the same time is my guess.
Anyway, no solution for you, but hope this info helps you.
If you are going to be doing a little bit of rewriting it is better if you create an array of active players rather than using player groups and use that to access player's data ... that is how I do it in Tofu (no player groups are used) and I have never had this particular problem.
This is the solution I had to implement as well. However, when referencing killing player of a unit, I was still having the same problem, albeit a lot less frequently after using a variable array to compare player indexes instead of the player group. Is there a way to reference the killing player of a unit without pulling the player group?
Somehow, im trying to figure out how this happened. I disabled every trigger in my map and tested to see if i could get the integers to read as default (player 1 being integer 1) and it still wouldnt work.
it started when I was getting errors of player array of -1, and 16, on triggers that didnt even call on these players and for some reason those triggers still worked. I spent hours doing a work around just for those errors not to show up and now i noticed my banked career stat library which calls on player integers doesnt catch any of my players.
i tested the exact triggers in new maps and they work.
Is it possible to fix this problem? perhaps game variants?
Thanks.
@Stexen: Go
something within your map changed without you wanting it to. check everything, Dependencies, Map Textures, Player Properties, etc etc and make sure absolutely everything is how is should be. if it is and nothing is wrong with your set up then you might have to start over.
Sometimes shit happens, it is easy enough to copy triggers over, copy terrain and your data should be in a mod anyways. Something similar happened twice (I think) over the course of Tofu's development where the engine just "broke" and I couldn't fix it ... everything was correct but it was still throwing errors, so I had to get an old backup and redo all the work again ...
If you added computers it may have moved the player positions ...
Otherwise there should never be a negative index for an array, it should always be 0 (neutral) to 15 (hostile) ... so it seems like you have gone one integer too much both ways.
@Stexen: Go
I ran into this problem too when creating a system to track kills and bounty. I had to create a very long winded work around involving creating a backup array of player index references. It mostly worked, but still had a problem once every few thousand times the trigger was called. In the end, I just had to trap the error and then make the code ignore it.
I have found that this happens when you have a trigger fire that pulls a player index, then fires again before the first trigger iteration has finished. Something maybe about the player index array not being accessible by 2 copies of the same trigger at the same time is my guess.
Anyway, no solution for you, but hope this info helps you.
If you are going to be doing a little bit of rewriting it is better if you create an array of active players rather than using player groups and use that to access player's data ... that is how I do it in Tofu (no player groups are used) and I have never had this particular problem.
@DogmaiSEA: Go
This is the solution I had to implement as well. However, when referencing killing player of a unit, I was still having the same problem, albeit a lot less frequently after using a variable array to compare player indexes instead of the player group. Is there a way to reference the killing player of a unit without pulling the player group?
Unit Dies - Owner of Killing Unit.
It is not a group, it is the player number.
@DogmaiSEA: Go
Ah. I was under the impression that, to access the killing player, the system was referencing a player group to find the index. Thanks for the info.
/thread hijack
Fixed. I changed all the cumputer players, which they were suppose to be anyways.
Still, it doesnt make since that this happens.