madrussian

So... I have an array of obj types, and I want to remove all elements for which the obj type is a man. For my particular application (building path-finder), this bit of code needs to be fully optimized. In other words, every little nano-second counts! My code currently looks something like this: _objTypes = _objTypes select { ! ((typeOf _x) isKindOf "Man") }; Any way to make this run much faster? Specifically with any of the newer A3 scripting commands? (Btw - Seems most soldier types have a lengthy parent hierarchy, so that's what got me thinking so hard on this.) Thanks!

@gc8 Correct, good catch. Thanks guys, ok isKindOf it is then!

Great explanations nKenny. 🙂 I do wish my Building Utilities system to work both with and without Lambs. Thus perhaps the need for a more general solution (for when not running Lambs). For this I'm thinking simply a (lightweight) copy of vanilla danger FSM with the passthrough functionality. Or... I could just require Lambs and spell out how to disable Lambs (during which time Lambs running for the passthrough-only)... for when folks would want that. As for when Lambs intended to be running (which of course is most of the time!): This sounds promising & very doable. I'd really like to get this working with EHs and not looping polling scripts though. By "extend the codebase with an eventhandler", are you talking about BIS devs adding those missing EHs to the game? Or (can anyone think of) some way I can access "lambs_danger_FSMDangerCauseData" (unit) variable via an EH? Like similar to addPublicVariableEventHandler, but for getVariable/setVariable variables set on units? If not... @nkenny What do you think about adding extremely simplified passthough to Lambs so we can detect these danger causes as actual events (via BIS_fnc_addScriptedEventHandler)? Again this would only apply to flagged units, via: _unit setVariable ["lambs_fireDangerEvents", true]; or something like that. Seems to me performance impact would be quite minimal, as it's one quick var check. If unit flagged, lambs fires a danger event via BIS_fnc_callScriptedEventHandler. (Obviously if no units are flagged, no scripted events are fired.) Would help me tremendously (and I think many others). Anyhow, regardless these are exciting A3 times. Thanks again for Lambs and all your hard work, for which we all benefit so much. Also, everyone please stay safe (and keep your loved ones safe too), with this virus rampaging about. 🙏

I just had a major lightbulb go on! Seems like many of us could use a passthrough FSM, that runs the vanilla FSM but first passes the danger info via BIS_fnc_callScriptedEventHandler for all desired units. Something like: _unit setVariable ["FSM_WatchFeed"]; And then one for Lambs as well (for when running Lambs), something like: _unit setVariable ["LAMBS_FSM_WatchFeed"]; Then we can track: params ["_affectedUnit","_dangerCause", "_dangerPos", "_dangerUntil", "_dangerCausedBy"]; ... and possibly _queue too, all via BIS_fnc_addScriptedEventHandler. But again only on desired units, to keep performance up to snuff. I really need this capability for my upcoming Building Utilities, because I'm using forced movement via playAction through buildings (technique learned from master @johnnyboy). Specifically I need to detect various danger events so I can stop my building unit and let him shoot back. (DCCanFire, DCBulletClose, and DCExplosion will be particularly useful.) Anyhow, I don't need/wish to create a whole danger FSM, just need the danger events from a passthrough FSM. I will likely (have to) try my hand at this for vanilla. Otherwise, if something like this exists already, please point me in the right direction, and I'll buy you 🍕. It's a real shame that BIS didn't allow for changing the Native FSM on-the-fly. Btw- Curious how many of you have messed around with these danger events? Here are some quick observations (from my limited testing so far): DCCanFire is super handy. If I pop back and forth from around a corner (in and out of view of the unit), this fires quite reliably. Before discovering DCCanFire, I was about to write all this same functionality using lineIntersectsSurfaces, knowsabout, etc. How dreadful that would have been to reinvent the wheel (not to mention how costly in terms of performance impact). DCBulletClose (bullet flying through the air, passing by unit) is also a big winner! Would be highly unreliable and taxing to do via script (via fired EH, and tracking projectile, measuring distances from units, etc). Conventional explosions fire DCExplosion (as expected), but if you shoot the ground right next to the target unit, DCExplosion will fire then too. Odd, but quite useful. I can't seem to get DCDeadBodyGroup or DCDeadBody to fire, even killing off a slew of same-side units (via setDamage 1), and then having my intended unit walk around the corner. These events don't fire, and he doesn't seem to discover them. Overall, seems like anything that would make these danger events accessible to the scripting masses (like passthrough FSM), would be mighty fine. 😄

OK, just tried that and worked great so far. Thanks! Going to see if I can get all these events(?) to generate: This seems so powerful and apparently goes way beyond the normal set of addEventHandler events.

UPDATE: OK, got the path working! Removed the leading '\' on each fixed the issue: But now getting an error when my FSM fires. My FSM is pretty simple so far (5 items): Start State -> True Condition -> State -> True Condition -> End State In State item, I have a simple hint command: hint "Danger!"; Otherwise all items are empty. OK, when I shoot an AI and my FSM fires, I get this error: I'm thinking the error might be due to saving my FSM using the wrong compile config. I compiled using "entityFSM.cfg", but probably it was suppose to be one of the others? Here they are (again): So which one should be used for Native FSM? Thanks again!

Thanks, that's definitely the way to go with WPs etc and helps so much! This gets my vote. Seems Lambs AI don't particularly adhere to tenant of "AI leader moves to his WP, then stay there". (Perhaps vanilla AI don't 100% either, but seems Lambs much less so.) Certainly some way to force them to at least try and stay would be extremely useful. Seems leveraging 'HOLD' WP would be just the thing. I've got some good insight one area of (Lambs) "lack of squad cohesion" issue: Seems often the group leader is going at full speed, while all his (potentially many) subordinates are at walking speed. In this case leader gets WAY out front of his men. When I run up and call "_unit forceSpeed -1" on various subordinates, each of those guys returns to full speed and catches up to group leader. This is all with the group on speedMode "NORMAL", so leader should be slowing down for his subordinates. Anyhow this explains (at least partially) why previously when playing with Lambs, seems like I was very often coming up against one enemy at a time (in this case the group leader which left his men behind). Pretty sure subordinate slowness is happening with "_group enableAttack false" as well. In any event, doesn't seem to have to do with them going after targets or anything (although they may know about targets, as they did automatically enter Combat mode). More details on this: Thanks again for your efforts! Please keep going. 🙂

Thanks, I spent a ton of time on those Bombers trying to get them perfect. Or at least perfectly believable. 🙂 (Pretty surprised, but you might be the 1st one to mention them.) OK to target an enemy vehicle, it should be pretty straightforward. Get your bomber support ready via 0-8-X. Then simply put your reticle (or whatever you want to call it) on the vehicle, and press 2 to "Call via LOS". This can be kind of challenging when the target is moving and/or at a distance. Binoculars can help. Also, you do have to have "Allow Player Targeted Bombing" enabled in the difficulty settings, or they will just target the ground instead. (Also to see the reticle, you need "Show Support LOS indicator" on in the Client Settings.) Or did you have another issue making it work? Btw- These bombers will try and hit moving targets too! Once I got this ability up and running, I had to tone back their accuracy on moving targets somewhat, because they were just too dead on. 💥 Now they can miss too, depending on a number of factors (mainly how hilly it is). Hopefully not too long now frogman. 🐑 Details:

We are having so much fun with your mod and it's such a game-changer! Many thanks for all your hard work and please keep going. @nkenny I'm trying to get my dynamic mission playing well with your mod. Handful of questions for ya: I like your "Hide" mode (and thanks for the recent option of disabling it completely), but I'd like a bit more control over how long groups are hiding out. I figured out (more-or-less) how to reassert control of groups by temporarily placing them into forced "AWARE" behavior. The only thing left for now is to detect when groups are in your "Hide" mode via script, so I can get them moving again periodically. Do you guys store current mode in a group or unit variable? (or similar?) Hope that makes sense. Is it possible to disable hiding on a group by group basis (via script)? (<- If not, I humbly request this.) Any way for mission creators to place a combat group into a LAMBS mode (like "Assault" or "Hide") via script? Do you guys ever move or delete group waypoints? (Specifically, do you ever move or delete WPs that mission makers place in editor or that we add via script?) In short if we add WPs, are they subject to LAMBS manipulation? Btw- I read and watched most (but not all) of the thread & videos, so sorry if some if this got answered previously.

@Mackov All that sounds really good. Hoping to check out C2 soon, and yes would like to create more scenarios (where players can win or be defeated)! Deep inside the guts of my mission right now trying to gets LAMBS to play nicely. Their "Hide" order (behavior?) is great, but it's really bogging the enemy down here, so working on a remedy. Also finding some brand new ways to keep the enemy moving (inc setBehaviourStrong command, which is really proving it's worth).

@Mackov Thanks, glad you like it! I just watched a couple videos, looks to be extremely useful & powerful. Should be OK, since seems it only affect your own squad. The only part that might conflict would be its markers overlaid on the main map might look strange on top of my markers. Anyhow, looks so useful I'll probably try it out myself tonight. Also if you try it out, please let us know how it goes. I recall someone on Steam pointing out some hick-ups playing with ACE. Seems like they had to die once at mission start to be able to do specific things (like re-enlisting fighters? or perhaps enlisting them to begin with?) They talked like it was a minor annoyance, otherwise fine. So I didn't worry about it too much at the time (b/c busy fixing other important bugs, etc). Anyhow, feel free to playtest with ACE and report back anything you find, and I'll see what I can do. Yes in terms of achieving Total Victory, mission can be pretty hard! After playing hundreds (perhaps over 1000?) times, we win often now (perhaps 3/4 of the time), but in the beginning it was more like seeing how long we could last. Early on, setting yourself more achievable goals is probably more fun, like drive enemy's "Overall Power" down more than ever before. Also, quick hint for anyone who might be intimidated by enemy's starting "Overall Power" (~190-200): You don't need to get them down to 0. Their breaking point is far far above that! Trust me, fight hard enough and they will break.

Sure thing, hadn't tried those two terrains yet. OK, I checked them out and yep very nice indeed. Looks like GOS Gunkizli will work, but unfortunately not GOS Dariyeh because it doesn't have any roads. At present, mission only introduces enemy onto roads (in trucks & transports), so if a particular map is (even mostly) devoid of roads, it probably won't work very well. At some point, I'd like to give the enemy helicopters and air transport ability (mostly to mix it up with the current ground transport, but also for road-poor maps). Anyhow yeah the whole "only on roads" thing was kind of an oversight on my part, because there are some really great wilderness maps out there. I hear you. Personally I like getting thrown into the mix and having to make due. Because when I'm given the ability to pick, haha I simply can't help myself and go for the best weapon out there. Let me spend a bit of time and see how easy this is to add, though it would probably be more for like a special modded version. Good wish! I'm glad someone finally asked. So I happen to be in the middle of an absolutely massive (& hopefully transformational, definitely cryptic) project, but after finishing/releasing that one (with a little help from my two best A3 buds), perhaps trusty old MRU Squad Commands can be next. For now you might be in luck. That system (voiced squad commands) is super portable. So I could give you some relatively simple instructions to add them to whatever mission you are playing. It's basically just copying the "MRU_GroupCommand" folder into your mission folder and adding a line or two to the mission's "init.sqf" file. So yeah, let me know if you want to try it. Haha, I drive like a maniac (in this game) too. And I waste my supports all the time, wishing I had them back. On the flip side, the moment my dad sees an enemy he gets this total tunnel vision, and completely forgets his supports. The only time I can get him to use them is when the enemy are just standing there oblivious & extremely far away. Hey thanks for saying. I'm glad someone is enjoying it as much as I do. Yeah it did take forever, but I learned so much in the process. (^ from his PM) Collection is a good idea, let me look into it. I actually wish I combined all the missions into a single addon, because it would be soooo much easier to do an update. At present, I have to upload 52 times to Steam. It might be a gigantic effort to combine all of them though. Important - If anyone is having trouble posting here, please alert me via PM, b/c Voronwe's last post (now seen above) somehow needed mod approval (and took a few days to pop up). Plus I have the same issue everytime I update the 1st post. Anyhow he reached out to me via PM and I've been able to answer his questions, etc that way. About that next update... I've already added a bunch of important fixes (internally). The ones I think people will find most useful are: "Allow Enemy Armored Transports" setting was way busted (i.e. not in the player's favor), now totally fixed with options for "On", "Off", and "On" with 5, 10, 15, 20, 30, & 40 minute delays. "Restore Weapon Cursors" optional setting (mostly for playing with IFA3 b/c they omit all the vehicle weapon cursors) was causing the new cursor to jump around. Now fixed! If anyone would like a current update (with those 2 important fixes above plus partial LAMBS compatibility), tell me which map(s) and I'll upload you the partial updates asap (like hopefully within a day or two of your request). Once I get the rest of the intended fixes in plus total LAMBS compatibility (which is perhaps 1/2 finished as we continue to play test), I'll update all 52 maps, though no ETA presently on that... Also if you want new terrains, just say so and I'll have a look. @Voronwe Just finished up Virolahti, check your PM. 🙂

@Voronwe Wow, very nice review & thanks for playing! Really great description, that totally sums up how I feel playing it! Curious, are you talking about the in-game Skill and Precision settings, or something else? Awesome, yep that's exactly what I was going for. You totally nailed it. If you had genie & 3 wishes... what would you add? Next update will definitely include LAMBS compatibility and a number of new maps, including Cham, Virolahti, Winter Hellanmaa, and more. (Playing with LAMBS now slows the enemy to a crawl, because the enemy keeps going off track, but I know how to get them more fluid again.) Update is taking a long time, because I got distracted by a Bigger Fish. Plus most everything here working great already, so no huge pressing bugs, etc. Also, I checked those beautiful victory screenshots. Well done! Haha I noticed you left so many supports on the table (inc 3 bombers). My dad always does that same thing when we win. Btw- Have you played in co-op yet? With those limited lives and having to rely on each other to survive, it can get pretty intense.

Good deal Elgin675, glad it's working for you.

Bravo j-boy, another glorious & eye-popping script to the ever impressive heap! Ok, I'm off to throw knives at some A3 goats and sheep...

That makes good sense. Hope I got the gears turning and this becomes a reality! Roger that, after another playthrough or so I should be able to give some better feedback on warehouse capacity and if storage values make sense currently. I do know I always had plenty of food and was never worried it would run out. ^ You are touching on an area I think could be expanded/tweaked to increase immersion exponentially. Few (constructive feedback) points: 1. Indeed, early on I felt like I was finding a civ in pretty much every building. Unfortunately, this felt very mechanical and wasn't very immersive. I'd rather get fewer civs early on per day. 2. Finding food, weapons, and materials in buildings "virtually" as implemented currently is a reasonable abstraction which I found to be immersive enough. However, I'd rather see actual civs out there in the world, hunkered down in buildings and similar, that I can tell about my settlement, and via action or similar actually see them head off direction of settlement. Then when I get home (depending on how long I took) perhaps they are all there ready to be assigned. Having the civs out there in the world would also increase exploration dynamics, as the civs would be vulnerable to bandit and aliens, etc, and perhaps tip the player off that enemies are nearby. 3. I think it would be better immersion-wise to find a civ here or there (sparingly), and then every once in a while find a batch of civs all at once. Player would get a great discovery moment! Again especially if the civs are actually present on the map. 4. If squadmates are eventually implemented -and- finding actual civs in world implemented, a huge plus would be an option to join them to squad right then and there (if desired). Then they can come along for the ride/hunt! ^ These are just some initial impressions & ideas. I know how tough this stuff can be to actually implement.

Thanks, roger all that! I know it might be tough to implement, but Squad AI would extend exploration fun factor by ~10x (for me anyway) so it might be worth it. Regarding heavy calcs, maybe just cue their radiation directly off what player is experiencing? Or give them a "lite" version of the calcs? So in my couple playthroughs so far, I built exactly one warehouse (in the beginning), and played for many "days" and accumulated many civs. I had something like ~25 civs ~120 food, ~110 ammo, and about ~120 materials. But I never noticed any impact from not having enough storage space. I could always store enough of everything. Seems I should not have been able to accumulate all that food, ammo, and materials with only 1 warehouse. Perhaps something was bugged?

Hi Rydygier, been playing the past couple nights. Great idea, well executed! Quick questions. Any way to get guards (or any AI) to join my group, at least temporarily? Like say "You 3 guards, follow me", and then later return them back to regular guard duty (should they survive the excursion). Or maybe it would be a new job for them, like placing them on Squad Duty, or similar? Also not clear on what Supply count does? I have been assigning most civs to build materials, in an attempt to house them all. Does building the warehouses somehow help increase my materials production? Btw - I read the whole briefing but not this whole thread (yet).

I think I maybe experienced exactly what you are talking about (after quick skim of thread). Here goes: A while ago with lineIntersectsSurfaces, I noticed using specific combinations of "FIRE", "VIEW", and/or "GEOM" in a single lineIntersectsSurfaces command, gives a very different set of intersect points than calling lineIntersectsSurfaces multiple times with the exact same set of "FIRE", "VIEW", and/or "GEOM" individually. In other words, contrary to intuition: _allIntersections = lineIntersectsSurfaces [_posASL1, _posASL2, objNull, objNull, true, -1, "VIEW", "GEOM"]; is absolutely not equal to: _intersections1 = lineIntersectsSurfaces [_posASL1, _posASL2, objNull, objNull, true, -1, "VIEW"]; _intersections1 = lineIntersectsSurfaces [_posASL1, _posASL2, objNull, objNull, true, -1, "GEOM"]; _allIntersections = _intersections1 + _intersections2; ^ Btw - These are not just unequal order-wise... you don't even get the same set of points back. In my building scanner for instance, for almost all buildings I can use VIEW + GEOM together in one lineIntersectsSurfaces command, and the floor detects just fine. But in certain buildings like "Land_Helfenburk", I have to use VIEW alone in one lineIntersectsSurfaces command, followed by GEOM alone in another lineIntersectsSurfaces command. (... Or else it fails to detect the floor) Hope that helps.

Wait, you might have me mixed up with someone else. My code usually ends up quite loopy. Good deal, looking forward to it! One thing I noticed when creating MP, is that locality sometimes (often?) matters, even when the wiki says it shouldn't. Especially when you're trying to time things on different machines (with attachTo having it's own set of peculiarities). Then often the thing causing MP hickups turns out to be some command you least expect. Thinking yours is probably fine, but curious to check it out.

How visceral and entertaining, well done j-boy! Thanks for all these great scripts, can't wait to see what ya come up with next. Maybe I missed some details, but is this just for AI or could player units be the winner and/or loser too? Also, how MP compatible is it? (Curious, which machine to call it on if winner and loser are local to different machines.)

All that sounds good. Just to clarify, by revive I mean that upon wounded player lies there incapacitated, waiting to be healed by another player or friendly AI, etc. If our mission isn't using revive, for example if we have description.ext set up like this: or like this: And then we play our mission with your "All-in-one Command Menu" and "Super AI" components, incapacitation/revive (or some form of it) won't suddenly start happening, correct?

@Leopard20 Good talking with you over PM regarding building path-finding, etc. What you are doing is incredibly inspiring, albeit kinda crazy. I'm totally pulling for you and eagerly await your Super AI. Quick questions. Will it be possible to completely disable whatever you are doing medical and/or revive system wise? My dynamic mission is not at all compatible with revive or similar (as I have my own custom "group linked respawn" in place). Also while I know revive has many fans, imo the vanilla way of simple healing via health pack is important and has it's place too. For instance as a basis for building one's own respawn system on top of, or for people who simply don't care for revive, etc. Also, really hoping we can turn Super AI on and back off (reverting to vanilla AI) for any desired set of units (friendly or enemy) on-the-fly via script command in a clean way. Like without any unfortunate unforeseen consequences (for example them getting stuck), etc. Will this be possible? (^ Having said that, I realize if we enabled Super AI on them and sent them into a building, we would no doubt will need to get them back outside again before switching them back to vanilla AI.)

Hi all, I'm getting crash with 0xC0000005 STATUS ACCESS VIOLATION under very specific conditions and could use some help thinking through solutions. The problem happens for me when playing my dynamic mission with certain factions selected, specifically IFA3 factions. (In my mission, you select the factions you want to play with at the beginning, which are scanned from the config.) I've never had this crash playing with non-IFA3 factions. So yes, various IFA3 faction selection combinations can cause it but one in particular makes it happen much faster: Player Faction: Fallschirmjager - Sicily Secondary Resistance Faction: Fallschirmjager - Battle Gear Support Equipment Faction: Sturmtroopers Civilian Faction: 40s Civilians Enemy Faction: US 2nd Ranger Battalion Additional Enemy Vehicles #1: US Tank Troops Additional Enemy Vehicles #1: US Army Mission usually takes about 50 minutes to play (or less), and the Crash occurs seemingly randomly usually about 30-40 minutes in. Crash does not seem to occur in a particular place in my mission code (based on inserting hundreds of diag_log commands). In SP crash is frequent but on DS crash is pretty much an absolute certainty (Client or Server will crash, one or the other). So when testing this I mostly run my mission on DS, so if I come across something that helps, it will be obvious (due to lack of crash). When reading about 0xC0000005 STATUS ACCESS VIOLATION error online I noticed someone saying when they switched from a 1920x1080 display to a 2560x1440 display, they started getting this error. My monitor is 2560x1440 (165hz capable with G-Sync, etc), so of course I normally run in this resolution. So I tried playing in 1920x1080 and crash hasn't happened yet (but I only tried that way a couple times). Playing in 1920x1080 is not a long term solution for me, as all my displays are 2560x1440, and importantly seems likely people playing my mission in 2560x1440 with IFA3 factions are likely getting these crashes too (considering I'm getting these crashes on at least 2 machines). I've messed with A3 Launcher settings to see if that changes anything, with very limited success. I normally run Platform at 64-bit, but I tried running at 32-bit and this does not help (game still crashes). I have 16GB of physical system RAM and 8GB of physical VRAM. If I set Memory Allocator to "Windows allocator (system)", System Memory Limit to 10240, Video Memory Limit to 8192, and enabled Large-page Support, (and play on fresh PC boot in non-windowed mode and never alt-tabbing out of the game as precautions), this seems to help and I can usually get an entire 2560x1440 playthrough done on DS (which is pretty astounding at this point). But here's the kicker: On the subsequent DS playthough (played directly afterwards without leaving game), it crashes with 0xC0000005 STATUS ACCESS VIOLATION every time (not right away, but much sooner than normal). During my mission development, I encountered 100s, perhaps over 1000 difficult issues, some of them complete and utter brain-benders. Through force of will and persistence, I solved them all (or at least understood and mitigated them). This issue is different (as it's a generic memory error), and has me totally flummoxed. (Plus with this, it's hard to test various remedies b/c basically you have to play mission all the way though and win which takes an hour each and every time, to know if each new remedy worked or not.) Questions: 1. First and foremost, anyone have insight on preventing this crash? (Btw - I kept all my crash logs: rpt, bidmp, and mdmp for each crash.) 2. Anyone aware of script commands that can cause 0xC0000005 STATUS ACCESS VIOLATION (presumably if used improperly)? 3. Curious, does 0xC0000005 STATUS ACCESS VIOLATION mean that another program is stomping on A3's allocated memory, or the other way around? 4. I'd like to disable IFA3 scripts, to see what the culprit is (my code vs IFA3 code vs something else). Any way to do this? Even if it's hard and/or would involve me creating a giant test addon, I'm game. 👍 Thanks for reading. I welcome any and all help, even simple things I may have missed. 🙂

Quick update, I'll be away from my gaming PC for next 1.5 weeks. Will run those US tank sound muting tests when I get back... Also for those following along, Dedmen responded (today) via PM about my latest 2 SP crashes. First was "checking ammo while reloading a magazine", same as before. Second was in audio processing. Thanks @Dedmen. 👍 Now I'm really wondering, if the "bad US tank sounds" are causing the audio processing crashing.