The fourth battle of the ATC4 campaign will be in the region of Vyshnoye, Mogilevka and Zub on Jan. 18th, 2012. The Redfor regained the strategical initiative and will attack.

Here the mission file

Good luck!

Hello all,

I am very disappointed with the last battle.
- we all were invited to untested BDR server which appeared unstable and crashed
- the map had the bug which did not perform initial spawn for Blufor
- the map had the bug which still allowed to aware the pilot in Apache when AA rocket is incoming (this was promised to be removed)
- UNA server disconnected over 20 people after 10 min of game, disappeared for long time in the server list and did not allow to rejoin
- in spite of known Arma2 bug with XML in patch 1.60 (https://dev-heaven.net/issues/27326) ATC staff still allow players to join the game with active XML which may cause server crashes

In the result of above we as Redfor experienced restart of game on Blufor request, Redfor lost an element of surprise while attacking the sectors, Redfor lost serious number of vehicles due to disconnected pilots and drivers, late start of game caused that few people with GMT+1 had to resign with participation in this battle, Server admin refused to reset the game on Redfor request, unbalanced fight over 30 vs 10.

I apeal to ATC staff to consider those unusual facts and objectively, with spirit of fair play decide how interpret last battle in campaign and take further actions to be fully prepared with the server and map in the future battles.

Hello Pit

I already sent yesterday night a mail to all Team Leaders telling the battle is void due to technical reasons.

About the map, I sent in advance the final map to all Team Leaders and attacked the file in the ATC forum. As far as I know, the apache problem was solved as promised.

On server side, I personally took all measures I could to assure a smooth and pleasant game, I'm still investigating about the cause of the technical probs and appreciate any hint or suggestion, the thing is there are variables beyond our control, I can send you the log and rpt files if they may interest you. For example if the UNA server (btw I thank the UNA team for hosting) disappeared as you say from the gamespy list I could think this is more a prob of gamespy rather than ATC.

I understand many players got disconnected but several were still playing. Both servers did not crash. In any case the battle is void. I am available for further discussion.

@Pit:

As the map maker I would like to answer to your post.

When you say that the server was untested you are wrong, we continuosly do tests on our server but, as you should know, most of the issues only show up on full numbers, so we need to have serious tests with you all connected and this is what has been done yesterday, and you were all warned by email. We decided to test yesterday because we were confident that we would have good results, otherwise we wouldn't have proposed to test.
We had a first start of the mission to have you all download the file and everything apperaed fine although we were not in full numbers. 5 minutes after we tried to start the mission with full numbers, and although many of us reported that the server was not lagging, there were issues. You have called those issues "map bugs" but they weren't. Peolpe were correctly spawned in the sectors where they should have been, but after some minutes they suddenly ended up in the sea, for no apparent reason. Also our antenna script, which had always worked well, didn't show any markers. So for this reason our side commander Jimmy asked for a restart. I believe that these issues came up because the server was having problems and not because of mission bugs. Keep in mind that the mission file is basically the same with which we played last week.
On the UNA server, which you would call a "tested server" we also had problems, so this is to say that we still need to investigate on the causes and, yes, test again.

Regarding the Apache problem, Teacup suggested that the Apache model from the Arma 2 USMC (which doesn't have a radar) should be used instead of the one from the OA version so I substituted the AH64D_EP1 with the AH64D. For me this problem was solved, but if you claim the Apache to still have a sound signal for incoming missile than it will need further inspection.

The squad xml bug might in some cases generate game crashes. We tried removing xml from profiles last week and it did not affect server stability as you surely remember. Also yesterday neither our BDR server nor the UNA server crashed. We had different problems all relating to server not responding on time, but not crashes.

I think that when there is a restart, all are damaged, both attackers and defenders because all give away their intentions.

The rules say that if for technical reasons there is a delay on the start of the match that goes beyond 30 minutes, the match will non be considered valid. Although if both the Commanders agree the game will be started and valid. So if you had something to say in regard to this topic you should have said it on time.

For what relates to the ATC behaviour rules, I'll leave that to Nemesi to sort.

Thanks for responses.

Problems had been said immediately when occurred on teamspeak by our commander Voy, so do not understand what you mean by "you should have said it on time"

Saying untested, I exactly mean that full number of players was not there. Announcing testing 24h before test time and scheduling it 30 min. before the match is little too late and inappropriate as that time is usually reserved for the latest briefing. It would quite propable that Gamespy caused such problem - if it is true, I guess nothing more can be done, but we prefer UNA server.

Until there will be no strict discipline in removal of XML you will never know if it effects server as at that time when you tried to remove it not everyone did it. If you will not prevent to join with XML, there will be no guarantee that someone will make a server crash in any time of game.

Apache problem (you are right) is removed in FINAL version but for some reasons we did not get it before match - I will speak with Voy about it - thank you Sibolo and Teacup for your efforts in this.

I wish to all of us and believe in it, the next battles will be only better and free of technical problems.

Hello Pit

About the mission file and the Apache problem, we announced it would have been solved in the final map, the one to be used in game, and it was. I sent the map by mail before posting it in the forum (the day before), I am sorry if you did not receive it, but the important thing is the issue was resolved in the version we used for the battle. The Apache problem was not affecting at all your trainings, this is important to note.

About communicating problems, the ATC rules say in case of problems the complaint should be clearly written in the chat and the two Commanders should agree on a decision (example restart of match, or invalidate the battle), in case of no agreement the Staff will have the final word. Of course this implies to have some time to be aware of the problem, to evaluate possible solutions and to make the final decision.

About the technical problems, I think you can understand that it is not easy to collect so large number of players just to make tests, so we have to ask them to join the server before the battle time to see if everything is working. The purpose of testing is not to bother people but to have better and better quality of the game, I can give you all specs on server machine and infos about what we did.

About .xml problem, as I understand it causes client crashes. And the servers never crashed. I hope this further clarifies something, I'm available on TS3 to talk in voice.

About communication - not possible to write in chat when we are out of server.
About XML you are wrong - one player causes server crash.

I will catch Nemesi on TS on Sunday evening, to explain these issues if still needed.