Force client restarts MUST be reworked

"Vampire_X;c-1570571" wrote:
Some easy tactics would also make other exploit holes too ;)

Its one of those if it was that essy it would be done... muliple popular games have similar systems.

Security and game part add layers to the ways client and server react.

It dosen’t really let the devs off the hook though, since this chat box issue wasn’t one until they implemented this annoying ‘updated’ version of chat.

It’s amatuer no matter how you look at it. Wasting time is what they are trying to cut out yet that tonight is the most blatant example of it. In my near 2 and a half years since i started this is the most de-motivating thing to happen.

"Vampire_X;c-1570571" wrote:
Some easy tactics would also make other exploit holes too ;)

Its one of those if it was that essy it would be done... muliple popular games have similar systems.

Security and game part add layers to the ways client and server react.

True. But such security holes can be closed. If a security hole is discovered in https://blablabla/api/v14/do_whatever and it cannot be corrected, just make that particular endpoint throw an error (HTTP 500, for example), and make https://blablabla/api/v15/do_whatever perform correctly. That doesn't mean that every other message for v14 has to be automatically thrown to the garbage can. That way, you can send the "restart order" to clients, which can then store it in a variable, try to contact the server to send their pending information (or, if in a battle, wait until the battle is over), and _then_ restart.
In this particular case, the hotfix was for some TB bug. Absolutely nothing to do with raids. In fact, if someone is doing a raid, then they can't be doing TB battles.

But hey, we already know that nothing will be done regarding this issue. Like _so many other issues_, it is just easier to let it fall into oblivion, until the next one comes along.

While the design could be improved, cross versioning everything would be not only dangerous from a security standpoint, but compatibility standpoint. It would also require a lot of manual tolerance input that would have to be defined by the devs as to what versions a fix works with.

Not unheard of, but a bit pointless to me when the better fix would be separating out when the reset flag is interpreted and having chat basically run it's own versioning. Basically the bug sounds like it is tied to the new chat system specifically and significant architecture changes as some are stating would be careless and shortsighted. Not only that, there are only a few scenarios of what would amount to asynchronous execution of transactions, mainly chat, so fixing those would likely be a lot easier and better then overengineering the architecture. This is also blind conjecture on my side based on the limited knowledge I have of their setup, so take it for what it is....

You can be irritated, the QA team has clearly missed some issues, but I wouldn't go so far as to try and tell them what design changes they should make to their architecture with only minimal knowledge of their codebase and operations (I write software for a living too and disagree with your ideas).

I didn't have any issue for some days...
While launching a battle in tb the client needed to restart.
Received some compensation and now I just can't open the TB.
Anyone else ?
Not complaining here... Just saying.

They've GOT to be kidding us... Forced restarts in the middle of a raid?!

Now I've lost all progress in an hRancor. And we get some stupid rewards as apologies... Hilarious. Simply hilarious.

"LtGenStu;c-1570521" wrote:
Forced restart aren’t technically pushed to devices, but the client get that restart "flag" upon next sync. Normally the client should not sync and get the flag during a battle. You should only get that restart message when the game syncs up after a battle for example.

Well it doesn’t, I just complained about it in another post https://forums.galaxy-of-heroes.starwars.ea.com/discussion/172122/client-restarts#latest

"Semi;c-1570533" wrote:
I didn't have any issue for some days...
While launching a battle in tb the client needed to restart.
Received some compensation and now I just can't open the TB.
Anyone else ?
Not complaining here... Just saying.

No it's working fine for me, just did a CM.

"Vampire_X;c-1570526" wrote:


Raids and events always going on with payouts globally on the hour , every hour so it can be frustrating.

Seriously? CAN be frustrating? Are they not coders? Can they not code something that will stop this?people missing out on decent gear is a huge issue to gamer satisfaction

I am not currently having any issues with TB after the client restart.

"EyeG_80ate;c-1570558" wrote:

"BigSillyPanda;c-1570551" wrote:

"EyeG_80ate;c-1570550" wrote:

"BigSillyPanda;c-1570546" wrote:

"Vettes4Fetts2;c-1570535" wrote:
Gonna have to side with the devs this time. Can't possibly account for every player when pushing restarts. At least it wasn't 5 minutes before payout...

According to a post above:
Forced restart aren’t technically pushed to devices, but the client get that restart "flag" upon next sync. Normally the client should not sync and get the flag during a battle. You should only get that restart message when the game syncs up after a battle for example.

In my case, I was in the middle of a hRancor, and all I did was open the **** chat window. When I closed it, client restart!
In what twisted universe is that WAI?
It doesn't have to account for anything. It just has to work. It just has to be tested (which the chat clearly wasn't).

Opening chat syncs with the server, syncing with the server gets you the hotfix, hotfix requires a client restart. If you hadn't opened chat, you wouldn't have had the client restart "in the middle" of your rancor run.

But it makes NO sense to do that in the middle of a friggin' battle.

I'm just telling you how it works, could they tell you were in a battle? Maybe, depends on how they have everything set up, but I doubt that info is sent with every request.

Dude, I know how it works. I develop software for a living.
I also know that the game (i.e., the "client") could store that "restart order" (issued by the server) in a variable, and only execute it _after_ the battle. It is not that hard. It just requires common sense.