Stop changing the amount when contributing to GB's

[Matt999]

It’s a non-refundable auction

That's probably a more fitting analogy, or a lottery. Anything likened to buying gifts/goods/services heavily supports OP's suggestion as being useful.

For me, it's not a great user experience to show me a UI where I make a decision based on what's there, and get something different as an outcome rather than a "can't do it now". But I get that the suggestion is not a popular one from the comments (aside from with me and OP!), which is fine.

 

[BruteForceAttack]

This happens when another player contributes to the same GB at the same time and there are not enough FP's left to contribute.
FoE changes the contribution amount in the background without notice to the maximum amount left to contribute.

The result is a leveled GB and massive loss of FP's for one of the persons contributing.

There is absolutely no valid use case for FoE to change the amount someone contributes to another players GB. In the case described the contribution should be declined with a message stating that amount cannot be contributed anymore.

I use it to fill my gb, after all contributions are done..just type in 99999... Makes power leveling gb way way faster

 

[Jasnah Kholin]

I just can't believe the devs won't admit this is a "bug" and fix it, instead of silly excuses.

It's such a simple fix and could be coded in minutes... if you try and contribute 45 fps, but the system sees there are only 15 left to level, your offer should be simply rejected with a message that there are not that many FPs left to contribute. And it should also be made the same with the 10FP button. If there are only 6 FPs remaining to level, the 10 FP button should simply be greyed-out, meaning that the exchange contract as drafted is no longer available.

The "paying with a €10 note and getting €2 back" is both a a silly and condensending argument, because the developers know that is not the players' intent of using these buttons. I could only imagine going to pizza restaurant and paying €10 for a pizza, but then the employee comes out and tells me that another customer got the last full pizza first, so he hands me 1 slices of pizza and gives me €2 back. Sure, perhaps someone wanted to pay €8 for 1 slices of pizza (and I wouldn't stop them from doing so), but MY desired exchange was €10 for a full pizza as advertised. If the agreed exchange is no longer possible--which sometimes it is not--the agreement should be terminated, not exchanged for something else.

Honestly... I'm truly lost on why this is a "feature" of gameplay and not a bug. ‍

 

[Emberguard]

I just can't believe the devs won't admit this is a "bug" and fix it,

If it's functioning the way the devs intended for it to function then it's not a bug. FoE was originally designed as a strategy game with Risk VS Reward involved. You don't have to like that. But not liking that aspect of the game doesn't define it as a bug, just means you'd prefer it to function differently

 

[RuudM]

If it's functioning the way the devs intended for it to function then it's not a bug. FoE was originally designed as a strategy game with Risk VS Reward involved. You don't have to like that. But not liking that aspect of the game doesn't define it as a bug, just means you'd prefer it to function differently

As I explained earlier, this has nothing to do with risk / reward or sniping. Read the post, it has to do with changing the intended amount of contribution. Even if a sniper would be involved (which by no means is required for this behaviour to occur) per definition the sniper would not be affected by it, their contribution would not be changed it is per definition the person doing the 1.9 (or any other higher amount) who's contribution is changed.

So please stop muddying up this discussion with references to snipers and risk as those have nothing to do, and are not affected by, the subject of this thread.

 

[Knight of ICE]

This has nothing to do with sniping and risk, For one because sniping is only one scenario where this happens but, more importantly, because this is about FoE actively changing the amount I was intending to contribute and thus actively causing a leveled GB and FP loss. FoE does not have to do that, it chooses to do that, The situation is simple: my contribution is too high and cannot be be executed that's where it should stop.

FoE did not cause a leveled GB and FP loss. You did. You do not have to donate that amount. You chose to do that. FoE can not see how much you mean to donate, or why. It only can correct your amount if it is to much.

 

[Emberguard]

this has nothing to do with risk / reward or sniping.

If there was no risk / reward and no sniping there'd be no conflict in the first place because you wouldn't be contending with anyone else

Even if a sniper would be involved (which by no means is required for this behaviour to occur) per definition the sniper would not be affected by it,

That's not always the case. A sniper would be effected if you beat the sniper to the punch, and that does occur

So please stop muddying up this discussion with references to snipers and risk as those have nothing to do, and are not affected by, the subject of this thread.

The only times your contribution would change is when two players are contributing at the same time. If you're throwing out the situations in which that occurs then there's no reason for the idea to even exist

 

[TheKingOfKool]

As I explained earlier, this has nothing to do with risk / reward or sniping. Read the post, it has to do with changing the intended amount of contribution. Even if a sniper would be involved (which by no means is required for this behaviour to occur) per definition the sniper would not be affected by it, their contribution would not be changed it is per definition the person doing the 1.9 (or any other higher amount) who's contribution is changed.

So please stop muddying up this discussion with references to snipers and risk as those have nothing to do, and are not affected by, the subject of this thread.

The problem you are experiencing has to do with what is known as data contention. When a value in a database changes their may be what is called data contention ► the data has been changed by someone else since the last time it was read/seen by the person viewing the data.

Now, there are two possible outcomes:
1) An optimistic change - allow the change you are trying to make regardless of who else may have changed the data since or in between what you are trying to enter.

Or,

2) A pessimistic change - Do Not Allow any changes you are trying to make If anyone else has made a change before you.

The GB's being donated to are done using Optimistic Updates - Allow the data entry No Matter what has changed since or in between you reading it - opening the GB - and someone else adding to it - changing it.

Inno will not change to Pessimistic Updates - they ignore data contention issues when it comes to changing data in a Great Building; it would cause all kinds of problems for them to deal with.

 

[Cuthwolf]

If you're sniping another player, it's just too bad

Snipers losing out? There is Instant Karma in this world.

 

[SlytherinAttack]

This is a problem which is kept there for a longtime. My actual guessing would be, FOE developers decided like 'NO possible solution' to fix this problem and left as it is. Why because, time difference might be nanosecond or microseconds on taking the spot from both players. You cannot code some logic with nanoseconds to give some alert or preventive measures. That's how the User interface works, am saying this because worked as Application Developer long back in my work career.

IMO, If the ticket raised to developer, It will be seen in Jira for the resolution as 'Won't Fix' and status as 'Known Issue' with the comments mentioning,
"Players would spend forge points in a careful manner in the strategy game".

 

[Matt999]

This is a problem which is kept there for a longtime. My actual guessing would be, FOE developers decided like 'NO possible solution' to fix this problem and left as it is. Why because, time difference might be nanosecond or microseconds on taking the spot from both players. You cannot code some logic with nanoseconds to give some alert or preventive measures. That's how the User interface works, am saying this because worked as Application Developer long back in my work career.

IMO, If the ticket raised to developer, It will be seen in Jira for the resolution as 'Won't Fix' and status as 'Known Issue' with the comments mentioning,
"Players would spend forge points in a careful manner in the strategy game".

You absolutely can code this - it is trivial and done all the time. It would be an update based on a rowversion (or similar) passed back in, and if 0 rows affected, then there has been another update and you show the message. If it wasn't possible from a software development perspective, then all payments and banking systems would shut down pretty quickly when people start getting charged without being fulfilled.

I agree that it would likely be a closed ticket in a game where they have lots to prioritise, but it should be closed based on a deliberate product manager decision rather than a dev not knowing how to manage a long-running transaction.

 

[klods hans]

I'm surprised this is still a problem for some players. I level at least one of my GB's almost every day, and I take top spots in GB's several times a day. It almost never happens. And I rarely hear anyone complain about it. Players are aware of the risk and they know how to be careful with their contributions.
There are plenty of ways to prevent it from happening.
Claim the GB spot in the thread where it's posted BEFORE taking it.
Only post GB spots in ONE thread.
Keep the GB locked until you find friends/guild mates who can secure 1st and 2nd (and maybe 3rd) spot at the same time.
And more...

 

[klods hans]

If you use a 1.9 thread with players from different guilds (or solo players), the risk of a contribution clash is high. You don't know if the GB spots have been posted in several other threads.

 

[SlytherinAttack]

You absolutely can code this - it is trivial and done all the time. It would be an update based on a rowversion (or similar) passed back in, and if 0 rows affected, then there has been another update and you show the message. If it wasn't possible from a software development perspective, then all payments and banking systems would shut down pretty quickly when people start getting charged without being fulfilled.

I agree that it would likely be a closed ticket in a game where they have lots to prioritise, but it should be closed based on a deliberate product manager decision rather than a dev not knowing how to manage a long-running transaction.

When dev quote any status, it will be mailed to manager regarding the ticket. Anyhow, that is not our concern here. As you pointed, payments and banking system, having queuing system. Even if 100 users doing transaction on the same account, it can be processed one by one.
But in the game, don't have that luxury to do one by one. Myself pretty sure about you know it very well why it cannot be done one by one in the game.

Also, this is a issue which can be fixed with one extra user actions. Likely, while spending the fps users should select the spot with some option newly introduced in the UI (kind of booking) and then spend the fps. This is the only way which can prevent and alert the user like 'marked spot is not available' while spending fps. As a fact, any new approach will be overhead to the normal behavior (1.9 thread or leveling/swap etc) where currently having no problem. It is best to be left alone.

 

[Matt999]

When dev quote any status, it will be mailed to manager regarding the ticket. Anyhow, that is not our concern here. As you pointed, payments and banking system, having queuing system. Even if 100 users doing transaction on the same account, it can be processed one by one.
But in the game, don't have that luxury to do one by one. Myself pretty sure about you know it very well why it cannot be done one by one in the game.

Also, this is a issue which can be fixed with one extra user actions. Likely, while spending the fps users should select the spot with some option newly introduced in the UI (kind of booking) and then spend the fps. This is the only way which can prevent and alert the user like 'marked spot is not available' while spending fps. As a fact, any new approach will be overhead to the normal behavior (1.9 thread or leveling/swap etc) where currently having no problem. It is best to be left alone.

It doesn't need any extra UI option, literally just within the context of the update transaction, you check either that a rowversion/timestamp hasn't been incremented (generally built-in), or you check that the remaining quantity hasn't changed (i.e. round-trip it). It is very standard "unit of work" functionality that exists in many applications.

Klods points are all fair - there are lots of ways to limit it happening from a player's perspective, and I do all of these. But statistically, take enough spots (I take many) and it will still happen at some point, and when it does, it's a right royal pain in the backside. It is very fixable (or "changeable" depending if it's thought of as deliberate). I buy into there not being compelling enough reasons to "fix" given that it's pretty rare, but it's definitely a simple fix if they want to.

I am pretty sure the "fix" already exists in some places in this app anyway. I did 159/160 on GBG, took the 160th at the same time as somebody else and was presented with "this sector has already been closed" rather than getting a reward and/or it locked for twice as long. Similarly I bet there aren't double rewards if two people click "motivate" on the last remaining unmotivated building in someone's city.

 

[SlytherinAttack]

It doesn't need any extra UI option, literally just within the context of the update transaction, you check either that a rowversion/timestamp hasn't been incremented (generally built-in), or you check that the remaining quantity hasn't changed (i.e. round-trip it). It is very standard "unit of work" functionality that exists in many applications.

Klods points are all fair - there are lots of ways to limit it happening from a player's perspective, and I do all of these. But statistically, take enough spots (I take many) and it will still happen at some point, and when it does, it's a right royal pain in the backside. It is very fixable (or "changeable" depending if it's thought of as deliberate). I buy into there not being compelling enough reasons to "fix" given that it's pretty rare, but it's definitely a simple fix if they want to.

I am pretty sure the "fix" already exists in some places in this app anyway. I did 159/160 on GBG, took the 160th at the same time as somebody else and was presented with "this sector has already been closed" rather than getting a reward and/or it locked for twice as long. Similarly I bet there aren't double rewards if two people click "motivate" on the last remaining unmotivated building in someone's city.

Even in GBG problem is there, but you never realize it. You are trying to increment from 124 to 125, but after you finish the fight it becomes 135 or 128. Because, someone doing battles with you. At the 159/160 scenario, it alert because, it is locked. Same cannot be done in GB. To get the same logic, it has to be with user actions. There is a possibility where both person has same timestamp (very rare- but it is possible to get that scenario on how close the milliseconds are calculated).

Just forgot the problem for a minute, take the normal usecase of 1.9 thread, you are trying to take 1st spot, no one else is there and you took it without any trouble. If the fix provided for it, when you apply for 1st spot, it will go check for spot taken already or not. By keeping the 5 row numbered mechanism, it will go and check the spot (it is a delay for sure). But currently, you never confirmed the UI about which spot you are taking. You just added the fps and it picked the next available slots. Did anywhere mention like reserving the 1st spot, actually no. It just takes the next available spot. That's the solution and problem as well !! how much fps spending from our side if the next available spot can accommodate the fps, it will get placed without our confirmation. You cannot prevent it by without changing the User interface for booking the spots.

happy forging!! pirates are calling me from hideouts to spin the wheel!!

 

[Matt999]

It doesn't need to check for spots, or have people declare spots - just that the remaining FPs (or rowversion) hasn't changed in the (generally) small time window between the UI displaying and the server-side code actually performing the update. I don't think Inno needs to (or should) "support" 1.9 spots per se. "There are 200fp left and I'm putting in 100fp" is how I see the transaction (rather than "I'm buying spot x for y" or "I'm randomly throwing in 20fp"). But I fully understand that the majority in the thread like it how it is

 

[klods hans]

But I fully understand that the majority in the thread like it how it is

It's not that I like how it is as such. But contribution collisions are so rare that they don't worry me much. I do take precautions, though, to limit the risk, e.g. not posting GB spots in more than one thread.
I don't know much about coding, but if there's an easy fix I'd welcome it, of course. A warning that there's not enough room for the fps you're trying to add seems like an easy thing to code, but maybe it's not. I wouldn't be happy with a solution where you have to confirm a contribution. That would require more clicking and delay the flow. I would switch the option off, if possible :-)

 

[SlytherinAttack]

majority in the thread like it how it is

Though myself given information for not supporting the discussion, doesn't mean that liking the current approach. It makes me suffer many times when some new GB introduced into the game. That time, collision happen like anything. Just given the details from my understanding. Myself too not like that approach, but until some super approach for GB fps contribution screen design change if it happens in future, can hope for positive expectation. Till now, couldn't get any design thought in my mind to solve the problem without any delay. If myself got the design plan, will post that as an idea for sure.

 

[DeletedUser]

Not sure that is quite right. Players didn't ask for the specific behavior the OP is complaining about. (If they did, show me the post).
Players asked for the ability to add more than 10 FP at a time. To be able to key in the exact number of FP they wanted to put in. They mostly did this because clicking the 10FP button to put 2K fp into a GB was painful, and because mobile players had an advantage here.

Nobody really thought about the corner case, where 2 people snipe at the same time. Since they didn't think about it, they didn't ask, at the time that it work some other way. Inno had to think about the corner case, and they did what they did.
I actually sort of like the way they handled it. Be quick, or get sniped. I'm OK with that, even when I lose.
But that is *NOT* what players requested.

Players requested the ability to place larger amounts of FP's to GB's, the fact players can not manage this, is hardly Inno's fault.

Dam may my tongue turn black for siding with Inno