• Dear forum reader,
    To actively participate in our forum discussions or to start your own threads, in addition to your game account, you need a forum account. You can
    REGISTER HERE!
    Please ensure a translation into English is provided if your post is not in English and to respect your fellow players when posting.
  • We are looking for you!
    Always wanted to join our Support or Forum Team? We are looking for enthusiastic moderators!
    Take a look at our recruitment page for more information and how you can apply:
    Apply
  • Forum Contests

    Won't you join us for out latest contest?
    You can check out the newest one here.

Fixed: [47758] Battleground Invisible hit range

Status
Not open for further replies.

DeletedUser111002

Since v1.122, the new green colour scheme for unit movement and hit ranges is unusable. Before this version, it was possible to tell the hit ranges of the enemy troops. No more. See the attached screenshot of an Iron Age GvG scene. The highlighted archer's movement range is visible, but his hit range is not. Somewhere in the top left corner of the battle field there should be a safe area for my ballistas, but it is impossible to tell the boundaries of that safe area.

I have marked with pink lines the place where I think this safe area starts.

IA-BG-colour-bug-v1-122.jpg


I thought I could doctor the colours by substituting the foeen.innogamescdn.com/assets/battle/hexfield/battle_hexfield_0.png file. I marked the various hexes in that swatch, to help identify which colours need to be modified for visibility, but it appears the bug is not that the colours are too subtle; instead the problem seems to be that the opacity values for the hit ranges are not added up together, so when a hex is in both offensive and defending armies hit ranges, it's not any darker than a hex that belongs to only one of the hit ranges.

Please fix this soon. Fighting blind is a nighmare, and I'm taking a break from the game until fighting is fun again.
 

DeletedUser110131

I'd like to add that this bug is close to game-breaking, for those of us who enjoy the battle aspect of the game. We're not playing this game to get counting practice.
 

DeletedUser15986

Just to note for everyone; This bug has also been reported on Beta, and is under investigation.
 

DeletedUser110131

Good to know, Lord B. Hopefully, they're already well on their way to a fix. Still, what do they have Beta for, if they release without fixing the bugs? It's not exactly the soundest strategy. On a strategy game, it's even ironically bad. Now to find my patience. I know it's around here, somewhere...
 

DeletedUser110615

Just to note for everyone; This bug has also been reported on Beta, and is under investigation.

Well, that's sad. Feels like they don't consider combat a major part of the game, if they let such a bug through. I guess that would please many.
 

DeletedUser111002

I tried a couple neighbourhood and campaign map battles, and this bug appears fixed. Can anyone confirm?
I have not tried in GvG mode yet, however the problem occured in GE and (I think) hood also. Maybe all modes are equally affected?

Update: The bug is still there, but I've done a bit of testing on a Campaign Map, and it looks like the bug is triggered by my next unit to move, and not by the battle mode (GvG/GE/etc)

If my next unit is a Heavy Infantry, the enemy hit ranges are visible, but if my next unit is a Trebuchet, the enemy hit ranges are not visible.

I haven't tested with different armies, but a composition of 4 Heavy Infantry and 4 Trebuches shows the problem well, as it only occurs when the Trebs are ready to move.

I hope this helps with the debugging.
 
Last edited by a moderator:

DeletedUser110131

There hasn't been any updates since your initial report, and thus no fixes. You can follow updates here.

As you pointed out, it's about overlapping hit ranges. From what I can tell, it also affects heavy infantry, though in a less obvious way, as their hit range is smaller, down to only one hex, in the early eras. With a shorter movement range, as well, they're much less likely to overlap with anything. I can confirm that the bug affects battles in the GE, neighborhood, and campaign map. I don't fight GvG, so I can neither confirm nor deny, but it would surprise me greatly if the bug doesn't affect that, as well.

Developers: This needs to be fixed, and fixed fast! We're not talking about a detail; this has a huge impact on one of the game's major strategies. It should never have made it past beta, given that it was reported there. In fact, it should have been picked up and fixed in the initial alpha testing. Letting it through was a major mistake, even unprofessional.
 

DeletedUser110131

I retract my forgiveness.
Version 1.123 is live, and the problem remains.
No change, whatsoever, that I can tell.
 

DeletedUser111002

I retract my forgiveness.
Version 1.123 is live, and the problem remains.
No change, whatsoever, that I can tell.

I can confirm, the bug is not fixed, though I see the devs "touched" the code, as the top left corner is now receiving some shading - the top left corner is now initially shaded, but once you make some moves, it's incorrectly shaded.

To illustrate once again, here is a scene with an enemy ballista not-selected, and then the same scene with the enemy ballista selected.

In the first screenshot, the bottom right corner is clearly shown as the enemy's safe area from my Trebuche's reach, but in the second, the bottom left corner should be lighter shading to show my safe area from the enemy ballista.

Enemy ballista not selected (nothing wrong with this picture):

GE-Enemy-ballista-not-selected.jpg


Same scene but with the enemy ballista selected. The area circled in pink should be lighter-shading than the middle of the field, to show that the enemy ballista does not reach that far:
GE-Enemy-ballista-selected.jpg

Game version:

1.123.0a75697f1d (03.04.2018 12:08), Arno The Fabulous (6666414), en9, en_US, WIN 29,0,0,113, Windows 7, Chrome/65.0.3325.181, 1268x813, OpenGL (Baseline Extended) (336 MB VRAM)

Game breaking: YES!!! Manual Battles are as much a gamble as auto battles
 
Last edited by a moderator:

DeletedUser4727

Thanks for your report, this isn't entirely the same as the previous bug which should be fixed. Additionally, Im not able to recreate this, are you still seeing this issue? Is it specific to units, or have you seen it for all?
 

DeletedUser111002

Thanks for your report, this isn't entirely the same as the previous bug which should be fixed. Additionally, Im not able to recreate this, are you still seeing this issue? Is it specific to units, or have you seen it for all?

The bug I reported initially on March 20 (v1.122 released) is still there, and reiterated as much on Tuesday April 3 (v1.123 released). :mad:

How do you know it's fixed if you're not able to reproduce it, and how did you report it to the devs in the first place if you're not able to reproduce it? I really would like to see the actual issue tracker bug report. :mad::mad:

The fact that I reiterated it on April 3, echoing Einrikr's report means we are still seeing this. Is this not clear? :mad::mad::mad:

I'm not sure if we're having a language barrier or a barrier of a different kind. :?

To reproduce it, recreate a battle scenario as depicted in the images above, and use the same unit types as in the original bug report. What steps did you take to reproduce it, :zzz:?
 

DeletedUser4727

The two issues are not entirely the same. The original issue was reported on Beta, and was fixed. The issue you're describing is different.

I will attempt to recreate, and will report if I am able to. Thanks again.
 

DeletedUser110615

Not sure if this is known, but it seems that all artillery units are affected. I've checked with Field Guns (CA) and Mechanised Artillery (ME) and with each of them selected none of the enemy unit attack ranges showed (movement ranges are fine). Every other unit seems to work fine.

Edit: I've played with things a bit and I noticed that with a Musketeer (ranged) selected, attack ranges won't show up either, if they overlap your unit's movement range (or some other reason):

Enemy attack range not visible

Enemy attack range visible

Both units have an attack range of 1, so not a big deal, but it's similar with longer range units; my neighbours hate ranged defenses, though.

Not sure if that bugfix fixed any of the previous problems as I've stopped fighting, but there still seems to be plenty wrong.
 
Last edited by a moderator:

DeletedUser110131

Thanks for your report, this isn't entirely the same as the previous bug which should be fixed. Additionally, Im not able to recreate this, are you still seeing this issue? Is it specific to units, or have you seen it for all?

I've bothered several neighbors, in order to re-confirm this:

The problem appears identical to the previous problem. Whether the cause is the same, or not, the effects are the same. The bug occurs in both Firefox (v. 59.0.2, 64-bit) and Chrome (v. 65.0.3325.181, 64-bit), on Windows 7 (build 7601). It's not unit specific, as far as my testing goes. However, it's far more noticeable with ranged units, as the hit ranges then overlap by much more.

The current version bug is also present in GE, though there I can't test for unit specificity until Tuesday.

I have to say that, given that the symptoms are the same, and are reported by the same players, I find it very likely that the bugs are, at the very least, closely related, and that the first fix was incomplete. While few things are impossible, many things are improbable.

Einrikr
(neighbor-botherer)
 

DeletedUser111002

I will attempt to recreate, and will report if I am able to. Thanks again.

I understand you're still not able to recreate this bug, since you did not report so?

The corresponding bug report on the Beta forum is still in the "Reported to Developers" ("not yet fixed") section, so it's not clear to me why you added to the 1.123 release notes that this bug was fixed.

Every day that passes where you and the developers don't seem to make any progress is aggravating to me and I'm sure other players who would like to battle in your game.

You could also mark this as "will not fix" so we know to stop waiting. That would be more respectful to your customers, the players.
 

DeletedUser110131

So, it's official: Version 1.124 will come and go, without any fix for this bug.

I'm starting to loose my patience, here. If you can put the bug in, you can take it out, so get to it!
 

DeletedUser111002

I am considering quitting FoE myself; a game is not supposed to be infuriating via the carelessness of its developers and support staff. There are plenty of other strategy games.

To be sure, this bug has not yet been reproduced, nor reported to the developers, nor assigned an [identifier] - Sovereign claims it's a different bug that some other bug, but he's MIA as far as I can tell, and his responses are not helpful when he does show up in the forum. I don't think it's Inno that doesn't care about their cash cow, but the front line support staff like Sovereign that are sabotaging the operation.
 
Last edited by a moderator:

DeletedUser110131

Well, now. It's Inno that appoints, organizes, instructs, and supervises the support staff, many of whom work for free, out of love for the game and a helpful nature. Where Sovereign fits in the hierarchy, I don't know, but it's certainly Inno that's ultimately responsible for what he does, how he does it, and how much time he has to do it in.

You don't necessarily get what you pay for. There's plenty of free, top quality things to be had; for instance, I'm writing this on Firefox, and Inno itself relies heavily on Firefox. Top notch, no cost. However, sometimes you need to pay a bit extra, in order to get and provide the best. That goes double for commercial businesses; it's hard to recruit idealists to work for free to help you make money. If those who do volunteer are too few and short on time, things move slowly. Inno certainly can afford to pay staff, ensuring many enough, with time enough. They choose not to. That's squarely on them.

The "buck" goes through many hands, but it stops at the top. I'm not a huge fan of president Truman, but he was entirely right about that. In this case, it doesn't stop with a head of state, but it does stop with the head of Inno. In spite of his nick, I'm pretty sure that's not Sovereign...

Given the similarity with the previous bug, I suspect that at least a quarter, maybe more, of this buck belongs with the developers. If the bugs are related, which I'm pretty sure they must be, they're by far the best qualified to locate it. If even related bugs must be reproduced at a lower level before the developers have a look at it, that's an Inno policy.
 

DeletedUser111002

If those who do volunteer are too few and short on time, things move slowly. Inno certainly can afford to pay staff, ensuring many enough, with time enough. They choose not to. That's squarely on them.

That is an assumption, that support staff are unpaid volunteers. I don't believe it for a second. Smart business people don't let their business depend on unpaid volunteers. It's just not good for business.

Even if the support staff gets paid with in-game currency, "diamonds" or "lanterns" or whatever, in this case, that is payment. The rest of us have to pay cash for those diamonds. By the way, FoE is not a free game. It's a paid game, although the business model seems to be "freemium". I paid for some diamonds, and since the bug hit, it's too frustrating to continue playing, so I won't be getting what I paid for. I would not have paid had I been aware of all the bugs in the core functionality of the game. Others are in a similar boat.

Even if the support staff were just other fans of the game volunteering their time, they should step aside and make room for someone more passionate about the game then they are. Otherwise they are doing the community a big disservice (and respectively, sabotaging Inno).
 
Status
Not open for further replies.
Top