doc. caliban
-
Content Count
273 -
Joined
-
Last visited
-
Medals
Posts posted by doc. caliban
-
-
12 hours ago, delta99 said:Personally I would keep the name the same so there is no confusion.
It'll still be Gaia, which is what I think everyone knows it as.
-
On 8/6/2020 at 7:35 AM, spirit6 said:Hi all! Was supprised to see this topic updated hahaha. Do what ever you want/please on GAIA, it was made for the community so enjoy it any way you like! I have not played arma in years myself now.... ....... Have fun! 🙂
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.
On 8/7/2020 at 7:18 AM, avibird 1 said:Where can I get the download with all these updates that you guys have been working on. Is the original link updated with the changes you guys been working on.
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.
-
2
-
1
-
-
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.
-
2
-
-
6 hours ago, strider42 said:Just to show you can't please all the people all the time. I like the script nature of GAIA. I prefer tuning text conficuration files rather than using modules in the Eden editor but I am prepared to give anthing a go and it is nice seing that GAIA is getting some love.
I guess is it is hard to decide 'how big a mission'/'how many units' is likely to require any form of caching. I currently run a multi-player mission with about 100 enemy units (18 groups) and no caching on a player server (i7-7770K) and I don't get the feeling that it is loading the PC I run it on (+50fps).
As the mission does not run with caching I can't be breaking the Fortify system a pointed out by @killick, however the units do seem to leave their posts, especially when number of units left in the group gets small. That said I feel it works quite well in the mission.
I too have been playing around with the Zen Occupy Houses script to make sure units stay in place. Placement is nice but there is some irritations. Units stand by a window and will engage. Then they like to take knee, at which point their weapon does not have an line-of-sight on you but you can snipe thier heads ^^
@doc. calibanYou asked if there were any features people would like added: I'd like to have the option to specify a patrol loop for a squad to use, rather than the random movement the current patrol system uses.
As reguards 2-stage cache (2SC) vs. DS it is hard to know without really understanding the performance advantage. I'd guess: 2SC > DS > 1SC, with both DS and 1SC adding to the group limit.
I'd also like to see caching retaining units kit and ammo count. It is certinly irritating when you equip units with particular weapons to have the caching system change them.
Keep the good work up S
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
-
Beta 1
-
48 minutes ago, killick said:The changes that you are proposing look very good, and the change over to the Zen Occupy Houses will be a massive improvement.
The benefit that Gaia caching has over dynamic simulation is that at Stage 2 it actively deletes the group. That used to make a big difference to the maximum group count in a mission, less so after the maximum group limit was upped some time back. With a really massive mission the need to do real 'delete - respawn' caching might remain, so the GAIA code version or a modified version of it could still have a role.
I find the stage 1 / stage 2 caching is noticeable with vehicles patrols more so that foot patrols. At stage 2 the vehicle will keep moving, so vehicle patrols and attacks keep going over longer ranges. Like Vigil Vindex I have looked at trying to add future predictions of position but never felt it added anything as, as you say, it is no better than a random position.
The main reason I had gone off Gaia caching was the way it messed up "fortify" units. If you have fixed that then I think caching might still have a place, especially in big missions (which I sometimes make). So I'm looking forward to trying out the changes you have made.
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.
-
23 hours ago, Vigil Vindex said:But if the patrol waypoints are less random and more curated, such as a patrol between larger distances, location to location, then you should be able to project into the future an estimated location they would have travelled to in the interval between caching.
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.
42 minutes ago, killick said:doc. caliban - you asked a question of me a few posts back and I have been AFK for a week so have missed all the developments in this thread, and unable to reply. I have a bit of catching up reading to do today then I will reply to the question properly.
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.
-
1 minute ago, Vigil Vindex said:I've been thinking about the caching system and how it freezes cached units at the last location. The only solution I can think of to this would be to calculate the average movement speed, direction, etc and compare the time from when cached to the time of de-caching and modify the location according to that projected location.
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.
-
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.
-
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):
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.
-
The Gaia Settings Module has Dynamic Simulation enabled by default, but you can disable it.
-
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.
-
2
-
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.
-
1
-
Completely rebuilt around Zen Occupy Houses which includes the options for:
-
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
-
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.
-
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
-
2
-
-
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.
-
Zone 1
-
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 versionwhere "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; -
I thought I'd share some of the changes I've made to this awesome mod. Most of it is geared toward making mission creation even easier. There are a few AI tweaks that we wanted for our small coop group. Feedback is welcome!
MISSION CREATION
Gaia zones are automatically determined based on the smallest zone marker occupied by the Group Leader.
Reason: Instead of manually entering the zone name in each Group Leader's Init field, I simply set a variable that specifies the command (move, nofollow, fortify), and use a function that automatically detects which zone the Group Leader is in and then passes the final Gaia zone/order variable to the Group. If the Group Leader is in multiple zones (nested) the Group is assigned to the smallest zone occupied. Once your zones are all laid out, you can simply copy-paste "move", "nofollow", and "fortify" groups into whichever zones you want and the rest is taken care of automatically.
Instead of the original Gaia Group Leader Init line, add one of the following 3 lines for the desired functionality.
(group this) setVariable ["gaiaCommand", "NOFOLLOW", false];
(group this) setVariable ["gaiaCommand", "MOVE", false];
(group this) setVariable ["gaiaCommand", "FORTIFY", false];
Groups in which the Leader does not have gaiaCommand defined are left alone in case you want to use them for non-Gaia things. (Assuming you have MCC_GAIA_ATTACKS_FOR_NONGAIA set to false as well.)
You can still use the old method if and when you wish:
(group this) setVariable ["GAIA_ZONE_INTEND",["zoneMarkerName", "MOVE" or "NOFOLLOW" or "FORTIFY"], false];
Gaia zone area markers are automatically hidden during mission startup.
Reason: This allows you to simply add your zone markers to a layer that you can toggle visibility on/off while editing, but you don't have to remember to set their alpha to 0 before playing the mission. This happens in initServer.sqf so that the markers are also hidden on the initial MP mission map.
Level 1 cache distance (all units in the group except the leader) is dynamically set to the mission view distance -100m, or 1,500m; whichever is smallest. The max range is user definable.
Reason: Performance and ease of configuration. In most cases it makes no sense to have the whole group uncached beyond the view distance. This way you don't have to manually update the cache distance every time you create a mission with a view distance below the user defined maximum because it's always set to the optimal distance. I take 100m off of the view distance for the cache value since you aren't typically moving and looking through a scope into the nearly opaque last dozens of meters of the view distance anyway.
Level 2 cache distance (cache the group leader as well) is user definable as either a multiplier or a fixed additional distance.
Reason: This gives you more control over the caching.
AI BEHAVIORA random (60-480 seconds) timeout for mortar and artillery missions is generated between each fire mission.
Reason: We didn't want a known safety window between fire missions.
AI units will check to see if they are likely inside of a building before they pop smoke.
Reason: Units kept giving their positions away by (uselessly) popping smoke inside the small buildings they were hiding in.
Reduced the waypoint random timeout range by half.
Reason: We felt that the infantry groups and helicopters were sitting ducks for too long at each waypoint.
-
@strider42, any thoughts on this? With the newer version, Gaia is sending "nofollow" and "garrison" groups out of their zone like "move" groups.
Before they have a target all 3 groups stay within the zone, but once there's action, they all leave the zone.
-Doc
EDIT: It's working properly now. I'm not sure what why that was happening but obviously an error on my part.
EDIT: Dang it, it's doing it again. I have two groups, both "nofollow", in a zone. They stay in the zone as long as they can see me and shoot at me. As soon as I move out of sight, they both leave the zone and come after me.
-
If anyone is interested in preventing the AI from popping smoke inside of buildings, this is how I managed it. It's not fancy or perfect, but it works.
I did it because I was tired of AI units giving away their position to me by popping smoke in little buildings that I hadn't searched yet. POP! Fshhhhhhhh.... smoke billowing through a wall. "I'm going to guess that there is a bad guy inside of that building over there."
Open up \gaia\functions\control\fn_issueOrders.sqf
Search for "go smoke it".
You will find this section:
//did we have more then 20% loss? go smoke it if ((_x getVariable ["GAIA_PreviousPoints",1])>(_x getVariable ["GAIA_points",1])) then { if (alive leader _x) then {"SmokeShell" createVehicle (position leader _x);}; };There is a garrison related GAIA function called gaia_fnc_indoors.sqf that I originally employed, but it checks for something over the unit's head (like a ceiling) to determine if the unit is indoors. The problem with that is it gives false positives when standing under trees, certain bushes, etc. It would be good for using before firing a flare, though!
My solution was simply to find the nearest building and make sure the unit is more than 10m from it. I came up with that number by checking several buildings and determining that the far interior corners were usually around 8m max from the building position. The unit may end up being inside of a larger building, or several meters away from a smaller one, but it's good enough for my purposes. I could dynamically set the minimum distance based on the building's hypotenuse, but I could not find a way to get the dimensions of the building to use in calculating that.
Here's my change:
//Did we have more than 20% loss? Are we outdoors? Go smoke it! if ((_x getVariable ["GAIA_PreviousPoints",1])>(_x getVariable ["GAIA_points",1])) then { _nearestBuilding = nearestBuilding (position leader _x); if ((alive leader _x) && ((position leader _x) distance _nearestBuilding > 10))then { "SmokeShell" createVehicle (position leader _x); }; };It's a small thing, but it happens a lot so it seemed worth figuring out.
-
@strider42 Thank you! Is the linked-to version "stand alone" in its functionality? Regardless, I'll grab it and have a look.
Thanks again,
-Doc
EDIT: I made some changes to the gaia init file to reflect the way I use it as a standalone and auto-detect and assign zones. So far it's working perfectly. Once I know for sure there aren't any bugs in how I'm using it, I'll post a sample mission here that contains my zone automation and explain how it works.
-
Interesting, strider42. I wonder what version of GAIA I'm using... this is my line 38, and it does have a matching function:
{ _dummy= [_group,_TargetPos] call fnc_DoAttackMechInf;};The header of the file says, :"spirit 14-1-2014".
I love GAIA and have made many little usability tweaks, like automated zone detection and assignment, cache distance based on mission view distance, units checking to see if they are inside of a building before popping smoke, reduced the frequency at which GAIA checks in on all the groups by half (every 1 second instead of every half second), etc. Probably some other small things that I don't recall at the moment.
I looked at the latest GAIA code from MCC and it mostly looks the same as the old stand alone version that I use. I figured I'd do some updating by picking things from MCC but Winmerge found almost no differences, though I haven't done a comprehensive comparison yet.
I'd say that my only frustration with the mod is the transport system. Either I am using it incorrectly, or it rarely moves troops around.
-Doc
p.s. I get a kick out the the comments in the scripts.
-
I'm running into the same issue. The mod works fine, so I assume there are no code errors. I've signed it in the past but have edited several of the scripts since then and swapped one sound file out, so I need to sign it again. This time it fails. Now I can't publish the mod. The lack of error logging is tragic.
I've done some testing. If I re-sign the older pbo it signs fine. If I change anything at all in the pbo, it will fail to sign it after that. To say that I'm sick of troubleshooting finicky crap like this is an understatement.
-
I'm working on a shotgun mod that has custom buckshot and an explosive round that emulates the FRAG12.
The problem I'm seeing is that they both destroy destructible buildings, which makes no sense. The frag round only does a tiny fraction of what a vanilla 40mm does and shouldn't be destroying buildings either. Something in my config must be wrong, and I was trying to keep the damage toned down to realistic levels as well.
One factor I have a hard time with is "caliber" where 1 is supposedly the penetration of a 7.62mm round. I'm not so much worried about my specs in general though. I really need to end up with double-ought that doesn't take a control tower down after a couple dozen shots. lol
Any feedback about the config at all is welcome though.
Here's what I've got:
class CfgAmmo { class SubmunitionBase; class ShotgunBase; class BulletBase; class B_12Gauge_00Buck: ShotgunBase { simulation="shotSpread"; hit=2; indirectHit=0; indirectHitRange=0; cartridge="FxCartridge_65_caseless"; cost=2; typicalSpeed=404; visibleFire=4; audibleFire=8; airFriction=-0.008; caliber=0.3; }; class B_12Gauge_FRAG12: BulletBase { hit=42; indirectHit=1; indirectHitRange=1; suppressionRadiusHit=5; explosive=0.02; caliber=0.3; typicalSpeed=274.3; airFriction=-0.008; cartridge="FxCartridge_65_caseless"; deflecting=3; }; }; -
Requesting help with adding and removing event handlers.
When I add an EH in the debug console in the game like this, I get a return number in the console as expected:
["test", {systemChat str _this}] call CBA_fnc_addEventHandler; Return window shows a number.If I add the _id = as per the official example, so that I can then use _id to remove the EH, the debug console shows no return number.
_id = ["test", {systemChat str _this}] call CBA_fnc_addEventHandler; Return window shows nothing.Using hint to show the value of _id comes back blank.
Because of this, I cannot remove the EH because the ID number is required.
Note: If don't add _id = and use the returned number in the remove function, everything works.
What am I doing incorrectly?
Thanks!
-
Going nuts with the lack of clear documentation on this.
The EH fires when a player fires a weapon. It works fine.
The EH has several parameters, one of which is the ammo type.
Q: Does the EH fire every time a player fires and returns all the parameters as variables that I can then use in the code block?
or
Q: Do I set one of the parameters to the ammo class name that I want and the EH only fires if the player fires using the specific ammo class?
So basically I have no idea if the parameters are generated by the EH or if they are things I define for the EH to use to determine if it fires or not.
I've wasted way too much time screwing around trying to work it out on my own.
Thanks!
-Doc
Mission Template Stand Alone GAIA - Make missions FAST by using MCC GAIA engine
in ARMA 3 - MISSION EDITING & SCRIPTING
Posted
Hey there. I am super behind on this still with work being busy and being in the middle of a protracted move. As of right now I don't have a link to a beta but I only need a day to get to that point... (He says as he's getting ready for a Saturday work shift.) I can certainly include a demo.
As for AI waypoints and vehicles, can you give me a good description of the issue? I have not touched that part of the code yet as I've been mainly focused on the garrison issues.
Off to bed... 5 am comes quickly.