madrussian

All of this is good (optimizing, etc), but largely misses the point. I can optimize until the cows come home, but my AI scripts are hungry and will quickly use all available CPU (at the expense of each other), unless kept in check. So again, I'm basically looking for a script-based solution to determine how much SQF scripting power is in use already (at any given moment). Something like we ask it: "SQF system, how busy are you currently?" And it replies: "32% busy!" Btw - I examined all the ~40 diag commands and nothing seems to report this. Also, I do think the 3ms execution per frame is key to a solution here, just not sure how to harness it yet.

I recall having an unresponsive AI after selectPlayer to another AI. In that case, the guy that was under player control and had now reverted to AI control (due to the selectPlayer), was somehow unresponsive after that. Seems like maybe he wasn't moving at all anymore (which wouldn't be an exact match for your issue, but still could be related). Sadly I also don't recall if this was a player group thing or not. Then years or months later, I saw (here on the forums) people discussing what appeared to be my exact same problem and a solution (though of course by then I'd moved on). Something about one of the enableAI components helps to get AI moving again after AI control being bestowed upon them by way of selectPlayer vacating player control of them. I'll try to find that discussion thread. Meanwhile I did find this under enableAI description (which I'm sure you probably noticed already): Maybe instead of: bob enableAI "ALL"; Try something like: bob disableAI "TEAMSWITCH"; sleep 2; bob enableAI "TEAMSWITCH"; Or alternately, does his unresponsiveness not arise in any way from player control leaving him (via selectPlayer)? If no selectPlayer is involved in getting him unresponsive in the first place, I'm probably barking up the wrong tree.

Interesting problem. What are you doing prior to: Sounds like everything that follows are things you tried to get him responsive again? Edit: In other words, what gets him unresponsive in the first place?

Hi all, thanks for creating. I'm trying to get Intercept up and running, mostly just for fun. But I hit a snag, and hoping someone can help. Got almost all the way though "Getting Started" instructions, which mostly make sense. Managed to build "intercept-plugin-template" C++ in Visual Studio, ended up with a dll. Packed both "core.pbo" and "main.pbo" correctly (I think). Created my addon dirs correctly (I think), like this: In main A3 dir, "@intercept\addons" with "core.pbo" inside. In main A3 dir, "@intercept-plugin-template\addons\" with "main.pbo" inside, plus "@intercept-plugin-template\intercept\" with "template-plugin_x64.dll" inside. Issue happens when I launch game with these two addons (plus CBA) enabled. I get this Arma 3 message: Then upon game coming up, just to confirm I go ahead and start the editor, drop in a player unit and fire up the mission, and indeed I don't see an Opfor guy appear or follow me around, or any indication intercept is loaded. My next thought is to have a look inside "core.pbo" and "main.pbo" to try and diagnose the problem. I de-pbo both: core.pbo's "config.cpp" has: main.pbo's "config.cpp" has: ^ So all this looks correct. OK, time to fire up the game again (again with these two addons + CBA loaded) and have a look inside CfgPatches, which I examine in Config Viewer. Low and behold, "intercept_template_plugin" is present but "intercept_core" is not! The question is - Why is intercept_core addon not loading? Does Intercept perhaps require a DLC I don't own?

Cool stuff! Always something useful & creative releasing from you good man. This one is particularly unique & visceral. Will give unsuspecting players a good shock (regardless of whether it hits them or their AI buddy, or simply whooshes by). 😉

Immersive & visceral is right! Every time I watch this puts a huge grin on my face. This (and more like it) should be part of SOG vanilla. Well done j-boy, can’t wait to see what’s next.

Good idea, yes seems some tests are in order. Units often calculate quite convoluted paths to avoid enemy units though. Seems like with fake mines units may very well path closely around the desired area, which could be shaped exactly as desired. (Again, without having tried this.) Probably pros and cons in each column.

I also wonder this, from a perspective of wanting to create an area of "fake" mines to get AI to "path around" a desired area.

Great list! One quick correction, if not already mentioned... Cham is listed as Vietnam, but it's a woodland map using GM assets & actually suppose to be in Germany. Also just a personal preference, but I'd ditch the "Island" cataegory, and re-categorize all those based on geographical region like the rest. For instance, Isla Duala is definitely African, etc. Then maybe just tag all the islands somehow to identify them. Anyhow again very useful, thanks for putting this together.

First off, hats off to FOW team for their awesome mod. This is a temporary fix for those experiencing FOW mod overwriting voices of non-FOW units including IFA3 and vanilla units (which thankfully appears FOW team is working on). Works well for me so far, restoring voices for all units (inc IFA3 and vanilla units)... should work for any units. Also, seems that FOW currently also overwrites its own units’ voices sometimes, which are suppose to be mute. This fixes that too. Feel free to use this until FOW is able to provide a proper fix in their upcoming release. Without further adieu, here’s my FOW voice remedy. Works in SP and MP. Tested and working for me on both HS and DS. (Didn't test anything related to JIP.) It's fairly easy to apply. Instructions: 1. Create a file in main mission directory called “RestoreSpeakersFOW.sqf”, paste in the following and save: 2. Then in “init.sqf”, paste in the following (make sure this runs on all machines): 3. Finally, simply call this line on any set of units to restore their voices (run from server, it will broadcast necessary info to clients): Wallah, that should get all those voices back in order! Hope this helps someone for now. If it works for you (or otherwise lol), I'd be curious to know. Again, thanks to FOW team for amazing mod. Can’t wait to see what’s next! [EDIT: Updated code in step 2, to account for MRU_TT_RestoreSpeakersClientsReady being a server-only variable.]

Hi all, I've been playing around with the lockWP command, trying to understand exactly what it does and what it does not do. Quick editor testing reveals: If you lock a group's WPs (via lockWP), and then add WPs to that group (via addWaypoint & setWaypointType "MOVE"), group will still move towards its new WP. Then upon arriving at WP, even though group has lockWP true, it will still evaluate its WP condition, and still execute its WP statements. If you then move that group's current WP (via setWPPos) (which group hasn't passed because lockWP true), even though group has lockWP true, group will again move to the WP's new position, and will again still evaluate its WP condition, and again still execute its WP statements. Conclusions: lockWP does not inhibit group moving towards current WP lockWP does not inhibit evaluating WP conditions lockWP does not inhibit executing WP statements Seems the only thing lockWP does is stop currentWaypoint (index) from advancing. What I'd like to know specifically is: How to inhibit execution of WP statements? (whilst not removing them) ^ If there is currently no way to accomplish this, how about an alternate syntax for lockWP (inhibiting most or all of these things)? Bit of background:

@johnnyboy - All good ideas, man you really think this stuff through. I have it excluding player groups currently. Eventually if I can make it work with player groups, I'll try to include them (with opt in from mission creator).

Development of a PBO-based AI system, think Lambs. Only I've got a good ways to go, so not remotely ready to reveal anything. I'm not adding/using WPs, but again as a PBO-based AI system, I want this to work with any mission. People use all sorts of WPs in their missions. I don't want my system to break missions because I'm messing with creators' WPs. Thus again I'm not modifying WPs. Likewise, I don't want creators' WPs to break my system. Thus, while in "control" I'm doing my best to inhibit WPs. My system manipulates AI-only groups. (Probably not player-led groups or AI-led groups with players.) No, not a scenario. If it was I'd have free reign over all the WPs. Yes, scripting. It's all script-based. What? You kidding? Yes, it's a bit more complicated than that. Try it again from the top. Edit: Thanks j-boy, very good explanation. 😉

Good idea, yes I was considering this. Seems to me, could still potentially mess up peoples' missions though if they are counting WPs, or storing WPs as they are in format [_group, _index] and all. Also now that I think on it, wouldn't work in my existing dynamic mission Fight Back (without heavy modifications), because on various groups I'm regularly "deleting all WPs and giving them a new WP" in a new place. Makes me wonder how many other missions do that too. Seems we have competing ideas on best way to handle this: Allowing groups to potentially run WP statements while one "controls" them (i.e. not attempting any counter-measure) [sarogahtyp]: Inserting "Hold" or a "Scripted" waypoint while one "controls" group, and removing that extra WP once finished [Panther42]: Copy group's WPs (via copyWaypoints), then delete the original WPs (or set to condition "false"), then "control" group, then when done restore group's original WPs (to "continue as you were") [Hope I got the gist of this correct.] [johnnyboy via PM]: Create a dummy logic in the desired group (to keep group from auto-deleting upon joining units to grpNull), then join all units to a new group via join grpNull, then "control" that new group, and once finished join units back to original group and delete the dummy logic. So... Which would cause greatest number of problems in peoples' missions (and most severe)? And which would cause least problems (and with least severity)? Short of an alternate syntax for lockWP, seems these are the options.

Agree your test works as you state (and thanks for the help) But it doesn't really cover my core concern, which goes something like this: Let's say an AI group is moving towards its next WP, and I want to take some control over that group temporarily (like something rather complicated, using doMoves, doStops, and doFollows, but nothing to alter that group's WPs). In this case, part of my intent is to stop that group's WPs from affecting the group while I'm messing with it. At this point (while I am "controlling" the group's units), specifically: 1. I don't want the group advancing past it's current WP 2. I don't want the group evaluating it's current WP condition 3. I don't want the group executing it's current WP statement Now lets say, while I am "controlling" the group's units, that leader does somehow arrive at group's next WP. (Because I'm not necessarily doStopping all group's units all the time or anything.) In this case, lockWP will stop #1, but not #2 or #3. Meanwhile, #3 (group executing it's WP statement) could potentially really mess up what I'm doing. (If you saw what I'm up to you'd totally understand.) ^ Edit: Typed all that before your latest response. Haha, that's awesome! 😉 That's what I'm thinking.

Thanks for the responses. So, I read through carefully and agree you guys sound right on all points. Also yes, seems I should clarify my intent. In the system I'm creating, by design I'm not messing with WPs at all (aside from trying to stop group from continuing along WP positions or processing it's WP statements temporarily via lockWP or similar). My code is designed to run alongside mission creators WPs. I'm just looking for stronger way to "lock" these user created WPs, so my system is not affected by their WP statements. I get that the WP's condition is the normal way to inhibit WP statement execution, and have used WP condition "false" many times in the past to achieve various ends. Ok, I shall repeat original question & re-phrase slightly for clarity: How does one inhibit execution of WP statements? (whilst not altering WP's condition or statement, or changing group's current WP index) Perhaps there is simply no way to do this. ^ If that's the case again I advocate for lockWP alternate syntax, to accomplish this. AI creators could definitely make use of it!

Hi all, I'm transporting & unloading some AI ground troops via helicopter (piloted by separate AI group as crew) in my mission. I've done tons of experimentation with clear point selection, "TR UNLOAD" & "SCRIPTED" (with "A3\functions_f\waypoints\fn_wpLand.sqf" script) waypoints for the chopper crew, along with "GET OUT" for the cargo men. Having some good success trying this different ways. It's a dynamic mission landing/unloading men at random positions and this part needs to work reliably. My one big remaining problem is: Once landed, during the process of unloading sometimes the AI helo crew takes off and flies straight up, causing men to fall to their deaths as they unload. This used to happen all the time, until I started syncing the helo crew group's "TR UNLOAD" WP with the ground troop group's "GET OUT" WP, or alternately using lockWP on the helo crew group for the duration of the unload. With either of these measure in place, now AI helo crew mostly unloads crew without incident, but sadly now very rarely sometimes still takes off and flies straight up during unloading (again causing unloading men to fall to their deaths). So the problem still happens, just way more rarely now. Somewhere along the line, I observed this bolting straight up by the helo crew during unloading, only starts once one or more cargo guys get unloaded. I am now ~ 98% convinced, that the helo crew is taking off this way as part of it's collision avoidance mechanic, which you'll also see in the air all the time when AI piloted helo gets too close to another aircraft. Seems to me, the AI pilot flies straight up in an attempt to avoid crashing into the guy he just unloaded to the ground. I'd like to test this theory, and I'm wondering how to turn this crash avoidance off. The question: How does one enable and/or disable helicopter pilot crash avoidance? Btw - For my purposes, I'm talking about actually landing the helo on the ground (so no fastrope), and with engine remaining on for the duration. I know turning engine off might help with this, but I am bound and determined to make this work with engine on. Thanks!

Thanks guys, great ideas, (& video, and code to examine)... should get me going towards a solution. Once I stop this rare sky suiciding insanity, will report back here on which specific thing(s) broke the case.

My pal froggyluv says (via PM) I should mention I'm landing these helos in an extremely hot combat zone. So again (at this stage, now that I'm inhibiting helo from continuing along it's WPs while unloading), yes I'm pretty certain it's the helicopter pilot crash avoidance kicking in (causing pilot to bolt upwards), quite possibly when helo or pilot taking hits or similar. ^ Adding to my code now, & very hopeful this suggestion will improve things. 😉 Meanwhile, any other ideas specific to getting helicopter pilot to disable his crash avoidance mechanics? Like even in the air this might be a problem for certain scripts. Barrel bombing from helos comes to mind, or other applications where uninterrupted level helo flight is required.

Yep, tried it and wow yes it's extremely useful! (btw thanks for releasing) But iirc (& please correct if I've got this wrong) HAS is for moving player groups around. Of course there are big differences when you want to move AI (like far more than meets the eye). Glad you got it working so consistently. I've been placing my helipads at exactly getTerrainHeightASL. Should they perhaps be up a certain small amount?

Nice, really great summary. Let's see... I'm currently using helipad. Also in my case attaching helo crew group WP to helipad via waypointAttachObject, which I'm hoping forces particular helo to choose that exact helipad, for cases in which several helipads are close together. Not totally sure waypointAttachObject works this way, but overall seems to do ok. This sounds very streamlined & promising. Haven't tried this exact combination yet. I'm guessing you'd have to also control helo speed to make sure he doesn't totally overshoot helipad (having to boomerang back around), based on my experiments with the "SCRIPTED" WP (with "A3\functions_f\waypoints\fn_wpLand.sqf" script) & otherwise land command by itself. I seem to recall using disableAI "ALL" (on pilot) and still having helo bolt straight up during unload. But that was before I was inhibiting helo from travel to his next WP (via syncing helo crew group WP together with cargo group WP, or lately instead using lockWP on the helo crew group). Anyhow sounds promising, will try these exact disable AI with what I've got currently. In my case, created an expanding clear / flat (within threshold) point selection routine, spawned and which increases nearestObjects radius at same additional area per cycle (the goal being no impact on fps). Seems to be super reliable, but can't always find a point in densely packed areas. Never thought about automatically cutting down the trees! @pierremgi - Curious in your landing/unloading system, (as far as you can tell) were you able to totally eliminate this upward helo bolting (aka "falling man syndrome")? Or for you does it still rarely happen like I'm seeing here?

Hi, I'm using cursorTarget to detect when player is aiming at an enemy AI, and having that enemy AI react. Working well so far, currently AI is reacting any time player points cursorTarget at him. However, turns out I only want reaction when player is pointing weapon at the AI. I checked out weaponLowered command, which is useful but not right for this purpose. Turns out, weaponLowered is really checking the state player enters when pressing the "Toggle Raise Weapon" key. What we need is something more like "weapon cursor displayed". So for instance, when player is stopped, weapon cursor is normally displayed. Then as soon as player runs or sprints, player weapon is lowered slightly (while moving), and weapon cursor disappears. Then as player presses the "Combat Pace Toggle" button, even while moving (non-sprint), player raises or lowers gun slightly and the weapon cursor appears and disappears. Ok, the related questions: How to detect when "weapon cursor displayed" (or not displayed)? How to detect "Combat Pace Toggle" state? ^ If it turns out either or both of these are impossible, what's the best workaround? Thanks! Edit: Also, curious if there is an equivalent to cursorTarget, but for where player's weapon is pointing?

That would likely work and I did consider this. I always dislike parsing animationState though, as it seems like whatever I do misses a bunch of important cases (because there are sooo many of those animations). Like for my current purpose, I don't think find on "sras" will catch while player is healing, etc. Checking disableWeapon in the config, on the other hand (at least for this), seems to catch every single relevant case I can think of. Also, checking disableWeapon is likely way less expensive CPU-wise, and I've got to call this on a short loop that's always running. Seems like find on a long animationState string has to do a lot of checking (at each position in whole string). Anyhow, yes good idea. 😉

Thanks guys, really good insights. I just took a closer look at both of these (in 3rd person using free-look & looking around): Standing still, cursorTarget seems to get the object your weapon is pointed at, whereas cursorObject seems to get the object your player camera is looking at. Also turns out cursorObject is very precise, in terms of the cursor ray hitting it's target. Miss by a smidge and it returns objNull (or the next obj behind). On the other hand cursorTarget uses a "softer" more forgiving detection. Then like you said cursorObject has ability to get unit's weapon, whereas cursorTarget does not. Both are no doubt extremely useful, depending on what you're looking for. Seems like for this purpose... I probably want cursorTarget. Wow, totally nailed it! Just tested out & seems to work perfectly in all my relevant cases. I was off on a big-time tangent, lol measuring the angle between the camera dir and weapon dir, which was turning out to be very expensive CPU-wise (using 5 vector commands plus aTan2 every time). This is waaay better!

Adding Global Mobilization support to my dynamic mission (inching forwards towards release, at this pace hopefully within one week now!) Upon startup, my mission scans the configs and lets you pick any faction for player, player support faction, enemy faction, etc. (Kinda like Dynamic Recon Ops, where I got faction selection idea though my mission is totally different than DRO.) I use configfile >> "CfgFactionClasses" >> _faction >> "flag" to get the flag textures. Some faction classes have a flag entry, some don’t. When flag texture is not present, I borrow flag textures from configfile >> "CfgMarkers" >> _type >> "texture", where appropriate. (Many nation’s flags are in there.) With GM factions selected, setFlagTexture is called on these GM textures and I was getting an error “Picture \gm\gm_core\data\flags\flag_ge_co not found”. I checked the config and all the GM faction flag entries have a format like this: With vanilla factions (and all mods’ factions besides GM), the entry looks like this: Seems GM’s faction flag entries are simply missing the “.paa” at the end so I tired adding it, but still getting the “Picture not found” error. Anyone know if these GM faction flag entries are just bugged? I would simply look inside the GM addons to see what’s going on, but I can’t because (again) they are EBOs (encrypted PBOs)! So I thought better head to GM Discord and ask team, but I’d rather not bug em until I exhaust all options. So I checked inside "CfgMarkers" to see if there are suitable flag textures in there. I need West German, East German, and Danish flags. Turns out, in here GM has good flag paths (with ".paa") for Austria, Bulgaria, Finland, East Germany, Romania, Sweden, Turkey, and the Soviet Union. Which is awesome because it looks like GM devs are planning on expansion! Now, good to go for East Germany ("\gm\gm_core\data\flags\gm_flag_GC_marker_ca") and Denmark (“\A3\ui_f\data\map\markers\flags\Denmark_ca.paa"), but still nothing for West Germany. So now I am using "\A3\ui_f\data\map\markers\flags\Germany_ca.paa" (modern flag?) for West Germany as a placeholder, but it looks pretty silly for 1980s and would much rather have actual West German flag texture. Here are the quick questions: 1. Anyone know how to make "\gm\gm_core\data\flags\flag_GE_co" work with setFlagTexture? 2. Otherwise, anyone know path to West German flag texture (with ".paa")? I welcome any and all help, inc simple things I may have missed, thanks.