Jump to content
Bohemia Interactive Forums

madrussian

Member
 View Profile  See their activity

  • Content Count

    1025

  • Joined

  • Last visited

  • Medals

Posts posted by madrussian

  1. Posted

    Question is pretty straightforward -

     

    Can setMarkerDrawPriority (ultra-powerful new command btw!) be used to (somehow) make standard markers (created via createMarker) show up on top of icons drawn via drawIcon?

     

    If no, is there any other way to achieve this?

     

    Spoiler

    I wrote (rather complex) systems long ago that make heavy use of drawIcon (to show and control units and groups on main map), that I still use today.  I used drawIcon at that time to overcome lack of setMarkerDrawPriority ability (aka making certain icons appear over top of others).

     

    In short, I'm psyched to (finally! have and) use setMarkerDrawPriority on a re-vamped area control system (which will greatly simplify things), and want it to play nice with my old drawIcon systems.  I'd rather not re-write those legacy systems if I can avoid it.

     

    P. S. If this is indeed not possible, seems like a big shame that standard markers will never be visible over "drawn" elements.  We have so many cool ways to draw things now: drawArrow, drawEllipse, drawLine, drawLink, drawLocation, drawPolygon, drawRectangle, drawTriangle

     

    P. S. #2 - It just occurred to me that if one wants to use any "drawn" commands and making standard markers show up above "drawn" elements in indeed not possible, seems one must completely ditch standard markers and go "whole hog" using just drawIcon icons instead.  (Which hurts performance, because no doubt standard markers are completely engine optimized, whereas "drawn" icons must be scripted per frame.)  Yeah it kinda hurts my brain to realize this.  Hoping I've missed something! 🙂

  2. Posted

    1 hour ago, RCA3 said:

    How about using WaypointComplete EH, and as soon that triggers, you know the next WP was activated, unless there's a timeout but you can check the waypointTimeout/waypointTimeoutCurrent through the EH _waypointIndex?

     

    Very nice indeed.  Cool, looks like there's lots of ways to skin this.

     

    I wish there was a way to store data on a WP too though (outside the condition and activation strings), like via setVariable or similar.  In my particular use case, player is selecting group icons and/or icons of those groups' WPs on main map and then pressing KB shortcut buttons to Add WP, Delete WP, and/or Delete All WPs.  Also drag/dropping the WPs.  If all the WPs are essentially the same, likely many approaches (inc WaypointComplete EH) would potentially work.  If some WPs are special for one reason or another, then it still seems important to be able to record specifics to each WP, in a string (like waypointName) or similar.  That way when new WPs are added and/or deleted, the info on each remaining WP persists.

     

    Ok still curious then, anyone know if "waypoint name" can be made to show up in-game in A3? (or is otherwise unused?)

     

    Also regarding WaypointComplete EH, would be nice if we had events for new WP being added, deleted, or moved too.

    • Like 1

  3. Posted

    Hey all, for my AI system I'd like to store some (additional) info on a group's WP (see the P. S. below for why), and don't necessarily see a dedicated command for that.  (I do see setWaypointStatements, which is for condition and activation so doesn't necessarily fit the bill.)

     

    Meanwhile, I had this idea to use setWaypointName / waypointName for this purpose, as I don't seem to recall ever seeing any "waypoint name" showing up in-game in A3.  Wondering if "waypoint name" can be made to show up in-game in A3?  Otherwise, perhaps "waypoint name" is basically an old concept that is now unused?  I tried several things in editor to see and haven't managed to display "waypoint name" yet... which makes me think it may very well be unused.  Perhaps I'm just missing a setting though, etc.

     

    Anyone know something about this?  Thanks!

     

    P. S. My plan is to make a scripted solution so that user code triggers once as soon as a group starts working on a new WP.  Again we have setWaypointStatements which covers condition (which gets checked repeatedly, and only once unit is in range) and statement (which runs upon condition being fulfilled) but no command that directly sets up code to run one time upon group starting work on a new WP (and regardless of range).

  6. Posted

    Hi all, I looked and hopefully just missed this somehow.

    Is it possible to write a line of text to the small Dedicated Server window?  (Not write to rpt file or any logs, instead write to that little DS window itself.  Like where it says "Rune connected.", "Mission read.", "Game started.", etc)

     

    I'd like to add a "% done" or something like that to my terrain scanner.  Thanks!

  8. Posted

    Hi all, I read though

     

    https://community.bistudio.com/wiki/Number

     

    and the only somewhat direct mention of this was, under Consequences (regarding Floating-point Precision):

     

    Quote

    Large numbers can not always be incremented / decremented. For example, 87654320 + 1 returns 87,654,320 in Arma 3 (the next larger floating-point number after 87,654,320 is 87,654,328).

     

    Anyone ever determine the actual largest integer that Arma 3 can handle as an integer (meaning + 1 or - 1 works)?

     

    I ran this little test:

    (and after narrowing things down a bit) 

    //_num = 20000000; // Immediate Problem!
//_num = 19000000; // Immediate Problem!
//_num = 18000000; // Immediate Problem!
//_num = 17000000; // Immediate Problem!
_num = 16000000; // No (immediate) problem... ran for perhaps 1-2 minutes so far... can't wait around all day and watch this though...
waitUntil {
	["_num"] call MRU_Chat;
	_numX = _num;
	_num = _num + 1;
	if (_num == _numX) exitWith {
		systemChat "This _num was a problem! (for + 1)";
		true
	};
	false
};

    Seems the true limit is... somewhere between 16-17 million?

     

    Spoiler

    In case anyone is wondering... I need this for my Terrain Scanner and AI system (ids for cells and portals).  I just figured out how to break some long-standing limits and scan larger swaths of terrain in parallel... 😉

     

  9. Posted

    Anyone try to get the AI to set up those bipods yet?

     

    Spoiler

     

    In Arma 3 those on-foot bipod anims were player-only (or at least bipod body flexing anim was player-only), which imo was (and still is) a huge tragedy.  With navmesh path-finding in Reforger, eventually we should be able to really unleash these AI to do all kinds of wild things.  Yeah... eventually being the key word.

     

    Would be a shame (in Reforger / Arma 4) if AI foot soldier can't be made to set up their bipod and flex around, just like the player.

     

     

    Even if only possibly via modding, please devs let the AI do this!

  10. Posted

    8 hours ago, pierremgi said:

    Perhaps a part of answer in KK's blog, here:

    http://killzonekid.com/arma-scripting-tutorials-forced-ragdoll/

     

    The animation states or gestures EHs could help... Not tested.

     

    Nice, the ole "can in the belly" trick.  This could indeed be part of the solution, thanks.

     

    Still working to get the various transitions (moment of unit killed, live ragdoll to dead ragdoll, etc) looking smooth.  Struggling with "HandleDamage" EH atm, but found a couple handy links.  I've been using that EH for ages, but apparently not quite correctly (and in some cases, no where near correctly).

  11. Posted

    I've got a pretty simple idea. I'd like to wake up dead units that are done ragdolling and send them flying on new ragdoll with each new shot.

     

    Seems possible with a combination of setConscious, addForce, awake, isAwake, lifeState, incapacitatedState commands, etc. Especially reading though the notes on awake.

     

    But I'm also facing some unique constraints. Basically, I likely need to keep all AI units alive (as ‘alive _unit’ reports) all the time, including the "dead" ones. What on Earth am I up to? If interested, please read on:

     

    Spoiler

    I’ve been creating an extension-based C++/SQF hybrid AI system that uses automatically generated nav-meshes and forced movement for the AI (think playAction), which move units over complex outdoor terrain and effortlessly in and out of buildings (i.e. capable path-finder) into good cover, etc. It’s undergone multiple re-rewrites, each time moving more and more from SQF to C++. With the latest iteration, I can move 100 units simultaneously at 85+ fps, so it’s finally getting there performance-wise.

     

    The way I’m doing all this is quite bonkers (you’ll see all the details upon release provided I actually get finished before A4 comes out, maybe best not to hold breath), but suffice to say I’m now facing tradeoffs when it comes to AI death.

     

    Even without any special re-awaking of AI’s ragdoll (yet), to avoid visual glitch when my moving AI units die, I’m having to treat this specially via a “HandleDamage” EH which capture the moment of his “death”, then ragdoll him myself via setUnconsious, and then ‘enableSimulation false’, to prevent him from automatically rolling over to his backside (presumably to await revive, which btw I’m not doing anything related to, because well respectfully I’m not personally a huge fan of revive-based gameplay, for players or AI).

     

    So currently AIs “die” (by getting shot, etc), I keep them alive and ragdoll them, then once their ragdoll settles, I “disable simulation” on them (via ‘enableSimulation false’), and then I discretely kill them ‘via setDamage 1’. And then they are actually dead. Again I’m doing this only because I have to… for the death from forced movement to look correct. (Btw – This special death comes with a caveat already: His rifle never separates from his body as he ragdolls and settles, because he’s technically alive during that part.)

     

    My hope is now, once they are ragdolled and settled, to re-enable ragdoll on them when they are hit with bullets, explosions, etc. Because of course that would be mega-cool!

     

    Unfortunately, because they died this way (using my special method), nothing I’m trying (to achieve re-ragdolling) is working. In most permutations (combinations of relevant commands), when I addForce to the dead body, it (the body) ends up teleported into the ground (still moving, at a seemingly random depth).

     

    My alternate idea (to achieve re-ragdolling) is to simply never let AI unit actually die (as in never use ‘via setDamage 1’ and allow ‘alive _unit’ to return true forever), and again simply ‘enableSimulation false’ him upon ragdoll settling, and flag him (with a variable) as "dead". Unfortunately, having big problems making this (re-ragdolling with unit always alive) work too (him teleporting still into the ground, etc).

     

    I’ve spent a couple days solid on this now and I’m about to give up and just leave the dead bodies in ‘enableSimulation false’ state indefinitely, and give up on rag-doll re-animation (at least for now).

     

    My question for you guys:

     

    Has anyone created a working system of any kind that re-ragdolls a unit (dead or alive) -and- manages to also completely disable all revive-related animations? And does this while remaining completely visually glitch free (like no animation snapping like with switchMove)? I know, it’s a tall order.

     

    Also, for those that have tried and failed (or succeeded at something similar), I’d love to hear about lessons learned, etc. 🙂

     

    • Like 2

  12. Posted

     

    6 hours ago, Larrow said:

    Updated my links in this thread, this is old I have not confirmed these are working or any longer the correct way to handle this, I have just updated the links to the original files.

     

    Many thanks!  I fired it up (SP only for now)... Still seems to work great.

     

    On 5/20/2023 at 5:45 AM, fn_Quiksilver said:

    this is an old method ... 

     

    use "addForce" instead

     

    Thanks, I tried that too.  Finally got them standing back up.  (Btw - Interestingly, whether I make them unconscious via setUnconscious or addForce, it doesn't seem to change much in terms of issues I'm experiencing or overcoming them.  Surely, I didn't try everything though.)

  13. Posted

    Old thread but directly on point.

     

    After calling 'Loon setUnconscious true' on AI guy, unit ragdolls and settles and ~1 sec later, he flips onto his back with arms to the side.  At this point I would expect 'Loon setUnconscious false' to rejuvenate and get him standing again, but instead does nothing, and AI keeps laying there.  Which command(s) might I be missing?

     

    Spoiler

    This is my first time messing with ragdoll on living units, anyhow I (apparently) need this for my upcoming AI mod, for deaths which happen during forced movement, so they can look clean.  I don't necessarily need to get the ragdolled guys up and moving again (because I'm just killing them off once down), but need to know how to do this in order to try and overcome a couple of related obstacles.

     

    On 10/19/2016 at 12:39 AM, Larrow said:

    Here is a test mission showing all possible combinations via player actions for both the player and an AI, run from a dedicated server.

    Self State - will set unconscious for the player, player automatically becomes conscious again after 5 seconds as being unconscious you lose the ability to run addActions

    Self Server - will set unconscious for the player via a sever function, as above auto conscious after 5 seconds

    AI State - will set/unset unconscious for a targeted local AI

    AI Server- will set/unset unconscious for a remote targeted AI via a server function

    AI Remote - will set/unset unconscious for a remote targeted AI directly via remoteExec

    Join Group and Remove Group will make a targeted AI join/leave(and hand back to server) the players group so as to test changing locality

     

    That looks super helpful, but unfortunately link (to your test mission) is dead.  @Larrow - Do you (or anyone) still happen to have this test mission?  Or otherwise recall how to get an AI back up standing and moving after '_unit setUnconscious true' called on him?  Many thanks.

     

  14. Posted

    Hi all, you know how when you doMove a player's squad AI unit, that unit's indicator will show "MOVE" while he moves?  (And then if you poll via currentCommand, it returns "MOVE".)

     

    And how, when you doStop a player's squad AI unit, that unit's indicator will show "STOP" while he's stopped?  (And then if you poll via currentCommand, it returns "STOP".)  And same for "HEAL", etc?

     

    In this case, I need player subordinate indicator to show "ACTION".

     

    I know one way to accomplish this (AI's icon to display "ACTION") is for player himself to order that AI to repair a vehicle (or similar).  But importantly, I need to have AI's icon display "ACTION" without that AI doing anything particular (like Repairing, etc), and importantly I need to do this 100% via script, as in without in-game player commands, etc.

     

    Theoretically, we should be able to get player squad AI's icons to display any of the following:

    • "WAIT"
    • "ATTACK"
    • "HIDE"
    • "MOVE"
    • "HEAL"
    • "REPAIR"
    • "REFUEL"
    • "REARM"
    • "SUPPORT"
    • "JOIN"
    • "GET IN"
    • "FIRE"
    • "GET OUT"
    • "STOP"
    • "EXPECT"
    • "ACTION"
    • "ATTACKFIRE"
    • "Suppress"

    as described in currentCommand.  Via script commands or via commanding AI personally in-game.

     

    Now I swear I saw some script command saying it would result in unit icon displaying "ACTION" indefinitely (until some other thing happened)... but now I can't seem to find it.

     

    Anyone know how to get player squad's AI icon text to show "ACTION" (via script only)?

     

    Btw - I ran experiments with the action command (lots of different combos), and didn't have any luck getting AI icon text to change... at all.  Which rather surprised me.

     

  15. Posted

    4 hours ago, _foley said:

    I've no clue about CfgMoves but I'm thinking maybe you wanna use a gesture (as in playAction) as opposed to the "full body" animation as in "AmovPercMstpSrasWrflDnon_gear". From my experience they blend okay into different stances.

     

    Yes, I'm using playActionNow for most of what I'm doing.  It's way more user friendly (than playMove/playMoveNow), not having to worry about weapon/stance, etc.  The playAction reaching animation is "PutDown", and it's a very exaggerated long reach that includes motion of unit's hand to his belt area (after the reach), like he's taking something.  And when you use "PutDown" on him while he's kneeling, he reaches all the way to the ground, which again looks strange for a door.

     

    "AmovPercMstpSrasWrflDnon_gear" (and the other 3), which as noted need playMove (/ playMoveNow), play out much quicker and imo look much more like someone opening a door.  Unfortunately these 4 have some pretty funky transitions.

     

    I spent the morning looking though these animations in the config, and it sure looks like InterpolateTo & ConnectTo are single-directional.  Mostly because InterpolateFrom & ConnectFrom also exist, which would imply using To would go one way, and using From would go the other way.  I do recall though, that one of the config entries for at least one Arma title, created transitions that went both ways.  It's quite a fuzzy recollection though, admittedly.

     

    Anyhow, I'm going to take a crack at fixing these transitions with InterpolateTo, along with fiddling with various anim costs, and see what happens.

     

    4 hours ago, _foley said:

    Also, this mod features door opening animations though funnily enough the door animation part has been broken for a few month now 😄 Maybe you can reverse-engineer something useful from it.

     

    Cool, looks like some brand new animations!

  16. Posted

    I'm trying to get AI to reach out to open doors (for crazy AI mod), using these animations (via playMoveNow) :

    • "AmovPercMstpSrasWrflDnon_gear"
    • "AmovPknlMstpSrasWrflDnon_gear"
    • "AmovPercMstpSrasWpstDnon_gear"
    • "AmovPknlMstpSrasWpstDnon_gear"

    It's working fairly well generally & the units reach out as expected, except that standing units end up kneeling prior to ending up the desired gear animation (bad), and also the unit ends up going through a broken animation transition (as if switchMove was used instead, also bad).

     

    I've fixed broken animation transition like these before in CfgMovesMaleSdr.  But it's been a long time, and I've slept a bunch of times since then.  If I knew one particular thing, it would greatly speed up my efforts here:

     

    In CfgMovesMaleSdr, are InterpolateTo and ConnectTo uni-directional, or bi-directional?

     

    ^ Meaning, for a given animation listed in CfgMovesMaleSdr: If its InterpolateTo or ConnectTo contains a particular animation, does that make the given animation just connect forwards to that other animation?  Or does that make the connection work both ways?

     

    Spoiler

    Btw - I posted here in "Mission Editing and Scripting", because although this may seem strictly addon-related, there's a good chance I'll have directly related scripting questions too.

     

  17. Posted

    Hey j-buddy, I've run into this exact same problem.  I think I handled it like this:

     

    Check his getPosASL (or perhaps a bit lower) to his eyepos (which is also ASL) for object(s) via lineIntersectsSurfaces or similar.  If you get a hit, pop him up above.

     

    You probably want to check on every frame.  One side effect is, you might end up with dudes up on top of objects where it doesn't make much sense for them to be.  Like up on a roof with no access, etc.  If you're only doing this for crater entry/exit, you'll probably be ok.  If you want, I can post some relevant code over PM.

    • Thanks 1

  18. Posted

    Very thoughtful & well implemented grenade / water fixes.  As for the fishies, wow that was quite the fish geocide.  john avatar strollin + bridge + a few too many == nade happiness 💥 💥 💥

     

    You're on a roll man, keep it going!  It's kind of amazing that grenades never got any special treatment for water in vanilla, after all these years & sequels.

  21. Posted

    13 hours ago, johnnyboy said:

    I have a complicated (probably too complicated) damage eventHandler for limiting damage to a threshold that won't trigger respawn, and instead calls my set unconscious script, and sends AI to revive the downed unit.  I think nades slipped through the cracks because of 10 or 20 fragments triggering the handleDamage event simultaneously, so not all of the small incremental damages per fragment (per fired handleDamage EH) were applied to the unit.

     

    Ah-ha!  I did something similar in Fight Back mission related to Destroy Truck explosion.  Vanilla truck destruction was too wimpy looking so I spiced it up with a giant bomb.  Just for the visual & sound effect.  Used a handleDamage to detect the moment the truck was going to explode to know when to add the bomb.  I also recall handleDamage firing a whole bunch-o-times & having to account for that (not to mention trying to sync it all in MP), and that giving me fits.  Also to my surprise turns out bomb was waaay too powerful (killing people very very far away), so I had to make sure and spawn bomb right in the middle of the truck, with truck doing nice job of shielding surrounding units & more importantly players from that vast blast radius.  (Turns out vanilla truck explosion itself was just right amount of deadliness.)  On top of this, I also had to worry & fiddle a lot about where the middle of the truck actually was, having no standard destroy truck size or shape because enemy faction was selectable by the player from all factions detected in the config.  With A3, it's amazing how much is often involved in such seemingly trivial thing.  It's like... you start adding a bit, and pretty soon everything easily spirals out of control.

    • Haha 1

  22. Posted

    Well done AI master, wonderful new water related features. 👍

     

    4 hours ago, johnnyboy said:

    - Fixed problem where player and his team was not taking full damage from grenades.  Grenades are deadly, so hit the dirt if you hear "Incoming!"

     

    Curious about this one.  What was stopping full grenade damages?

    • Like 1

  23. Posted

    AI-master j-boy, wow you really hit the nail on the head here, great detective work!

     

    12 hours ago, johnnyboy said:

    Rube posted under doFSM something interesting.  Part of which says:  "Anyway, if you want to be able to call your FSM either way, a "ready" condition might look light this: (moveToCompleted _unit) || (moveToFailed _unit) || (unitReady _unit), assuming you have a moveTo or a doMove (depending on how the fsm is called) in the prior state."

     

    I wonder if you checked that ORed condition of the 3 states if one of them would be true earlier than 15 seconds?

     

    I did see this bit previously.  During this latest crack at solving the mysteries of these commands, mostly I've been ignoring unitReady because of the inconsistency with how it treats group leader vs his subordinates, plus seems like there are much better cues like expectedDestination, etc.  However, unitReady may be quite important after all, at least in how it fits in regarding doFSM (and engine's built-in FSMs).  After running another couple tests this morning, my (latest) observations:

     

    As long as your doFSM is running, unitReady will never be true.

     

    I think what Rube was saying slightly rephrased is:  If you're using execFSM, a good "ready" condition would be (moveToCompleted _unit) || (moveToFailed _unit) || (unitReady _unit).  If you're using doFSM, a good "ready" condition would be (moveToCompleted _unit) || (moveToFailed _unit).

     

    Importantly here if you're using execFSM, you're not actually suspending engine's built formation FSM from trying to send the unit places, and it could bust in and send him somewhere at any moment.  Only doFSM will accomplish that.  (Again, if I understand all this correctly.)  Of course it's possible to do all sorts of things without doFSM, but I suppose I'm trying to determine whether doFSM is a prerequisite for getting moveToFailed to fire.

     

    In case anyone was curious about this bit:

    20 hours ago, madrussian said:

    Btw- In my experience, when moveToCompleted (or presumably moveToFailed) return true, it's a bit hard to detect, because this only happens for perhaps 1 frame.  So I've needed to detect it inside an each frame environment, like inside an FSM.  (Now that I think more about this, maybe moveToCompleted only returns true for one frame for me because I'm ending my FSM right after detecting moveToCompleted or moveToFailed, hard to say but I'll answer this quickly upon diving back in.)

     

    ^ Upon diving back in, I verified that indeed moveToCompleted will return true for many frames or seconds, actually as long as your doFSM is still running (or presumably until you call another moveTo inside your doFSM).

     

    12 hours ago, johnnyboy said:

    I'm sure you thought of this (and it sucks as an option), but if you monitor if unit hasn't moved in 2 seconds after moveTo, then consider the move a failure?

     

    Using timeouts in combo with "PathCalculated" EH would get the job done, but like you say would be ugly.  Ideally we'd have a working "PathCalculationFailed" EH or a working moveToFailed.  After pondering this next bit, I'm not sure which is most important.

     

    12 hours ago, johnnyboy said:

    I found this old post saying it was a problem from A2 into A3 and never fixed (at least I think its what it says):

     

     

    ^ Some absolutely great revelations in here.  Let's expand these so everyone can see:

     

    On 7/3/2014 at 12:26 PM, haleks said:

    I wonder if anyone else experienced this, but most of the "moveTo", "doMove" commands don't work well.

    I'm working on a script to have a unit follow another one closely (without being part of his group).

    The ASL position (the wiki says it is the fastet getPos method) of the target is updated every 0.5 second, and the unit is ordered to move to that position with "doMove" (all this in a loop).

    All works fine - for a few minutes. At some point the unit freezes, and just stands there without animations. But it still does try to move to the target : the unit always turns around to keep its target in sight. If the target get close to the unit (5 meters, maybe), it will eventually "unstuck" it, but the problem will occure again after some time. I've tried pretty much all variations of "doMove" & similar commands, "disableAI", combat modes & behaviour to no avail.

    I'm starting to think about using waypoints, but I feel that it is a complicated work-around for what should be a simple task to a single unit.

    😞 Is there no way to have a unit follow you as fluidly as if it was in your group?

    Any thoughts guys?:confused:

     

    A few posts later Rube chimes in:

     

    On 7/5/2014 at 6:12 PM, rübe said:

    Have a look at these posts.

    Chances are you're running into this exact problem.

    While I've only verified this for ArmA2, I'm pretty sure this also applies to ArmA3, considering this went undetected for more than 2 years. In short: moveToFailed never gets triggered, which easily leads to units being stuck in all kind of situations.

     

    Upon following these links, what we uncover is utterly fascinating:

     

    On 6/27/2014 at 8:57 AM, rübe said:

    I've posted this yesterday already, but in the wrong thread (sorry :o)...

    I think this belongs here:

    Problem: Units can get easily stuck during a moveTo.

    Presumed reason: moveToFailed does not fire when it should. Actually I think moveToFailed currently never gets fired at all!

    Repro./demo mission: http://non.sense.ch/shared/moveToFailed.Chernarus.pbo

    The scenario is as follows: 4 AI are spawned into the players group, which then execute the very simple move.fsm (see moveToFailed-fsm.png) by a call to doFSM. Unless the AI don't die, that move.fsm is supposed to run indefinitely: at each step a random position around the player is chosen for the next moveTo, which is issued and then we check if moveToCompleted or moveToFailed (this would get written to the RPT file - but never does...). Either way, completed or failed, the next moveTo is issued, and so forth. Thus, the spawned AI units are supposed to continously walk around the player here.

    To get them stuck for this repro, a ruins object is spawned, but it's really not a problem with this object and the actual problem may occur anywhere else. This simply speeds this up a bit. Start the mission, speed up time and observe from commander perspective.

    What can be noted is:

    • moveToFailed never get's fired a single time. (I tried this too in cities and close to massive rocks - yet moveToFailed never fires...)
    • stuck units - they don't move any longer, yet they don't issue a moveToCompleted nor a moveToFailed - can be occasionally unstuck, by having other AI or the player move into them. In the posted demo mission, often all but one unit get stuck, and after a while some get unstuck again, and get stuck again a bit later... and so on...

    I hope this helps to narrow down, what is wrong here.

    I did these experiments with 1.62.95248. Are you guys (maybe with newer beta patches) able to reproduce my experience with this?

    And did anything with respect to low-level moveTo commands actually get changed?

    I'm pretty sure this was not always the case, and that I've observed many moveToFailed in the past. But not any more? How come?

     

    On 6/29/2014 at 1:48 PM, rübe said:

    Okay. I've uninstalled Arma2, imported all keys into Steam and reinstalled the whole thing, including the (marked as obsolete?) beta patch.

    Then I've repeated the experiment (repro mission posted above) with 1.63.116523.

    Same outcome - sooner or later all your units will get stuck: moveToFailed is completely broken (or the part of a moveTo that should detect a failure and consequently report it respectively). If I figure out how to install 1.63.125402, I'll let you know the results.

    Edit: Ok, figured it out. Same problem with 1.63.125402.

    Please have a look at it. Having reliable moveTo's is rather critical, and chances are this is still broken in ArmA3 (then again, I'm stunned how this went unnoticed for more than 2 years, apparentely...).

     

    On 6/30/2014 at 10:31 AM, oukej said:

    Acknowledged. There might be however something more to it. Thank you for your repro mission!

    Would you by any chance remember which rev. it was still working correctly for you?

     

    So... moveToFailed definitely used to work and now does not.  And hasn't for some vast amount of time...

     

    Meanwhile, interestingly we have acclaimed AI creator @genesis92x breaking down in detail how doMove used to work extremely well and then, in his words:

     

     

    Per Genesis92x:

    Quote

    "One of the things that really bothered me is that, how, Bohemia at some point, I don't know exactly when or how, it was during one of their AI reworks, they broke the doMove command.

     

    The doMove command is a command you can use in A3, that tells the AI to go to a spot and go to it now.  Go, get to this spot.  Doesn't matter what's going on, I want you to go to a spot.  It was nice because it was one command.

    ...

    You could use it to get them to go to any position that could be pathed to ... and they would just... do it."

     

    I've been in the A3 AI trenches for so long, seems likely I've forgotten just how well doMove used to work.  After I knock some of the 🕸️ out from up there, yes I too recall doMove working much better, like... generally (meaning with less fussing around with commands to the point of own hair pullin', etc).

     

    It occurs to me that just maybe what Rube discovered with moveToFailed being broken, is directly related to creators including Genesis92x (and myself) encountering big problems with doMove, moveTo, etc.

     

    The pinnacle questions regarding all this:

     

    1. Should moveToFailed be working -or- was it actually depreciated as part of an AI update?

    2. If moveToFailed should be working (which it clearly isn't), can it be fixed?

     

    3. If this technical detail were fixed, would that also suddenly fix all manner of AI issues, including many of the AI driving bugs A3 creators everywhere are encountering all the time?

     

    Ok, that's a decent bit-o-sleuthing for the day on this wonderous cold case. 🐔 🥚  I want to take a quick moment & thank the BIS devs & creators for everything they do.  (I love this game!)  [Scurries back to subterranean AI dev complex.]

     

    • Like 1
    • Thanks 1
    • Sad 1

  24. Posted

    I've been using trusty old doMove and "PathCalculated" events for ages now.  Most of the time this combo works great.  Call doMove and then split seconds or a couple seconds later (depending on how far destination is and how complicated the in-between terrain is), "PathCalculated" fires, and we can use this path to do all manner of cool things.  However...

     

    What about the case where we call doMove and the unit can't get a path?  Of course, it must be that unit only tries his path-finding for so long and not forever.  Anyway, how do we know when he's actually given up?  The big elephant in the room (from my perspective anyhow) is, why don't we have an event for the instant a unit gives up on his path?

     

    ^ Alas, no such event exists, and this (determining when path-finding has ceased) is basically what I always supposed moveTo, moveToCompleted, & moveToFailed (& doFSM) are for.  Despite vast experimentation, I haven't had a huge amount of luck with these commands in the past (in terms of doing anything useful), aside from using doMove/moveTo together to get units to move when they otherwise wouldn't... which is a wonderful trick btw.  Today, un-deterred I'm having another crack at getting to the bottom of all this in some editor tests.  Here's what happened so far:

     

    Test is pretty simple.  I have 8 AI guys in a group, all set to allowDamage false to better observe (because I also wanted to see the effect of AWARE vs COMBAT during all this).  Here's my 2-cent understanding of how these moveTo-related commands work (again based on many hours trying various things, also please correct if I've got any of this wrong) :  The command moveTo is intended for use in (or at least alongside) an FSM called on a unit via doFSM (not execFSM).  The command doFSM is there so we can (temporarily) stop the engine's built-in FSM(s) from messing with units while we work on them.  [The engine operates on units via two FSMs, combat and formation.  And the one we're mostly concerned with here is the engine's built-in formation FSM.  I'm modifying the combat FSM, basically disabling it for the moment (if that's how it works), and thus can tell engine's formation FSM is the one directly moving AIs around, not engine's built-in combat FSM].  So in theory we call doFSM, and for the time being the unit is ours, and we are free to call moveTo on him without interruption.  To do all this, of course we need a custom FSM, but it can be a little simple thing with a start node and an end node, and a bit of stuff in between, etc.  And the idea is to keep it running for just as long as necessary and then promptly let it end so the game can mess the unit again.

     

    So far so good.  I would then presume, that upon calling doFSM on our unit, and then inside our running FSM calling moveTo, that moveToCompleted would return true once unit (calculates path, then gets moving, then) gets where he's going.  And indeed my tests reveal it actually works this way, which is nice.  Meanwhile, I would also presume that upon calling doFSM on our unit, and then inside our running FSM calling moveTo, that moveToFailed would likewise return true at some point, presumably when unit failed to get a path.  In my tests however, I've never seen moveToFailed return true, like never ever ever.  Indeed, when inside a doFSM I try to send my unit to a known bad place (via moveTo), like inside a giant rock (from not too far away, to ensure whole path would otherwise be calculating + because I know distant units calculate paths in chunks or at least revise paths in chunks as they get closer), & after about 15 seconds, no path has calculated (as expected) but moveToCompleted returns true.  Two things are weird about this.  First, I expected moveToFailed to return true, not moveToCompleted.  And second, that it takes so long (again, ~15 secs).

     

    Spoiler

    Btw- In my experience, when moveToCompleted (or presumably moveToFailed) return true, it's a bit hard to detect, because this only happens for perhaps 1 frame.  So I've needed to detect it inside an each frame environment, like inside an FSM.  (Now that I think more about this, maybe moveToCompleted only returns true for one frame for me because I'm ending my FSM right after detecting moveToCompleted or moveToFailed, hard to say but I'll answer this quickly upon diving back in.)

     

    Questions:

    1. Has anyone (ever) managed to get moveToFailed to return true?  And if so under what circumstance?
    2. In cases where moveTo is unable to find a path, is engine really doing it's pathfinding for a full 15 seconds before giving up?  (I suppose I would have expected a timeout of like 3-5 seconds tops...)
    3. Semi-related - Does anyone understand expectedDestination command return's forceReplan component?  Seems like it always returns false for me...
    4. If devs happen to be reading, could we get a "PathCalculationFailed" event?  Pretty please?
    Spoiler

    Regarding #3 above (expectedDestination's forceReplan):

    I observe AWARE units will stop upon reaching the place engine's built-in formation FSM wants them, whereas COMBAT units will often not be satisfied upon reaching the place engine's built-in formation FSM wants them, and again and again end up moving to another (engine built-in formation FSM provided) position nearby ad nauseum, all in the presence of zero enemy.  Seems to this extra COMBAT movement upon reaching destination is what I would think forceReplan could be intended for.  So maybe at the moment long ago when the FSMs became built-in (no longer visible to us), forceReplan became OBE and henceforth always reads false.

     

    Anyhow, I'm sure my tests are not anywhere close to exhaustive.  Any insight/discussion is greatly appreciated. 🙂

    • Sad 1
×