Jan-H

Already for a long time I have an annoying issue, already before patch 1.03. Perhaps one of you can relate to it and point me to a solution? Phenomenon: Sometime the player vehicle (player not necassarily driver) or even a fully AI crewed vehicle will get stuck and stop moving. The engine is off and can't be turned on except for a blink of an eye. Seems link to CarX or Car type wheeled vehicles. It does not matter where, even on a clear road. - Fuel is 1, damage=0, getAllHitPointsDamage (particularly "HitEngine") shows all intact, vehicle getposATL is above ground. - "vehicle EnginOn true" will turn on the engine for a fraction of a second, and return to off the next frame. - I can see a greyed-out engine symbol below WHL in the Vehicle info tab of the GUI blink a couple times very quickly in white before going grey again when giving the AI driver scripted domove/moveto orders though. - Any Move-type order won't do. Currentcommand is "MOVE", unitready is false and stays. Dostop or alike and reissuing move orders won't do the trick. - Simulation of the vehicle and crew is on. Disableing simulation and reenabling it wont help. - All AI or player crew have "enableAI"ed all their states. disabling them and reenabling "all" or single ones like "path" or "move" won't help. - Disembarking driver, effectivecommander or all crew and reembarking won't help. - Embarking player as driver only won't help. I can run around the car, but once I get on the driver seat, the engine seems drowned. - setting fuel to 0 and back up won't help - setting hitpoints to damage 1 or back to 0 won't help - limitspeed, forcespeed, addVehicle to group, disjoin from group... same - I use ACE, RHS and lot of other own scripts, so I monitored scripts (sqf, fsm) and successively killed them or skipped those addons. No success either. The new ACE speedlimiter or or engine start funcs can't be either, not only because I saw the sources and no reason that could cause trouble, but because this problem existed before the latest ACE versions. - One thing that makes me suspect it has nothing to do with scripting is: I can SAVE and LOAD the mission in the editor when this problem occurs, and upon reloading the problem is gone! All scripts, vars etc. are being stored as well as I am to understand, so the same stats and funcs/scripts will be running after the reload again whereas the problem is gone. I use a loop or perframe handler to catch this: _v Engineon true; sleep 0.01; if (! IsengineOn _v) then { here we go...} I have tried a myriad of tricks to fix this, but they cost performance and it is really annoying. The best fixes seem to createvehicle a copy, delete the original, assign its orignal ID (vehicleVarName) to the copy, and transfer the crew and all stored setvariables over. Or to save and reload, unfortunately. Has anyone of you had a similar issue? Any ideas? Thanks!

Anyone else noticing: (a) ARMA3.log spamming with "...bla sees blub..." entries (b) 10-20% loss of performance in large, vehicle rich scenarios even with -nologs (due to the first)? Since I have been working for more than 4 years on single scenario on the Fallujah map (sort of Blackhawk down, but with AI smartly ordering CGs and adjusting to the situation), I have a good feeling for the FPS (and its scatter range) in that scenario. I have been fighting with pathfinding of AI in the "hotel" type buildings, and spent uncounted hours in trying to get AI groups of vehicles to propperly navigate the twin roads and lately been converting scheduled grp-based scripts to single-statehandlers (treating all groups in one thread) to reduce scripting overhead. Prior to the patch, I got 18-22 FPS in situations that now result on 12-16 FPS. In the past week, nothing changed in my scripts, but...? PS. Dear devs: You are probably moving on to the new Engine now, but if you still intend to extend ARMA3s lifetime, here a few suggestions for new funcs for the patches...: - pathfinding function for buildings: "fnc_findshortestpath [[room/entry pt start], [room/entry point end]]" => result [array of coordinates or room nodes to be crossed] (a engine-based solution faster than a scripted Dykstra ...). Moreover, pathfing in hotel or other larger structures is often poor, AI only manages if you give it step by step only adjacend "rooms" until arrived. Would be good to get this more robust. -> Some improvements to vehicle handling and scripted control: - fnc_bboxes_will_collide [[entity or config A, presumed position of A, presumed orientation of A], [entity or config B, presumed position of B, presumed orientation of B]] ==> true/false (again, faster engine based solution would be nice) - fnc_follow_group [[lead group], [following group(s)], distance, direction] => Linking two or more groups to a lead group with offset (avoid having to join all units...). And corresponding command to unlink. ->Some funcs to influence driving behavior more directly. I see them often veering off the road on the Fallujah map, no matter what combatmode, behaviour, forcefollowroad, engagament status, etc. Oftentimes they crash into each other in column, overtake wildely and chaos ensues. When they crash at odd angles, they sometimes fling across the map or dive below ATL=0. Anything to improve driving or help scriptes to affect AI driving would be welcome. Any of that would be most appreciated...

Dear developers, I must say ARMA3 is a huge leap from ARMA2 and very enjoyable, were it not for one mood issue: AI driving. Groups with only one vehicle move fine on the various maps. However, convoy driving with two vehicles staying together, not to mention convoy of 4 or more cars/trucks etc. is really poor. That was certainly much better in ARMA2. Since it is quite obvious that ARMA3 remain be the key BIS sim in this line for a few years with addons still coming out regularly, is there any chance to get this topic revisited? Particularly the AI vehicles bumping often into static objects, other vehs is quite annoying. Better preplanning would be nice, and more steady formation keeping/driving. Also, eliminating those events where a crash between (PhysX?) objects at specific angles will lead to vehicles being flung around weiredly, or pushed below ground/launched skywards would help much to mitigate poor driving.

Neat script, and good idea using the invisible dummy to get the dragger "seemingly" moving. I'd like to get the AI to move in the dragging stances itself, but... After Christmas I finally decided to move from ARMA2 to ARMA3 and I felt some functionality missing, and not yet officially ported to A3. One of them - of course - is Solus' SLX Wounded/Findcover modules, that I consider a key mod since the caring and rescuing of wounded by AI adds so much to the atmosphere. I found posts that this was not done for reasons related to the physx ragdoll death feature. So I gave it a try. I found a way to make wound and dead entities attachable and dragable, without loosing the ragdoll or death animations. Fine, I thought that would be the difficult part. Attaching works perfectly. But moving only for players: the last weeks I tried desperately to get AI moving in wounded-carry and -dragging stances, i.e. the ones along the lines AcinPercMstpSnonWnonDnon and AcinPknlMstpSnonWnonDnon (all: Wnon, Wpst, Wrfl). I tried all I could think of now, and even transfered the corresponding SLX dragging animations and actions classes (and rtm) from A2. But to no avail. Sometimes, but rarely, AI would move in these stances (after put in it by switchmove). Mostly it showed to be ordered to "move", turned towards the right direction, but remained immobile. Does anyone know what changes to the corresponding actions and animations classes need to be made in order to get AI moving in the dragging/carrying stances (from the 1.71 cfg for e.g)? Or where the trouble arises from? Any help would be much appreciated!