flaregames ignore windows players

before this war started i sent many mails to flaregames about the game that crashed after win but they just ignore me , im not asking for a miracle, i just need an answer but they refused to give me one, the bug is since last year and they did nothing about it i hope with the new update this bug will be eliminated or i am just dreaming?

confirm. ignore :unsure:

Don’t worry Daniel, they will continue ignoring us…

Hello,

 

This issue doesn’t concern only Windows players, it happens on all platforms.

It has been forwarded and the team is looking into it, but the issue doesn’t occur to all players, and it is not possible to reproduce it on their side for now, sorry…

Many of our alliance members are also raging about this. Needs a fix

thanks aether, see that is an answer shat should do flare after many mails cuz i think they dont just care about that. and well so this coming update is not going to be eliminate the bug right? :slightly_frowning_face:

The bug has been eliminated and reappeared several times now. It’s just a fact of life that every other update reignites it.

I don’t think the update will fix the bug, just bring even more bugs as always  :lol:

testers triing to reproduce it, sitting in office near servers? on high-end devices? :lol:

 

True, the windows crashing bug was already eliminated. It came back with the last game update.

I expect developers to have some kind of source control available. It must have been produced by some changes in latest versions. They have the option to check what has been changed since that version and isolate the problem.

 

They should know what code is executed at moment after succesful raid to activate showing up the chamber of fortune. Somewhere in that specific block of code something must have been changed, either data that is used there or code. I would concentrate on that part as a developer.

It could depend on how source code changes are synchronized in a group of developers.

Normally only one person can change a given file/object at a time. A developer checks out

a file from the server, works on it let’s say for one week, and at the end checks in the changed

file. After that another developer can check it out and work on the file.

 

This implies problems, if the second developer cannot wait for one week do do his changes

(because of money, time, whtaever). Now he helps himself by doing this: he gets the file as

read-only from the server and changes this “local copy” while the first developer is doing his

changes on his PC. After the first developer has checked in the file (with his changes) a week

later, the second then immediately checks out the file, replaces it with his “old local copy” and

checks in (later). Obviously the changes of the first developer are lost now.

 

The first developer in this story was the one fixing the windows crashing bug (version 1.9.5?)

and the second one was the developer of the blacksmith update (version 1.9.6). It is likely, that

these versions did overlap in time, because the blacksmith update was a big one, needing a lot

of development time.

 

We had exactly this situation with a CRM-Application (Siebel) in our company, where fixed

problems in one version came back to life in the next one after it.

 

This may explain the current problem, but of course there could be another explanation. We will

never know :grinning:

 

You would be surprised at how irrelevant bug-causing parts of code can appear to be. For example, a poorly executed memory request at runtime can lead to a memory leak that won’t show itself until well after the instance, or the cof may contain the particular block that is executed to trigger a failstate caused earlier.

subjectively, as a programmer, I have the feeling …During the battle for each unit is allocated a block of memory. (Not only under the units, but apparently a rest)At the end of the fight, with a large number of surviving units (dozens), there is a sharp release of memory. That is, at the same time dozens of requests to the operating system to release memory blocks. And this causes a glitch OS.

 

This is how it looks to me.

It makes sense, it could be an overload of data, as more info has to be shown afterwards (percentage raid, animations, XP, level, your king, the prizes you got…)

Even calculations have to be made as the prizes you got depend on the percentage you raided.

At least i know the bug is not only on Windows player

I am actually not surprised, because I am a senior developer (20+ years experience) myself and those kind of bugs are introduced by developers who either are short on time or where they don’t seriously test and don’t do impact analysis. Mss73 is hinting in the right direction and there are also tools for monitoring what’s going on at that exact moment.

 

For finding memory leaks there are enough tools out there, it should not be a problem finding them. I have also worked with them and tracked down really nasty ones in an environment where every leak can be a disaster.

 

It can be a disaster, but let’s be realistic, that is no excuse at all.

It indeed is no excuse, they should fix it, it’s somewhere in their code.

10+++ times today

 

fuck