Jump to content
Sign in to follow this  
tpw

TPWC AI suppression system

Recommended Posts

Even though these have been SP releases, I have been able to test solely on my dedi. For the majority of time it works reasonably well. A full MP variant will be lovely.

I reckon that I will still get a slight slowdown as I normally run with 300-400AI most of the time :)

Keep up the good work gents !

You know how I keep saying Ollem and Fabrizio are magicians? I mean that metaphorically. If you could run 400 units without slowdown, then they'd have to be actual magicians....

Share this post


Link to post
Share on other sites
You know how I keep saying Ollem and Fabrizio are magicians? I mean that metaphorically. If you could run 400 units without slowdown, then they'd have to be actual magicians....

Thanks, but Fabrizio is the real magician - I'm just the assistant ;-)

Share this post


Link to post
Share on other sites
Thanks, but Fabrizio is the real magician - I'm just the assistant ;-)

Popcorn is ready... .can't wait for the show to start!!

:yay:

Share this post


Link to post
Share on other sites

bDetect v0.70 SP/MP released.

Please wait for a new release of TPWC AI to hook it.

Big thanks to Ollem.

For script version, MP required configuration is:

bdetect_mp_enable = true;

Since MP is not automatically handled per-default (to limit overhead for SP-only players).

Then, ONLY if server side detection is not considered satisfactory please try adding:

bdetect_mp_per_frame_emulation = true;

---

Now let's see what's working and what's not - TPW it's up to you hooking this ;)

---------- Post added at 18:54 ---------- Previous post was at 18:48 ----------

Thanks, but Fabrizio is the real magician - I'm just the assistant ;-)

Not true, without your efforts we would NOT have any bDetect MP version available.

Edited by fabrizio_T

Share this post


Link to post
Share on other sites

Hi tpw

Thanks for the update!

A few quick tests - same missions, same addons as before:

- the text debug clashes badly with CO SLX_wounds, I'm guessing it's the name-labelling of the wounded ally markers. System graunches to a halt, errors like:

Cannot create video memory surface DXT5,1024x1024 (size 1398096 B), Error 8876017c
Virtual memory total 2047 MB (2147352576 B)
Virtual memory free 1271 MB (1332752384 B)
Physical memory free 1075 MB (1127419904 B)
Page file free 3167 MB (3321188352 B)
Process working set 522 MB (547540992 B)
Process page file used 529 MB (555712512 B)
Longest free VM region: 361562112 B
VM busy 1023528960 B (reserved 162566144 B, committed 860962816 B, mapped 60616704 B), free 1123823616 B
Small mapped regions: 15, size 86016 B
VID: alloc 903634668, limit 2147483647, free: local 0, nonlocal 61067166, DX9 60817408, virt. 1333211136
Error: Failed to create surface texture (ca\structures\data\plastic\plastic_grey_old_nohq.paa:0)

Debug balls work OK, but twice also had some video memory surface errors (but recovered after a flush). The tell-tale is suddenly getting a black screen with "Receiving...", both times on switching from optics to normal view. Also noticed when I turned them on that map unit markers were now mostly triangles (with or without SLX running) & a few allies had red triangles.

Without SLX in Trial by Fire (2of 3 runs) the chopper didn't land, it headed inland; Once it shot up the ZSU truck then landed, once it just kept circling around shooting (badly!) at anything enemy, & never landed. With SLX it merely fires at the truck as it comes in to land.

In a couple of missions - "Pinned Down" & a port to Podagorsk of the latest Flashpoint mission - with & without SLX, & a single run of "Pinned Down" without asr_ai or SLX (so only CBA, TPW_LOS & OKT_noblur running) I got intermittent error messages about aiming shake:

Error in expression <"aimingshake",_newshake];        
_unit setskill ["courage",_newcourage];  
};
>
 Error position: <setskill ["courage",_newcourage];  
};
>
 Error Type Any, expected Number
File tpwc_ai_suppress_207\tpwcas_decskill.sqf, line 47

I had similar results with the script version & the PBO. Also happened once or twice with all debugging off in one test.

I'll have a hack at the SLX_Wounded.sqf in ORC_SLX_wounds to see if I can disable the wounded-ally marker-naming without buggering up the whole thing. The naming is fairly pointless anyway (except maybe in a large MP).

If something is conflicting with map markers I should probably look at one or two HC missions as well.

I'll run some more methodical tests tomorrow - just CBA & TPWC AIS207, then add in the others one by one.

Share this post


Link to post
Share on other sites

This is the last thing you want to hear but the visual effect doesn't really work at night/dusk/dawn as the high contrast just blacks everything out so you cannot see anything, At least for me, is it possible to have only blur for certain times or something? I wouldn't care so much but when you are being suppressed you cannot see where to move to cover.

This is without night vision... Anyway no biggie in the scheme of things and I can off course just turn it off if playing at these times :)

Share this post


Link to post
Share on other sites

Hmmm...

Anyway, I tested 2.07 this morning. Had exactly same results with coslx wounds as I noted yesterday with only tpwc debug balls enabled, and also with balls and text enabled together.

However, I found that running text debug alone caused no problems whatsoever that I could determine. No civ creation beyond expected values, no noticeable slowdown and that while using coslx including slx_wounds, along with asr. I found the debug text to be more useful anyway, as its visible through obstructing obstacles and landscape features. Anyway looking good.

Edited by tadanobu

Share this post


Link to post
Share on other sites

I do have some MP code available which does work quite well on 1 server, but fails AI stance reaction on another (but the debug balls work, so no complaints there :D )

Test was done with exact same mission file.

The following code is not yet based on today's release of TPWC and bDetect, but If some of you could test on dedicated server that would be great.

The fact it didn't work on that server might be caused by older version of ASR_AI???

MP-Compatible-TPWC

These are just files , no pbo.

Start with:

[] execVM "tpwcasMP.sqf";

(if you don't know how to enable, you might better not test this ;) )

NOTE: in this release no player camshake, no text debug.

Edited by Ollem

Share this post


Link to post
Share on other sites

Thanks for the report Orcinus. The map marker stuff is actually part of the ball based debug. The text stuff I added does nothing to markers, so should not conflict in any way. Try your tests again with tpwcas_debug=0 and tpwcas_textdebug=5.

I run COSLX wounds and have never seen a problem.

At Fabrizio's suggestion, I am going to change how the system handles unit filtering, which might also be causing problems.

Hi tpw

Thanks for the update!

A few quick tests - same missions, same addons as before:

- the text debug clashes badly with CO SLX_wounds, I'm guessing it's the name-labelling of the wounded ally markers. System graunches to a halt, errors like:

Cannot create video memory surface DXT5,1024x1024 (size 1398096 B), Error 8876017c
Virtual memory total 2047 MB (2147352576 B)
Virtual memory free 1271 MB (1332752384 B)
Physical memory free 1075 MB (1127419904 B)
Page file free 3167 MB (3321188352 B)
Process working set 522 MB (547540992 B)
Process page file used 529 MB (555712512 B)
Longest free VM region: 361562112 B
VM busy 1023528960 B (reserved 162566144 B, committed 860962816 B, mapped 60616704 B), free 1123823616 B
Small mapped regions: 15, size 86016 B
VID: alloc 903634668, limit 2147483647, free: local 0, nonlocal 61067166, DX9 60817408, virt. 1333211136
Error: Failed to create surface texture (ca\structures\data\plastic\plastic_grey_old_nohq.paa:0)

Debug balls work OK, but twice also had some video memory surface errors (but recovered after a flush). The tell-tale is suddenly getting a black screen with "Receiving...", both times on switching from optics to normal view. Also noticed when I turned them on that map unit markers were now mostly triangles (with or without SLX running) & a few allies had red triangles.

Without SLX in Trial by Fire (2of 3 runs) the chopper didn't land, it headed inland; Once it shot up the ZSU truck then landed, once it just kept circling around shooting (badly!) at anything enemy, & never landed. With SLX it merely fires at the truck as it comes in to land.

In a couple of missions - "Pinned Down" & a port to Podagorsk of the latest Flashpoint mission - with & without SLX, & a single run of "Pinned Down" without asr_ai or SLX (so only CBA, TPW_LOS & OKT_noblur running) I got intermittent error messages about aiming shake:

Error in expression <"aimingshake",_newshake];        
_unit setskill ["courage",_newcourage];  
};
>
 Error position: <setskill ["courage",_newcourage];  
};
>
 Error Type Any, expected Number
File tpwc_ai_suppress_207\tpwcas_decskill.sqf, line 47

I had similar results with the script version & the PBO. Also happened once or twice with all debugging off in one test.

I'll have a hack at the SLX_Wounded.sqf in ORC_SLX_wounds to see if I can disable the wounded-ally marker-naming without buggering up the whole thing. The naming is fairly pointless anyway (except maybe in a large MP).

If something is conflicting with map markers I should probably look at one or two HC missions as well.

I'll run some more methodical tests tomorrow - just CBA & TPWC AIS207, then add in the others one by one.

Share this post


Link to post
Share on other sites
Also noticed when I turned them on that map unit markers were now mostly triangles (with or without SLX running) & a few allies had red triangles.

Unit marker is a triangle by default. It changes to a circle whenever the unit is fleeing.

Very interesting you noticed some allies having red triangles, as long as you play WEST.

It may mean they are renegades: that happens when, due to low accuracy, friendly units accidentally fire blue-on-blue, becoming "enemy" to own side.

That's quite common for machinegunners.

Let's see if anybody else is having this kind of issue. In that case, i know how to solve the problem.

---------- Post added at 22:20 ---------- Previous post was at 21:32 ----------

System graunches to a halt, errors like: ...

Can you tell how many units were on the field? How long did you play before the problem?

The error message looks unrelated to TPWC AI though, more PC config / vanilla ArmA2 related (see: http://forums.bistudio.com/showthread.php?129586-How-much-swapfile-does-this-game-need).

Edited by fabrizio_T
typos! Too late, good night

Share this post


Link to post
Share on other sites

Hi all

We are moving much closer to a proper release of SP / MP / Dedi compatible TPWCAS. Again this is a very big change, so will warrant a full integer update. v3.00beta will be available in addon and script hopefully within 24 hours. Thanks to Kremator and Pellejones for helping with MP testing.

Share this post


Link to post
Share on other sites

Hi Fabrizio /TPW, have been following this from the start, it's been great to watch.

I was keen get suppression effects at long range with support weapons so I made the following changes to bdetect (and appropriate changes to TPWCAS variables):

if(isNil "bdetect_bullet_max_distance") then { bdetect_bullet_max_distance = 1200; }; // (Meters, Default 400) Bullets havin travelled more than distance are ignored

if(isNil "bdetect_bullet_max_lifespan") then { bdetect_bullet_max_lifespan = 1.5; }; // (Seconds, Default 0.5) Bullets living more than these seconds are ignored

The math is a bit rough and ready but I presume that otherwise it should work ok - or am I likely to get odd results? I've got a beefy cpu

cheers

JJ

Share this post


Link to post
Share on other sites
Hi Fabrizio /TPW, have been following this from the start, it's been great to watch.

I was keen get suppression effects at long range with support weapons so I made the following changes to bdetect (and appropriate changes to TPWCAS variables):

if(isNil "bdetect_bullet_max_distance") then { bdetect_bullet_max_distance = 1200; }; // (Meters, Default 400) Bullets havin travelled more than distance are ignored

if(isNil "bdetect_bullet_max_lifespan") then { bdetect_bullet_max_lifespan = 1.5; }; // (Seconds, Default 0.5) Bullets living more than these seconds are ignored

Fine jiltedjock,

it should cause no problems.

Of course overhead would be higher, since bullets are tracked 3x the distance / duration, but that would matter only if you play missions with a massive number of units and/or your FPS are low.

Be aware that tpwc settings override bDetect default values though.

So you'd better set tpwc max distance appropriately ( tpwcas_maxdist = 1200 ) just in tpwcas.sqf.

Edited by fabrizio_T

Share this post


Link to post
Share on other sites

Great, thanks Fabrizo.

TPW - I wonder if there should be a tpwcas_maxlifespan variable that can be set in the hpp too, to override the bdetect_bullet_max_lifespan? (as presumably if you alter the distance you have to alter the time too to get the full effect.)

JJ

Share this post


Link to post
Share on other sites
Great, thanks Fabrizo.

TPW - I wonder if there should be a tpwcas_maxlifespan variable that can be set in the hpp too, to override the bdetect_bullet_max_lifespan? (as presumably if you alter the distance you have to alter the time too to get the full effect.)

JJ

Good point, thanks.

Share this post


Link to post
Share on other sites
Great, thanks Fabrizo.

TPW - I wonder if there should be a tpwcas_maxlifespan variable that can be set in the hpp too, to override the bdetect_bullet_max_lifespan? (as presumably if you alter the distance you have to alter the time too to get the full effect.)

JJ

Thanks for the input jj. Both these variables will now adjustable within tpwcas.

Share this post


Link to post
Share on other sites

Just had a quick blast at lunch ( I work near home :) ) and I noticed the following in the rpt (I am paraphrasing but I will correct it when I get home tonight). Using script version of 206B:

error in tpwcas_decskill.sqf _unit setskill ["courage",_newcourage] type any, expected number

repeated a considerable number of times. I remember courage specfically, but I think there were some errors logged for the other variables in decskill too. I was running with debug off.

JJ

Edited by jiltedjock

Share this post


Link to post
Share on other sites
Just had a quick blast at lunch ( I work near home :) ) and I noticed the following in the rpt (I am paraphrasing but I will correct it when I get home tonight). Using script version of 206B:

error in tpwcas_decskill.sqf _unit setskill ["courage",_newcourage] type any, expected number

repeated a considerable number of times. I remember courage specfically, but I think there were some errors logged for the other variables in decskill too. I was running with debug off.

JJ

Thanks jiltedjock, we're aware of the issue, it is fixed into next build.

Share this post


Link to post
Share on other sites
I don't think findCover will be fixed.

Suma already gave some hints about the matter (and setHideBehind) long time ago, you can read some info in this 3yrs old :( ticket by Solus: https://dev-heaven.net/issues/2016.

However there's no need for reimplementing findCover in my opinion.

Some basic findCover-esque routine may be easily scripted with a few lines of code ( see note by Kju with my code at the bottom of same ticket for a very raw example, or just the repro in ticket : https://dev-heaven.net/issues/28311 ).

The problem is that unless we get some forceMove command (hint: https://dev-heaven.net/issues/28319) overriding core AI takes, we won't be able to get any decently reliable functions for AI moving into cover and AI fleeing / withdrawal.

Obviously my subjective 2 cents.

Thanks for sharing this info. I still think a native findCover would useful for performance reasons. Can you please explain this bit of code:

_objects = (nearestObjects [(position _unit),[],_dist ]) - ((position _unit) nearObjects _dist) - ((position _unit) nearRoads _dist);

I get why you take the road segments out, but what it the bold part for ?

I'll try to use your function as a starting point, if you don't mind, even if it's not working 100% if it at least gives the AI a nudge towards cover, without causing too much processing power drain, then I'm happy with it. I'm going to play with this idea, I've always stayed away from it because I know SLX and Zeus implemented it this way and I wasn't quite happy with the result.

Thanks.

Edited by Robalo

Share this post


Link to post
Share on other sites
Thanks for sharing this info. I still think a native findCover would useful for performance reasons. Can you please explain this bit of code:

_objects = (nearestObjects [(position _unit),[],_dist ]) - ((position _unit) nearObjects _dist) - ((position _unit) nearRoads _dist);

I get why you take the road segments out, but what it the bold part for ?

I'll try to use your function as a starting point, if you don't mind, even if it's not working 100% if it at least gives the AI a nudge towards cover, without causing too much processing power drain, then I'm happy with it. I'm going to play with this idea, I've always stayed away from it because I know SLX and Zeus implemented it this way and I wasn't quite happy with the result.

Thanks.

Hi Robalo,

if i recall correctly (i wrote it quite some time ago) that piece of code was added to filter out all editor placed objects, since i wanted to intercept only island stuff (vegetation, rocks, ...).

It's basically a trick playing on differences of nearestObjects vs. nearObjects output.

Obviously that may removed for more general usage and buildings may be added as well.

Everybody should feel free to use and possibly improve that code, as is it's just a proof of concept.

NOTE: I agree with you on writing code not causing much overhead for minor ( and possibly unreliable ) stuff ;).

As long as you apply a small radius and you don't have hundreds of units running it at the same time, the code should have negligible overhead.

Edited by fabrizio_T

Share this post


Link to post
Share on other sites
Unit marker is a triangle by default. It changes to a circle whenever the unit is fleeing.

Very interesting you noticed some allies having red triangles, as long as you play WEST.

It may mean they are renegades: that happens when, due to low accuracy, friendly units accidentally fire blue-on-blue, becoming "enemy" to own side.

That's quite common for machinegunners.

Let's see if anybody else is having this kind of issue. In that case, i know how to solve the problem.

---------- Post added at 22:20 ---------- Previous post was at 21:32 ----------

Can you tell how many units were on the field? How long did you play before the problem?

The error message looks unrelated to TPWC AI though, more PC config / vanilla ArmA2 related (see: http://forums.bistudio.com/showthread.php?129586-How-much-swapfile-does-this-game-need).

Unit marker is a triangle by default. It changes to a circle whenever the unit is fleeing.

Very interesting you noticed some allies having red triangles, as long as you play WEST.

It may mean they are renegades: that happens when, due to low accuracy, friendly units accidentally fire blue-on-blue, becoming "enemy" to own side.

That's quite common for machinegunners.

Let's see if anybody else is having this kind of issue. In that case, i know how to solve the problem.

---------- Post added at 22:20 ---------- Previous post was at 21:32 ----------

Can you tell how many units were on the field? How long did you play before the problem?

The error message looks unrelated to TPWC AI though, more PC config / vanilla ArmA2 related (see: http://forums.bistudio.com/showthread.php?129586-How-much-swapfile-does-this-game-need).

Thanks, Fabrizio_t & tpw, for explaining the markers - sorry, must have missed that information. How intriguing about the 'renegades', I'll try to set up a test for that sometime soon.

Graunching problems gone - though it needed a new HD :(

Bad blocks in the swapfile partition, kept re-appearing after chdsk &/or WD Lifetools. Never mind, I was thinking of adding another drive anyway. & expect a replacement under warranty (whenever).

No more graunching, & no more apparent conflicts with COSLX when using text debugs.

Re the civ count increase that tadanobu reported: it happens whether or not SLX is not running, and only with ball-debug on. Seems to be related to the number of units, not the number of kills; certainly not counting dead units as civs, recycle bin values between 20 & 200 in Flashpoint 1.20.1 make no significant difference.

Share this post


Link to post
Share on other sites

Orcinus - if you have extra RAM or capacity to put more in, consider using a Ram disk for the swap file - http://memory.dataram.com/products-and-services/software/ramdisk/ - the free one supports a disk up to 4GB in size.

I've got 16GB in my workstation - 4GB is a Ramdisk with the swap file on it, and 7GB is set aside for read only caching of the hard disks - http://www.romexsoftware.com/en-us/fancy-cache/download.html

Although I am using Win 7 64Bit, all of my apps are 32 bit so the RAM above 4GB is basically spare

Edited by jiltedjock

Share this post


Link to post
Share on other sites

Can someone running this with ASR_AI please confirm it's working? I've been trying every update and none of them work - green bulbs stay green and the units are unresponsive.

Share this post


Link to post
Share on other sites

Im using the supression scripts + ASR AI 1.15.1 on our dedi warfare server with no problems.

Though I did tweak the the scripts a little, aswell as the ASR AI.

The ASR AI runs server side and the supression scripts have been put in the mission pbo

ASR AI:

join_loners = 0

join_loners_sameFaction = 0

split_legged = 0

TPWC AI SUPPRESSION:

tpwcas_debug = 0

tpwcas_textdebug = 0

Edited by kaysio1

Share this post


Link to post
Share on other sites

Fabrizio_T and I made some changes and (hopefully) improvements to the Dedicated Server code.

Though it's limited tested decided to make it available here to get some feedback, especially about performance.

So warning: it works quite well for me but that is no guarantee it will work for you.

Use at own risk, though risk is really minimal in our opinion, and the result is great :) ...

Please let us know if it works for you or doesn't.

In the feedback here please mention:

- Linux or Windows dedicated server

- ASR_AI usage

TPWCAS_MP_betav073

Edited by Ollem

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×