cannot capture towers about domination HOT 54 CLOSED

This was tested on Malden and Altis with v4.01 on Windows with a headless client. This bug always occurs on the server since v4.01.

from domination.

Which setting is "only check towers"?

from domination.

arma3server_x64_2019-07-29_16-19-44.rpt.txt

from domination.

Only check for captured camps and destroyed radio tower to end main target:

from domination.

Ah, this one "Only check for captured camps and destroyed radio tower to end main target:"

from domination.

Bug occurs whether d_enemy_max_camps_count is defined or random.

This is happening on the server now, check out Camp Flabanabba Domination to see the issue.

from domination.

Pardon me, check Camp Flabanabba Experimental.

from domination.

https://drive.google.com/open?id=1dYH0pVkvoNWHXiCLjbRwZwHEeur-jyZ9

from domination.

There are several mission parameters that may be different on other servers, could cause the bug? Anyway offline for a while but back later, hope to help if possible.

from domination.

I've tested with the same mission parameters as you use.
Also used a HC and made a Malden version with my build batch file.

Everything was working as expected. I've captured camps/towers and also the markers showed up.

The only difference was that I've used the latest 4.02 code.

What to do now?

from domination.

Do me a favour and test with the Malden version in from the Google Drive link

https://drive.google.com/file/d/17LGvWr7fajkbWmPk5J4LIk4wxWBwVdtT/view?usp=sharing

from domination.

edited

from domination.

oops, spoke too quickly. about 20 players on the server and can't capture the last tower... worked on another server when I was playing alone... This is with one HC btw.

from domination.

Only the last tower and the other tower worked?

Will try again tomorrow. Not at home for.two days.

from domination.

I am not sure if it was always the last tower but it was the last in some of my tests. I am now testing with very few non-default mission parameters, the few exceptions on the server are "AI enabled - 8 max" "10km viewdistance" and "armor less" but otherwise the parameters are all default. The issue still occurs with those settings.

Anyway, no rush and let me know if I can assist in any way.

from domination.

If only I could reproduce it or the RPT files would give a hint..

from domination.

I haven't been able to reproduce this bug when testing alone. Maybe turning on trace logging on a multiplayer server would show us something?

from domination.

I'll try to make a version with more debug code tomorrow

from domination.

Ok, I've made a 4.02 version which prints quite a lot debug messages to client and server RPT
I need both RPT files

https://drive.google.com/file/d/1IhGkub9v2Eh-x3KI-rQu4XaBqN3ForAP/view?usp=sharing

from domination.

This server log is a mess, an error in the up/down script. Sorry, it seems I committed a bug with that script?

This log shows a period where the capture had stalled out for maybe ten minutes. Oddly when I arrived to the capture area the progress bar magically started working again... As a result this log may only show the bug as a transient issue.

from domination.

arma3server_x64_2019-07-30_19-05-55.zip

from domination.

Arma3_x64_2019-07-31_21-21-30.zip

from domination.

The bug seemed to happen before 1:24 (or 21:24 depending on which log).

from domination.

Arma3_x64_2019-07-31_19-38-11.zip

from domination.

The above zip is from another player that experienced the stalled capture.

from domination.

This one in the server RPT is quite a weird one...

23:04:00 WARNING: Function 'name' - d_delta_2 has no unit
23:04:00 - network id 9:5
23:04:00 - person BadStache
23:04:00 - dead
23:04:00 Error in expression < != -1), 0, "", [], []];
d_player_store setVariable [_uid, _p];
_f_c = true;

} >
23:04:00 Error position: <setVariable [_uid, _p];
_f_c = true;

} >
23:04:00 Error Reserved variable in expression
23:04:00 File mpmissions__cur_mp.malden\initPlayerServer.sqf, line 38

Reserved variable in expression? Err... It can only be the name of a player. Weird weird weird

from domination.

And I've fixed the UpDown error already...

from domination.

And I've fixed the UpDown error already...

Thank you!

from domination.

Let me know if I can assist with more troubleshooting. None of this makes sense to me yet...

from domination.

Don't ask me, the camp capture code hasn't changed for ages... And all the debug messages look good.

So far no one else has problems :(

from domination.

I don't see many servers running the 4.xx code (less than 10 and most with mods) so perhaps not many server admins have found this issue yet. There was also one report from user "John" on the Domination Steam page.

There is a bug hiding here somewhere.

from domination.

The question is, where is that bug?

In the mission or the game....

Btw, I've never seen a problem with reserved variable in expression before.

from domination.

What makes it so hard to fix is that both FSMs responsible for the camp handling haven't changed from 3.99s to 4.xx

I have more and more the feeling that it is caused by some BI changes. Maybe the announced 1.94 hotfix will magically fix the issue.
https://twitter.com/Arma3official/status/1157217955987505152?s=19

I've also made a fix that players without a unit (BadStach in your server RPT) are (hopefully) getting kicked to the server lobby/slot selection and thus do not cause issues.

from domination.

Ok! I deployed the latest master to my server for testing. We will kick it around.

from domination.

The progress bar stalled again with a large group of players on the server.

Here is the RPT from the server:

arma3server_x64_2019-08-02_22-45-31.zip

from domination.

Here is another RPT from a player at the tower at the time the bug occurred. I don't see much...

Arma3_x64_2019-08-02_19-02-18.zip

from domination.

The sad thing is, there are thousands of errors in the Liberation part of the server RPT but none in the Domi and that one isn't working

from domination.

This is still occurring. Is it possible the tower state is being transferred to a headless client? Considering 3.99 code still works correctly it seems likely this bug was introduced by the HC work for v4.

There is a posted discussion regarding HCs and FSM state that caught my eye, might be relevant?

https://forums.bohemia.net/forums/topic/178434-arma3-headless-client-guide/?do=findComment&comment=2804958

I notice setGroupOwner is used in fn_addgrp2hc.sqf and fn_recreatehcs.sqf. I'm not clear on where the tower code is executed.

from domination.

Nothing to do with scripted FSMs but behaviour FSMs like danger

Do me a favour and remove disableRemoteSensor true from init.sqf and test again

from domination.

Please test this version

https://drive.google.com/file/d/10RmO7DRbWoE6OitQVnhFANvaAW7OCO_t/view?usp=sharing

The Camp Capture FSMs are exactly the same as in 3.99s
remote AI sensors are not disabled
and Camp creation code rewritten

from domination.

Cool! We have captured targets with the 4.03 code!

There was one case where the capture progress bar seemed to freeze for maybe 5 minutes but it self corrected. I will let it continue and report issues here.

from domination.

What are the client and server FPS when the problem occurs?

from domination.

Can't remeber, do you use civilian module?

from domination.

What are the client and server FPS when the problem occurs?

The client and server FPS were both very high usually 48+. By the way from my observation the server FPS has been EXCELLENT since v4, rarely below 48. The factory was more than 12m away and no enemies were close.

It looks like that issue was transient and hopefully one-time only. It has not happened again.

Can't remember, do you use civilian module?

Yes. However I have successfully captured towers with a civilian very nearby. It does not appear the civs block a capture.

from domination.

We have beaten six main targets so far on 4.03. Other than the one odd experience we discussed the mission has been running normally.

It looks like this bug is fixed now! You did it Xeno, congratulations!

from domination.

Noooooooooooooooo. Hold the champagne. :(

I am seeing the bug now on Camp Flabanabba. We are on main target #7 and suddenly a tower won't capture more than 40%. The server and client FPS are not visible (no number is displayed).

from domination.

Well, your server hangs...

Can you tell me how many AI units are there?

from domination.

I don't see any AI. Just some human players. Windows server looks healthy. The mission was running well for almost 24 hours.

from domination.

Ah, I thought you might have a debug console running :)

And can you somehow show the server FPS?

With a #monitor command?

from domination.

Funny story, I don't know how to use the debug console.

I already performed a #restart and I didn't think of trying #monitor first. The server is an Amazon instance so you can decide if that is stable or unstable (opinions differ). :)

After a #restart the client and server FPS are visible and pegged at 48+ again. Let's see how it goes.

from domination.

Well, I have 4.04 ready, I'll release that as a normal release. I have optimized some more things.

Btw, are you running the A3 profiling branch (which has the latest improvements) or the last hotfix?
(Both are compatible)

from domination.

Just the latest hotfix. I will look into the profiling branch, thanks.

from domination.

At least I've fixed another headless client issue:

Fixed: While remote AI units on a headless client trigger a EntityKilled eventhandler on a server immediately, the alive status of the killed unit is not updated right away, this broke respawn AI groups when they were transfered to headless clients

from domination.

Ok, closing this ticket. Thanks Xeno.

from domination.