madrussian

Interesting results, thanks! Ran some more tests. It seems that at soon as I run the snippet, the gun begins to automatically reload, whether it's manned or not. So if I run the snippet and immediately jump onto the gun, I experience the reload. If I run the snippet, wait 5-7 seconds and then man the gun, I don't see the reload at all. If I jump on half way through, I miss half the reload, etc. Is this consistent with what you're seeing, GOM? My intent is to have a weapon drop (from heli), weapon disassembled in crate (two backpacks). So you have to assemble the parts, per usual. Upon weapon assemble, I run the limited ammo snippet (via "WeaponAssembled" event handler). Often in my scenario, the player will be assembling the weapon under fire, and thus will want to jump on and man the gun immediately, and obviously in that case seems kind of silly if the gun doesn't come preloaded (ready to fire). Wondering is there a way to "skip" the reload?

As many others have voiced, I too would love to see an AI roadmap! Even if our most important feature(s) was not on the current list, at least we'd know. In that case, we could always just roll up our sleeves, and better enjoy what we've got currently (which is way more AI-wise than so many other games). With an actual AI roadmap in hand (even a slightly disappointing one), seems like we could all breathe a collective sign of relief, knowing we could simply look forward to future AI roadmaps (six months, perhaps a year down the line). What is yet in store for AI in ArmA3?

My sentiments exactly. With all the advances we are seeing lately (which are awesome and greatly appreciated!), AI path-finding on foot seems to be getting left in the dust. Agree with froggy, there have been a number of small steps forward since A2. However, very little progress regarding path-finding in and out of open buildings (getting stuck inside), and now (apparently) we have large swaths of the map inaccessible to the AI via foot. It occurs to me this must be a particularly challenging area to advance. Regarding such AI navigation improvements (particularly on foot), have we hit some sort of technical barrier? Or are they simply not a priority (for now)? Seems like this will be big problem for zombie missions on Tanoa.

Good summary, good bug reports, nice mission! Shifting my thinking slightly - This really a multi-faceted issue. I agree that some buildings are worse offenders than others. I think that's a sound theory that it comes down to object placement near the buildings. I also stand my assessment that the AI path-finding should be more forgiving, and be able to recover when it gets off track or similar. In short, imo the AI should be able to get where it needs to go (certainly in and out of buildings), regardless of whether it encounters a slightly bugged building. Above all, AI should never get in just fine, but be stuck once inside. Speaking of buggy buildings, one in particular that consistently has a major "AI can enter but can never leave" problems is "Land_i_House_Small_03_V1_F". On Stratis in Ageia Marina, turns out this building accounts for fully 25% of buildings with positions! (see blue dots in the screenshot below) I created a quick simple test mission. Loon gets ordered to move into nearest building (closest to player) via radio 0-0-0. Loon gets ordered to move back to player via radio 0-0-9. To make testing easy (as Loon keeps getting stuck), 0-0-8 teleports Loon back to the player and clears his doMove order. Results are repeatable. AI can enter most buildings. Upon entry, AI gets stuck in many "Land_i_House_Small_03_V1_F" buildings, but he can consistently successfully enter and exit other instances of "Land_i_House_Small_03_V1_F". For certain instances of "Land_i_House_Small_03_V1_F", AI can always enter but successful exiting seems to depend heavily on the location of the exiting doMove position. I only spent a few minutes in there and found 2 consistently bad exit buildings and 1 consistently good building. Again, all "Land_i_House_Small_03_V1_F" have a blue dot:

Definitely not building type, as when you find a bad instance of a building (bad individual building object), there are perfectly functional instances of the exact same building type elsewhere on the map. I don't pin the problem on the buildings or the building object's placement, or on nearby object placements. In the cases I'm thinking of there is nothing obstructing the building's doorway, and nothing funny about the terrain at the doorway. I simply order the AI through the front door to interior buildingPos via doMove, and he happily walks right in. Then he moves around just fine within the confines of the building, but there's absolutely no way to get him to walk back out again. (To repeat: single AI alone in his own group, and not in combat.) I pin the problem squarely on the AI path-finding. Also, there's a totally separate issue (not mentioned here yet), regarding multiple AI in the same building, when one or more are trying to move. They get in each other's way and often one or more stop moving completely. The problem is compounded if they are in the same group and in Combat (due to the "go, I'll cover" fsm algorithm, etc), so again I always put men in their own group, which works far better but still has major issues. (Also I use forceSpeed -1, in cases they are stopped due to forceSpeed 0.) I imagine making AI path-finding inside buildings work effectively is quite a challenge, and I believe that progress is totally possible and that this is a great area for improvement in our beloved game. I wonder if BIS has looked at 3rd party path-finding solutions. Something like SpeedTree but for Path-finding complex crowd AI (including within a confined environment) might be just the ticket.

The one you found might be a #2 or #3 variety. Before getting stuck inside, can the AI walk into the building on his own two feet? (via doMove to a buildingPos position) There really are a plethora of these "bad buildings" (both #2 and #3) on every map I've checked out. Many right there in the main Stratis village. Many are close to that man-made concrete ditch.

I recall seeing perhaps as many as 10+ additional task types inside CfgTaskTypes that are no longer present, none of which were listed on the wiki at that time. (Indeed I specifically recall a discrepancy between CfgTaskTypes and the wiki, and needing to go through them one at a time to see what was there.) It's possible they were from a mod, but I don't think so. In any event, I can't find any mod I was using that added them. Another thing makes me think they weren't from a mod: At least one of the task types changed names from "Infantry" to "Rifle" (since previous version). I also recall seeing a Tank in there. My guess is the wiki had the ones that made the cut, and the rest got removed from the game config / data just recently, Anyhow, all the extra task icons were really handy! Helps differentiate when you have 6+ task icons going at the same time. For instance, I have destroy truck and steal truck sub-missions. Was using "Destroy" for destroy truck and "Truck" for steal truck (aka steal supplies). Now I'm having to use "Repair" (which looks like tools) for steal truck, and it looks kinda silly. Unless I'm shroomin, would be nice to see at least the vehicle related ones come back.

I was using task type "Truck" for a steal the truck type sub-mission. The truck icon was absolutely perfect! But unfortunately task type "Truck" seems to have disappeared from CfgTaskTypes. Did this truck icon get moved somewhere else, or was it simply removed all-together?

Regarding the new overhauled Task Icons/Tooltips, is there any easy way (via script) to determine which Task Icon has the mouseover or selection on the map, at any given time? Edit: Figured out the mouseover part: Using ctrlMapMouseOver on the main map works like a charm. That's a mighty handy command too! Can get Tasks, Task Tooltips, Markers, probably more. Plus it gives back the associated local task (for tasks and task tooltips) or string name (for markers).

Agree, option to either continue showing or hide the task indicator on the map upon task completion (via script command, etc), would be nice.

I seem to recall needing Veteran or above to overcome some hard coded game behaviour that pulled from the Configs... now that I think about it, perhaps all the way back in ArmA1. Anyhow, good to hear oukej. As long as we can adjust everything in the settings (or otherwise via script command), I'm a happy camper. :)

Thanks chortles. I read warkonaut's response on hiding the indicators in the difficulty settings, which is certainly nice. I rather prefer Twisted's idea of the option to leave the indicator visible, just take the distance text out. And I understand that's probably beyond the scope of this development effort. In any event, should be fairly trivial to hide the real indicator (via script command or settings) and simply display our own scripted "distance-free" variant. ;)

Thanks devs for giving tasks a makeover! I've been knee deep mucking about with the task system the past couple weeks... Here's some quick feedback (hopefully useful): I'm really hoping with the new system, we can do the following (via script commands): Hide all task indicators in the HUD (including the assigned task indicator), all of this while the journal is up in 3D with the assigned task selected. Simultaneous to above, show the task indicators on the 2D map, including assigned task indicator having it's own "highlighted" mark. Will this be possible? Very good idea, I have this issue myself with always knowing the distance to the objective, and being able to zero my gun accordingly. That is to say perfectly zero it, especially with grenade launcher (which feels like a major cheat). Hope devs reconsider this one! Next, I advocate for an easy way to maintain Task order, when switching to a new character. The problem is that when a task is created (via BIS_fnc_taskCreate), and subsequently a new unit is created that the player switches to (via selectPlayer), he won't have that task (yet). If other tasks were created in the mean time (before the selectPlayer), and later the original task info gets updated (via BIS_fnc_taskSetState or similar), the new unit gets the original task, but the tasks end up all out of order! I scripted a solution to all this, and it works great. (Basically, upon player switch, it strips all tasks and associated variables locally from the unit, the reapplies the tasks locally and in order.) Anyhow, would be nice to see an official solution to preserving Task Order. Lastly, I advocate for (optional) Multiple Destinations per Single Task. Example: I have an "Enlist Fighters" objective system I apply to various missions, that places joinable fighters on the map, periodically and when the player completes certain objectives. Basically it's a way to replenish your losses. If you can get to the fighters, you get an action and they join your group. Originally each fighter group had it's own Task. Sometimes in long missions, 10 or more of these Tasks were ending up in the journal, cluttering it up! I'd prefer one Task, with multiple indicators on the map that the user may highlight on the map, just like any other task indicator. I scripted a solution (single Task, multi-Obj) and it works great, but it was a real bitch. (Mainly due to my insistence on allowing the assigned task to be highlighted on the 2D map, simultaneous with hiding it in the 3D HUD. I ended up having to detect the map opening and closing via EHs, and set the task destination to objNull to while map was down, and back to the destination while the map was displayed.) Lol, there has to be a better way.

Agree, a simple script command to limit 3rd person (overriding individual user's 3rd person preference setting) would be a very nice indeed... In addition to the option to disallow 3rd person per server. My point was 3rd person (and crosshair) should continue to be allowable in Veteran mode... otherwise I can't get a proper combo of difficulty options for my SP (and LAN) play-style.

Agree, please continue to allow 3rd person and crosshairs forced on/off in Veteran (as it's always been). Agree, I like the ability to show squad indicators and hide them, all-at-once or individually via a simple keypress (as we had it before the EDEN update). Perhaps add to this an option where the squad indicators fade individually with squadmate distance and are no longer visible outside a certain radius. (Again, this fading should be optional.) Sounds promising!

Wow, that's quite a tectonic shift. Many thanks for that!

Quick update, I got it working! Couple points: Turns out the animation transition glitch (described above) does not appear to be present in vanilla after all. However, I am seeing the glitch every time I run AIA Terrain Pack (with or without other mods, it's always there). If anyone else is experiencing this animation issue while using AIA Terrain Pack, good news! I now have a working patch that fixes it. [somehow in my previous attempt above, I had left out the States class in CfgMovesMaleSdr, and that was causing all sorts of strange behavior.] Anyhow, here's the updated and working "config.cpp": class CfgPatches { class MRU_AIA_AnimFix { units[] = {}; weapons[] = {}; requiredVersion = 0.1; requiredAddons[] = {"A3_anims_f"}; }; }; class CfgMovesBasic { class StandBase; // External }; class CfgMovesMaleSdr : CfgMovesBasic { class States { class AmovPercMstpSlowWrflDnon : StandBase {}; class AmovPknlMstpSlowWrflDnon : AmovPercMstpSlowWrflDnon {}; class AmovPknlMstpSrasWrflDnon : AmovPknlMstpSlowWrflDnon { //ConnectTo[] = {"AidlPknlMstpSlowWrflDnon_AI",0.1,"AmovPknlMstpSrasWrflDnon",0.03,"AmovPknlMstpSrasWrflDnon_turnL",0.02,"AmovPknlMstpSrasWrflDnon_turnR",0.02,"WeaponMagazineReloadKneel",0.1,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSlowWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPercMstpSrasWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPpneMstpSrasWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWpstDnon",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWlnrDnon",0.02,"AmovPknlMstpSrasWrflDnon_AwopPknlMstpSoptWbinDnon",0.02,"AmovPknlMstpSrasWrflDnon_AinvPknlMstpSrasWrflDnon",0.02,"AmovPknlMstpSrasWrflDnon_AinvPknlMstpSrasWrflDnon_Putdown",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSnonWnonDnon",0.025,"AwopPknlMstpSgthWrflDnon_Start",0.1,"AwopPknlMstpSgthWrflDnon_End",0.1,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDup",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDdown",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDleft",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDright",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWrflDnon_gear",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMrunSlowWrflDf",0.01}; ConnectTo[] = {"AidlPknlMstpSlowWrflDnon_AI",0.1,"AmovPknlMstpSrasWrflDnon",0.03,"AmovPknlMstpSrasWrflDnon_turnL",0.02,"AmovPknlMstpSrasWrflDnon_turnR",0.02,"WeaponMagazineReloadKneel",0.1,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSlowWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPercMstpSrasWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPpneMstpSrasWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWpstDnon",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWlnrDnon",0.02,"AmovPknlMstpSrasWrflDnon_AwopPknlMstpSoptWbinDnon",0.02,"AmovPknlMstpSrasWrflDnon_AinvPknlMstpSrasWrflDnon",0.02,"AmovPknlMstpSrasWrflDnon_AinvPknlMstpSrasWrflDnon_Putdown",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSnonWnonDnon",0.025,"AwopPknlMstpSgthWrflDnon_Start",0.1,"AwopPknlMstpSgthWrflDnon_End",0.1,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDup",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDdown",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDleft",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDright",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWrflDnon_gear",0.02}; }; }; }; Works whether you load AIA Terrain Pack first then the fix, or the fix first then AIA Terrain Pack. So my issue is largely sorted out. Still curious what including addons inside the PreloadAddons list does, if anyone has a good explanation??? [Also, obviously AIA Terrain Pack is awesome beyond belief! Many thanks to kju and all involved with putting it together.]

Searches are not turning up anything specific (enough), so I figure might as well ask. Question first, then some background for those interested in a saga. In the "config.cpp", what is the difference between including an addon inside the requiredAddons[] list, versus including it inside the PreloadAddons list? OK, some background on my current struggle. Here's the long story condensed: Recent BIS patch created an animation transition glitch for me in vanilla game while running AIA Terrain Pack. Steps to repeat: Create test mission with single rifleman as the player, and start the mission. Enter 3rd person Kneel. Observe you are kneeling , stopped, with rifle raised. (Helps to view yourself from the side, via the "Freelook" key) Press and hold the "Sprint" key. (For me it's left shift.) Press the "Move forward" key Observe animation glitch! (Imo, it's a real eye sore. If you view yourself from the side, it's even worse.) (7-10 optional) Stop, stay kneeling, and lower your rifle. Press and hold the "Sprint" key. Press the "Move forward" key Observe, smooth regular transition to sprinting! EDIT: Further testing has revealed this animation glitch is actually not present in vanilla after all. Rather it is a problem with (my version of) AIA Terrain Pack [with or without other mods present, it's always there]. If you are having this animation issue, please see my working fix in the next post down! I made an addon to fix the glitch, and it works perfectly. Here's my "config.cpp": EDIT: Don't use this fix (it has issues)... use the one in the next post down! class CfgPatches { class MRU_AnimTransFix { units[] = {}; weapons[] = {}; requiredVersion = 0.1; requiredAddons[] = {"A3_anims_f"}; }; }; class CfgMovesBasic { class StandBase; // External }; class CfgMovesMaleSdr : CfgMovesBasic { class AmovPercMstpSlowWrflDnon : StandBase {}; class AmovPknlMstpSlowWrflDnon : AmovPercMstpSlowWrflDnon {}; class AmovPknlMstpSrasWrflDnon : AmovPknlMstpSlowWrflDnon { //ConnectTo[] = {"AidlPknlMstpSlowWrflDnon_AI",0.1,"AmovPknlMstpSrasWrflDnon",0.03,"AmovPknlMstpSrasWrflDnon_turnL",0.02,"AmovPknlMstpSrasWrflDnon_turnR",0.02,"WeaponMagazineReloadKneel",0.1,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSlowWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPercMstpSrasWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPpneMstpSrasWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWpstDnon",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWlnrDnon",0.02,"AmovPknlMstpSrasWrflDnon_AwopPknlMstpSoptWbinDnon",0.02,"AmovPknlMstpSrasWrflDnon_AinvPknlMstpSrasWrflDnon",0.02,"AmovPknlMstpSrasWrflDnon_AinvPknlMstpSrasWrflDnon_Putdown",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSnonWnonDnon",0.025,"AwopPknlMstpSgthWrflDnon_Start",0.1,"AwopPknlMstpSgthWrflDnon_End",0.1,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDup",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDdown",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDleft",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDright",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWrflDnon_gear",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMrunSlowWrflDf",0.01}; ConnectTo[] = {"AidlPknlMstpSlowWrflDnon_AI",0.1,"AmovPknlMstpSrasWrflDnon",0.03,"AmovPknlMstpSrasWrflDnon_turnL",0.02,"AmovPknlMstpSrasWrflDnon_turnR",0.02,"WeaponMagazineReloadKneel",0.1,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSlowWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPercMstpSrasWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPpneMstpSrasWrflDnon",0.01,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWpstDnon",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWlnrDnon",0.02,"AmovPknlMstpSrasWrflDnon_AwopPknlMstpSoptWbinDnon",0.02,"AmovPknlMstpSrasWrflDnon_AinvPknlMstpSrasWrflDnon",0.02,"AmovPknlMstpSrasWrflDnon_AinvPknlMstpSrasWrflDnon_Putdown",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSnonWnonDnon",0.025,"AwopPknlMstpSgthWrflDnon_Start",0.1,"AwopPknlMstpSgthWrflDnon_End",0.1,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDup",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDdown",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDleft",0.02,"AmovPknlMstpSrasWrflDnon_AadjPknlMstpSrasWrflDright",0.02,"AmovPknlMstpSrasWrflDnon_AmovPknlMstpSrasWrflDnon_gear",0.02}; }; }; Apparently, "AmovPknlMstpSrasWrflDnon_AmovPknlMrunSlowWrflDf" in the ConnectTo[] list is causing the glitch, thus once it's removed everything works great! However... For some reason when using 3rd party mods, one of the addons was overriding my animation fix and reintroducing the animation glitch. It was like trying to find a needle in a haystack, but I managed to pin down the offending addon. It's in the All In Arma Terrain Pack (which has 152 PBOs), and one of those PBOs is specifically causing the override, and thus my headache: "misc_acr_c.pbo". Side note- I thought the ArmA3 shortcut mod order would sort this out, but alas my animation fix is being overridden even though I placed my fix after AIA Terrain Pack, like this: "-mod=@AllInArmaTerrainPack;@MRU_AnimFix;" Obviously, I need to rewrite my addon to account for and override whatever it is AIA Terrain Pack's "misc_acr_c.pbo" is doing to thwart my animation fix. This seems to me to boil down to PreloadAddons and requiredAddons, and here's where I could use some insight. After dePBOing "misc_acr_c.pbo", I can find these 13 addons: AiA_Misc_acr_Config CAMisc_ACR CAMisc_ACR_3DMarkers CAMisc_ACR_Container CAMisc_ACR_Dog CAMisc_ACR_Helpers CAMisc_ACR_PBX CAMisc_ACR_ScaffoldingSmall CAMisc_ACR_Shooting_range CAMisc_ACR_Sign_Mines CAMisc_ACR_Targets CAMisc_ACR_Targets_InvisibleTarget CAMisc_ACR_TestSphere CAMisc_ACR_PBX appears to be the only one that modifies CfgMovesMaleSdr (the same class my fix is modifying), so I suspect I may have found the culprit. I can add PreloadAddons to my addon in the "config.cpp", like this: class CfgAddons { class PreloadAddons { class MRU_AnimTransFix { list[] = {}; }; }; }; Overall just trying to figure out exactly what requiredAddons[] and PreloadAddons do, so I can determine which addons should go in which list (and in what order within each). So that my animation glitch fix will magically gain the upper hand and override whatever the sinister AIA Terrain Pack is currently doing to subjugate and nullify my fix. Thanks for reading. Any insight is much appreciated!

True... that may be a while though. I had a dream that Tanoa came out, and they offered Chernarus+ as a DLC for ArmA3, and Tanoa as a DLC for DayZ. Who knows, maybe that's how it'll pan out!

Many thanks cifordayzserver and all involved for the hard work. Looking forward to release. Anyone have a handle on about when this might happen for Chernarus+, based on BIS past track record? (as with how we were eventually allowed to port A1 & A2 content to A3)

Sounds pretty awesome. Most importantly, does the AI use it?

Wow, it's really heating up in here lately. Amazingly handy and straightforward, compared to parsing nearTargets, many thanks for that! :cool: countEnemy, countUnknown, etc, will still come in handy I think. Also curious, does anyone know off hand if nearTargets result comes sorted (by distance or otherwise)? Ruebe, great specific questions regarding knowledge sharing and createCenter. Always wondered about these very things. :)

Thanks oukej for the response and all your efforts. Your previous FSM comments you mention are actually what inspired me to attempt to try out the FSM-related commands. I would like to try this! Handful of clarifications (might help others with understanding FSMs as well): When we do a Loon disableAI "FSM", which FSM gets disabled? Your comment suggests this disables Danger FSM? How do we disable the Behavior FSM in-game? (You mention in your comment it's running all the time...) Which of the two FSMs get halted while a doFSM is running? Or are both halted? Regarding doFSM's halting of one or both of the unit's standard FSM(s), are they merely suspended while the doFSM's FSM runs? Or, are they actually stopped and then restarted upon doFSM completion? Also, is there any reason not to allow blocking the transition of AWARE to COMBAT modes (on a per group basis), strictly for scripting purposes? (I don't want to push it, just curious...) Thanks again. :)

This is long but near and dear to many of our hearts. Was going to start a thread entitled "Discoveries on Getting the AI to suspend default combat behavior while in COMBAT mode", but given the pitch at the end I figure posting here is probably better: I spent a couple days straight trying to get the AI to cooperate (with my scripted commands) while in COMBAT mode, and made a series of discoveries. Here are my findings. First of all, some context. I wanted to create a handful of scripts to get the AI to enter buildings intelligently (to garrison & and to separately enter to eliminate known threats vs enemy AI and player alike). Fundamental to this endeavor is getting the AI to temporarily suspend its regular cover and start/stopping during COMBAT while moving. After reading through most of the AI Dev thread, I set out to defeat this hard-coded default COMBAT behavior. A fools-errand? Perhaps, but I did learn a thing or two and I might as well share. To simplify things, my experiment involved only two units, the player (west) and an AI Loon (east). For observation purposes, the Loon is placed in Combat Mode "BLUE" (so he never fires). I monitor Loon's Ready status (via unitReady), Behaviour (via behaviour), Combat Mode (via combatMode), expectedDestination results (Position, Planning Mode, & Forced Replan), and FSM AI state (which I track and update every time I disable or enable "FSM" AI component, via enableAI and/or disableAI). Expected Destination position is monitored via a mark. Loon is ordered to move between two marked points (with sufficient cover in-between), on my command via various methods (mostly move & doMove depending on the experiment), and I watch the Loon in-game to see if he's doing the regular cover/start/stop combat shuffle or not. Note that I decided to only use a single AI in a group, to avoid the "Go, I'll Cover" mechanic of multi-unit AI groups in Combat. In my experience, that's half the battle of getting AI into buildings effectively. Again though, the regular Combat mode cover and start/stopping applies and must be overcome, even with single-unit-AI groups. OK, now to the perhaps minor, perhaps potentially significant discovery. After trying (most?) everything in the book: experimenting with forceSpeed -1, doStop, doFollow, various disableAI/enableAI components, creating my own FSM and running it on Loon via doFSM, using FSM specific move commands (moveTo and setDestination), having my FSM run quick and exiting, having my FSM run for longer (including indefinitely), regrouping Loon into new group via join, regrouping Loon into new group in combo with setBehaviour, etc... all of this in various combination based on the experiment. I learned a lot but finally: I managed to get the AI to MOVE with suspended cover & no starting/stopping WHILE IN COMBAT MODE. Here's how: By disabling "FSM" AI component via disableAI prior to the AI entering COMBAT. They still go into COMBAT mode per normal but completely suspend the cover/start/stop shuffle. This seems significant because the only other way (I'm aware of anyhow) to get the AI to move with suspended cover/start/stop shuffle is via setBehaviour "CARELESS", and in that case they don't shoot back! That's the good news. We can achieve AI movement in COMBAT mode with suspended shuffle, and they will shoot at you. The bad news is that because the shuffle is suspended, on the way to their move point, they won't stop to turn and shoot at you. So really, we need a way to turn the shuffle on and off. Fortunately at this point, doing a simple enableAI "FSM" turns the shuffle back on. Unfortunately and here's the big kicker, if you do a disableAI "FSM" while the AI group is in COMBAT and the AI is in cover, the AI will get stuck in cover and not proceed to his move point. At this point with AI stuck in cover, enableAI "FSM" unsticks him and gets him on his way (but he's back to doing the cover/start/stop shuffle). I'm sure one of you AI-savy coders can take these findings and run with it. What we really need, is a clean way to enable and disable "FSM" while AI is in COMBAT / potentially in cover (i.e. without him getting stuck). Alternately (and hopefully this shouldn't be such a major undertaking oukej :cool: ), we need another behaviour: CARELESS SAFE AWARE COMBAT COMBAT_FAST (Just like COMBAT but with cover/start/stop shuffle suspended, for scripting purposes like getting AI into buildings quickly; or rather just like AWARE with transition to COMBAT blocked, again for scripting purposes only) STEALTH Longer term, (ideally) we should be able to suspend the combat shuffle on an individual unit basis. But in the here and now, being a programmer it seems to me that "AWARE with transition to COMBAT blocked" should be relatively straightforward to implement and would make so many of us happy, and right away. Lots of bang for your buck. Lots of bang for our buck.

Yes I believe you are seeing default turn speed, and I agree it shouldn't be that way. In MP when other players turn that fast, I think it interpolates (or similar) on your end so you don't see it. But you sure see it on your own character when turning fast.