ollem

I believe we could still use the debug balls, but in stead of creating by default, attaching and then hiding/change color we should just create and delete them when applicable. Yes, there is overhead in creating and deleting, but it's a debug feature anyway.. For debug purposes I've added a simple 'bullet radar' feature to 'tpwcas_fnc_localbullets' which creates dot markers on the map for every detected bullet, and deletes them after 10 seconds. (NOTE: this only works when 'tpwcas_fnc_localbullets' is spawned in stead of called, while 'sleep' doesn't work in 'call') I will try to see if same approach could perhaps be used to create colored debug balls in game

Some Dedicated Server findings: Changed parameters: tpwcas_st = 5; (//SHOT THRESHOLD. MORE SHOTS THAN THIS WILL CAUSE UNIT TO DROP/CRAWL) bdetect_debug_enable = true; bdetect_debug_levels = [0,2,5,6,7,8,9]; bdetect_bullet_max_distance = 800; bdetect_bullet_max_lifespan = 1.1; - Bullet detection framework does work - though in the short test 'bullet discovery' log shows 80 Fired (MG) bullets of which 13 bullets reported 'close to targets'. This number seems a bit low too me, but I may also be a bad shooter. Needs further investigation. - tpwc_ai_suppress202 part doesn't deem to work as-is. Debug balls are not shown at al, hence hard to tell what's working. Some additional logging showed: 1 entry (only) with status tpwcas_supstate=3 => only 1 full suppresion by long MG burst! 5 entries with status tpwcas_supstate=2 7 entries with status tpwcas_supstate=1 This is not to be expected while the enemies I shot at were quite close to each other. I did see AI reacting to the shooting, but they did not drop/crouch as being seen with SP. I shall take closer look with additional debugging and some more parameter changes to see what's realy going on and if things can be improved for Dedicated.

The pace at which you and F release new version makes it very hard for me too keep up with testing :-) Minor bug at line 290: tpwcas_filter = should be tpwcas_fnc_filter =

@Fabrizio_T, in the 'time-sensitive-per-frame' bdetect_fnc_detect function you trigger the callback function using 'call'. I.e. [_x, _bpos, _x distance _bpos, _data] call bdetect_callback_compiled; Shouldn't the usage of 'spawn' be preferably in this case? As far as I know (which is not a lot..) call is waiting for a return (== delay) and spawn is like fire-and-forget and running in parallel. The whole stance-skill thing doesn't need to report back to your bullet framework.

Did some extensive debugging (thanks for the additional logging): it appeared to be a timeout issue after all. It does work if I increase timeout So we may need to consider to make time-out a relative value related to distance. Standard STANAG bullet fired by an M4 was only able to fly around 330m in 0.5 seconds..

The issue isn't new - so it should not be related to code changes in v2 - June 27th there wasn't reveal around.. http://forums.bistudio.com/showthread.php?136304-TPWC-AI-suppression-system&p=2179540&viewfull=1#post2179540

Grazie! Will give it a closer look tomorrow (will test SP too)

No, I've not yet tried to execute within isServer block - unfortunatley not behind my gamesystem now Local server is quite close to SP - e.g. 'player' variable is showing my username - unlike at dedicated server. As additional debug I added some bullet markers: _bulletMarker 'createMakerLocal [str(time), getPosASL _bullet]; _bulletMarker setMarkerShapeLocal "ICON"; _bulletMarker setMarkerTypeLocal "dot"; ( placed right after the code line "[_x, _bullet, _x distance _bullet, _data] call bdetect_callback_compiled;" ) To my surprise the dots allways appear quite close the shooter - I would have expected them to appear close the target unit.. ------ update ----- How/when is the position of a bullet determined? A bullet is flying and on a fast system might be detected more then once. If system is fast (mine is above average) the detection could be in early stage already...?

Tried again but still same issue occurs in "bdetect_fnc_detect" function To debug, I've added at line 286, right between _units = _bullet nearObjects ["MAN", bdetect_bullet_max_proximity]; and { if( !(_x in _blacklist) ) then { if( alive _x && vehicle _x == _x && lifestate _x == "ALIVE") then the following debug logging: if ( (count _units) > 0 ) then { hint format ["DIST: %1",(_units select 0) distance player]; diag_log format ["%1 - DIST: %2 - UNITS: %3", diag_ticktime, (_units select 0) distance player, _units]; }; If I then engage an enemy squad with a short MG burst at around 370 m distance, I get the following result: The (filtered) log shows entries like: "32607.3 - DIST: 353.572 - UNITS: [O 1-1-B:5,O 1-1-B:4]" "32608.8 - DIST: 0 - UNITS: [b 1-1-A:1 (ollem)]" "32611.2 - DIST: 0 - UNITS: [b 1-1-A:1 (ollem)]" "32612.9 - DIST: 0 - UNITS: [b 1-1-A:1 (ollem)]" "32613.1 - DIST: 0 - UNITS: [b 1-1-A:1 (ollem)]" "32613.4 - DIST: 361.813 - UNITS: [O 1-1-B:4,O 1-1-B:5]" "32613.6 - DIST: 357.14 - UNITS: [O 1-1-B:5]" So above a certain distance, _units = _bullet nearObjects ["MAN", bdetect_bullet_max_proximity] suddenly only finds the shooter in stead of units near the bullet ???? (NOTE: this is while testing on MP - Locally hosted server with no other clients connected)

Did some more testing (with bdetect.sqf v0.5) and encountered a very weird issue I can't explain yet: if shooter > +/- 400 m (+/- 385 to be precise) away from _unit being shot, it's not the _unit who is put in the _data array but the _shooter.. ??? changed some settings: bdetect_bullet_max_distance = 800 up to 1200, and changed live_time from 0.5 to 0.7 but it's still the same.. Is it just for me? Increase bullet_max_distance and add the following debug line to 'bdetect_fnc_detect' function: .......................... else { _units = _bullet nearObjects ["MAN", bdetect_min_distance]; diag_log format ["%1 - UNITS : %2", diag_ticktime, _units]; { if( alive _x && vehicle _x == _x && lifestate _x == "ALIVE") then .......................... ===== update ========= With v0.6 code still the same behaviour - though now no units at all at larger dist Distance at which the issue occurs has decreased though..

addCamShake does not work for me either - but I'm pretty sure we would need some local client code for that to work. Suppress works - at least somehow - during my 1 minute test on dedicated

:459: Awesome progress made over the weekend Some minor remarks: TPWCAS 2.00 line 186: ( player == _unit ) ==> (isPlayer _unit) bdetect: usage of 'time' ==> isn't diag_ticktime a more reliable time parameter, especially on low FPS servers?

some other thought: in current aproach the _unit stance is determined by setpos "middle" or "down". Did anyone try with 'reveal' (in combination with a specific accuray? http://community.bistudio.com/wiki/reveal The main issue with Vanilla behaviour seems to be that if the shooting starts the _unit is still unaware about the shooter and does not react on just bullets. Reveal the shooter to the _unit should (hopefully) trigger some reaction. Accuracy adjustment etc would still be needed to get the suppression feeling (not able to test myself now - hopefully later today again) Accuracy for infantry settings: [ 0 , 1.5 ] - side unknown, some position offset, identified as SoldierWB [ 1.5, 1.6 ] - side identified, subjective cost set [ 1.6, 2 ] - type identified better (USMC_Soldier_Base) [ 2 , 3.6 ] - type identified precisely (USMC_Soldier) [ 3.6, 4 ] - position identified precisely So if this approach could work a (random?) setting of around 1.5/1.7 seems to be the best starting point.

Amazing: real follow-the-sun development marathon going on here :cool:

Great! Slightly off-topic but quite useful for the code writers out here: updated notepad++ syntax high lighting http://forums.bistudio.com/showthread.php?91939-Notepad-SQF-syntax-highlight&p=2181113&viewfull=1#post2181113

Slightly off-topic but quite useful for the code writers out here: updated notepad++ syntax high lighting http://forums.bistudio.com/showthread.php?91939-Notepad-SQF-syntax-highlight&p=2181113&viewfull=1#post2181113 (hmm sorry for cross-post - was supposed to be in other thread but won't harm here either)

It's possible to define additional variable in the Fired EH (which could be used in nested arrays of the bullets). E.g.: _unit addeventhandler ["fired",{tpwc_ai_sup_fired = _this select 0;tpwc_ai_sup_mag = _this select 5; tpwc_ai_sup_bullet = _this select 6;tpwc_bullet_side = side (_this select 0);}]; In same way more logic (including if - then ) can be added to the EH

Great! It did annoy me very much the /* */ syntax highlighting didn't work in the original version. This morning finally decided to fix that, only to see that you recently fixed it as well but even went beyond just fixing that! :bounce3:

Gave it a quick try, but injured units were still showing debug balls.. not sure about unconcious.. Current code has only 2 options on Dedicated: no balls and red balls => I will look into this I tested with detection radius of 20 meters and shot threshold of 3 bullets, and the results were hopeful: again still not as responsive as SP, but for sure much more natural effect compared to no TWPC-Suppress :cool: Needs some fine tuning for best settings. CVhxZRBlLl0 Also for Dedicated server I might add 'player only' option to only enable the 'fired' eventhandler for players - I usually play coop versus AI - so then there's no need for AI Eventhandlers. On Dedicated I did not notice the 'player shake' anyway, though I'm running latests beta.

fabrizio_T, Thanks for your feedback. Unfortunately no time to look at it. Here a short comparison video: No TPWC - Dedicated Server TPWC - SP TPWC You will clearly see the diff...

One of the issues with Dedicated server is (at least for me) that it's very hard to get more the 3 shots counted, so tpwc_ai_sup_st needs to be lowered. At least that does clarify why only 'yellow' and no 'red'. Still behaviour is not as responsive as SP, so might not work that well on MP afterall :-/ Will have al closer look at it For now, this works more or less on Dedicated server:

Still struggling with dedicated... 2 steps forward 1 step back... Added some MP specifics, and I moved some code around again - should have a minimal perf bonus: use 'switch' in stead of "if x > 0" -> " if x > 1" -> "if x == 3", e.g. at 3 some settings are overruling just set settings in >1 Balloons will appear and disappear now (but only none, green and yellow ???) Still, the behavior in SP/local Server is much better then on Dedicated :mad: Will post some updated code later again

I made some progress with Dedi Server compatibility, but still not 100% (vid above is not based on updated code) With code below some baloons turn red on and off - but should be more, and AI is much less responsive compared to SP/locally hosted MP: there they drop like flies when shooting starts.

Did some more MP testing with Dedicated Server: unfortunately the debug markers stay red all the time, and suppressing doesn't seem to be equal to SP. But that needs some more verification. Colorcoding => "hideObject": Multiplayer: Command has local effect, needs to be run on each client -> so would need CBA function to work properly in MP In the mean time some more footage with 'right' color coding ;-) (Shooter (me) is in AI invisible cheat mode - hence no reaction to shoot me..)

No problem to front page the footage (though it could use some proper editing) I've missed the 'friendly fire' bit in your latest code - your debug color coding makes sense too.