Jump to content

doc. caliban

Member
  • Content Count

    272
  • Joined

  • Last visited

  • Medals

Community Reputation

32 Excellent

About doc. caliban

  • Rank
    Staff Sergeant

Recent Profile Visitors

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

  1. It'll still be Gaia, which is what I think everyone knows it as.
  2. Oh, wow! So good to see you here! I think I sent you a PM asking if it's ok to be doing all of this, so thank you for letting us run with it! I could never create something like this from scratch, but I love to tinker... Gaia has been a blast to work with. Thanks again! I hope you don't mind, but I came up with a slightly different idea for what the acronym stands for. I know it was originally Greater Artificial Intelligence. To make it clear that it functions at the group level, I came up with Group AI Augmentation. What do you think? I also threw together a logo for the mod version that uses the Greek alphabet in keeping with the Gaia namesake: The ancient Greek for Gaia. Gamma Alpha Iota Alpha. Hi there. I am working on getting Beta 1 out shortly ... hopefully today. It will be fully functional but it will have some things for me to improve for Beta 2, and I will also try to fix any bugs that you guys find in B1. I'll post a Dropbox link when it's ready. UPDATE: I'm trying to pin down one last bug but I need to stop for the night. I'll get back on it first thing in the morning.
  3. Sorry, guys; I haven't forgotten about this! I'm both back to work, and moving to a different home. I'm maybe 1 evening's work away from being able to give you B1... maybe tomorrow if I can make the time. Otherwise, probably next weekend.
  4. Hi there. Thanks for chiming in! It would be easy to release a mod version and script version side by side. I will do that. I'll keep the built in 2SC and make some performance and feature improvements, and also make DS an option. Best of both worlds. (And the fortify-breaking issue is 100% resolved.) I occasionally had the same issue with garrison units leaving their positions but I'm pretty sure that I chased down the cause and resolved it. IIR, it was related to the next topic. The changing of posture, (taking a knee, lying down, standing up again) is due to the JBoy Up-Down script included in Zen Occupy Houses. Since ZOH was last updated, JBOY made an update to his script which I have incorporated into ZOH. I could easily make that entire subroutine an option as well. Units would still change position based on whatever FSM file is in use, but it would not be as elaborate as JBOY's code. Should I split that out as another optional feature? I think it was this code that I had to add to to prevent units from leaving their garrison positions. I'm pretty sure that I can create a per-group option for manually specifying patrol waypoints. Is that what you mean? Or do you want the script to automatically create a loop-like route inside the perimeter of the zone? I can fairly easily create a radius based loop, but would have to do a little more braining to get it to do the same for a rectangular or elliptic route. At this point I think I need to create some "beta" releases or it will be a while before I release anything at all. How does something like this sound? (Please suggest modifications as this is off the top of my head): Beta 1 Script and mod versions Zen Occupy Houses based FORTIFY code (Maybe a feature or 2 not enabled yet.) Multiple additional garrison options Some unfinished features to be completed for B2 Automatic zone detection Partially updated cache system Stage 1 cache performance improved Stage 2 cache mostly untouched but with added kit detail retention Dynamic Simulation as an option Cache range calculated based on mission view distance Adjusted on the fly when looking through optics Definable maximum distance past which caching will happen regardless of view distance Mortar and artillery timeouts are randomized Beta 2 Stage 2 cache updated Adjustable random timeout range for mortar / artillery missions Adjustable random timeout range for foot patrol waypoints Completed FORTIFY features Per group patrol options: Random Perimeter of zone Manual waypoint placement Make JBoy Up-Down feature optional? Bug fixes from B2 testing Possible completion of feature requests from B2 testing Beta 3 Feature completion Bug fixes from B2 testing Release For the sake of organization and version control, I think I'll want to keep beta testers to a specific group instead of simply posting everything openly in the forum. I also still need to do my due diligence in getting permission from Spirit and Zen to make the final results public. PM me if you're willing to do some testing and I'll send a download link once Beta 1 is ready to go. Thanks! -Doc
  5. Thanks for the feedback! The new "Fortify" code is indeed working awesomely... it's put that feature back on the map in a big way. I also have very much appreciated being able to set all the options in 3den instead of copying config files around and editing them. I do have an override file in the mission root that allows mission makers to still go that route instead of using the 3den module. BTW, I've also converted the entire thing into a mod instead of folders full of files that have to be in the mission folder. All you have to do is enable the mod and everything works on its own from there. No fuss, no muss. I agree on all of your points. I've just been called away again, probably for the day, but here are some quick thoughts that may not be directly related to each other: How does delete/despawn caching compare to Dynamic Simulation, which BIS sells as "all you need" for huge missions? Is DS close enough in performance to be "good enough"? You guys have made excellent arguments for retaining the 2-stage cache system. Regardless of whether we stay with delete/respawn or switch to DS, I can retain a 2-stage system. If delete/respawn is worth using over DS, I can still improve upon the second stage by adding a few more things like retaining unit's kits (ammo counts) and perhaps streamline the existing code a bit. I have a few half-baked ideas for a hybrid DS / delete/respawn system.
  6. That's a good point and also a good example of the value of the existing Gaia stage 2 cache where the group leader keeps patrolling. Here are my thoughts on a solution: Make both cache options available in the Gaia settings. (Original and Dynamic Simulation.) Update the Gaia cache system as follows: Change the way that the UI are disabled by using enableSimulation instead of disableAI since the latter is not actually reducing CPU usage. That fact was not documented at the time the original system was created; the note in the wiki was added in early 2017. I've already made this change in the functions for Stage 1, and also for Stage 2 in the event that the group is garrisoned since the Team Leader isn't moving around anyway. Replace the process of logging, deleting, recreating, and re-configuring the entire group in the Stage 2 cache function with simply teleporting the group into patrol formation with the Group Leader when they are uncached. No worries! I have a bunch of stuff going on as well and have been afk more than expected recently. Looking forward to your feedback.
  7. I suppose that's inherent in any cache system. The problem with calculating a later position would be that most groups / vehicles are making relatively random movements in their patrol areas. You could uncache them at a different, randomly selected position, but I figure if you don't know where they were when they were cached, then it makes no difference. Again, just my opinion.
  8. I'm considering retiring the built-in Gaia caching system and would appreciate your feedback on that. It's a great system, especially for the fact that it was created at least 5 years ago. The 2-stage cache is interesting in that it lets the team leader continue moving around at a greater distance than the rest of the team once they are cached. How it works in a nutshell: Stage 1 - Everyone but the team leader is disabled and hidden. I improved on how that was happening by changing the way that the AI was being disabled. Stage 2 - The entire group, its vehicles, variables, units, etc, are cataloged and deleted. IIR, their ammo counts are not kept, so when they respawn they have a full kit again. When back in range, the entire group is recreated from scratch and then has all of the above attributes applied... this involves many steps. In my mind, it seems like less overhead to simply use the current Dynamic Simulation system. The upshot is that it's a lot less activity happening compared to the stage 2 Gaia system, and the downside is that you lose the 2-stage system, though I admit that if you don't know where the group is on its patrol, you don't know. Having the leader keep the patrol going so that it's at a different location that you still don't know about doesn't seem to make much practical difference IMO, but that's subjective. I thought of a way to still have 2-stage with Dynamic Simulation, but it would increase the amount of work the engine is doing which defeats the purpose. This is how I have it set up now: The Gaia Settings Module has Dynamic Simulation enabled by default, but you can disable it. The Gaia initialization code manages all of the DS settings on its own (no need to set them in the mission attributes or description.ext): Enable/Disable the Dynamic Simulation system for the mission. Sets the distances based on the mission view distance. This is adjusted on-the-fly when a player looks through a scope to ensure they don't see any transitions in the AI. The user can set a maximum distance at which groups will remain uncached if the view distance goes past that point. Automatically enables Use Dynamic Simulation for all Gaia controlled groups. This can be overridden on a per-group basis by unchecking the cache option in the new Gaia section of the Group attributes window. In short, in this modified version of Gaia that I'm crafting, what are your thoughts on moving it over to using Dynamic Simulation the way killick had suggested trying? EDIT: I can also keep the original system but do the stage 2 in a much more efficient way. Simply apply the same method to the group leader instead of going through all the work of removing and recreating the entire group.
  9. Still working on smoothing everything out, but I have the Gaia Settings module created and working. All of these settings are now in an 3den module, though you can still set them in a config file if you wish: Enable Gaia Enable Dynamic Simulation for Gaia Groups Maximum cache range Distance from which foot troops will attack Distance from which ground vehicles will be sent Distance from which aircraft will be sent Can Gaia attack with non-Gaia troops Can Gaia units use smoke and flares at night Smoke and flare frequency Transport reset time Garrison - Fill buildings evenly Garrison - Indoors only Garrison - Fill positions from the top down Garrison - Place units on the roof Garrison - Use static weapons There is also now a Gaia section in the Group Attributes UI: Drop-down list with the three orders: Attack, Defend, Fortify Edit box to manually specify the group's zone (leave blank for automatic zone detection) Checkbox to cache the group if Dynamic Sim is enabled in the settings module Not a big deal, but kind of cool to not have to edit config files or copy and paste code into init fields anymore.
  10. Stay tuned for a sizable update to the FORTIFY and caching code. FORTIFY Changes Completely rebuilt around Zen Occupy Houses which includes the options for: Place units on the roof Fill buildings evenly or fully fill the closest first Assign positions from the top down I updated the JBOY UpDown code to the newest version. Feature added (retained) from the latest version of CBA_fnc_taskDefend: Use static weapons Feature added from Achilles instantBuildingGarrison by Kex: Only use positions inside buildings Cache Changes: Garrisoned units now retain their positions, direction, and behavior when un-cached... it's like they never left! (This feature is finished, pending some testing.) @killick, Should I look at switching it over to the vanilla Dynamic Simulation system instead? Found a way to, I think, vastly improve Gaia's cache system as it relates to reducing CPU use. Stage 1 caching (the bulk of the caching) uses disableAI to shut off features of the AI. I learned that this provides no CPU load reduction for units that do not have nearby enemy... so basically all of your Stage 1 cached units. I modified it to use enableSimulationGlobal to fully shut the units down and free up all the CPU cycles they are otherwise using. It may be more efficient to apply that to the Stage 2 caching as well instead of going through the dozens of steps of cataloging, deleting, recreating and reconfiguring the groups unit by unit. I still have a few bugs to work out with the FORTIFY mashup, and I need to make sure I check for permission from the people who's code I've borrowed and adapted for use by Gaia. I'm hoping it will all be finished by the end of this coming weekend. From the testing I've done so far it makes the FORTIFY option much more useful and flexible. I will probably also add a Gaia Group Settings section to the Group properties tab where you can use check-boxes to select features such as my automatic zone detection, which order to give, caching, and all of the various garrison options. I guess I'd also do a Gaia Settings module where you can set all of the other user options like my new caching distance options, my random mortar timeout range, and whatever else seems like it would be good to have in there. Let me know if you have any suggestions! Maybe once all the updates are working, some Eden UI options and modules are added, and I've cleaned up some of the old code elsewhere in the mod, we can arrange to have a formal update posted to this thread? Thanks again to Spirit for the great mod! I could never make something like this from the ground up, but I've been having a great time rummaging around in its guts and finding cool things to make changes to, and I hope others will get some use out of what I'm doing.
  11. Hello. Ace Map Gestures. Sometimes they fail to work for me during a mission while the other two players can see each other's. What kind of troubleshooting can I do? Is there a way to reinitialize the feature in the debug window? -Doc
  12. I can see how that would get messed up. I hadn't thought about garrisoned units being spawned back into incorrect positions. On the topic of "FORTIFY", I've stopped using it because I feel that the garrisoning functionality is pretty bad. I think that a rewrite of the building / position detection is badly needed. I'd say the biggest issues for me are that they miss a ton of buildings, and that they end up underneath elevated structures, as though AGL is not taken into account for the position they are supposed to move to. I may look at the code from other mods that do a better job with that and try to adapt it to Gaia. I really miss being able to have AI troops deal with that on their own. Part of the reason my zone automation leaves undefined groups alone is that I also disallow Gaia from using groups that aren't hers, and I use undefined groups as manually garrisoned groups. I don't like having to do that as it removes the dynamic and somewhat random positioning of the units, but I gave up on the built in function.
  13. Hello. ACE Movement. Does it do anything other than let you climb onto H-barriers? It seems like it's more just a button that generates a message saying, "Can't climb here". I'd been hoping for something more along the lines of the old Enhanced Movement mod. Am I using it incorrectly? -Doc
  14. Is Gaia partially broken due to an Arma update? This is the behavior I see now, and I believe that it is new. Test mission with no mods loaded. Zone 1 Group 1 "MOVE" Group 2 "NOFOLLOW" I engage the groups until both are aware of my location. Result: Both groups fire on me. I move out of view of both groups. Result: Both groups send everyone except for the Group Leader out of the zone to look for me. Expected behavior: All members of the NOFOLLOW group should stay in Zone 1. All members of the MOVE group should be sent after me. Basically, everything works as expected until contact is made. Then the zone assignments don't seem to be handled properly anymore.
  15. Thanks! I like the renaming of the commands but have been too lazy to bother yet. Do you have a screenshot of your UI? I'd love to see it. As for versions of Gaia, it doesn't look like there is anything newer than late 2017... is that the case? BTW, I am still having the issue with the new version where "nofollow" groups leave their zones once they lose line of sight of me. I'm going to do some proper testing and post a new reply with my results. I haven't had any issues with the cache system that I'm aware of. I was using ZBE Cache for a while but stopped because the Gaia one seemed fine. We usually only play with 2-4 players, but the missions often have well over 100 AI units... sometimes almost double that. It allows me to lay out a long, multi-session mission that way, and the cache keeps it from having undue impact on performance. (One of my guys has a lower-spec machine, so I try to conserve everywhere that I can.) That's why I adjust the mission view distance to something appropriate for the map and mission, and why I have the cache distance automatically fine-tune itself to that. The zone automation that I have is 100% compatible with using the normal method. If a group does not have the "gaiaCommand" variable set, the automation completely ignores it. Thus, you can have a mix of both if need be. Here's my current method and code for zone automation. Place a zone (or all of them) and name them however you want. Nest them as much as you want to. (I name mine gz_x because my marker alpha automation looks for "gz".) Place groups in the desired zones (it keys off of the Group Leader position) with one of the following lines in each Group Leader's Init field (use your custom command names): (group this) setVariable ["gaiaCommand", "NOFOLLOW", false]; (group this) setVariable ["gaiaCommand", "MOVE", false]; (group this) setVariable ["gaiaCommand", "FORTIFY", false]; Do not run gaia\gaia_init.sqf from your init.sqf. Use execVM "gaia\gaia.sqf" instead, and create that file with the following content: if (isServer ) then { // FUNCTION TO DETERMINE THE SIZE OF AN AREA-TYPE MARKER. MarkerArea = { switch (markerShape _this) do { case "RECTANGLE": {getMarkerSize _this params ["_msw", "_msh"]; _msw * _msh}; case "ELLIPSE": {getMarkerSize _this params ["_msw", "_msh"]; _msw * _msh * 0.25 * pi}; default {0} } }; // CREATE A LIST OF ALL AREA-TYPE MARKERS ARRANGED FROM SMALLEST TO LARGEST. allMarkersByArea = [allMapMarkers,[],{_x call MarkerArea},"ASCEND"] call BIS_fnc_sortBy; // FUNCTION TO DETERMINE THE SMALLEST AREA MARKER THAT AN OBJECT IS WITHIN. getGaiaZone = { {if (_this inArea _x) exitWith {_x}; ""} forEach allMarkersByArea}; // ASSIGN ZONE AND ROLE TO EACH GROUP THAT HAS THE "gaiaCommand" VARIABLE. { if (!isNil {_x getVariable "gaiaCommand"}) then { private _unit = leader _x; private _zone = _unit call getGaiaZone; private _command = _x getVariable "gaiaCommand"; _x setVariable ["GAIA_ZONE_INTEND",[_zone, _command], false]; _x setVariable ["gaiaCommand", nil]; } } forEach allGroups; // Initialize Gaia call compile preprocessfile "gaia\gaia_init.sqf"; }; Now when you start the mission, that file will find all of the groups with "gaiaCommand", determine their intended zones, and issue the actual Gaia variable with zone and order assignments. Any groups that are manually assigned, or not assigned at all, will be left as is. Then Gaia launches and off you go. Here's the code I put in initServer.sqf to automatically hide the Gaia zones. I got tired of changing the alpha on them all the time for editing and hiding them in missions. Now I just put them in a layer and toggle the viability when needed for editing, and this makes sure they never show up on the map in a mission. If you place this in init.sqf, the zones will be visible on the MP pre-mission briefing map, thus why I use initSever. // HIDE GAIA ZONE AREA MARKERS { if (_x find "gz" == 0) then { format ["%1",_x] setMarkerAlpha 0; }; } forEach allMapMarkers;
×