Fixed: [47758] Battleground Invisible hit range

[DeletedUser110131]

Volunteers can be as proficient as anyone. You're probably right that they get "paid" in diamonds. To the extent that that's payment, it's similar to the old, and currently universally banned, as far as I know, practice of paying laborers in company "money", that can only be used in the company store. If it's viewed as a reward or incentive, it becomes somewhat less like slave labour. Regardless, it's not a job in the sense of something done professionally to make a living. It's also very cheap for Inno. I think there's little doubt that a love of the game and a wish to help make it better for everyone must be an important part of the motivation. I can't believe that they've found people willing to work with no other motivation than in-game currency. More passionate volunteers might be nice, if any are to be found. Myself, I think volunteering to work for a game, even with diamonds as a reward, proves plenty of passion. You won't see me doing it, that's for sure.

The number of people needed to provide user support is huge, and I know for a fact that there are volunteers at the lower levels - the "frontmost" of the front line. Obviously, from some level on, you'll find only paid employees, and Sovereign may be one of those. I suspect he is. I hope he is, since he has some serious responsibilities. However, the thing is, whether they're paid or not, in diamonds, money or not at all, is irrelevant. It's still Inno that's responsible. It's still Inno that should have more people in place, or more/differently qualified people, or better compensated people, or better trained people, or better equipped people, or better routines and instructions. No matter what the trouble is, it's Inno's responsibility. That's just how things are: Whoever's in charge has the responsibility. That's where the buck stops.

I agree that FoE is a paid game. Even those who don't buy diamonds contribute to Inno's profits, by being a part og the game's content. A massively multiplayer game needs a massive number of players, after all. Once people have invested hundreds of hours in the game, they have a right to feel entitled to fair treatment and the respect due a good customer. Myself, I've been known to buy some diamonds, and if I walked away right now, I'd be "cheated" out of some money, just like you.

That would be Inno cheating me, though, not a "community manager", and not front line support. It would be whoever's in charge of the business model, along with whoever profits from it; the ones in charge of the organization that is Inno.

What we both agree on, though, is that whoever the blame rightfully belongs with needs to get his or her ass in gear. By "ass" I mean "donkey", obviously; I wouldn't use course language. Not yet. Getting there, though.

 

[DeletedUser4727]

Hi guys,

Apologies for not getting back to this thread sooner. I've worked with one of my mods to confirm this issue, and filed a report with the developers.

I appreciate the responses in this thread, but lets try to put it back on topic.

Thanks,
Richard

 

[DeletedUser110131]

Thanks, Sovereign! You're back in my "all is forgiven" column, with the developers hopefully not far behind. Not least, I'll resist future impulses to go off topic.

Am I right in expecting the fix in about two weeks, at the earliest, and do you have any idea if it's likely to be in the next update?

 

[DeletedUser4727]

Hopefully it will be fixed in the next sprint (1.125) if its not fixed before then in a hotfix. Obviously I can't know for sure, but I'll try to keep this thread up to date.

 

[DeletedUser111002]

The bug fixing track record does not support the hope that a fix will arrive any time soon. Meanwhile the new release brings new bugs, which I won't bother documenting any better, as the respect between this company and its customers is clearly not mutual.

In v1.124 : Is it hard to not mess up the premium pop-up?

Also in v.1.124 : is it hard to not mess up the allignment of sector HP bars?

In v.1.124 : After conquering the left sector, there is no HP bar on it.

Don't bother fixing these two, who knows what else you'll break.

Maybe scrap the beta program. It's clearly not worth the trouble. Release any new bugs straight to production please.

 

[DeletedUser4727]

Please report new bugs in their own individual threads, thank you.

 

[DeletedUser110131]

Arno, if not for Inno, then for the rest of us. The thread is necessary, I'm fairly sure, in order to get the ball rolling. After all, once you've gone to this much trouble, copy-pasting it to a new thread won't be that much extra effort. I don't play GvG, myself, but know many who will appreciate the effort.

P.S.:Also, "release new bugs straight to commercial, please" deserves the additional readership. Dry and cutting, yet without resorting to offensive language, making a good point, yet not too likely to derail into an off-topic discussion; just like a good insult should be, in this context. I myself promise not to pick up that ball and running with it.

 

[DeletedUser111002]

Arno, if not for Inno, then for the rest of us. The thread is necessary, I'm fairly sure, in order to get the ball rolling. After all, once you've gone to this much trouble, copy-pasting it to a new thread won't be that much extra effort. I don't play GvG, myself, but know many who will appreciate the effort.

The graphics bugs I pointed out are not affecting the game, but are obvious if any amount of testing were done before release, and look easy to fix. I would rather Inno not have them pointed out to them, so maybe they spend their time on fixing bugs that do affect playability.

At the same time, these graphic bugs are ugly and serve as both a good warning to potential new long-term players, and as an embarassing black eye to Inno. This embarassment is well deserved, and if Inno put the tiniest effort into quality, they would have discovered them themselves, or at the very least show the initiative to cut and paste themselves into the appropriate internal issue tracker. It's going too far that Inno expects customers to point out plain and obvious blemishes in their product.

 

[Vesiger]

Speaking as a mobile player who has NEVER had access to the easy range checks you are illustrating here , I can confirm that it's perfectly possible to win battles without them...

 

[DeletedUser110131]

I guess we're spoiled, who play on PC. Then again, everyone could be spoiled, if they had the good sense to use proper technology, rather than miniaturized phone booths / glorified pocket watches ; ) If you fight a lot of battles, you really should try fighting on a PC. It removes accident from the game; all mistakes are properly and rightly because you made the wrong decision, rather than not squinting hard enough while counting on a tiny screen. It's much more interesting, that way.

However, I also suspect that, on average, PC players put more emphasis on fighting, fight a lot more battles, and depend on easy range checks to have enough time for it. I fought the last half of level IV, this week; the alternative would have been negotiating, as auto-battle is risky and unpleasant enough even at lower levels, and can do serious damage to your victory/defeat ratio. Usually, fighting manually, I don't loose troops until the last two encounters. This time, I lost several units before that. I'm not short on troops, but hate wasting them. On the Continent Map, fighting just a few ages ahead of one's own becomes very time consuming, as a single mistake can cost the entire battle (thankfully, I haven't had to do much of that). In addition, the time spent on each battle has increased by 50% or more. That's time spent on counting hexes, which isn't exactly exiting. Complaining about it may make me/us seem spoiled, but for those who fight 100 to 300 battles a week, a lot of them manually, 50% on time makes a difference, and means a lot of hexes counted.

It also shifts focus, and tactics and strategy requirements, from what we've been attracted to, to other, less attractive elements, tactics, and strategies. It's enough to seriously harm the interest in fighting, and in the game. I quite simply wouldn't play the mobile version of the game; it's too limiting. So, I'm not kidding when I say that this could end my playing of FoE. A complete merge between mobile and Web not only could, but would definitely do so.

So, while it may seem strange to some, this is a serious bug for many players. Not game-breaking, but potentially game-ruining. It needs to be fixed, and fast.

 

[DeletedUser104623]

According to me programmers of the game change the order of the layers. The picture of battlefield is made from different layers which show movement and hit ranges of units. Normally layer with movement range of players unit was under partial transparent hit range of enemy unit now it is opposite so partial transparent hit range is “invisible” under not transparent movement range. The result of this is that hit range of enemy unit is not visible if movement range of players unit is on the same hex as hit range of enemy unit. (For picture crossbowmans movement range is 12 and hit range is 5.)

 

[DeletedUser110131]

That it appears when the players movement range overlaps the enemy's hit range is true. However, the problem also occurs when the hit ranges overlap. It's quite clear when using units whose hit ranges greatly exceed their movement range. On your own attached file, see hex 6,6. It shows no indication that it's in both hit ranges. The enemy hit range is invisible whenever it overlaps with any layer, at all, excepting possible landscape layers.

The explanation that it's caused by the wrong sequence and wrong transparency of layers is likely, in my opinion. It's been suggested by someone, previously in this thread, I believe. Maybe not. I'm too lazy to check.

The player unit's movement range has hidden it's own hit range from the start, as makes sense. The enemy unit's hit range has overlaid (rather than hidden) both the player unit's movement and hit range. Now it seems to be hidden by both. It's also possible that it's being hidden by the player unit's movement range, while itself hiding the player unit's hit range. Either way, it seems like a fairly silly mistake, that should have been easy enough to clean up in beta, and certainly in the first update after full release.

Even so, I'll forgive and forget, as long as it's fixed in the next update. I don't hold a grudge. Well, not always. I won't this time. Well, not much of one. I promise. Well, I don't plan to, anyway. In summation: Devs, just fix it!

 

[DeletedUser111002]

This bug is absolutely game breaking.

We've seen the casual perspective (mobile player, never uses browser, probably hardly ever fights, and minimal GE activity, single-line report "doesn't bother me, so it shouldn't bother you"), the enthusiast perspective (completes much of GE by fighting, some campaign map fights "a few ages ahead", 100-300 fights/week, "affects and frustrates me greatly").

Allow me to add the perspective of a dedicated and proficient player. I'm in HMA, complete all of GE by fighting, with some injuries but without losing troops, fight Industrial campaign with some troops lost, and fights 1000-1800 fights/week, most in IA GvG, "a significant number" of which, manually.

GE L1-2 is the most casual of fighting experience in FoE. You fight previous era troops, and can even skip by negotiating.
GE L3 is a medium level of difficulty that all but the most casual of players should be able to fight completely.
GE L4 is a challenging difficulty, that requires dedication ("beware - only the strongest will survive here")

GvG is a level of challenge above GE L4. While in GE L4, you have unlimited time to finish a fight, and it's only the final outcome (victory/defeat) that matters, in GvG, the focus is on winning fights quickly and with no, or minimal injuries/casualties. All casualties are avoidable, as are most injuries. It's a race against time to capture a sector before the siege is defeated. If the attack is detected, and multiple sieges are necessary, it's a race to find which of the two opposing teams fights more efficiently (last man standing). The first side to run out of healthy troops will lose the battle.

In the context of GvG, the focus is on completing battles as quickly as possible, with as few injuries as possible. In fact, if you suffer casualties at all, it's a clue that you're not proficient enough. To capture the typical sector, you need to win 80-ish battles in one hour, more or less (could be much shorter time, or many more fights, depending on how big the opposing teams are, how many re-sieges are done, and DAs replaced between sieges). In a long war where you sustain casualties, you will not last long. Assuming two equally matched teams, the more proficient one at avoiding unnecessary damage will win (ie, the marginal skill increment is determinative).

So, in order to complete about one fight per minute, you need to be able to judge the battle at a glance, and decide if "auto-fight" is viable, or if you need to start the fight manually, and auto-finish, or if you should surrender, or fight it manually the whole way. A few battle scenarios are trivial to judge (either can be auto-fought, must be manually fought, or the terrain is bad, surrendering is the quickest option), but most, and the most fun are the scenarios that are difficult to judge (eg, "can a medium range defensive attack hit your units on the 2nd turn?"). For example, if the enemy archers or soldiers can hit you on the 2nd turn will make the difference between the fight being a candidate for auto-fighting or not. You might be able to move your units out of the enemy's range, or it may not be possible. It's at these times when you need to quickly check ranges. Quickly is the key, because sieges are often lost or won with mere seconds to spare.

So, because the element of speed is vital in GvG, so is the ability the quickly make decisions, and the field markings are essential for GvG players. Thus, without the markings, GvG is effectively no longer a game of skill, but one of luck. There simply is no time to count hexes, nor would it be fun, due to the sheer number of fights that must be completed. Without the field markings, GvG is broken.

I should mention that there are many players who have reached a level of over-powering by means of very high level military buildings (lv 60+ Zeus/CdM/CoA/Traz/AO), who can auto-battle any fight, and for them, FoE is not a game of skill, but rather an exercise in fast clicking the "auto-battle" button. FoE is "Candy crush" to these players, and they too don't care about any field markings, as they never even enter the battle fields.

So, without the markings, the portion of the player base, who is progressing through mastering GE level 4, and/or getting into GvG and/or progressing through mastering GvG (not overpowering), is, I think prevented from making this progress, as the fighting without markings is akin to playing chess while blindfolded and balancing on a tight-rope.

Without the markings, what should be a game of intellectual skill, accuracy and speed becomes a game of chance. The battle aspects were clearly not designed to be a game of chance, so they are broken with respect to the intended design. On the mobile platforms it is somewhat a game of chance, and this is why the players who look for a challenge play the browser version, and avoid the mobile version for all but the mundane tasks (messages, spending FP, collecting productions).

Also, if praise is ever deserved, so should be blame. In the present case, I believe the blame for this bug not being addressed lies squarely with Sovereign, who is a Inno employee, and didn't even bother to try reproducing the bug for two weeks. He lied about the bug being fixed in v1.123, before he even understood what the bug was. He tried to cover-up his inadequate response by claiming this bug was already fixed, and this report relates to a different, yet identically behaving bug. Whether he is lazy or incompetent, I don't know, but I do know Sovereign fully deserves the blame for this serious bug still being with us 5 weeks later. Given his attitude so far, I doubt the bug report is very helpful for the devs to identify and fix the bug, and am certain he has done nothing to prioritize a bugfix. The devs deserve much blame too for not testing their software before releasing it.

TLDR: the field marking bug is a GAME-BREAKING bug, Sovereign is not doing his job.

 

[DeletedUser110131]

The careful reader will notice that I make several on-topic points, scattered throughout the text below.

Thanks for the insight into GvG, @arno the fabulous! I've still not gotten into that, but plan to. Descriptions of strategy, tactic and technique, that make sense, are always appreciated, and your description made a lot of sense. More on-topic, I have a better understanding of why you're more upset than me. For your category of players, it does seem game-breaking. It's GvG-breaking, which is the same thing as game-breaking, to those who find GvG the main attraction of the game.

The one's with very high level military GBs aren't without skill. It's a different skill, though, focusing on the slow-moving aspects of the game. Optimizing FP earnings and balancing FP investment between different benefits, such as future earnings vs. military boosts, is a slow process, but patience and careful deliberation are skills. Some invest in military boosts to "buy" time for social aspects, including running guilds and helping other players. That takes skill, as well. It's a complex game, with many valid strategies, and all successful strategies require some skill.

Assigning blame hardly ever helps a situation. I don't know how the devs managed to cause the bug in the first place. Perhaps it was an utterly stupid mistake, perhaps there are complexities and circumstances we're not aware of. I also don't know what Sovereign has and hasn't done, or why. Our problem here isn't his sole focus. We also don't know how many are affected, which I imagine plays a role in prioritizing. It shouldn't play too big a role, though; any bug is a flaw, and if it's left alone, and other functions become connected to it, it can propagate and become a much larger and more deeply embedded problem in the future. Bugs can be hard to reproduce. If the problem is layering, it can go all the way down to the hard-code on our graphics cards. It probably doesn't, but it can (it would probably require additional bugs or flaws in the OS and/or Flash, though). Some bugs require testing on a huge number of set-ups to reproduce. Making sure the staff has access to those set-ups is Inno's job, and one I suspect they haven't done. Not having to do that is one of the main reasons for having a large beta testing program, but that only works if they actually fix the bugs from the program, which they haven't done. I don't know why they haven't. Perhaps they have cash-flow issues? I very seriously doubt it, but anything is possible.

None of that matters, though. What matters, is that it's a serious bug on affected systems, and it needs to be fixed ASAP, in everyone's best interest.


P.S.: I tested your blindfolded-chess-on-a-tightrope comparison. I can confirm that both are difficult, but that blindfolded-chess-on-a-tightrope is distinctly more painful...

 

[DeletedUser4727]

Also, if praise is ever deserved, so should be blame. In the present case, I believe the blame for this bug not being addressed lies squarely with Sovereign, who is a Inno employee, and didn't even bother to try reproducing the bug for two weeks. He lied about the bug being fixed in v1.123, before he even understood what the bug was. He tried to cover-up his inadequate response by claiming this bug was already fixed, and this report relates to a different, yet identically behaving bug. Whether he is lazy or incompetent, I don't know, but I do know Sovereign fully deserves the blame for this serious bug still being with us 5 weeks later. Given his attitude so far, I doubt the bug report is very helpful for the devs to identify and fix the bug, and am certain he has done nothing to prioritize a bugfix. The devs deserve much blame too for not testing their software before releasing it.

For absolute clarity, once again, whilst I appreciate you may think this bug is the same, it is not. The code issues are different. There is in fact a fairly lengthy explanation of why the two bugs are not the same in the bug report itself. The bug fixed in 1.123 is a different bug to the one I reported, and this has been confirmed by the developers. It isn't true I didn't attempt to recreate the issue when you reported it, I did. At no point have I been dishonest during this process.

You're entitled to believe what you want, but I am being truthful. Additionally, I have no say over prioritization of bug reports.

I appreciate your frustrations, I do, but attacking me personally for things I simply haven't done isn't particularly productive.

 

[Vesiger]

However, I also suspect that, on average, PC players put more emphasis on fighting, fight a lot more battles, and depend on easy range checks to have enough time for it. I fought the last half of level IV, this week; the alternative would have been negotiating, as auto-battle is risky and unpleasant enough even at lower levels, and can do serious damage to your victory/defeat ratio. Usually, fighting manually, I don't loose troops until the last two encounters. This time, I lost several units before that

That's the difference , then; I accept that I'm going to lose units in just about every battle (I don't know of any way of avoiding it, save having large enough numbers of rogues to soak up all distance attacks; most Future armies can hit from across the board) save the ones in Level 1 where I vastly outnumber the opponent.

I'm currently fighting GE with Tomorrow troops against Future ones in order to score on the Tomorrow tower, and I've worked out enough strategy to complete the first couple of levels like that; I don't really have enough experience with Future troops to complete Level 3 at the moment even using the Future units I've won, and fighting Level 4 has always been pretty much a non-starter. I think everyone who does it in our guild negotiates it.

I've never tried counting hexes, I'm afraid; I wouldn't trust myself to predict the unit paths to that degree of accuracy! The mobile app does allow you to click on each individual enemy unit and see what it can hit, but in my experience there are very few safe hexes after the first enemy advance. My main issue is with the impossibility of distinguishing between what you can hit, and what you can hit without moving; you get a good instinct for it, but it's not infallible.

 

[DeletedUser110131]

The battleground invisible hit range issue isn't addressed in 1.125, either. My patience is running on empty, and I find myself spending less and less time and effort on the game...

 

[DeletedUser111002]

I think it's time I cut my loses and look for another game. It's not worth being a customer of this company. I pay for entertainment, I get frustration and BS from customer support.

I wish Sovereign would own his f.up and cut the BS. Save it for your supervisor, not your customers. You are lieing, Sovereign, and shoveling BS in my face to cover it up. I am not attacking you personally but as a representative of your employer, which with respect to me, the customer, is an entertainment vendor, and a bad one. At the time you reported "Hovering your mouse over an enemy unit sometimes didn't display their range on the battlefield anymore. This has been added back in." in the v1.123 release notes, the only but report fitting that description was this one, which is the only bug you should have been referring too. It's not a different bug as you claim. If there were an internally discovered, and more obscure bug, you should not have reported it in the public release notes. Furthermore, for two weeks after the bug was first reported, you were MIA. When you finally appeared, you claimed you could not reproduce the bug, and I merely pointed you to the initially posted screen capture, without giving you any additional details, and miraculously, the same information was more useful to you. Please, don't add more insult to injury. Own your mistakes.

Other than the many bugs in this game, here's a memory leak, that shows once again the developers don't even do basic testing. On the left side, is memory leaking while manually fighting GvG by myself against a 6 DA sector, over about 45 minutes. The right side, is the memory leaking while the game is idle (just loaded the city, then moved to working on another window, not interacting with the game window in any way).

All the while, both in GvG and the idle city, the graphics stutters every approx 35-40s like clockwork for 1-3 seconds.

This software is a steaming pile of german software engineering, and it's offensive that you want me running it on my computer.

Edit: Corrected "...over 45 seconds" to read "...over 45 minutes"

 

[DeletedUser110131]

I don't have any memory leak in Chrome, but I do in Firefox. It's bad enough that the browser becomes unresponsive, running as the sole application, with 16GB memory. That's insane for a browser game. I switched to Chrome for FoE, and having a browser dedicated to FoE turned out to be handy, so I'd forgotten all about it. You're right, of course, that memory leaks are a strict no-no in programming, especially in the high-level languages used in browser games. You almost need a special talent to manage to create a leak. In this case, they must've "targeted" a weakness in Firefox (or Chrome, in your case), Flash, or both. That Firefox and Flash aren't perfect isn't an excuse; you can't expect other SW to catch all your mistakes.

Regardless:

It's eminently possible to create a bug while fixing one. It's also eminently possible for two bugs to occur in the same or related sections of code. I suspect they either just shuffled the error around a bit, thought they'd fixed it, but really just changed it around just enough that it's technically a new bug, OR they inspected the relevant code, found an error, fixed it, and released it as a fix to the reported bug, unaware that they'd fixed something completely unrelated.

It seems to me that support and actual programming aren't sufficiently prioritized at Inno. Instead, resources are poured into events, pretty buildings, and other methods of extracting diamonds/money from players. Don't get me wrong, I like several of the new event buildings, there's nothing wrong with pretty, and I get that they want to make money. However, there needs to be a balance. Pretty buildings are no good, if the game doesn't work.

 

[DeletedUser111002]

Version v1.125 brings new bugs, of course. Now even the unit and ground tooltips are not displayed on the battle fields.

I took the liberty of having a closer look at the battlefield rendering code in the game, and found some fascinating facts:

• in v1.122, the battlefield hex rendering was largely rewritten. This was not mentioned in the release notes, but should have been seriously tested. The shading bug is not some obscure effect of graphics card drivers or a one line mistake, but a software bug in a block of new, untested code.
• The v1.121 was very messy, but so is v1.122 (one was spaghetti, the other is spaghettini)
• In v1.123 the code was lightly refactored, hacked a little bit (probably contains the "fix" for the top left, 0,0 hex shading)
• In v1.124 it was not touched
• In v1.125 poisoning code was touched (poison status was set on a scalar variable storing an array length, instead of the correct element of the array)

From what I've seen in the code, the "battleground shading fix" that Sovereign reported for v1.123 relates only to the top left, 0,0 hex shading. This was fixed by adding some boundary condition tests, and in no way relates to battleground shading. It was a single hex shading fix. The 0,0 hex was the "default" hex to receive shading whenever coordinate calculations were out of bounds. The out-of-bounds condition is now checked in several places in the code, but the reason for its existance was not fixed, only papered over.

Here is a typical gem, that doesn't require a CS degree to understand. A section of code that used to do alpha calculation, was changed to do coordinate calculation. This is the equivalent of replacing a defective electrical fuse with a paperclip. Yes, the code still "works" after the change, but it is unwieldy. No doubt touching this code in one place is bound to break any number of unrelated functions, and probably explains why the amateur developers likely avoid debugging it. Not only it would be a nightmare to debug, but touching it is more likely to break it more, in unexpected ways.

{
- _cursorHighlightQueue[0].alpha = Math.min(_cursorHighlightQueue[0].alpha + 0.4,1);
+ screenToHex(mouseX,mouseY,_prevPoint);
}

One more gem: the v1.122 code contains the city reconstruction feature that was mentioned as "extended beta" in the v1.124 release notes. It has seen major changes in both the v1.123 release and v1.124 release. While it's not activated for (most) live players, the fact that it is incorporated in the live release means that Inno's development lifecycle has development code being released straight to live servers. A more careful outfit would use a separate code branch for "experimental" features, such that the code in active development would never be run on production infrastructure. Development branch code typically runs on alpha/beta servers only, until it is deemed 'ready for general release'. The point here is, the "beta" servers that Inno runs are really just a joke. They must have read in a book that a beta server is a good idea, and simply run code there for a week or two, before copying it on the live servers. This has the implication that new bugs reach the live server two weeks after they run in beta, and so do any bugfixes. It just serves as a delay, so if the game is completely broken, they can find this in beta and delay release to live.

I have no remaining hope that the battlefield shading bug will ever be fixed. By extension, the many other serious synchronization bugs that plague GvG will also not be fixed. They are actually not bugs, but code that was never designed with multi-user synchronization in mind.