madrussian

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? 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! 🙂

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).

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.

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!

Thanks guys. Dang, oh well maybe I'll rig something up. I've running ~10 DSs in parallel, all launched from batch files. And my scanner uses callExtension already (to create the scan files), so maybe I can pipe some "progress" feed to the consoles the batches make.

Thanks, yeah unfortunately it seems systemChat does not write to the Dedicated Server window. I have a constant stream of systemChat going on in my mission (already), and don't see any of that on my DS window. I was wondering though if a different chat command or similar does though?

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): 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?

Awesome, makes perfect sense now. Very well said & many thanks! I'll put this to use immediately.

Anyone try to get the AI to set up those bipods yet? Even if only possibly via modding, please devs let the AI do this!

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: 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. 🙂

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).

Many thanks! I fired it up (SP only for now)... Still seems to work great. 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.)

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? 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.

I know of (at least) 3 ways to get a turret's direction, but my usual bag of tricks is not working on a particular turret within a particular vehicle. Could use some help, thanks! Vehicle is Sherman tank from IFA3, type is "LIB_M4A3_75". Turret is [1], the "hull" turret (the one you get in via "To Machinegunner's seat" action). My normal methods for getting turret direction: Use weaponDirection command. Of course this works on main gunner's turret only. As this turret is not a main turret, weaponDirection returns non-direction of [0,0,0] as expected, so we need another method. From turret's config get "gunBeg" and "gunEnd", use selectionPosition to get the points in space, and then use vectorDiff to subtract gunEnd from gunBeg to get the turret's direction. Normally this works, and normally I can confirm visually via addMissionEventHandler "Draw3D" with drawIcon3D command. But in this case: Upon manning this turret the gunBeg and gunEnd positions are in the right place, but as I move the turret around, the gunBeg and gunEnd points should move around accordingly, but they do not move around and instead errantly remain fixed in place. (Again, this method and visual verification works with other vehicle types.) From turrets config get "animationSourceBody" and "animationSourceGun", and then use animationPhase command to compute the guns rotation from center in radians, and go from there to get turret's direction. (Btw - "animationSourceBody" gives X transfer, and "animationSourceGun" gives Y transfer.) (Also, for sub-turrets, you have to add/subtract the transfer of the parent turret, but as this turret is not a sub-turret, no addition/subtraction is necessary.) When I try this on other vehicles, I can see the X transfer and the Y transfer change as I move the turret. But for this troublesome vehicle/turret, X transfer and Y transfer both remain 0. Which happens to correspond 100% to the visual result from method 2 (gunBeg and gunEnd positions incorrectly remaining fixed straight ahead as I move the gun around). Should I be suspecting a broken config for this vehicle type ("LIB_M4A3_75") that's fouling up methods 2 and 3? Anyone know a good universal method for getting turret's direction? Anyone wonder why we don't have a (simple) turretWeaponDirection command to save us all these shenanigans? Hmmm... I'm jealous... VBS seems to have this.

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.

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?

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. Cool, looks like some brand new animations!

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.

I'm developing an AI system, and need to get the types of various buildings. This is usually trivial, as one can use the nearestObjects or cursorTarget commands. But on Dingor Island, turns out certain buildings are actually (apparently) technically terrain objects. There are at least two of these I know about: the large apartment style buildings (which come in 3 different heights) and these small wooden huts. For my AI system to work properly, these terrain object buildings are no good, and I need regular buildings instead. The main problem is, that typeOf on these terrain obj buildings doesn't work (returns empty strings). Thankfully I've succeeded in detecting and swapping out the large apartment buildings, like this: Detect all terrain objects via nearestTerrainObjects (within the desired area). Get the string of each of those objects. (Because, again typeOf won't work on these terrain objects) Get all the terrain objs within that set where substring "ibrpanenak" is present (which I guess "panenak" is Czech for apartment). Hide the offending buildings via hideObjectGlobal, and place in usable (i.e. normal, non terrain obj) building that's essentially the same thing with a different texture, in this case building type "Land_Panelak1_Grey". So far so good. But then unfortunately, I tried this same method for the little wooden huts, and turns out the string of these particular terrain obj buildings don't return anything useful (only substring "house", which of course is the base class for most buildings). Couple questions: Anyone know where terrain objs are defined in the config? (I suspect cfgVehicles, but have not been able to prove this, seeing as I can't actually get the types for these particular "building terrain objects".) If these "building terrain objects" are actually defined within cfgVehicles, that means they must have a type. How can I get their type? OK, that's it. I welcome any and all help, even with simple things I may have missed. 🙂

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.

Wow man, you really have all this thought through extremely well. BIS or one of the paid DLCs would do well to scoop you up while the getting is good.

Extremely immersive indeed & well done! Curious how you are floating these things? attachTo to small things that float? addForce? setVelocityTransformation on every frame? Very cool regardless. Also, how do they react when you bump boat against them?

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.

Well done AI master, wonderful new water related features. 👍 Curious about this one. What was stopping full grenade damages?

AI-master j-boy, wow you really hit the nail on the head here, great detective work! 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: ^ 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). 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. ^ Some absolutely great revelations in here. Let's expand these so everyone can see: A few posts later Rube chimes in: Upon following these links, what we uncover is utterly fascinating: 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: 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.]