cannot capture towers

[longtimegamer]

Players attempting to capture a tower can see a progress bar but it does not fill.

Steps to reproduce:

• start a mission (tested on Altis and Malden with settings "only check towers")
• advance to a capture tower
• observe the capture bar is not filling

This prevents the main target from ever being "beaten" and turned to a green circle.

[longtimegamer]

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.

[Xeno69]

Which setting is "only check towers"?

[longtimegamer]

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

[longtimegamer]

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

[Xeno69]

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

[longtimegamer]

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.

[longtimegamer]

Pardon me, check Camp Flabanabba Experimental.

[longtimegamer]

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

[longtimegamer]

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.

[Xeno69]

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?

[Xeno69]

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

[longtimegamer]

edited

[longtimegamer]

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.

[Xeno69]

Only the last tower and the other tower worked?

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

[longtimegamer]

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.

[Xeno69]

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

[longtimegamer]

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?

[Xeno69]

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

[Xeno69]

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

[longtimegamer]

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.

[longtimegamer]

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

[longtimegamer]

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

[longtimegamer]

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

[longtimegamer]

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

[longtimegamer]

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

[Xeno69]

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

[Xeno69]

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

[longtimegamer]

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

Thank you!

[longtimegamer]

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

[Xeno69]

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 :(

[longtimegamer]

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.

[Xeno69]

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.

[Xeno69]

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.

[longtimegamer]

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

[longtimegamer]

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

[longtimegamer]

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

[Xeno69]

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

[longtimegamer]

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.

[Xeno69]

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

[Xeno69]

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

[longtimegamer]

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.

[Xeno69]

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

[Xeno69]

Can't remeber, do you use civilian module?

[longtimegamer]

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.

[longtimegamer]

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!

[longtimegamer]

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).

[Xeno69]

Well, your server hangs...

Can you tell me how many AI units are there?

[longtimegamer]

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

[Xeno69]

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

And can you somehow show the server FPS?

With a #monitor command?

[longtimegamer]

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.