TPWCAS for A3 - AI Suppression System - suggestions/comments/ideas discussion

[neodammerung 8]

I'm the only one having this error when trying to launch Arma3 with Tpwcas v5.3 ?

Btw I did replace the .hpp file in the userconfig folder

[Heinrich Kramer 172]

I'm the only one having this error when trying to launch Arma3 with Tpwcas v5.3 ?

http://i251.photobucket.com/albums/gg314/Neodammerung3333/Others/tpwcas_a3_v53.jpg~original

Btw I did replace the .hpp file in the userconfig folder

nope, me too :(

[lordprimate 159]

i noticed this error

tpwcas_mags =

[

"B_9x21_Ball",

"B_9x21_Ball_Tracer_Green",

"B_556x45_dual"

];

It use to be like this.

tpwcas_mags [] =

{

"B_9x21_Ball",

"B_9x21_Ball_Tracer_Green",

"B_556x45_dual"

};

Ollem, I had not seen the edit of your post until now what i have done is this

First, I removed the "All" from the nearestObjects search.

Second, I changed and item in the filter as per your previous suggestion. the filter looks like this now.

if (["fence", (str _this)] call BIS_fnc_inString) exitWith {false};

if ([": b_", (str _this)] call BIS_fnc_inString) exitWith {false};

if ([": t_", (str _this)] call BIS_fnc_inString) exitWith {false};

if (["slop", (str _this)] call BIS_fnc_inString) exitWith {false};

if (["rater", (str _this)] call BIS_fnc_inString) exitWith {false};

seems to work. it could be a placebo effect. in the past, tpwcas would almost always select a bush or a road section. now it doesnt. I saw flags, at a few road barriers, runway markers(wedge shaped red and white striped things), but no bushes, road segments etc.

i have not checked the rpt logs though for hard evidence.

Edited November 16, 2013 by Lordprimate

[ollem 4]

I'm the only one having this error when trying to launch Arma3 with Tpwcas v5.3 ?

http://i251.photobucket.com/albums/gg314/Neodammerung3333/Others/tpwcas_a3_v53.jpg~original

Btw I did replace the .hpp file in the userconfig folder

Oops - missed that one - updated the link with fixed userconfig .hpp file

as mentioned by Lordprimate fix is to replace [] by {} :

tpwcas_mags =

[

"B_9x21_Ball",

"B_9x21_Ball_Tracer_Green",

"B_556x45_dual"

];

tpwcas_mags[] =

{

"B_9x21_Ball",

"B_9x21_Ball_Tracer_Green",

"B_556x45_dual"

};

Edited November 17, 2013 by Ollem

[neodammerung 8]

If I replace tpwcas_v2.hpp by the one you fixed in your new link I get :

tpwcas_mags =

{

"B_9x21_Ball",

"B_9x21_Ball_Tracer_Green",

"B_556x45_dual"

};

and this error :

If I replace manually by the one you wrote in this topic :

tpwcas_mags [] =

{

"B_9x21_Ball",

"B_9x21_Ball_Tracer_Green",

"B_556x45_dual"

};

I get this error :

Edited November 17, 2013 by Neodammerung

[ollem 4]

For temporary workaround please remove the mags entry completely from the .hpp file. I will check later today.

-----update -----

I believe the error is caused by the space in between tpwcas_mags and [].

So should be tpwcas_mags[] = { etc,etc... };

Updated .hpp in zip file link above

Edited November 17, 2013 by Ollem

[lordprimate 159]

For temporary workaround please remove the mags entry completely from the .hpp file. I will check later today.

-----update -----

I believe the error is caused by the space in between tpwcas_mags and [].

So should be tpwcas_mags[] = { etc,etc... };

Updated .hpp in zip file link above

Oops, that one is my fault .. I thought it didnt look right. so i put a space there.. Sorry peeps!

edit: after reading your post on the last page bout the filter, i can see that it works.. but last time i had looked at my rpt i saw bushes and road segments being used the object and in the bushed .p3d name there is the ": b_". and that is in the filter. I bet I was using the wrong rpt for debugging... thats my luck .. Mor testing

Edited November 17, 2013 by Lordprimate

[neodammerung 8]

Thanks, that's was really fast, works like a charm

[Variable 322]

Updated .hpp in zip file link above

Above where? Is the link in the first post updated?

[gagi 10]

Still no debugs balls with HC

[ollem 4]

Above where? Is the link in the first post updated?

I actually referred to my post Nov 15 2013, 17:21 #173 but I've updated start post as well now :-)

---------- Post added at 22:43 ---------- Previous post was at 22:39 ----------

Still no debugs balls with HC

Are you sure AI is actually spawned at HC?

HC no longer worked properly for me in case HC automatically picks the first available player slot.

forceHeadlessClient=1; doesn't work at all for me currently, so a bit hard to verify and/or chase potential bugs.

If HC is working for you, when HC picks a player slot does it disappear for you or stays visible?

In cases it disappears I think I noticed the funtion I used to determine if the system is an HC no longer works properly.

[gagi 10]

Well I think because server monitor was steady 50 FPS ...

But the behaviour seems good !

I'll investigate tomorrow´s eve cause now I'm in a test to validate a Domina for friday coop eve :)

The best test I can do is probably with an Hardcore Insugency with HC support.

Perhaps after this test mission...

[gagi 10]

Did you log as player admin BEFORE connecting the HC Ollem ???

If you don't do that : you'll encounter the behaviour you described.

You have to log in as admin first

Then HC

OtherWise, the HC launches the mission. And i think you become a JIP ...

Edited November 20, 2013 by gagi

[gagi 10]

I did the Hardcore Insurgency v1.35 test from Code34.

I did have debug balls sometimes but the AI were sometimes dumb, sometimes debug balls and sometimes spotting me.

I respawn like 10 times and it was really strange feeling ... Perhaps the way Hardcore Insurgency spawns/despawns the bots is not good for tpwcas ...

So I tried with another latest Domina and I encounter other problems, I think Xeno removed HC support in latest Domina cause the tower/camps markers didn't even spawn when running HC. So, I revert back to a previous version which was handling tower/camps on HC correctly but didn't have more time to verify debug balls...

[gagi 10]

Verified : no debug balls at all on the Domina compared to Hardcore Insugency 1.35

So I've got no mission for HC+tpwcas working right now.

For friday I will revert back to standard no HC coop dedicated server+tpwcas.

Cannot stand this Vanilla AI anymore !!!

Another thing I noticed is that when running tpwcas : it seems really network verbose, not sure every connexion can handle such trafic client side...

[Make Love Not War 10]

BTW, I changed the nearestObjects classname search to "All" because from what i can tell, the AI find ok cover on first contact. This is just to test out. with this change they will only get an order from tpwcas to go to cover if there is an object with a classname found, (vehicles, buildings, etc)

The nearestObjects search returns the .p3d name of the object. IE. bushes, trees, rocks... However, no matter how i try I cannot get those objects to be filtered out... Even using boundingboxReal... a roadsegment would return a value of 6m,6m,6m(for example not exact).. but we all know that the road segment isnt 6m tall.. but for some odd reason it is found (by BoundingBosReal) to have a max height of 6m.... so the ai will be sent to a roadsegment for cover..

the problem is after you get the .p3d name of the object, forsome odd reason you cannot use bis_fnc_instring to find a string of letters in that objects .p3d name.. I dont know why.. bis_fnc_instring is suppose to be able to find any set of letters that you tell it to. With in a specific string... IE . If i wanted to filter out bushes.. a bush in arma is named . 12327232: b_(insert bush name here).p3d.. so my filter is looking for names with a "b_" in them.. that didnt work so i added ": b_" still doesnt work. but that is the whole point of bis_fnc_inString.. is to find a few charactors (that you designate) inside of another string... but its not working..

anyone have any ideas... outside of that i think its current method is best.. Only being told to go to cover if it is a known objects(ie has a classname)

Hey, LordPrimate, besides bushes which objects are you trying to filter out of the nearestObjects return? To get rid of roads, for instance, do something like this:

_objects = nearestObjects [_pos, [], _rad] - (_pos nearRoads _rad);

nearestObjects also retuns a metric ton of garbage objects like clutter, triggers and footsteps, which, conveniently enough, are also returned by nearObjects. So, instead of eliminating them via string comparisons which are kinda gross performance-wise, a much easier way to knock the grabage out is by subtracting nearObjects return from your nearestObjects array. That will also subtract all buildings, BTW, but that's not a problem as we can add those in afterwards.

In terms of buildings, another trick is to use a separate, much larger radius for returning buildings seeing as they can be very large and all these returnTheseObjects commands only return objects whose center positions are within the 3D radii passed. Meaning, you could be on a building corner, but nearestObjects with a radius of 8m won't return the building in question because its center is, say, 10m away. Something to watch out for in regards to tall structures too. So, our code might now look something like this:

_objects = nearestObjects [_pos, [], _rad] -
       (_pos nearObjects _rad) - 
       (_pos nearRoads _rad) + 
       (_pos nearObjects ["House", _houseRad]);

Going back to the problem of large objects and the 3D search sphere, one other critical area to watch out for is trees. Trees can be quite tall and especially when attempting to search from a centre position located on a steep slope, they can be easily omitted from the return if the passed radius is too small. For that reason, I recommend an 8m search radius as a minimum. Something around 16m would probably be better.

As for strings, you'll probably find yourself forced to do some string comparisons at some point in the culling process. Here's what I use:

MLNW_FNC_isInString = {
   /*
       isInString

       Description: 
           Returns true if _searchFor string is contained within _searchIn string.

       Syntax:
           [_searchFor, _searchIn, _case] call MLNW_FNC_isInString

       Parameters:
           _searchFor String
           _searchIn   String

           Optional:
               _case    Boolean

       Return Value: 
           Boolean

       v 1.0
   */

   private ["_searchFor","_searchIn","_match","_shift","_case","_compareTo"];

   _searchFor = _this select 0;
   _searchIn  = _this select 1;
   _case      = _this select 2;    // case-sensitive?

   if not (isNil "_case") then {
       if not (_case) then {
           _searchFor = toUpper _searchFor;
           _searchIn  = toUpper _searchIn;
       };
   };

   _searchFor = toArray _searchFor;
   _searchIn  = toArray _searchIn;

   _match = false;
   {
       _shift = _forEachIndex;
       {
           _compareTo = _searchIn select (_forEachIndex + _shift);    
           if (isNil "_compareTo") exitWith {_match = false};
           if (_x != _compareTo) exitWith {_match = false};
           _match = true;
       } forEach _searchFor;    
       if (_match) exitWith {};
   } forEach _searchIn;

   _match
};

Let me know if I can be of any further assistance.

Ed: Oh, before I forget, another tip: when culling out bushes search for " _b" rather than "_b". I started with the latter and was wondering why some of the pine trees weren't returning. Well, with names like "t_pinuss2s_b_f" they shouldn't be returning. :)

Edited November 20, 2013 by Make Love Not War

[lordprimate 159]

makelove not war, thanks but you should look at the code as it exists already. Most of what you said i already know, but thanks for the sentiment!

for the strings i am currently using "str" and "BIS_fnc_inString, however, in the current release its using format and BIS_fnc_inString. I use ": b_" to filter out bushes because their string is something like " 1234323423: b_blahblah.p3d ".. for trees i use ": t_" becuase the string for trees is " 123123412: t_treename.p3d " so i use ": b_" and ": t_" for bushes and trees, seems to be working with str and bis_fnc_instring.

I think you got the wrong idea from what i said about large objects and their boundingbox values. a road segment that is "flat" returns a height of over 6meters... but its flat ... so the filter thinks its a good object to hide behind.

I am still working on the road issue but your mentioned code was originally part of the filter.. it doesnt work... so it was removed. right now i am looking for the AI to choose a road as cover again so i can look at the rpt for the string returned for the road.

for now i have to go I just saw that this had a bump and wanted to read what it was..

MLNW, look at the current code in tpwcas.

[gagi 10]

I have a question perhaps you know :

There's an option in ASRAI to throw smoke grenades, I activated this feature in the hpp but AI nether throw smokes...

Do you know if I'm missing something?

Do we need an other addon? Do we need to set content of AI load outs?

Thanks in advance.

Latest tpwcas+latest ASAI on 1.06 seems quite good : I'll retest the HC ASAP with these versions.

[lordprimate 159]

gagi, on the previous page you mention that when running tpwcas, "it seems really network verbose/taxing"

Is this "With" debug, and bDetect logging?

Or, "WithOut" debug, and bDetect logging..

because if you have debugging on and bdetect logging on it will lag a bit, its literally typing the whole battle down as it happens in the RPT. Bullets detected, suppression, ai skills , etc. all that stuff gets logged into the rpt and bog's the game down...

If not then , Hmmm...

[gagi 10]

Yeah Lordprimate, that's what I thought so I already deactivated the logging asr&tpwcas level on the server and it was better.

I'll double check but it seems still network verbose, which is normal.

I will compare with & without and feedback.

Edited November 21, 2013 by gagi

[fabrizio_t 58]

makelove not war, thanks but you should look at the code as it exists already. Most of what you said i already know, but thanks for the sentiment!

for the strings i am currently using "str" and "BIS_fnc_inString, however, in the current release its using format and BIS_fnc_inString. I use ": b_" to filter out bushes because their string is something like " 1234323423: b_blahblah.p3d ".. for trees i use ": t_" becuase the string for trees is " 123123412: t_treename.p3d " so i use ": b_" and ": t_" for bushes and trees, seems to be working with str and bis_fnc_instring.

I think you got the wrong idea from what i said about large objects and their boundingbox values. a road segment that is "flat" returns a height of over 6meters... but its flat ... so the filter thinks its a good object to hide behind.

I am still working on the road issue but your mentioned code was originally part of the filter.. it doesnt work... so it was removed. right now i am looking for the AI to choose a road as cover again so i can look at the rpt for the string returned for the road.

for now i have to go I just saw that this had a bump and wanted to read what it was..

MLNW, look at the current code in tpwcas.

What about:

_objects = nearestObjects [_pos, ["house"], _dist * 2] + (nearestObjects [_pos, [], _dist ]) -  (_unit nearTargets _dist) -  (_pos nearObjects _dist )  -  (_pos nearroads _dist); 

Old stuff, but working almost fine for me, with some post-filtering added (boundingBoxReal, height, min. dimension, ...)

Beware of string comparison functions, they are usually slow.

Edited November 21, 2013 by fabrizio_T
Junk removed from code!

[lordprimate 159]

i hope that didnt come off as snarky in that last post. the nearroads check use to be in tpwcas but it was commented out. I commented it back in, and i swear i still saw them take up road positions, and i think ollem completely removed it a while ago. Ill try to work it back in and check the results.

[ollem 4]

I indeed removed the road check a while ago while we already checking measurements/heights, but we will add it back in asap :-)

Thank you all for contibution to this thread.

@Gagi: I will check your 'admin' check related to HC.

[gagi 10]

I indeed removed the road check a while ago while we already checking measurements/heights, but we will add it back in asap :-)

Thank you all for contibution to this thread.

@Gagi: I will check your 'admin' check related to HC.

ok

I checked asr_ai, it seems that for the smoke grenades, Ai need special weapon to throw smoke grenades. It doesn't seem to handle hand smoke grenades.

[lordprimate 159]

gagi, i know you want to help. So, you need to post your findings in the ASR_AI thread for Arma 2 here:ASR_AI