Jump to content
Sign in to follow this  
tpw

TPWC AI suppression system

Recommended Posts

Hi LondonLad. According to our MP guru Ollem, in an earlier post, you need it running on both server and client. I'm pretty sure nothing has changed since the last time he announced that. If he can 100% confirm then I will update the 1st post accordingly.

I'm not sure that's accurate. So you're saying if you have like 10 people on the server they have to run the AI mod, even though the clients have no control over the AI? Doesn't really make sense.

Share this post


Link to post
Share on other sites
I'm not sure that's accurate. So you're saying if you have like 10 people on the server they have to run the AI mod, even though the clients have no control over the AI? Doesn't really make sense.

If you want the player suppression effects you would though for sure :)

Share this post


Link to post
Share on other sites

I run the script version in my mission, so everyone gets it (ie it isnt the addon version). This way everyone gets it (all AI, and player suppression)

Share this post


Link to post
Share on other sites

Just installed this great mod - I installed as a mod (to be used automatically on all missions).

1. Just to clarify, this mod effects/affects both BluFor AI and OPFOR AI, correct? Is there anyway to make it less effective with your Blufor AI teammates? Meaning your AI teammates won't become surpressed as easily / quickly.

Share this post


Link to post
Share on other sites
I run ASR_AI, tpwcas and LOS, and DAPMAN first aid with 400 AI ... seems to work fine for me on a dedi server. I think SLX would prolly cause the thing to melt.

I usually run with asr_ai, TPWC AIS, TPW LOS & various COSLX files with no problems - though I have been trying it with up to 500 AI on Chernarus using HAC & DAC; that hits the FPS at times, however. Probably partly due to the graphics tweaks I've been trying out to ameliorate the awful LOD switching in CO v1.62....

Share this post


Link to post
Share on other sites
If you want the player suppression effects you would though for sure :)

Ah, true. I was thinking primarily of the AI improvements.

Share this post


Link to post
Share on other sites

Orcinus, I believe you're running SP right?

LL and I are interested from a large coop MP perspective (60+ in LondonLad's case). We also run ACE/ACRE and a variety of other scripts such as UPSMON. My concern is we're overloading the scheduler and adding yet another AI event related script might cause severe lag. I guess the only way it to test - but that's tough when we're also trying to offer a good game to a large community of impatient players!

Share this post


Link to post
Share on other sites
Orcinus, I believe you're running SP right?

LL and I are interested from a large coop MP perspective (60+ in LondonLad's case). We also run ACE/ACRE and a variety of other scripts such as UPSMON. My concern is we're overloading the scheduler and adding yet another AI event related script might cause severe lag. I guess the only way it to test - but that's tough when we're also trying to offer a good game to a large community of impatient players!

I might suggest - for lag-sensitive situations - the use of a framerate monitor to maybe ramp down the addon to a more random, spaced-out level. So in times of FPS stress, the addon relaxes it's workload. Would mean less suppression, but not no suppression. Got to be better than not using it for lag, right? :)

If the addon has a FPS hit natch. If not - all's good.

Share this post


Link to post
Share on other sites
I'm not sure that's accurate. So you're saying if you have like 10 people on the server they have to run the AI mod, even though the clients have no control over the AI? Doesn't really make sense.

Just to clarify, the addon is expected to be running on both clients and server.

That because the underlying bDetect framework take cares of units which are local to the actual peer (client or server), while event handlers are broadcasted throughout the network.

By having the addon running only onto the server you lose the suppression effect on units which are local to any client, for example AI units in a player led team.

---------- Post added at 19:09 ---------- Previous post was at 19:02 ----------

Orcinus, I believe you're running SP right?

LL and I are interested from a large coop MP perspective (60+ in LondonLad's case). We also run ACE/ACRE and a variety of other scripts such as UPSMON. My concern is we're overloading the scheduler and adding yet another AI event related script might cause severe lag. I guess the only way it to test - but that's tough when we're also trying to offer a good game to a large community of impatient players!

Severe lag should not happen.

bDetect is instructed to keep its own clocking/overhead under control, by progressively cutting features below a minimum FPS threshold ( = bdetect_fps_min global variable, default 20 fps).

So it already keeps an eye on your FPS.

Once FPS stabilize after a drop bDetect automatically restores its original clocking.

So the worst thing you can experiment is a drop in suppression effects accuracy, not a meltdown.

I might suggest - for lag-sensitive situations - the use of a framerate monitor to maybe ramp down the addon to a more random, spaced-out level. So in times of FPS stress, the addon relaxes it's workload. Would mean less suppression, but not no suppression. Got to be better than not using it for lag, right?

It works already exactly this way ;)

Edited by fabrizio_T

Share this post


Link to post
Share on other sites
Hi LondonLad. According to our MP guru Ollem, in an earlier post, you need it running on both server and client. I'm pretty sure nothing has changed since the last time he announced that. If he can 100% confirm then I will update the 1st post accordingly.

The tpwcas is based on 2 monitoring functions:

1 - monitoring bullets fired (by both AI and players) (shooter side focus)

2 - monitoring if bullets are close enough to trigger suppression (both AI and players) (target side focus)

In case the mod is only running on the server, all shots are monitored, but only AI local to the server will be able to react to suppression.

This should be the majority of the AI.

However, in case there would AI part of a players group, they would be local to the players system, and hence not react to suppression.

Also player suppression will not work, i.E camshake will not kick in.

I'm considering to create a dedicated server tpwcas-lite version (or config option) which will only monitor player shots, to (only) allow suppression of server side AI.

This version would be specifically be for dedicated servers for coop players vs AI.

So no player camshake, and no AI versus AI suppression, but I think there are quite a few coop players around who are less interested in that, and prefer player triggered AI suppression in combination with slightly less server load then full blown tpwcas.

Just like ASR_AI, this would need to be a dedicated server side only version.

Share this post


Link to post
Share on other sites
Just to clarify, the addon is expected to be running on both clients and server.

That because the underlying bDetect framework take cares of units which are local to the actual peer (client or server), while event handlers are broadcasted throughout the network.

By having the addon running only onto the server you lose the suppression effect on units which are local to any client, for example AI units in a player led team.

Thanks for the clarification. That makes sense. I was thinking of the server-side AI which is why I got confused. So I guess if you only run it on the server, only the opposing/non-squad AI gets suppressed? Seems kinda unfair for them, huh? :p

I'm considering to create a dedicated server tpwcas-lite version (or config option) which will only monitor player shots, to (only) allow suppression of server side AI.

This version would be specifically be for dedicated servers for coop players vs AI.

So no player camshake, and no AI versus AI suppression, but I think there are quite a few coop players around who are less interested in that, and prefer player triggered AI suppression in combination with slightly less server load then full blown tpwcas.

Just like ASR_AI, this would need to be a dedicated server side only version.

That would actually be really nice, as 99.99% of the time I play co-op vs AI.

Share this post


Link to post
Share on other sites

Does this mod enable the supression of Static and vehicle Weapons? As far as I know those weapons can't be supressed in vanilla. It would be nice if you could introduce some supression effects for them. Like higher dispersion or slower rate of fire

Share this post


Link to post
Share on other sites

That's extremely helpful with the responses there gents - Thank you :)

As with MaverickK96 - I'd be interested in any possible development in a 'lite' version for Servers only (as our group are for the most part utilse 'Coop vs Computer AI)

Share this post


Link to post
Share on other sites

Just put it on as the script version mate.... that's what I do and it works well for coop vs AI.

Share this post


Link to post
Share on other sites
Does this mod enable the supression of Static and vehicle Weapons? As far as I know those weapons can't be supressed in vanilla. It would be nice if you could introduce some supression effects for them. Like higher dispersion or slower rate of fire

It's technically feasible, but such a feature should be carefully thought, that's the reason it's not implemented at the moment.

In that case type/caliber of bullets should be taken in account, as well as approximated degree of "protection" offered by a static weapon.

Reason for that is we don't want to make tanks being suppressed by small arms fire, nor a machinegun nest being suppressed by some sporadic fire.

I don't know whether such a feature would be worth the computational overhead, though.

Edited by fabrizio_T

Share this post


Link to post
Share on other sites
Just put it on as the script version mate.... that's what I do and it works well for coop vs AI.

He's probably thinking more along the lines of just being able to plop it on the server and not have to worry about clients needing mods and/or adding scripts to existing mission... in which case I would agree :)

Share this post


Link to post
Share on other sites

We're looking at using the suppression system in some of the missions included in the v2.62 release of I44, and with the talk of static weapon suppression I thought I'd weigh in, as we've got a lot of static MG's and open type weapons, but understand the issue of vehicles being suppressed (wouldn't make much sense for a Tiger to get suppressed by a Garand going full auto etc) I had a few ideas that would be relevant in our situation at least:

-A customisable array for static weapons (and possibly vehicles) that mission makers or addon makes could easily add unit class names too (similar to DAC's allowed list of vehicles for AI to man) that could be suppressed, possibly requiring a slightly higher value to be affected, once suppressed the AI could disembark and go prone seeking cover. Following on from this you could also have several types of definition e.g. Static Open (placed static MG), Static Cover (placed static weapon with cover e.g. sandbags or bunker), Open Vehicles, Closed Vehicles.

-The last two options above are obviously for vehicles, open ones such as a car or truck where crews can be targetted and affected by fire when suppressed could either speed up or move to disembark and take cover. While closed or armoured vehicles crews could turn in if under fire if already turned out, so for example an exposed tank commander directing the tank could be suppressed to turning in (which in our case would prevent them using the MG's on top of the vehicle that due to the old school tech, could not be fired from inside, and also limiting view/effectiveness of the vehicle with the commaners limited view).

As these options would be very specific to missions and mods I would suggest making them open optionable variables rather than hardcoded with small arms and infantry just to provide further options rather than base functionality to the mod. Anyway just loving the system as it is, with I44 especially it has produced some really exciting gameplay and adds something that really was missing from the game, great work guys and thanks for the tremendous work from all those involved in developing and supporting this great addition to ArmA2!

Share this post


Link to post
Share on other sites
We're looking at using the suppression system in some of the missions included in the v2.62 release of I44, and with the talk of static weapon suppression I thought I'd weigh in, as we've got a lot of static MG's and open type weapons, but understand the issue of vehicles being suppressed (wouldn't make much sense for a Tiger to get suppressed by a Garand going full auto etc) I had a few ideas that would be relevant in our situation at least:

-A customisable array for static weapons (and possibly vehicles) that mission makers or addon makes could easily add unit class names too (similar to DAC's allowed list of vehicles for AI to man) that could be suppressed, possibly requiring a slightly higher value to be affected, once suppressed the AI could disembark and go prone seeking cover. Following on from this you could also have several types of definition e.g. Static Open (placed static MG), Static Cover (placed static weapon with cover e.g. sandbags or bunker), Open Vehicles, Closed Vehicles.

-The last two options above are obviously for vehicles, open ones such as a car or truck where crews can be targetted and affected by fire when suppressed could either speed up or move to disembark and take cover. While closed or armoured vehicles crews could turn in if under fire if already turned out, so for example an exposed tank commander directing the tank could be suppressed to turning in (which in our case would prevent them using the MG's on top of the vehicle that due to the old school tech, could not be fired from inside, and also limiting view/effectiveness of the vehicle with the commaners limited view).

As these options would be very specific to missions and mods I would suggest making them open optionable variables rather than hardcoded with small arms and infantry just to provide further options rather than base functionality to the mod. Anyway just loving the system as it is, with I44 especially it has produced some really exciting gameplay and adds something that really was missing from the game, great work guys and thanks for the tremendous work from all those involved in developing and supporting this great addition to ArmA2!

On bDetect side it would be possible to trigger suppression on "vehicles" (included static weapons) based on a configurable array of CfgVehicles classes: http://community.bistudio.com/wiki/ArmA_2:_CfgVehicles#Static_Class_Vehicles

Hypotehical example:

bdetect_units_kindof = ["Man","StaticWeapon","Car","Tank","Air"];

Then on TPW AI side the suppression effect may be handled in many ways depending on bullet type and target (soft or hard), but that's a bit off my competence.

Edited by fabrizio_T

Share this post


Link to post
Share on other sites

Currently any type of weapon fired will cause suppression - but only AI not mounted in vehicles is being suppressed.

It's technically possible to add an "else" section in "tpwcas_mainloop" in case unit is mounted in a vehcile.

Turning in turned out crew is relatively simple to add.

Disembarking vehicles is also not an issue, however, determining for which verhicles this should be done an for which not is not that straightfoward.

Let's take the Humvee as example:

In case of unarmed Humvee, in most cases the crew is better of staying in the vehicle.

In case of the open .50, the gunner might be better of disembarking, however there are also some light-armored .50 Humvee's and even Humvee's with the CROWS .50 in which case the gunner is relatively safely operating the weapon while being inside the vehicle.

So this would mean a full list of vehciles for which disembarking of (at least the gunner) is expected would be needed, which is certainly not a straightforward exercise.

Also once disembarked, I'm not sure if the gunner will embark automatically again.

It may result in very strange AI behaviour and even become to easy...

Maybe some random function to sometimes result in disembarking could be a potential solution.

To be continued..

Share this post


Link to post
Share on other sites

I´m against disembarking, some kind of supression effect should be enough.

Share this post


Link to post
Share on other sites

Regarding TPW_AI_LOS; does it take into account the time of day and the weather conditions ? Just tested a scenario during day and night time and there wasn't much difference if any to the AI's capabilities.

They weren't equipped with NVGs and they were just as fast and accurate during the night time as they were during the day.

BTW These two mods are totally indispensable. Thanks for the hard work

Share this post


Link to post
Share on other sites

Thanks verde13. TPWLOS takes into account time of day. There's a visibility calculation which includes the angle of the sun. It doesn't take weather into account though.

Regarding TPW_AI_LOS; does it take into account the time of day and the weather conditions ? Just tested a scenario during day and night time and there wasn't much difference if any to the AI's capabilities.

They weren't equipped with NVGs and they were just as fast and accurate during the night time as they were during the day.

BTW These two mods are totally indispensable. Thanks for the hard work

Share this post


Link to post
Share on other sites
Thanks verde13. TPWLOS takes into account time of day. There's a visibility calculation which includes the angle of the sun. It doesn't take weather into account though.

The game engine already takes fog into account (even changing fog) so if TPW suppression works off the back of the game settings then it should follow.

Share this post


Link to post
Share on other sites
Thanks verde13. TPWLOS takes into account time of day. There's a visibility calculation which includes the angle of the sun. It doesn't take weather into account though.

Unfortunately nobody noticed up to now, but a small bug has slipped into the code resulting in no time of day diff :-/

Function defined is:

 tpwlos_fnc_sunagle 

Function called:

 [] spawn tpwlos_fnc_sunangle; 

The missing 'n' will be fixed in next release

Share this post


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

×