Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

331 Excellent


About madrussian

  • Rank
    First Sergeant

Profile Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Looking for an outcome, not necessarily an answer. Just got a good outcome here (in "Mission Editing & Scripting", and btw wasn't really expecting anything), so I figured I'd give these a shot here too. Anyhow, good points/suggestions.
  2. I'm knee deep in development of an AI mod I believe many of you will find truly transformational. Rather than show videos, provide lengthy descriptions, etc, I'd rather simply focus my time moving forward towards completion. Please take me at my word - If I manage to complete everything, the reward will be worth the wait. A very brief description would be - Automatic Navmesh creation (covering entire map) Pathfinder (implemented in C++) Innovative new way to move units around (allowing strafing, etc) Advanced use of Buildings & Cover Here's what will help my effort the most right now: _unit doMovePath _path - Engine will pre-check the user-provided path to see whether engine can perform it (considers slopes, etc). If the path checks out, engine proceeds to move unit along the path using exact same mechanics as doMove. Returns true if it worked and false if not. "PathCalculationStarting" event - Different than existing "PathCalculated" event, as this one happens just prior to the engine's normal path calculating attempt, and gives option to prevent the path calculation from even starting (in other words aborting path calculation), by handler returning false (instead of the normal true). Parameters provide path's intended start and end positions. With these two new capabilities (EH and command), creators could easily intercept engine path creation and substitute in their own highly efficient (C++ produced) paths, saving enormous amounts of CPU and preserving what I like to call precious SQF bandwidth. Curious, how feasible are these and might we see one or both eventually? Quick speculation: Meanwhile, big thanks to the devs (plus anyone else who had a hand) for these absolutely amazing recent AI related (2.10) capabilities: Finally this bit:
  3. That sounds splendid, many thanks. 🙂
  4. Thanks, very good to know this definitively. 🙂 I checked out your blog entry. From entry: I'm definitely experiencing pain in the butt from restarting A3 over and over. Your tool dlls look extremely useful, but probably won't help me much in this case, because I'm in-game visually analyzing a bunch of 3D markers generated by my C++ code. So I do need the game up & running, and the actual A3 callExtension dll connected up. Also as you point out in your blog, freeExtension is a command you wish were included in the actual game (but unfortunately isn't). Anyhow, my last two questions stand. I'll re-phrase them a bit to be more specific: 2. If one needs/has actual A3 running and calls callExtension dll (via callExtension command) from A3, is there any particular reason calling LoadLibrary (from within aforementioned callExtension dll C++ code) to a separate dll shouldn't work? ^ Specifically, I'm trying to figure out why my callExtension dll's LoadLibrary call is returning a NULL pointer. (Whereas this very thing works perfectly in my exe -> dll -> dll test code.) Again, I'll post my A3 callExtension code and seperate dll code (and/or my test code too) if someone cares to take a look. 3. If one managed to make this work (see #2, again running actual A3 calling callExtension dll via callExtension command which then calls a 2nd dll via LoadLibrary and GetProcAddress C++ calls), anyone know if that 2nd dll will simply end up "locked" as well? (like callExtension dll always ends up "locked" upon being called 1st time by A3) By "locked" I mean unable to be deleted/replaced until game exit. If that 2nd dll can indeed be called, but is destined to directly end up "locked" too (unable to be deleted/replaced), I might as well just give up on this idea now and try something completely different. My pal @johnnyboy recommended a queue [callExtension dll communicating to/from another app like an exe (console or similar)]. Thanks again for the help. Just trying to figure out how all this works. Also, thanks @killzone_kid generally for your blog. It's helped unstuck me more times than I can count.
  5. I'm writing an A3/C++ interface for my (crazy) AI mod, using callExtension. Noticed something that's slowing down my dev effort, namely that as soon as you callExtension on a particular dll file, from that point on that dll file is frozen until the game itself is exited. Meaning that called dll can't be deleted (or thus rapidly replaced). So every time you make a C++ change, unless you go to some extra lengths, you must restart the game to try out changes to your dll. It is of course possible to keep copy/pasting in your new dlls and renaming them (while keeping the game open), and correspondingly change your callExtension calls within A3. Anyway that's super finicky, and I'm wondering if there's a better way. Question #1: Is it possible to tell A3 to release control of a previously called dll? (without exiting game) Meanwhile, I had the idea of having my very basic callExtension dll just call another dll with all my important code in it. My idea is, even if A3 locks down the callExtension dll, maybe other dlls called by that dll remain free for deletion/replacement, etc. I read up on run-time based dlls and set up 3 test projects in VS: One exe and two dlls. Basically my test exe gains access to my 1st dll's function (during runtime). That 1st dll's function then gains access to my 2nd dll's function (during runtime), which returns a result. So on my test exe's console, I see the correct result from my 2nd dll, proving that this mini chain works as expected. (in my test environment anyhow). In this working example, my exe is analogous to A3, my 1st dll is analogous to callExtension dll (which remains locked upon calling), and my 2nd dll is analogous to the dll that we wish to remain unlocked (and thus deletable). Armed with this small victory, I tried to duplicate this result with a new A3 callExtension dll and a separate dll (both containing minimal test code like before). I did everything the exact same way as before (for all practical purposes). Fired up the game and called callExtension. But unfortunately so far, it doesn't work. I can tell based on the callExtension return values (which I set up for various outcomes). Upon investigation, my LoadLibrary call (in my callExtension dll) to my separate dll returns NULL pointer, so I'm stuck there. Question #2: Any particular reason calling LoadLibrary (inside your callExtension dll) to a separate dll shouldn't work? Otherwise, maybe I'm just doing this wrong. In that, case maybe I'll post my simple test code and see if someone can point out the flaw. Question #3: If this idea should work, anyone know if that separate dll will end up "locked" (until game exit) as well, making all this a fool's errand? Anyhow, thanks for reading and thanks in advance for help. 🙂
  6. madrussian

    Controls issue (please help)

    Ok, I had a minute to try Reforger again. I put all controls back to default just for testing purposes, and confirmed that both "Toggle perspective" and "Aiming down sights (toggle)" work as expected. The thing is, I will never play this way. The first thing I do with any new game is go set up my keys. I tried remapping "Toggle perspective" to several other keys (one at a time). All other keys (that I tried) have same original problem (see above), where camera flinches a bit but I only end up actually switching perspective ~ 50% of the time. I tried remapping "Aiming down sights (toggle)" to several other keys (one at a time). All other keys (that I tried) have same original problem (see above), where camera flinches a bit but I only end up actually switching sights aiming perspective ~ 50% of the time. Getting up and running with a new game from an established developer shouldn't be this hard. Imo remapping keys in-game should just work. (I haven't messed with ".chimeraUserImput.conf" yet.) I'm sure I'll love Arma 4 (& maybe Reforger) one day, but right now I'm really regretting this purchase...
  7. madrussian

    Controls issue (please help)

    Yes. Iirc, "Toggle Sights" by default is bound to the same key as another control as well (zoom perhaps?). To help troubleshoot, I rebound "Toggle Sights" and "Change Perspective" to exclusive keys. 99% sure I was having these problems with vanilla key setup too, but I'll double-check. Hopefully no controls in the game are (even halfway) hardcoded, such that certain controls can't be rebound successfully (due to cross-talk, etc). Good info to go on, I'll check this out. Thank you. 🙂
  8. Loving many aspects of Reforger so far. However can't jump on board fully yet due to two severe (seemingly related) issues: From normal view (not looking down sights), pressing "Toggle Sights" should result in looking down sights. However roughly 50%, upon pressing "Toggle Sights" I don't end up looking down sights. From sights view, pressing "Toggle Sights" should result normal view (not looking down sights). However roughly 50%, upon pressing "Toggle Sights", I don't end up looking down sights. To summarize, "Toggle Sights" works about 50% of the time, and doesn't work the other 50% of the time. From 1st person, pressing "Change Perspective" should result in 3rd person. However, roughly 50% of the time I don't end up in 3rd person. Likewise from 3rd person, pressing "Change Perspective" should result in 1st person. However, roughly 50% of the time I don't end up in 1st person. To summarize, "Change Perspective" works about 50% of the time, and doesn't work the other 50% of the time. More specifics: In both cases (above), upon pressing the control I can see the camera motion fiddling around a little bit, like it started to switch and just ended up switching back. I made sure that both of these controls are set to exclusive keys, meaning no other controls are set to those same keys. (And obviously these two controls are set to different keys. Also note, when I say "key" I mean key or mouse button.) Either of these problems alone is pretty much a show-stopper. Taken together, they make for a completely maddening experience! Any suggestions?
  9. madrussian

    Arma Reforger - Mission Editor

    Has anyone found a list with all Enforce script commands yet? (either online or in-game)
  10. madrussian

    Arma Reforger - Mission Editor

    I like and use Arma 3 editor in 2D mode all the time, and never bother much with 3D editor mode. I create things dynamically (pretty much exclusively) all the time, so don't need that 3rd dimension, except in scripts of course which I go absolutely vector-crazy with. Enjoying Reforger so far, but really missing that editor, which imo should have shipped with the game. As in, seems to me the game should have been held back until at least a 2D editor was ready. But we are where we are so might as well trudge along and make the most of it.
  11. madrussian

    New informations or announcement soon?

    Wow this sounds pretty rough editor-wise... still got my fingers crossed though. I guess it's going to be a while before anyone can say, but I'm really curious how these "simplified AI" (per Drewski's phrasing) hold up for basic infantry combat and path-finding? Also has anyone managed to get an AI into a car to see how he drives?
  12. madrussian

    New informations or announcement soon?

    In my bomb bunker too anticipating exact same words.
  13. madrussian

    AlertAI mini-mod

    I like it... simple & effective! Agree, it's a rather huge shortcoming in vanilla to not have any communication to dudes who are right there standing next to you. (The implementation wasn't simple though, huh?)
  14. Very interesting, didn't realize you started this prior to calculatePath. So glad you followed through and created this. It's quite integral to cases where engine paths won't work, for one reason or another (like inside buildings). In my own experience (perhaps ironically), it is the game engine's calculatePath that could be argued as obsolete. Especially considering the potential for Intercept powered path-finding as it performs so lightning fast, plus ability to provide alternatives to engine path (which can be quite problematic, as anyone who has ever tried to load up squad AIs into own vehic can attest). Another dev request while we're at it: A "CalculatingPath" event, which fires just prior to the path calculation beginning. (May sound counter-intuitive but trust me, this would be a huge gamechanger for calculating engine paths faster, at least in my AI.) ^ Not to be confused with the existing "PathCalculated" event, which fires after the path calculates.
  15. The feeling is mutual. 😉 You've inspired me (and hit my funny bone) more than you can know. Churning out brilliant useful scripts like that. You are quite welcome. Curious on your distance problem (great catch btw), can you just use vectorDistance? I imagine as a game command it's super optimized. Haha, my own code confuses me too & sometimes after I just wrote it. Basically, I'm sending units through buildings using forced movement (like with playAction). With point selection based on "rooms", etc (in far more dynamic way than using buildingPos positions). It's pretty fun and looks great when working properly. Hopefully I can show something off sooner or later. When it stumbles or messes up, it reminds me of when pierremgi called forced movement though buildings a Rube Goldberg machine. Btw - Johnnyboy helped me get my AI force moving, and inspired me big time to get them moving through buildings. As far as I know, he's the forefather of these forced movement techniques. Also, Leopard has helped me big-time getting Intercept up and running. Which can (theoretically) perform path-finding much faster than SQF. One day you guys are going to be pretty shocked by how well AIs are able to fully use buildings, once unleashed using forced movement and pathfinding. It'll come sooner or later. Anyhow, mine's still a good ways off. Long story short I got pretty far, but ultimately may end up being just for personal use... if it can't be made to perform well enough, etc. If any devs are reading this, will you please find a way to enable the "flex" pivot bipod poses for AIs (where AI's gun pivots on a point and AI's feet stretch down to the surface below, like player can do), so AI can make far better use of windows & low walls? I (along with Leopard & no doubt others) will take that capability and run like crazy with it!