Would be cool if there was a compatibility between the LAMBS modules

LAMBS danger https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=1858075458 is working fine with the mod, I've just tested.

Does it work with Liberation game mode?

Is there issues with CBA, RHS and CUPs maps

CBA is the single requirement for this mod, so no issues :) RHS - no issues also. Non default maps- the mod would only work on them if their grass textures have "grass" or "dirt" as part of their name. Liberation - did not test, but should work.

is it compatible with cf_bai ?

Yep, fully compatible with cf_bai.

Is this compatible with Antistasi Plus?

Can confirm working with Antistasi Community Edition. Have not as yet tested with Antistasi Plus..

Can confirm working with Antistasi Plus

Liberation should be working AFAIK but check the maps for sure, no idea if single terrains (Saint Kapaulio, VT7) will be 100% compatible because of that "grass" string.

The mod works very weirdy with the "COOP 08 Force Recon (Weferlingen, West)" by Vertexmacht mission. Requires Global Mobilization 1.5 DLC
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=2956673906&searchtext=COOP+08+Force+Recon

1. It creates infinite amount of HIG_Wall objects. I found it out by counting and dumping allMissionObjects "All" to the .RPT My FPS went to 2-5 per second after reaching ~30k of the wall objects.

2. For some reason it causes to fire "KnowsAboutChanged" event on enemy groups 10-30 times per second spamming script scheduller wirh 3000-6000 of new threads (spawn-ed) with event handler spawned. And the target unit (_this select 1) for that event is a... wall (wtf?).

3. After code review I found that your code has some flaws like defining (and redefining) functions inside the loop (_sect_fn and _srfce_chkr_fn) on each loop iteration, not disabling simulation for the wall, not privatizing local variables with the "private" keyword, and not using lazy evaluation in the expressions. These commands are used to diagnose: diag_activeScripts, diag_activeSQFScripts

Is there way to enable texture for the wall for debug purposes?
this setObjectTexture [0, "#(rgb,16,16,4)color(1,0,0,1)"]
in the wall INIT doesn't work (probably there's no hidden selection with index 0)

@Samara Morgan, if you play the mission in coop, I'd suggest turning off the logs. The slowdown may be due to log overload with useless reports - see Gunter Severloh's comment in the multiplayer feedback thread.
1 & 2. Could indeed be mission incompatibility, or see the above.
3. Good spot on functions defining within a loop (well, one of the secondary loops) - I repent this sin :) I may refactor them when I get back to my A3 PC, although the performance hit in their scheduled enviro is probably negligible (in a non-schduled enviro it would be less so).
I used underscore for private vars so they do not clash outside their threads.
Lazy evaluation- breaks and continues :)
4. No way to enable texture for the wall. You may substitute HIG_wall with something like Land_CncBarrier_F - the dimensions will be off, but it should probably do the job otherwise.

@claudiopolez
same problem with the Lato's "HUNTER SIX 2 The Malden Crisis" mission. It is the mission of the week but after playing it several hours I have noticed that this command

count (allMissionObject "All");

was returning more and more objects. I have dumped all objects to .RPT with this

{
diag_log (format ["OBJECT: %1 | TYPE: %2", _x, typeOf _x]);
} forEach (allMissionObjects "All");

and found out this record literally spammed the .RPT

21:32:57 "OBJECT: 6055cb80# 634238: hig_barriergi.p3d | TYPE: HIG_mywall"

So, basically the mod spawned several thousands HIG_mywall objects when I had fixed amount of AI on the map (284 of AI units). And the count of HIG_mywall is constantly increasing causing the performance leakage.

At this moment I decided to turn ACSTG off from using it on regular basis (as core mod for all missions) because of that, but this is not very nice because the mod is very cool and it makes the gameplay more consistent.

@Samara Morgan, I'm still away from my Arma PC, but played Lato's "HUNTER SIX 2 The Malden Crisis" mission on my friend's pc for an hour and had no issues with the ACSTG mod. And I mean not just the fps, but the way enemy lists populate and depopulate, walls spawn and despawn and so on - everything was work ok (despite this mission having some weird mechanics like dead bodies sinking and disappearing into the ground after searching the bodies).
The diag log may not necessarily give the true picture as the log would and should be spammed by numerous HIG_mywall objects. They are spawned at a changing fast rate, but they are also DEspawned/deleted at a different changing fast rate. The logs may not reflect the deletion part. tldr, as I have said above, turn the logs off.

@claudiopolez
Alright, I have found the root of the problem. Incorrect local variables privatisation. In particular _createWall variable is being created in badly manner. I made every single local variable private according to its scope and the problem with the lost pointers to the objects (created by createVehicle []) gone. There is no more thousands of thousands abandoned HIG_wall objects after 5-20 hours of gameplay.

I strongly recommend you to read the article dedicated to PRIVATE command on arma 3 wiki especially the red framed part (with the warning symbol at the left side). Thanks for the reply anyway, I thinkg you can fix it by yourself in the next update. At least for me it's again "must have" core modification!

Also I suggest you to create HIG_wall with disabled simulation (or even using createSimpleObject) but it needs some testing to make sure the AI still can't see through the wall.

And the last thing :) S.O.G. Prairie Fire DLC has #CLN_Forest surface with dense grass and it is not in the list of surfaces for creating the wall (_srfce_chkr_fn function and _cur_surf variable). It is Cam Lao Nam world. I didn't check the other one but probably it has its own forest / grass type also. Gonna report back after the checking.