madrussian

Many thanks for that! :cheers: Got my mission running smoothly again.

No problem. :) While you're in there looking in the join related code, quick question for you: Should we consider "side-spanning" joins something that is officially supported? By side-spanning join, I mean to say joining units from a group of one side, to a group of a different side. This is/would be extremely useful in many scenarios, such as having groups of resistance fighters "change alliances" based on mission conditions, etc. If it is suppose to be officially supported, I may be able to dig up an issue or two (highly detailed like this one) that you might be interested in looking into. In any event, thanks to you and all involved for all the excellent AI improvements lately. They are really making a big impact!

OK, got another one for you. I have isolated a 100% repeatable way to get the AI stuck, relating to the join command and AI attempting to get healed. (Occurs in Stable 1.40.129533, Dev Build 1.43.129971, and Dev Build 1.43.130072) While developing a large-scale assault mission, I kept getting stuck AIs (badly stuck, as in I've found no way to unstick them). After a couple days of digging, I've isolated the cause and determined the steps to repeat. I've also included some demo code to show it happening. Steps to repeat: Create an AI group. Give the AI group a WP to get them moving. Damage the AI in the group via setDamage. (damaging all of them to 0.9 makes the problem quite apparent, though damaging smaller numbers of units will still result in stuck units by the end of the step sequence) Wait for the damaged units to ask to be healed. Once they ask for healing but before they are healed, create a new group and join all the units from the original group to the new group. Give the new AI group a WP to get them moving (only they won't move now). At this point, any unit that wanted to be healed prior to the join is now completely stuck. They cannot move, they cannot even turn. Apparently, these guys are stuck pretty bad. They will do things like respond verbally to commands but not carry out the orders (of course they won't move). They will not respond to doMove (even once healed). They will salute or sit down when ordered however. They will fire at enemies, but again they will not turn to face them. I have tried everything in the book to unstick them, all to no avail: Tried healing them via setDamage 0. (They heal but they are still stuck. Tried healing them individually and all at once, same result) Tried healing them via in-game med pack. (They heal but they are still stuck. Tried healing individuals, then everyone in the group one by one, same result) Tried enableSimulation true (which I figured wouldn't work anyhow as they are still playing idle animations... still stuck) Tried forceSpeed -1. Tried regrouping them again after a delay (creating new group, then joining all the stuck units into the new group). Tried disabling various AI components via disableAI (including "FSM"), then re-enabling via enableAI. Tried disabling various AI components via disableAI (including "FSM"), then regrouping (per #5), then re-enabling via enableAI. Again, nothing I've tried unsticks them. I suspect the FSM is bogging out somewhere. (Curious whether disableAI "FSM" followed by enableAI "FSM", kills and restarts the unit's FSM routine? Seems not?) I'm aware under normal circumstances, units in the middle of healing undergoing a join is pretty rare, but apparently it is happening quite frequently during my assault mission, in which I consolidate groups (via join) when they take losses... which happens to be the very time surviving units are most likely to be damaged and in the middle of healing. I imagine other mission creators using join will run into this "healing + join = stuck" issue at some point as well. Also, I have no idea if this AI stuck issue is related to the "buildings" one mentioned, but I suspect not. Here's the code (includes getting the AI units stuck and the attempts at unsticking them): Anyhow cheers, hope this helps and hope you are able to resolve this. :)

Agree, and I would add the following: AI should detect suppressive fire directionally (based in part on his knowledge of the position of the enemy suppressing him), and seek out appropriate cover to shield himself from the incoming fire, attempting to position himself accordingly. The greater the suppression inflicted upon the AI, the greater that AI's desire to seek cover should be. Most importantly, if the AI is already in cover and begins taking new suppressive fire, he should reevaluate his current cover situation. If the AI finds himself exposed to the new suppressive fire, by all means he should reposition himself around his current cover, or leave current cover if his best option is new cover nearby. A tall order to effectively code all that, but curious which of these are possible or perhaps even planned (or currently implemented to some degree). Great AI improvements so far, keep going! :)

Totally agree. Anyone who argues against AI weapon deployment should fire up COH and order their AI to deploy MG, opening up a firing lane from which the opposing units scatter and take cover. Sure it's an RTS, but it's quite an accurate representation of how effective a single MG can be and how deployment works. Sounds like BIS is laying the foundation for something similar with this from SITREP #97: Having AI "avoid crossing impact zones" sounds like a great start. Hopefully we'll eventually get to AIs scattering and finding cover to escape a firing lane. At the very least, I hope we can place AIs into deployment via a script command, for mission making purposes. Deployed AIs can more properly defend fortifications, buildings, etc, and this would definitely up the immersion factor. (And we can and always have been able to adjust AI accuracy, so I don't see that as a barrier.) Anyhow, forget about AIs for a minute. Picture some of the attempts at static machine guns over the years (official and mods). The unit manning the MG (players and AI alike) would stand or kneel in a fixed pose, and the gun would move but the unit remained perfectly rigid. Most prominent example being when unit is standing straight up manning an MG. Not very immersive, not to mention the unit is usually quite easy to hit (as he's not conforming to his moving weapon). Think of how long those guys manning an MG on the back of a pickup truck usually last... not long! Deployment as discussed in this thread (as I understand it) applies to foot units deploying their weapons in appropriate spots. However, the animation tech associated with deployment could very well be applied to certain static weapons, and if so obviously that would carry over from player to AI. Similarly, I wonder how exactly this foot unit deployment will be implemented behind the scenes in the engine... Will units in deployment be placed in an "invisible" vehicle, attached to and rotating around the bipod memory point? If that's the case, I think there's a good bet we'll get AI that can deploy. Appreciate the comments on AI and weapon resting. Curious to get dev comment on AI deployment specifically (apart and aside from weapon resting), whether it will be possible and/or automatic, or whether this has even been decided yet.

Do you recall AI deployment being mentioned by dev in this thread, or elsewhere? If that's the case, I wonder if they meant no AI deployment at all or just no automatic AI deployment. Imo, AI's being able to deploy (even if only via script) is very important, as one of the big tenants of OFP/Arma since the beginning has been that players gets no special treatment, as far as the AI is concerned. For example, AI targeting consideration giving equal priority to enemy players and enemy AI targets alike. Also, AI can fire from vehicles, so hopefully that's an indication that weapon deployment will get the full treatment as well. Hopefully yet in ArmA3.

Obviously deployment isn't out yet, but wondering has anyone has seen anything regarding AI? 1. Will AI be able to deploy? 2. Will AI deploy automatically, or do we have to control it via script similar to current "getting AI to go inside buildings"? 3. Will AI be able to deploy inside buildings at windows (all windows?), detect enemy units through windows, and fire accordingly? All three would be a perfect trifecta (not to mention just what WW2 mods are missing right now with those MG42s).

One way to immediately stop units from fleeing (then optionally allow the units to flee again straight away or not, as desired) is detailed over here. It works great in my missions.

Greetings, While attempting to write a small "Kill the Collaborator" sub-mission today, it occurred to me that it would be very useful to have precise control of a unit's "fleeing". Did some searches... then ran some tests. I quickly reviewed the two most obvious related commands (both which have been around since OFP 1.0): 1. allowFleeing: Sets a unit or groups propensity to flee the scene and run away. 2. fleeing: Checks whether a unit is currently fleeing. So we can easily allow fleeing by using something like "Loon allowFleeing 1". (Actually this forces fleeing, provided the unit knows he's in any danger.) And we can run a loop to monitor how long he stays in a fleeing state. And we can allow the fleeing unit to eventually stop fleeing by something like "Loon allowFleeing 0". However, so far I have been unable to make the unit stop fleeing immediately on command. He just keeps fleeing for what seems like ages, until he is good and ready, despite the "Loon allowFleeing 0". :eek: I have even tried to getting a unit fleeing, disabling all AI components, then "Loon allowFleeing 0", then re-enabling all AI components... no dice. :confused: Too bad really... Fleeing adds some great dynamics and can be harnessed to produce unique mission elements without having to script elaborate "escape" sequences (and figure out where to send the escapees running... cumbersome in dynamic missions). Does anyone have any idea how to get a unit to stop fleeing immediately on command? And if not, maybe if BIS is reading, perhaps add a quick command for this, something like "forceFleeing"? Any help is much appreciated, as always. :)

Solved this old problem. To get a group to stop fleeing, one way (the only way I know of) is to re-group them, like this: MRU_Regroup = { private ["_group","_resetFleeing","_newFleeVal","_newGroup"]; _group = _this select 0; _resetFleeing = false; _newFleeVal = 0.5; if ((count _this) > 1) then { _resetFleeing = _this select 1 }; // Optional if ((count _this) > 2) then { _newFleeVal = _this select 2 }; // Optional _newGroup = createGroup (side _group); if (_resetFleeing) then { _newGroup allowFleeing 0 }; (units _group) joinSilent _newGroup; if (_resetFleeing) then { _newGroup allowFleeing _newFleeVal }; deleteGroup _group; _newGroup }; Hope this helps someone. :)

Here's a quick method using locations (call as func): private ["_pos","_mark","_inside","_shape","_loc"]; _pos = _this select 0; _mark = _this select 1; _inside = false; _shape = markerShape _mark; if (! (_shape == "ICON")) then { _loc = createLocation (["Name", markerPos _mark] + (markerSize _mark)); if (_shape == "RECTANGLE") then { _loc setRectangular true }; _loc setDirection (markerDir _mark); if (_pos in _loc) then { _inside = true }; deleteLocation _loc; }; _inside

Hey all, I've had this idea in my head for some time, and finally a relevant game popped up. The idea is, the game begins and the story plays out over a period of time to conclusion. Multiple outcomes are possible, and the player can (but isn't forced to) act to affect the events and steer the game forward. The important points are that the game does not wait on the player and that eventually the game ends. It is likely possible to "win", "lose", or somewhere in between but that's not absolutely necessary. [btw- I'm specifically not referring to SP games "running" while you are not playing (ala State of Decay).] The RTS genre is about the only place I've seen attempt this recipe, and that's by definition really. Spelunky (awesome game btw) comes close, with the Ghost and the collapsed level entrances driving you forward, ever deeper. I'd really like to see a 1st or 3rd person game take this on, and fortunately there's an indie title I'm aware of that fit the bill. Hopefully Consortium will live up to expectation. It releases on Steam about an hour! As an aside, imagine if Skyrim, Deus Ex or similar operated on these principles. It would be mind blowing! Certainly several user-made ArmA scenarios have attempted this, though I struggle to come up with one atm. Even Abandoned Armies, which was completely immersive and awe-inspiring, (mostly) waited on the player (to discover the convoy, kick off the war, etc). [btw- Can anyone think of a SP or coop Arma scenario that fits?] Here' the big question. Surely other game devs have tackled this recipe. Anyone aware of other SP (or coop) games which follow this formula? Again, the game proceeds with or without player action and eventually comes to a conclusion?

In the editor, apparently if you link an object to a series of markers, at mission start the object will be randomly placed at one of the marker locations. (I discovered this the other day in the editor while looking at someone's mission. Seems kinda shocking, as I've been using the editor for years and never knew about this!) Questions: Is this new for ArmA3? More importantly, how do you link the object to the markers? Unfortunately, I can't seem to make this work! I tried synchronize, which normally works by dragging together the two items you wish to sync. However, I can't seem to sync an object with a marker. With Sync selected, if you position your mouse and drag from the object, you simply move the object. Likewise with Sync selected, if you position your mouse and drag from the marker, you simply move the marker. Yet somehow the creator of the mission I was looking at managed to link an object (vehicle in this case), to four markers, which shows up like this in his "mission.sqm" file: class Item2 { position[]={3058.8953,3.8787389,6005.8179}; azimut=-254.83099; id=80; side="EMPTY"; vehicle="O_MRAP_02_F"; leader=1; lock="LOCKED"; skill=0.46666664; text="FogCar"; markers[]= { "r", "r_1", "r_2", "r_3" }; init="this engineOn true;"; }; Really curious about this. Any insight is much appreciated!

That sorted it... Many thanks kylania!

Regarding the lights going out (mentioned a couple pages back): Something I've noticed playing a night mission in vanilla ArmA3. When I order my units into stealth mode, they turn off their lights. Thus if you put units into stealth mode via command, I imagine they would likewise turn off their lights. Could this be / have been the problem? Also, something I'm wondering: How often do you have units taking cover? Every time they are shot at? Curious, how does this algorithm work? Btw- Great mod! :)

I'm having a really good time with your mission! Please keep expanding the concept! Quick ideas: Maybe make the initial base an actual fire base? Add some type of AI Helo transport (unlockable like the others... costing action points, of course). Love the UAV mission, but sometimes it feels kinda simplified. Do you plan on using real UAVs that actually fly when they come available in-game? I wonder if they would detect enough of the enemy to make this viable? Also, really liking the new fire base idea, but looks like I may have found a bug: Fire bases I create do not seem to allow purchase of new units. No matter where I stand, I don't get that option. (I do get option for checking stats.)

Really liking the new ragdoll in ArmA3. Quite immersive! As soon as a body comes to rest though, it is no longer affected by physics. (i.e. even if a grenade or satchel goes off underneath it, etc.) This automatic disabling of ragdoll is probably a good idea under general circumstances, to save CPU cycles etc. Anyhow... Trying to figure out how to keep the ragdoll going on certain dead bodies (or "re-enable" ragdoll indefinitely for them I suppose), to increase immersion factor in battle. (Btw- I recall Far Cry 1 having this. I would blast away at the dead bodies sometimes, lol.) My first thought was to re-enable the simulation via: _body [url="http://community.bistudio.com/wiki/enableSimulation"]enableSimulation [/url]true; No dice so far. Upon coming to rest, the dead remain completely unaffected by physics. Any ideas?

+1, yes standing sprint feels so much more like real life now. Just perfect, please keep it like this! Also, minor quibble: Seems like the new crouch sprint should be a somewhat slower than the standing sprint, but as far as I can tell the two are pretty much exactly the same speed. Anyhow, imo everything is much better now in terms of speeds, many thanks indeed. :)

First of all really enjoying ArmA3 Alpha! So many things work so well now that when something doesn't it really feels out of place. Throwing hand grenades and firing under-barrel launcher grenades in ArmA3 is one such area, with both pretty messed up currently imo. Hand grenades have 3 major problems atm: First and foremost, as mentioned on a related thread we have no means to throw hand grenades harder or softer. This was working brilliantly since OA, and it's extremely frustrating now! Most importantly, in A2 thrown grenades leave the body at a significant upward angle, allowing you to better see what you were throwing at. From OA, there were two indicators on screen to help you perform a reasonable grenade throw. Upper indicator ("circle") gave you a sense of what angle you were throwing up to. Lower indicator ("dot") gave you a sense of where your grenade might land, based on how hard your throw was. In A3 currently there is no such indicator system, and thrown grenades leave the body straight down the middle of the screen. To aim any thrown grenade now in A3, you have to suddenly pitch the camera up to get a proper thrown arc, throw, then suddenly pitch the camera back down to restore your view, all which ironically takes your eye completely off what you're throwing at. Again, thrown grenade exiting arc and indicators worked so well in A2, why mess it up so bad for ArmA3? When attempting to throw a grenade from 3rd person in A3 now (due to the straight exit angle mentioned above), your own body obstructs the thrown path of the grenade. Horrible. Launched grenades have 2 major problems atm: Launched grenades in ArmA3 3rd person suffer (as with thrown grenades) from your own body obstructing your view of the projectile path of the grenade. Slightly different reason here. Just double checked this: In A2 3rd person, the camera lines up exactly with the right side of your helmet, thus allowing you an unobstructed view of what you're launching a grenade at. In ArmA3 however, the 3rd person camera lines up well to the left of the right side of your helmet, effectively obstructing your view. Also, the 3rd person indicator for launched grenades in ArmA3 is very low, seems to correlate little with where the launched grenade actually ends up, and is again completely obstructed by your body. Solutions: Reinstate the thrown grenade indicator system with adjustable throwing power from OA. Reinstate the significant upward exit angle that thrown grenades leave your body at from A2/OA (as opposed to the current A3 "straight ahead" method), so we can see what we're throwing at! For launched grenades (and can apply to all weapons really), shift or pivot the camera slightly (ever so slightly) to where the weapon direction vector is no longer obstructed by the player's head / helmet in 3rd person. This is especially important for slow rounds like launched grenades that drop significantly. Rework the 3rd person grenade launcher indicator, so it's more intuitive as it was in OA. Anyway I don't want to sound negative and nothing against the devs, this is an awesome game! Please consider changing the thrown and launched grenade operation back to like OA, which worked so well. :) Note - The one improvement I see so far in A3 in this area is the 1st person grenade launcher aiming sites. Also, let's keep the discussion here on thrown and launched grenade operation in A3 and previous titles, and refrain from comments about whether people prefer 1st or 3rd person that cross the line into judging how everyone else should play. I happen to like both 1st and 3rd person, as I'm sure many others around here do. Thanks!

Some great ideas and discussion. Seems we have people that like thrown grenade exit at both upward angle trajectory -and- straight ahead. Making it optional sounds good to me. I'll probably make a small mod (personal use?) with upward trajectory for player thrown grenades in the mean time, until we get something official.

Yeah, we really need an "impact" event handler. Either that or make "killed" event handlers also work on projectiles to detect impacts.

Oh that's great news! Curious, which part(s) of grenade throw did you see discussed as being placeholders? When throwing a grenade from 1st person in A3, you should see a noticeable difference from how it operated in OA. In OA, when you switch to a hand grenade, you get that upper circular indicator (even in 1st person), which is quite a ways UP from the central crosshair, and the central crosshair turns into a dot. Most significant, when you actually throw your grenade, it flies up towards the circle, not directly straight ahead like in A3. Having a thrown grenade fly upwards is essential imo, so you can see what you're throwing at! (in 1st person and 3rd, due to extreme arc of the grenade as gravity pulls it down) Also, in OA you had fine control over how hard your throw was. In A3 currently it's all tied to a key, thus completely binary. Throw at full power or not at all! (This too applies to 1st and 3rd person.) On the other hand, the issues with obstructed view I detail above are problems with the 3rd person view only. Agreed, I'm talking about an extremely slight shift in 3rd person perspective only, moving the cam slightly to the right (so your head does not obstruct slow moving projectiles that you fire, like launched grenades as they drop. Agreed, more options is always better. I personally like my 3rd person view just like A2 has it. With my soldier right in the middle, crosshair a bit above and slightly to the right, so I can see what I'm shooting. A3 is very close to this now, just needs a small tweak. Part of this is due to the night vision goggles which stick out further than before. :) EDIT: Interesting, curious how these two work? Two great ideas!

Hi all, I wrote a little script to see your death upon dying in ArmA3 SP. As opposed to default ArmA3 where everything blurs and blacks out when you die, now you get to see yourself ragdoll. Works pretty good, but it's not perfect yet. Wrote two Event Scripts, which get placed in the main mission dir, and override the corresponding event scripts (located inside "A3.pbo"). onPlayerKilled.sqs: _this execvm "onPlayerKilled.sqf" ~10000000000000000000 onPlayerKilled.sqf: [] spawn { sleep 10; endMission "END1" }; _pos = positionCameraToWorld [0,0,0]; _cam = "camera" camCreate _pos; _cam cameraEffect ["internal", "BACK"]; _dead = player; selectNoPlayer; _cam camSetTarget _dead; // Wipe out the blur, fisheye effect, and blackout [] spawn { while {true} do { for "_i" from 0 to 1000 do { _i ppEffectEnable false; _i ppEffectForceInNVG false; _i cutFadeOut 0; }; sleep 0.1; }; }; while {true} do { _cam camCommit 0; sleep 0.001; }; In order to see one's death, we must overcome 3 different visual effects that default ArmaA3 generates upon death: Screen blurred - The ppEffectEnable line above eliminates the blur. Fisheye effect onscreen - The ppEffectForceInNVG line above eliminates the fisheye effect. Screen blacks out - After a few seconds, the screen begins to black out, and will stay that way without any intervention. The cutFadeOut line above makes the blackout effect go away, but only after the blackout fades in first. Question is regarding #3. I can make the blackout go away, but again only after the blackout completely fades into view. I'd like to stop the blackout as soon as it starts, so the player never even sees it. So, trying to wipe out the blackout upon death all-together. Any ideas?

Thanks, that pointed me in the right direction. Turns out a cutText right before the cutFadeOut will do the trick, eliminating the blackout completely. [] spawn { while {true} do { for "_i" from 0 to 10000 do { _i ppEffectEnable false; _i ppEffectForceInNVG false; }; 4 cutText ["","PLAIN",0]; 4 cutFadeOut 0; sleep 0.1; }; }; Appears the death blackout is occurring in layer 4, at least for me. Also, apparently the post process IDs for the blur and fisheye effect are not always in the 0 to 1000 range, so I increased the loop to encompass 0 to 10000. No where near optimized yet, but works like a charm for simple missions! :-)

Anyone know which value in CfgWeapons makes weapons such as the M1A1's "SmokeLauncher" not visible/accessible to the player? (There is an invisible "Smokelauncher" weapon in the commander turret along with the M2.) Seems like showToPlayer would govern this, however "SmokeLauncher" has a showToPlayer value of 1... as do all the M1A1's other (visible) weapons.