Is personal res overflow supposed to be in the game?
lwf
Join Date: 2006-11-03 Member: 58311Members, Constellation
Join Date: 2006-11-03 Member: 58311Members, Constellation
<!--QuoteBegin-http://www.unknownworlds.com/ns2/news/2012/1/ns2_build_192_released+--><div class='quotetop'>QUOTE (http://www.unknownworlds.com/ns2/news/2012/1/ns2_build_192_released)</div><div class='quotemain'><!--QuoteEBegin-->Balance:
<ul><li>Personal resources have now a limit of 100 per player. Any overflow will be split amongst the other players on the team.</li></ul><!--QuoteEnd--></div><!--QuoteEEnd-->
PRes overflow was added in build 192 but isn't working anymore. I can't find PRes overflow being mentioned again in later changelogs so I don't know if this is a bug or bad documentation.
Is personal res overflow supposed to be in the game?
<ul><li>Personal resources have now a limit of 100 per player. Any overflow will be split amongst the other players on the team.</li></ul><!--QuoteEnd--></div><!--QuoteEEnd-->
PRes overflow was added in build 192 but isn't working anymore. I can't find PRes overflow being mentioned again in later changelogs so I don't know if this is a bug or bad documentation.
Is personal res overflow supposed to be in the game?
Comments
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->function PlayingTeam:UpdateResourceTowers()
if self.timeSinceLastRTUpdate + kResourceTowerResourceInterval < Shared.GetTime() then
self.timeSinceLastRTUpdate = Shared.GetTime()
local numRTs = 0
local numSupportedHarvesters = kMinSupportedRTs + self:GetNumCapturedTechPoints() * kRTsPerTechpoint
// update resource towers
for index, resourceTower in ipairs(GetEntitiesForTeam("ResourceTower", self:GetTeamNumber())) do
/*
if numRTs >= numSupportedHarvesters then
break
end
*/
if resourceTower:GetIsCollecting() then
resourceTower:CollectResources()
numRTs = numRTs + 1
end
end
// update resources
local pResGained = numRTs * kPlayerResPerInterval * self:GetPresRecipientCount()
local tResGained = numRTs * kTeamResourcePerTick
self:SplitPres(pResGained)
self:AddTeamResources(tResGained)
end
end<!--c2--></div><!--ec2-->
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->function PlayingTeam:GetPresRecipientCount()
local recipientCount = 0
for i, playerId in ipairs(self.playerIds) do
local player = Shared.GetEntity(playerId)
if player and player:GetResources() < kMaxPersonalResources and player:GetIsAlive() and not player:isa("Commander") then
recipientCount = recipientCount + 1
end
end
return recipientCount
end<!--c2--></div><!--ec2-->
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->// split resources to all players until their they either have all reached the maximum or the rewarded res was splitted evenly
function PlayingTeam:SplitPres(resAwarded)
local recipientCount = self:GetPresRecipientCount()
for i = 1, recipientCount do
if resAwarded <= 0.001 or recipientCount <= 0 then
break;
end
local resPerPlayer = resAwarded / recipientCount
for i, playerId in ipairs(self.playerIds) do
local player = Shared.GetEntity(playerId)
if player and player:GetIsAlive() and not player:isa("Commander") then
resAwarded = resAwarded - player:AddResources(resPerPlayer)
end
end
recipientCount = self:GetPresRecipientCount()
end
end<!--c2--></div><!--ec2-->
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->function Player:AddResources(amount)
local resReward = math.min(amount, kMaxPersonalResources - self:GetResources())
local oldRes = self.resources
self:SetResources(self:GetResources() + resReward)
if oldRes ~= self.resources then
self:SetScoreboardChanged(true)
end
return resReward
end<!--c2--></div><!--ec2-->
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.
So, no res overflow, no resources split. Just plain raw x restowers is x res for you. As suspected.
So, no res overflow, no resources split. Just plain raw x restowers is x res for you. As suspected.<!--QuoteEnd--></div><!--QuoteEEnd-->
That's actually not what he said, nor what the code reflects. And after a theory to practice is does work, but as noticed it's not a huge amount. If one player is maxed out you won't really get much more than normal but you will see your res ticks go up by about .1 or .2 depending on how big the game is. It also works the same for team res as well which is actually a larger boost I believe.
Assuming this applies for Aliens as well? This is probably more handy for a team with a dominating Onos to give the rest of lifeforms a bit of catchup to end the game quicker.
Assuming this applies for Aliens as well? This is probably more handy for a team with a dominating Onos to give the rest of lifeforms a bit of catchup to end the game quicker.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes it does work for aliens also. This is why a gorge with 100 res isn't really that bad all in all.
<!--quoteo(post=2050247:date=Dec 23 2012, 08:20 AM:name=lwf)--><div class='quotetop'>QUOTE (lwf @ Dec 23 2012, 08:20 AM) <a href="index.php?act=findpost&pid=2050247"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->PRes overflow was added in build 192 <!--sizeo:3--><span style="font-size:12pt;line-height:100%"><!--/sizeo--><b>but isn't working anymore</b><!--sizec--></span><!--/sizec-->. I can't find PRes overflow being mentioned again in later changelogs so I don't know if this is a bug or bad documentation.
Is personal res overflow supposed to be in the game?<!--QuoteEnd--></div><!--QuoteEEnd-->
a gorge with 100 res isnt really that bad all in all ... IF RES OVERFLOW WAS WORKING ... i take it ?
You just quoted 1 guy who was wrong, and 2 people who just showed you the code and told you after testing that it does work... WTF are you talking about?
the guy who showed the code was the op ... WTF are you smoking ?
100% confirmed that pres overflow IS NOT IN THE GAME. If you have 100 pres, your pres income is wasted.
Well since it was two different things and it's late, i assumed it was a different guy. Why would someone post something then post the contrary? Then I realized he was saying something that was incorrect.
<!--quoteo(post=2050500:date=Dec 23 2012, 08:45 PM:name=GORGEous)--><div class='quotetop'>QUOTE (GORGEous @ Dec 23 2012, 08:45 PM) <a href="index.php?act=findpost&pid=2050500"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I just retested this empirically in game.
100% confirmed that pres overflow IS NOT IN THE GAME. If you have 100 pres, your pres income is wasted.<!--QuoteEnd--></div><!--QuoteEEnd-->
We got 2 very different results then, how did you test? It would be easy to test just by checking your res count when people die because they won't be part of the count and therefor not figured into the split.
But if you're interested here is a break down of the split res code
// split resources to all players until they either have all reached the maximum or the rewarded res was splitted evenly
function PlayingTeam:SplitPres(resAwarded)
local recipientCount = self:GetPresRecipientCount() // <b>This loads the number of people that are allowed to get resources</b>
for i = 1, recipientCount do // <b>This is the beginning of a for loop that starts at 1 and goes up to the number of people who can receive res</b>
if resAwarded <= 0.001 or recipientCount <= 0 then // <b>This condition checks if the amount of res is less than or = to .001 or if the count is less than = to 0 and stops the procedure if it is</b>
break;
end
local resPerPlayer = resAwarded / recipientCount // <b>this is where it decides how much to split by dividing the res to be given by the number of players available</b>
for i, playerId in ipairs(self.playerIds) do // <b>This loop actually gives the res to each player based on their playerid #</b>
local player = Shared.GetEntity(playerId) // <b>This selects player based on playerid #</b>
if player and player:GetIsAlive() and not player:isa("Commander") then // <b>This checks to make sure the player is not a commander and is alive</b>
resAwarded = resAwarded - player:AddResources(resPerPlayer) // <b>This part gets pretty tricky, the short version is that if resPerPlayer which is resAwarded divided by number of players is less than current player res and max res that much will be subtracted from res awarded. Basically it's just a check to make sure you're not getting more than the usual number of resources per tick cause if it's greater than 1 you'll get 0 or close to it.</b>
end
end
recipientCount = self:GetPresRecipientCount()
end
end
What does it all mean? Well basically as the recipient count goes down, the amount that the res is being split up is lessened. So if your team has 2 towers and 5 players active, you should get about .25 per tick (assuming the res interval is .125). Now if you have 4 players active you'll get .31, 3 players .42, and so on. The code seems correct to me. Now from my test which was basically putting 2 players on marine team with a bunch of towers and then checking if the pres gained changed once we got to 100, I'd say it works.
Not if it's a good gorge, I think...like in the range of 120pts/ k3/d4 when the round ends (pub play).
To bad he may have 100 PRes not being spend, but appearantly, bit by bit the overflow is being spread over the team, which is sortof comforting.
An Alien commander needs such a gorge more, than a 4th or 5th Onos.
To bad he may have 100 PRes not being spend, but appearantly, bit by bit the overflow is being spread over the team, which is sortof comforting.
An Alien commander needs such a gorge more, than a 4th or 5th Onos.<!--QuoteEnd--></div><!--QuoteEEnd-->
thats a terrible gorge
and res overflow is broken according to 2 people. The only person that has tried to say that it isnt ... seems too derpy to take seriously
I guess we should remove the "player:GetResources() < kMaxPersonalResources" condition in GetPresRecipientCount, to ensure that pResGained in UpdateResourceTowers is not affected by resource capped players.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->function PlayingTeam:GetPresRecipientCount()
local recipientCount = 0
for i, playerId in ipairs(self.playerIds) do
local player = Shared.GetEntity(playerId)
if player and player:GetResources() < kMaxPersonalResources and player:GetIsAlive() and not player:isa("Commander") then
recipientCount = recipientCount + 1
end
end
return recipientCount
end<!--c2--></div><!--ec2-->
Now, res overflow is supposed to work, but SplitPres got quite inefficient. In case some reached the resource cap, the code in the inner loop will be executed playerCount^2 times. We should do something to prevent this from happening:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->// split resources to all players until their they either have all reached the maximum or the rewarded res was splitted evenly
function PlayingTeam:SplitPres(resAwarded)
local recipientCount = self:GetPresRecipientCount()
for i = 1, recipientCount do
local resPerPlayer = resAwarded / recipientCount
local awardedCount = 0
for i, playerId in ipairs(self.playerIds) do
local player = Shared.GetEntity(playerId)
if player and player:GetIsAlive() and not player:isa("Commander") and player:GetResources() < kMaxPersonalResources then
resAwarded = resAwarded - player:AddResources(resPerPlayer)
awardedCount = awardedCount + 1
end
end
if resAwarded <= 0.001 or awardedCount <= 0 then
break;
end
recipientCount = awardedCount
end
end<!--c2--></div><!--ec2-->
(The code is untested and it may contain/cause issues.)
is that you SANTA ? :D
I tested it in game in a controlled setting.
Two players. 8 RTs to provide exactly 1 pres per tick. First player joins and caps pres. Second player joins and watches their pres ticks. It went up by 1 every time, never more than one. And the actual timing matched up exactly. IE they had 40 pres after 20 ticks (started with 20). Thus, I concluded that pres overflow does not work.
(there are some discrepencies in real game situations where when you first cap it seems like your pres will overflow, but it will only do it once... i think)
<img src="http://tdotcomics.ca/wordpress/wp-content/uploads/2012/10/aliens-meme.jpg" border="0" class="linked-image" />
Because in the split pres section it takes the total res awarded and divides it by the number of players able to get it. Refer back to a few pages ago. But it's pretty clear mathematically that if you split something by 5 it will be less than if you split it by 4.
There does seem to be an issue with the way that the splitres function is called. I'm not sure exactly why it's called by self, i'm sure max could explain that. Personally I'm not sure why that is since I haven't read the code for self.
local pResGained = numRTs * kPlayerResPerInterval * self:GetPresRecipientCount()
self:SplitPres(pResGained)
<a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=125969#entry2051113" target="_blank">http://www.unknownworlds.com/ns2/forums/in...69#entry2051113</a>
This will help the comm who is short on res an increase in res flow for quicker upgrades.
Not sure if this is possible but coding it should be pretty easy I would imagine
100% confirmed via controlled testing in game w/ 2 players. Pres overflow DOES NOT work.
This will help the comm who is short on res an increase in res flow for quicker upgrades.
Not sure if this is possible but coding it should be pretty easy I would imagine<!--QuoteEnd--></div><!--QuoteEEnd-->
I like this.
local pResGained = numRTs * kPlayerResPerInterval * self:GetPresRecipientCount()
self:SplitPres(pResGained)<!--QuoteEnd--></div><!--QuoteEEnd-->
/Facepalm... Did you not notice that pResGained is used right there in the SplitPres function? And then if you actually LOOK in that function rather than assume that pResGained is the variable that actually assigns the res vice the variable it becomes in that function which is resAwarded you might actually understand rather than pretend to, thank you very much for giving me a headache through sheer ignorance.
Just to make it a little easier for you, here's the appropriate line in the SplitPres function: "local resPerPlayer = resAwarded / recipientCount"
*Edit: Found the actual fix down below.