Not a Bug: Out of sync GB view causes incorrect amount of FPs added (and GB levels)

[scibuff]

When I open a Great Building window to add forge points (via the input box), it correctly calculates the amount of remaining FPs and uses that value as the max I can contribute. Nevertheless, if someone else adds forge points the amount I end up adding is incorrect (and can cause the great building to level).

For example, let's say that a level of a GB costs 1000 FPs. I open the GB view to contribute there are no FPs added (current count is 0/1000), I try to add 500 FPs. But while I'm doing that someone adds 600 FPs to the building. I try to contribute 500 but instead 400 FPs are added (I take an incorrect slot = lose FPs) and the building is leveled.

The correct behavior should be that if I try to add forge points and my GB view is out of sync (i.e. forge points have been added), there should be an error message and the view should update before any forge points are taken.

• World: en9 (but the issue is on all worlds)
• Browser and Version: Chrome/80.0.3987.163
• Overview of the bug: Tell us what happens when this bug occurs, what prompts the bug to occur - include as much information about the bug as you can, so that we can address it. The more descriptive you can be, the more chance we have of understanding you.
• Screenshots: N/A
• How often this occurs: Every time the GB view is out of sync and the user tries to add more FPs than the remaining amount
• Urgency: game changing (unexpected behavior =
• Preventative Actions: Can't be prevented and the GB view can always get out of sync?
• Summary: Out of sync GB view causes incorrect amount of FPs added
• I have performed a quicksearch of the forums using a select few keywords relating to my bug to see if it has already been reported: Yes.
• Have you tried fixing it by using these methods? Yes?

1.175.28fad09de71 (01.04.2020 10:51), scibuff (6869907), en9, en_US, WEB 7,1,1,0, Windows 10, Chrome/80.0.3987.163, 2133x1041, OpenGL Vendor=WebKit Version=WebGL 2.0 (OpenGL ES 3.0 Chromium) Renderer=WebKit WebGL GLSL=WebGL GLSL ES 3.00 (OpenGL ES GLSL ES 3.0 Chromium) (512 MB VRAM)

 

[Agent327]

Your view isn't out of sync, you are to slow and about the 50th to come up with this. It isn't a bug.

 

[DeletedUser]

I try to contribute 500 but instead 400 FPs are added

It isn't a bug.

Seems like a visual one, which makes it a bug

 

[Cursedveggie]

The GB amounts are correct at the moment you open the window. Even if they added some sort of refresh every 0.5 seconds or so someone would still lose out

 

[DeletedUser]

Even if they added

2 solutions, the 1 is to enable max cap to correct the amount at the same time that someone adds and the 2 is to remove the max cap completely
i agree it has interest the way it is now, but it is a bug the way he described it..
*Its not because he loses FP, its because it keeps displaying wrong numbers !*

 

[scibuff]

Your view isn't out of sync, you are to slow and about the 50th to come up with this. It isn't a bug.

It might have been reported before but I don't see it anywhere in the current or accepted bugs. And I beg to differ ... what else (other then "out of sync") do you call the client showing 0/1000 when on the server it is 500/1000?

 

[Agent327]

It might have been reported before but I don't see it anywhere in the current or accepted bugs. And I beg to differ ... what else (other then "out of sync") do you call the client showing 0/1000 when on the server it is 500/1000?

Like said before. You are to slow. Difference between 0/1000 and 500/1000 could be 1 millisecond. Would you see the adjustment?

 

[scibuff]

2 solutions, the 1 is to enable max cap to correct the amount at the same time that someone adds and the 2 is to remove the max cap completely
i agree it has interest the way it is now, but it is a bug the way he described it..
*Its not because he loses FP, its because it keeps displaying wrong numbers !*

Actually, a much simpler solution would be if the client including the "current" state along with the number of FPs when communicating with the server. For example, when I try to add 500 FPs the request data should include that the GB state was 0/1000. When the server receives the request, it should first check if that state (0/1000) matches the current state on the server. Alternatively, the request to add 500 FPs could be rejected if it is no longer possible to add that many (instead of adding just 400), i.e. it should be all or nothing.

 

[scibuff]

Like said before. You are to slow. Difference between 0/1000 and 500/1000 could be 1 millisecond. Would you see the adjustment?

It doesn't matter. I understand that it is not possible to keep the client perfectly synced. But the server behavior should be all or nothing, i.e. either accept the full amount I'm trying to add or return an out-of-sync error (accept 0)

 

[Cursedveggie]

It doesn't matter. I understand that it is not possible to keep the client perfectly synced. But the server behavior should be all or nothing, i.e. either accept the full amount I'm trying to add or return an out-of-sync error (accept 0)

On many threads most people put the exact amount to allow someone to take a spot at 1.9.

This means 2 people can add the spot + 90% price at the same time and both would add the full amount to the GB levelling it.

Person 1 is ok, person 2 loses out by getting the next spot down but your all or nothing scenario passes as both have added the amount they requested

 

[DeletedUser96901]

the solution would be very simple
the server should decline a donation if it doesn't fit in complete
(I even suggested this in the years before it came when players discussed that they want this feature)

On many threads most people put the exact amount to allow someone to take a spot at 1.9.

This means 2 people can add the spot + 90% price at the same time and both would add the full amount to the GB levelling it.

Person 1 is ok, person 2 loses out by getting the next spot down but your all or nothing scenario passes as both have added the amount they requested

put one FP more in to secure place 1
place 1 still would need 190%
but place 2 one FP less
FP donation thread problem solved
(100 reward. 190 to donate. let 379 missing in the GB and not 380)

and for donating elsewhere
if the server would decline too much but accept the same amount twice if that levels it many player would be happy to pay 1 FP more
if 2500 FP would missing I would donate 1251 to prevent getting 2nd if the system would refuse my donation for place 2

 

[DeletedUser]

On many threads most people put the exact amount to allow someone to take a spot at 1.9.

the server should decline a donation if it doesn't fit in complete

Yeah Veggie , the Bug is the wrong number that the server is keep sending to the player whille the amount has changed

 

[Cursedveggie]

put one FP more in
place 1 still would need 190%
but place 2 one FP less
FP donation thread problem solved

Many many people struggle with even putting the correct amount on let alone extra to stop this happening

 

[Agent327]

It doesn't matter. I understand that it is not possible to keep the client perfectly synced. But the server behavior should be all or nothing, i.e. either accept the full amount I'm trying to add or return an out-of-sync error (accept 0)

You are right. It doesn't matter. It isn't a bug. It is intended behavior.

 

[scibuff]

You are right. It doesn't matter. It isn't a bug. It is intended behavior.

No it is not intended behavior. Why do you keep spamming with your baseless opinions. Please stop if you have nothing beneficial to add (e.g. a quote from a developer saying that it is intended behavior ... though I doubt such developer would keep his/her job for long)

 

[Agent327]

No it is not intended behavior. Why do you keep spamming with your baseless opinions. Please stop if you have nothing beneficial to add (e.g. a quote from a developer saying that it is intended behavior ... though I doubt such developer would keep his/her job for long)

Actually only one spamming is you.

Devs made a choice for it to work this way. It isn't a bug and if you do not like it there is a feedback thread for you to voice your opinion.

 

[scibuff]

Actually only one spamming is you.

Devs made a choice for it to work this way. It isn't a bug and if you do not like it there is a feedback thread for you to voice your opinion.

If I select to add 500 FPs and the game accepts that but then adds 400 FPs that is a bug ... and if you don't like that you can unsubscribe from this thread

 

[Andrew420]

For example, let's say that a level of a GB costs 1000 FPs. I open the GB view to contribute there are no FPs added (current count is 0/1000), I try to add 500 FPs. But while I'm doing that someone adds 600 FPs to the building. I try to contribute 500 but instead 400 FPs are added (I take an incorrect slot = lose FPs) and the building is leveled.

So for example you have a lvl80+ Arc and want to take 1st place on a 1000 FP lvl for 500 FPs so you can make a profit
Someone else donates 600 FPs faster than you most probably a 1.9 donation so they broke even
Its not a bug
If you have an amount of FPs selected and the GB still needs FPs to lvl
The game will take the FPs you have selected up to the amount to level the GB

 

[scibuff]

So for example you have a lvl80+ Arc and want to take 1st place on a 1000 FP lvl for 500 FPs so you can make a profit
Someone else donates 600 FPs faster than you most probably a 1.9 donation so they broke even
Its not a bug
If you have an amount of FPs selected and the GB still needs FPs to lvl
The game will take the FPs you have selected up to the amount to level the GB

Yes, and I'm saying that's a bug. If I enter 500 FPs into the box I expect the game to add 500. IF it cannot add 500 it shouldn't take anything (and let me know it cannot add 500). If you don't like that you can join Agent unsub from this thread and keep wasting your FPs in the game ...

 

[Emberguard]

I get you don’t like it, but it’s not a bug for multiple players to contribute simultaneously.