I dont think you understand enough about programming to understand what is going on in that function, im not going to waste my time trying to explain to you why it doesnt work. Its been confirmed via in game testing to not work, yet you still seem to think it does and also have a terrible attitude about it?
<!--quoteo(post=2051390:date=Dec 26 2012, 09:56 AM:name=xDragon)--><div class='quotetop'>QUOTE (xDragon @ Dec 26 2012, 09:56 AM) <a href="index.php?act=findpost&pid=2051390"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I dont think you understand enough about programming to understand what is going on in that function, im not going to waste my time trying to explain to you why it doesnt work. Its been confirmed via in game testing to not work, yet you still seem to think it does and also have a terrible attitude about it?
No Thanks.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is why you get negativity from me, you assume I have no idea what I'm talking about when I can guarantee I have far more experience than you. I agree that it isn't working the way it's supposed to, except under some very odd circumstances. All you've done is copy and paste 2 lines that don't prove anything other than you found 2 lines that have the word res is them, and you somehow think those 2 are the only ones that handle the actual assignments for the variables in question. Team res does seem to filter down when it's maxed, however pRes does not.
In conclusion if you don't believe me then plug some numbers in and go through it all like I did and you might understand. I've done my best to explain in great detail what every line is doing but you don't seem to care to read it, instead you only say that I have a negative attitude. If you think I'm really not understanding something feel free to read what I said fully, then explain with at least some amount of detail. Why people think everything is a huge secret and try to bluff their way into seeming knowledgeable I'll never understand. If you go to any programming forum people will clearly state what you did wrong and how you should fix it.
And just to further prove to you that I do know what I'm talking about when it comes to programming here's a link to one game I'm making by myself <a href="http://www.indiedb.com/games/apocalypse-not" target="_blank">Apocalypse Not on IndieDB</a>. I'm sure you'll say something pointless about how it looks like trash or you don't like my choice in engines, but I could care less. The fact is I once again have shown something tangible while you can do nothing but trash talk. I apologize if I seem out of line, but I give people back the same attitude I get.
After thinking about it I believe you might be trying to say that the splitres function doesn't do anything because it divides by the same number that the resources are multiplied by. Which I agree is the heart of the problem, but the part before SplitPres and the part where it divides it aren't the issue, it's the recipient count that is the actual problem, see below.
<!--quoteo(post=2051389:date=Dec 26 2012, 09:48 AM:name=lwf)--><div class='quotetop'>QUOTE (lwf @ Dec 26 2012, 09:48 AM) <a href="index.php?act=findpost&pid=2051389"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Davil, it wouldn't hurt you to show some humility.<!--QuoteEnd--></div><!--QuoteEEnd-->
I know, but when a dude points out 2 lines from one script and acts like he just found the holy grail and I just missed something obvious it's like having a 2 year old tell you where babies come from. You don't really even know where to start trying to explain the truth to them so you just have to sit there and smile.
This line in AddResources I didn't notice at first: "self:SetResources(self:GetResources() + resReward)"
This should be saying ok take the number of resources we're splitting and add them to current resources. But it's strange that the game will always give you the full amount of resources and never the split amount. Going by the code if you have 8 resources towers that 8 * .125 * 5 if you have 5 people capable of receiving res. So then it takes that number and puts it into SplitPres. That number is now stored in resAwarded then divided by 5 and stored in resPerPlayer. That number will be used in the for loop and each time a player receives res it's subtracted from resAwarded so each player should receive 1 which they currently do.
Now the actual problem is that even if a player is dead or has max res they still seem to be added to that recipient count. Also that the recipient count isn't counting people that have max res when it multiples the total res to be given out at the start which makes the split meaningless in a way. So the initial recipient count should include people that have max res and are dead, the second one used in SplitPres however, should not. That way the following could happen.
8 towers * .125 * 5 players total = 5 The split would read that there is 5 res to be given but only 3 people capable of receiving so it divides 5 by 3 giving 1.67 instead of the current 1.
<!--quoteo(post=2050376:date=Dec 23 2012, 02:33 PM:name=lwf)--><div class='quotetop'>QUOTE (lwf @ Dec 23 2012, 02:33 PM) <a href="index.php?act=findpost&pid=2050376"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The total PRes to be distributed every 6 seconds is calculated using "pResGained = numRTs * kPlayerResPerInterval (which is 0.125) * GetPresRecipientCount()".
GetPresRecipientCount returns the amount of players in the team that are alive, not commanding and has less than 100 res.
SplitRes is then called from UpdateResourceTowers with the total amount of PRes (pResGained, but now called resAwarded) to distribute to all the players in the team, which SplitRes will proceed to do. The requirements for receiving res is the same which was used to allocate the total PRes to be distributed. You must be alive, you must not be the commander and players with 100 res will not take anything from the total amount.
It all comes down to the first calculation I mentioned, from UpdateResourceTowers. All this means that each player will always receive the same amount of PRes per RTs no matter what (there's an exception but it's small enough not to even be worth mentioning) since the total comes from "0.125 * owned RTs * players that can receive res", which is then split evenly between the very same players that can receive res. For res overflow to work it could be "0.125 * owned RTs * players that are alive, not counting the commander (unless you would want the commanders PRes to go to players as well)" and then distribute that in the same fashion. Hope I got that right.<!--QuoteEnd--></div><!--QuoteEEnd-->
You didn't mention the split at all, and then you just told me to look at the code before the splitpres call. If you had just said the GetPresRecipientCount() function isn't right for what it's used for initially I'd have understood completely. It just needs to count EVERYONE initially and then only count the players who should be receiving res later. Really I don't see why they didn't use a variable that is linked to the total people on the team to begin with rather than running another loop to count them.
But yea it was a good catch I just could understand what you were trying to say without seeing the numbers.
The question remains though, is PRes overflow even supposed to work or was it removed intentionally? UWE has a track record of not documenting changes, even post-release, so it's certainly possible. I am however sure the PRes lost due to dead players is intended, I believe I've heard Hugh talk about that during a Q&A or some other video, but not overflow.
Im sure I have absolutely no idea what I'm talking about, considering I have never worked with the lua in this game before, or made any mods for it.
I never once gave any attitude in my post, just being factual. If you take offense to that well im sorry your so sensitive but thats not my fault. And as I said before those two lines are important because it determines how much res is distributed between the players by the SplitPres function. And it uses the same GetPresRecipientCount function that is used in SplitPres. So if it calculates 5 recieving players for 5 rts at .125 a player, it passes 3.125 to SplitPres.
SplitPres then loops from 1 to the Recipient Count, which is obtained from the same function GetPresRec.. It then divides the resamount by that recipient count, which gets you the .625 per player. It then does another loop, which uses the same variable 'I' as the parent loop (a bug I presume) and loops through all the playerids stored on that team and distributes the res accordingly. They only way there is any possible overflow in that situation is if some people have say 99.9 res, and can only recieve a portion of the .625 they are allotted. However since the same variable I is used there I doubt that this would ever happen, as after it has looped through all the playerIDs the 'I' variable should always be greater than the recipient count, and it should exit that loop also.
There is two 'bugs' there if your looking at it correctly and if res overflow with res calculated for the entire team is supposed to still be in the game. First being that the initial amount is calculated using only the players that can recieve instead of everyone on the team sans commander. This goes back to those two lines I posted, basically if they want the resources to be calculated for all players always, it should use something like #self.playerIds instead of self:GetPresRecipientCount(). The second being how the 'I' variable is used in both loops which I believe causes excess to never be distributed, although this really accounts for a small amount of res overall (generally probably <1 pres per player per game).
<!--quoteo(post=2052031:date=Dec 27 2012, 02:45 PM:name=lwf)--><div class='quotetop'>QUOTE (lwf @ Dec 27 2012, 02:45 PM) <a href="index.php?act=findpost&pid=2052031"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The question remains though, is PRes overflow even supposed to work or was it removed intentionally? UWE has a track record of not documenting changes, even post-release, so it's certainly possible. I am however sure the PRes lost due to dead players is intended, I believe I've heard Hugh talk about that during a Q&A or some other video, but not overflow.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well it seems odd given that they typically like to reward people for staying alive. Have you tried messaging one of them directly about it?
<!--quoteo(post=2052303:date=Dec 28 2012, 07:38 AM:name=xDragon)--><div class='quotetop'>QUOTE (xDragon @ Dec 28 2012, 07:38 AM) <a href="index.php?act=findpost&pid=2052303"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Im sure I have absolutely no idea what I'm talking about, considering I have never worked with the lua in this game before, or made any mods for it.
I never once gave any attitude in my post, just being factual. If you take offense to that well im sorry your so sensitive but thats not my fault. And as I said before those two lines are important because it determines how much res is distributed between the players by the SplitPres function. And it uses the same GetPresRecipientCount function that is used in SplitPres. So if it calculates 5 recieving players for 5 rts at .125 a player, it passes 3.125 to SplitPres.
SplitPres then loops from 1 to the Recipient Count, which is obtained from the same function GetPresRec.. It then divides the resamount by that recipient count, which gets you the .625 per player. It then does another loop, which uses the same variable 'I' as the parent loop (a bug I presume) and loops through all the playerids stored on that team and distributes the res accordingly. They only way there is any possible overflow in that situation is if some people have say 99.9 res, and can only recieve a portion of the .625 they are allotted. However since the same variable I is used there I doubt that this would ever happen, as after it has looped through all the playerIDs the 'I' variable should always be greater than the recipient count, and it should exit that loop also.
There is two 'bugs' there if your looking at it correctly and if res overflow with res calculated for the entire team is supposed to still be in the game. First being that the initial amount is calculated using only the players that can recieve instead of everyone on the team sans commander. This goes back to those two lines I posted, basically if they want the resources to be calculated for all players always, it should use something like #self.playerIds instead of self:GetPresRecipientCount(). The second being how the 'I' variable is used in both loops which I believe causes excess to never be distributed, although this really accounts for a small amount of res overall (generally probably <1 pres per player per game).<!--QuoteEnd--></div><!--QuoteEEnd-->
We had a misunderstanding so we move on, no hurt feelings on this side mate.
As for the code, I'm sure they have a variable that counts members of the team since that number is on the scoreboard. They should probably just use that * RT's * .125 instead of recipient count.
As for the loops the first one seems to be ok as it limits the number of times the res is divided to the number of recepients used in the actual division. So for example
for i = 1, recipientCount do
we could say the recipient count was 5 so the the result is it counts 1, 2 , 3, 4 ,5 and stops which makes sense as opposed to starting with 0 which would divide it 6 times.
Now the second loop using ipairs is a bit more tricky. ipairs is basically used for stateless iterators like arrays which is what I would guess the playerIDs must be stored in. It takes the variable a as an argument and uses that as the 'invariant state'. It uses the variable behind it as the iterator and the initial i as just a place holder of sorts. So to explain it in more detail would be like this:
for i, playerId in ipairs(self.playerIds) do
i - used as a counter and not needed to be set as anything initially playerId - is the interator, each iteration will be by this amount ipairs(self.playerIds) - is the array that is being read
We can assume that this is working otherwise addResources would never be called which is the actual function that assigns resources to the player. Well we can at least assume it's not giving too few otherwise someone would get no resources that should have. And generally trying to read from an array that does not exist will cause an error at the least.
<!--quoteo(post=2052729:date=Dec 28 2012, 11:14 PM:name=piratedave)--><div class='quotetop'>QUOTE (piratedave @ Dec 28 2012, 11:14 PM) <a href="index.php?act=findpost&pid=2052729"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->youve basically made a fool of yourself in this thread and now just what exactly are you trying to prove ?<!--QuoteEnd--></div><!--QuoteEEnd-->
You quote me saying ... but i didn't say that. I haven't made a fool out of myself at all. In fact I reached the same conclusion as everyone else but just managed to actually explain it in more detail. And as for you I'm not even sure why you're bothering to necro old topics just to talk ######. Just go away how about?
<!--quoteo(post=2052936:date=Dec 30 2012, 04:35 AM:name=Davil)--><div class='quotetop'>QUOTE (Davil @ Dec 30 2012, 04:35 AM) <a href="index.php?act=findpost&pid=2052936"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You quote me saying ... but i didn't say that. I haven't made a fool out of myself at all. In fact I reached the same conclusion as everyone else but just managed to actually explain it in more detail. And as for you I'm not even sure why you're bothering to necro old topics just to talk ######. Just go away how about?<!--QuoteEnd--></div><!--QuoteEEnd-->
Him quoting your post as saying ... is his way of saying "your entire post" without stretching the page down another 2 scrolls.
Comments
No Thanks.
No Thanks.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is why you get negativity from me, you assume I have no idea what I'm talking about when I can guarantee I have far more experience than you. I agree that it isn't working the way it's supposed to, except under some very odd circumstances. All you've done is copy and paste 2 lines that don't prove anything other than you found 2 lines that have the word res is them, and you somehow think those 2 are the only ones that handle the actual assignments for the variables in question. Team res does seem to filter down when it's maxed, however pRes does not.
In conclusion if you don't believe me then plug some numbers in and go through it all like I did and you might understand. I've done my best to explain in great detail what every line is doing but you don't seem to care to read it, instead you only say that I have a negative attitude. If you think I'm really not understanding something feel free to read what I said fully, then explain with at least some amount of detail. Why people think everything is a huge secret and try to bluff their way into seeming knowledgeable I'll never understand. If you go to any programming forum people will clearly state what you did wrong and how you should fix it.
And just to further prove to you that I do know what I'm talking about when it comes to programming here's a link to one game I'm making by myself <a href="http://www.indiedb.com/games/apocalypse-not" target="_blank">Apocalypse Not on IndieDB</a>. I'm sure you'll say something pointless about how it looks like trash or you don't like my choice in engines, but I could care less. The fact is I once again have shown something tangible while you can do nothing but trash talk. I apologize if I seem out of line, but I give people back the same attitude I get.
After thinking about it I believe you might be trying to say that the splitres function doesn't do anything because it divides by the same number that the resources are multiplied by. Which I agree is the heart of the problem, but the part before SplitPres and the part where it divides it aren't the issue, it's the recipient count that is the actual problem, see below.
I know, but when a dude points out 2 lines from one script and acts like he just found the holy grail and I just missed something obvious it's like having a 2 year old tell you where babies come from. You don't really even know where to start trying to explain the truth to them so you just have to sit there and smile.
This should be saying ok take the number of resources we're splitting and add them to current resources. But it's strange that the game will always give you the full amount of resources and never the split amount. Going by the code if you have 8 resources towers that 8 * .125 * 5 if you have 5 people capable of receiving res. So then it takes that number and puts it into SplitPres. That number is now stored in resAwarded then divided by 5 and stored in resPerPlayer. That number will be used in the for loop and each time a player receives res it's subtracted from resAwarded so each player should receive 1 which they currently do.
Now the actual problem is that even if a player is dead or has max res they still seem to be added to that recipient count. Also that the recipient count isn't counting people that have max res when it multiples the total res to be given out at the start which makes the split meaningless in a way. So the initial recipient count should include people that have max res and are dead, the second one used in SplitPres however, should not. That way the following could happen.
8 towers * .125 * 5 players total = 5
The split would read that there is 5 res to be given but only 3 people capable of receiving so it divides 5 by 3 giving 1.67 instead of the current 1.
Eureka the problem is solved.
GetPresRecipientCount returns the amount of players in the team that are alive, not commanding and has less than 100 res.
SplitRes is then called from UpdateResourceTowers with the total amount of PRes (pResGained, but now called resAwarded) to distribute to all the players in the team, which SplitRes will proceed to do. The requirements for receiving res is the same which was used to allocate the total PRes to be distributed. You must be alive, you must not be the commander and players with 100 res will not take anything from the total amount.
It all comes down to the first calculation I mentioned, from UpdateResourceTowers. All this means that each player will always receive the same amount of PRes per RTs no matter what (there's an exception but it's small enough not to even be worth mentioning) since the total comes from "0.125 * owned RTs * players that can receive res", which is then split evenly between the very same players that can receive res. For res overflow to work it could be "0.125 * owned RTs * players that are alive, not counting the commander (unless you would want the commanders PRes to go to players as well)" and then distribute that in the same fashion. Hope I got that right.<!--QuoteEnd--></div><!--QuoteEEnd-->
You didn't mention the split at all, and then you just told me to look at the code before the splitpres call. If you had just said the GetPresRecipientCount() function isn't right for what it's used for initially I'd have understood completely. It just needs to count EVERYONE initially and then only count the players who should be receiving res later. Really I don't see why they didn't use a variable that is linked to the total people on the team to begin with rather than running another loop to count them.
But yea it was a good catch I just could understand what you were trying to say without seeing the numbers.
I never once gave any attitude in my post, just being factual. If you take offense to that well im sorry your so sensitive but thats not my fault. And as I said before those two lines are important because it determines how much res is distributed between the players by the SplitPres function. And it uses the same GetPresRecipientCount function that is used in SplitPres. So if it calculates 5 recieving players for 5 rts at .125 a player, it passes 3.125 to SplitPres.
SplitPres then loops from 1 to the Recipient Count, which is obtained from the same function GetPresRec.. It then divides the resamount by that recipient count, which gets you the .625 per player. It then does another loop, which uses the same variable 'I' as the parent loop (a bug I presume) and loops through all the playerids stored on that team and distributes the res accordingly. They only way there is any possible overflow in that situation is if some people have say 99.9 res, and can only recieve a portion of the .625 they are allotted. However since the same variable I is used there I doubt that this would ever happen, as after it has looped through all the playerIDs the 'I' variable should always be greater than the recipient count, and it should exit that loop also.
There is two 'bugs' there if your looking at it correctly and if res overflow with res calculated for the entire team is supposed to still be in the game. First being that the initial amount is calculated using only the players that can recieve instead of everyone on the team sans commander. This goes back to those two lines I posted, basically if they want the resources to be calculated for all players always, it should use something like #self.playerIds instead of self:GetPresRecipientCount(). The second being how the 'I' variable is used in both loops which I believe causes excess to never be distributed, although this really accounts for a small amount of res overall (generally probably <1 pres per player per game).
Well it seems odd given that they typically like to reward people for staying alive. Have you tried messaging one of them directly about it?
<!--quoteo(post=2052303:date=Dec 28 2012, 07:38 AM:name=xDragon)--><div class='quotetop'>QUOTE (xDragon @ Dec 28 2012, 07:38 AM) <a href="index.php?act=findpost&pid=2052303"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Im sure I have absolutely no idea what I'm talking about, considering I have never worked with the lua in this game before, or made any mods for it.
I never once gave any attitude in my post, just being factual. If you take offense to that well im sorry your so sensitive but thats not my fault. And as I said before those two lines are important because it determines how much res is distributed between the players by the SplitPres function. And it uses the same GetPresRecipientCount function that is used in SplitPres. So if it calculates 5 recieving players for 5 rts at .125 a player, it passes 3.125 to SplitPres.
SplitPres then loops from 1 to the Recipient Count, which is obtained from the same function GetPresRec.. It then divides the resamount by that recipient count, which gets you the .625 per player. It then does another loop, which uses the same variable 'I' as the parent loop (a bug I presume) and loops through all the playerids stored on that team and distributes the res accordingly. They only way there is any possible overflow in that situation is if some people have say 99.9 res, and can only recieve a portion of the .625 they are allotted. However since the same variable I is used there I doubt that this would ever happen, as after it has looped through all the playerIDs the 'I' variable should always be greater than the recipient count, and it should exit that loop also.
There is two 'bugs' there if your looking at it correctly and if res overflow with res calculated for the entire team is supposed to still be in the game. First being that the initial amount is calculated using only the players that can recieve instead of everyone on the team sans commander. This goes back to those two lines I posted, basically if they want the resources to be calculated for all players always, it should use something like #self.playerIds instead of self:GetPresRecipientCount(). The second being how the 'I' variable is used in both loops which I believe causes excess to never be distributed, although this really accounts for a small amount of res overall (generally probably <1 pres per player per game).<!--QuoteEnd--></div><!--QuoteEEnd-->
We had a misunderstanding so we move on, no hurt feelings on this side mate.
As for the code, I'm sure they have a variable that counts members of the team since that number is on the scoreboard. They should probably just use that * RT's * .125 instead of recipient count.
As for the loops the first one seems to be ok as it limits the number of times the res is divided to the number of recepients used in the actual division. So for example
for i = 1, recipientCount do
we could say the recipient count was 5 so the the result is it counts 1, 2 , 3, 4 ,5 and stops which makes sense as opposed to starting with 0 which would divide it 6 times.
Now the second loop using ipairs is a bit more tricky. ipairs is basically used for stateless iterators like arrays which is what I would guess the playerIDs must be stored in. It takes the variable a as an argument and uses that as the 'invariant state'. It uses the variable behind it as the iterator and the initial i as just a place holder of sorts. So to explain it in more detail would be like this:
for i, playerId in ipairs(self.playerIds) do
i - used as a counter and not needed to be set as anything initially
playerId - is the interator, each iteration will be by this amount
ipairs(self.playerIds) - is the array that is being read
We can assume that this is working otherwise addResources would never be called which is the actual function that assigns resources to the player. Well we can at least assume it's not giving too few otherwise someone would get no resources that should have. And generally trying to read from an array that does not exist will cause an error at the least.
youve basically made a fool of yourself in this thread and now just what exactly are you trying to prove ?
You quote me saying ... but i didn't say that. I haven't made a fool out of myself at all. In fact I reached the same conclusion as everyone else but just managed to actually explain it in more detail. And as for you I'm not even sure why you're bothering to necro old topics just to talk ######. Just go away how about?
Him quoting your post as saying ... is his way of saying "your entire post" without stretching the page down another 2 scrolls.