All Categories

defensive troops attacked defensive troops on a repository

defensive troops attacked defensive troops on a repository

Search
How to join our moderation team?
May 7, 2018, 21:5305/07/18
7

defensive troops attacked defensive troops on a repository

Hi,


Platform : facebook

Server : badlands

Bug : Defense troops attacked defensive troops to capture a repository

UTC Time : May 7, 2018 - 20:42


Step 1 : Launch a capture against a vacant repository with the player A.

Step 2 : Nearly in the same time, launch a capture between the same vacant repository with the player B.

As you can see with the screenshots of the report, defensive troops, sent by the player B with the capture of a repository held by the player A, participated in the "capture" of the repository... 

And on the report, it said « attacked » instead of « seized » while the initial action of the player B is a capture of the repository

I intentionally masked the identities and coordinates of the players to prevent the information on their defense being revealed to other players. Of course I am at your disposal to provide you with the coordinates.

Request : Can you do the necessary to restore the defense of each player as they were before the bug?

Thank you for your help




Views
4k
Comments
12
Comments
Agent PavelTechnical Support
May 8, 2018, 12:4005/08/18
07/02/15
4521

Hello, Commander!

I have tested this feature and can confirm it works as intended. In case you send seize to a vacant Repository, the defensive troops won't participate in the battle. Even if the Repository turns captured when your troops arrive. 

Since the bug has not been confirmed, the troops cannot be restored. 

May 8, 2018, 16:3305/08/18
May 8, 2018, 19:50(edited)
7

Agent Pavel said:


Hello, Commander!

I have tested this feature and can confirm it works as intended. In case you send seize to a vacant Repository, the defensive troops won't participate in the battle. Even if the Repository turns captured when your troops arrive. 

Since the bug has not been confirmed, the troops cannot be restored. 

Hello Pavel,


but in this case you have a report showing that the defensive troops were involved in the battle for the capture, so we are in the case of a bug.

So, I ask that an analysis be done, especially that you have another bug report that indicates the same malfunction.


Normally, we can not launch an attack against a vacant repository : 


So how the troop could make an attack when the only choice on an empty depot it's a capture ?

But but we have two reports of captures that resulted in attacks. And now we can not reproduce this bug...

We know the difference between an attack and a capture !

In conclusion, we ask that the troops lost during this action and bug be restored.


Thank you for your understanding.

Have a nice day.

Agent PavelTechnical Support
May 9, 2018, 09:2005/09/18
07/02/15
4521

Lem said:


Agent Pavel said:


Hello, Commander!

I have tested this feature and can confirm it works as intended. In case you send seize to a vacant Repository, the defensive troops won't participate in the battle. Even if the Repository turns captured when your troops arrive. 

Since the bug has not been confirmed, the troops cannot be restored. 

Hello Pavel,


but in this case you have a report showing that the defensive troops were involved in the battle for the capture, so we are in the case of a bug.

So, I ask that an analysis be done, especially that you have another bug report that indicates the same malfunction.


Normally, we can not launch an attack against a vacant repository : 


So how the troop could make an attack when the only choice on an empty depot it's a capture ?

But but we have two reports of captures that resulted in attacks. And now we can not reproduce this bug...

We know the difference between an attack and a capture !

In conclusion, we ask that the troops lost during this action and bug be restored.


Thank you for your understanding.

Have a nice day.

Your screenshots display the attack on Repository. In case you send units to capture the Repository, the battle report would indicate it was a siege, not the attack.

I have tested the capture and attack options and both of them work correctly. According to the steps you described, the bug has not been confirmed. 
May 9, 2018, 11:5305/09/18
7

Lem said:


 we can not launch an attack against a vacant repository : 


So how the troop could make an attack when the only choice on an empty depot it's a capture ?

But but we have two reports of captures that resulted in attacks. And now we can not reproduce this bug...

We know the difference between an attack and a capture !

As I already wrote it is a capture that was launched and not an attack. 

It's impossible to launch an attack on an empty repository.

The bug is that this capture has been treated as an attack !


So analyze the logs because the losses are not neutral and represent money and time for the players.

AndriiTechnical Support
May 10, 2018, 13:3005/10/18
06/03/14
607

Hello, commander! All actions in the game are made only after the appropriate command of the account holder. The game server processes the command received from the game client in the player's browser. If you send troops as an attack they will arrive at the target and commit an attack; if you dispatch battle squad for the capture, it will capture the target. Commands from the game client cannot be changed during the process of its delivery.

May 10, 2018, 15:5605/10/18
May 10, 2018, 15:58(edited)
7

I understand your analysis and position.

But as I already said, the repository was free when each player launch the capture, the only choice when a repository is free.

However we have at least 2 cases which shows that there was a problem on free repository and for which 4 players had sent troops in capture with the result that the battle which has was delivered for players who came in second resulted in an attack.

The players involved are all regular players with more than 3 years of seniority on the game and who know the mechanics of the game.

Do you believe these players are stupids to launch an attack with defense?









May 12, 2018, 20:1505/12/18
7

Can you tell me where you are in the investigations for the restoration of the lost troops due to this bug ?

At least 4 players are impacted.

May 13, 2018, 07:3805/13/18
1

yes I would like this bug to be analyzed, because I suffered exactly the same problem to capture a free deposit.

As I agree to lose troops on an action of my fact, as I cannot agree to lose troops because of a dysfunction.

For the money which we spend in the game, you owe us a support in case of dysfunction noticed by several players.

Agent PavelTechnical Support
May 13, 2018, 09:4705/13/18
07/02/15
4521

Dear Commanders!

Compensation can be provided in case of a confirmed game malfunction which leads to the troops' loss. At this point, the bug has not been confirmed and the compensation cannot be provided. 

We have tested the feature and didn't find any issues with capturing the Repositories. If you send troops to capture the Repository, the defensive troops won't participate in the battle. Since the attacks have been sent to the Repositories, the troops were lost within the regular gameplay.


May 13, 2018, 16:4005/13/18
May 13, 2018, 16:42(edited)
7

what do you not understand when we tell you that the repository was empty and that it is impossible to launch an attack against an empty repository ?


The players have sent capture on the free repository and this results in attacks. Here is the bug !


Agent PavelTechnical Support
May 14, 2018, 10:3805/14/18
07/02/15
4521
Lem said:

what do you not understand when we tell you that the repository was empty and that it is impossible to launch an attack against an empty repository ?


The players have sent capture on the free repository and this results in attacks. Here is the bug !


As it has already been mentioned, the bug has not been confirmed. The feature works and intended and in case you send troops to capture the Repository, they won't attack the target. I.e. defensive troops won't participate in the battle. 
Since this case has not been classified as the bug, the topic will be closed. 
The topic is locked. You cannot post comments.