gromit190

Hi, I'm afraid not. I could add a mechanism to have multiple unit specifications per task force group. But I'm not sure what would be the best way to specify these units. (EDIT: Deleted concept code, issue resolved)

Awesome, thanks! I realized this might not be the appropriate subforum, as the tests were done on a realease version of DCS. But I assume the bug is the same for all versions :music_whistling:

Reported here: https://forums.eagle.ru/showthread.php?p=3007246#post3007246

Steps to reproduce: - Add a BLUE MI-8 or UH-1 huey to a mission - Play as the unit local groups = coalition.getGroups(coalition.side.BLUE) for i = 1, #groups do env.info("CRASHING TIME") local units = groups[i]:getUnits() -- <- Will crash if the group has a MI-8 or UH-1 end

The bug with "getUnits()" crashing on any group with MI-8 or UH-1 units is quite a devastating bug (and not just for this script, I would imagine). As to this script it means: As long as the there's a MI-8/UH-1 in a base zone when a reinforcement (not spawning) timer is triggered, it will CTD ... Can someone report this to the higher-ups? (Meanwhile, the only workaround is to keep your UH-1 and MI-8 away from base zones, sorry to say) That's definitely a reasonable feature request :) I should add functions to stop the timers (issue #64). Maybe just a single "stop()" that stops them all (reinforcement, respawning, advancement).

Thanks for the suggestion :) I don't want to blame anything specific until I know for sure but I have a hunch what is causing the crash. We need to do some tests so I think we'll have the answer ready shortly ... EDIT: This is the line causing the crash. Here's how to reproduce the crash (without AutoGFT). Add a BLUE MI-8 and then run this script: local groups = coalition.getGroups(coalition.side.BLUE) for i = 1, #groups do env.info("CRASHING TIME") local units = groups[i]:getUnits() -- <- Will crash if the group has a MI-8 end :music_whistling:

:thumbup: It's a feature to locate enemy vehicles for any group, which is now disabled. I don't know for sure which part of it was causing the error, but I haven't been very confident about having it and I realized it does more harm than good (for anyone interested here's the snippet I suspect causes the crash with Mi-8/UH-1). Version 1.4 is out: - Changed reinforcement system (only reinforcing whole groups) - Fixed Mi-8/UH-1 crash - Removed "Intel On Closest Enemy Vehicles" feature - Various minor changes

With a lot of help from Pikey (I don't have the modules in question, tbh) we found what's causing the bug. I'm releasing version 1.4 later today with the bug fixed. Workaround: - Remove/comment out the line invoking autogft_enableIOCEV() (line 79) in the example.lua - Re-load the example script to your mission

Which version of this script are you using? EDIT: My bad, I suspected long routes produced this bug but I'm preventing long routes in 1.3. Thanks for the details. I'll get right on this issue later this evening.

Hmm, still haven't tested this myself. Maybe I can have a try tomorrow.

Thanks! I'd like to work out how to prevent lags. Are you using the latest version? Also, would you mind sharing your script (or at least the part that is invoking the functions in AutoGFT)? Thanks for the suggestion. As Pikey said, I'm hoping to stop using MIST in the project, at some point. If anyone has any problems with integrating AutoGFT with other scripts using MIST then please let me know and I'll make an update to fix it. Happy new years everyone! :)

Actually, this function only returns the fuel of a unit. You can't set it, only "get" it (for printing it to screen or whatever). Sorry :/ Maybe someone else knows how to set the fuel

I've added a modifier to task forces to set a "max route distance" for task forces. I've released version 1.3 with the following upgrades: Added task force speed modifier Added ability for task forces to use roads Added task force maximum route distance between movement Various code cleanup / fixes Updated example mission script to show new features Added docs Huge thank you to Pikey for helping out with extensive tests today!

I don't think there's really a best order, because either it will work in any order (all scripts using comatible versions) or one or more of the scripts will fail to run regardless of which order you choose. With that said, I've planned to replace the functions I'm using in MIST with a somewhat different approach. So MIST won't be loaded by AutoGFT in the future. EDIT: Just wanted to add that I've added documentation (not complete, but the key features are documented). Regarding the parameter to set maximum time, it is documented here: https://birgersp.github.io/dcs-autogft/autogft_TaskForce.html##(autogft_TaskForce).setRespawnTimer

What you're suggesting is highly possible and not that hard to do (I think). Here's a function to add radio commands: http://wiki.hoggit.us/view/DCS_func_addOtherCommandForGroup I haven't really refilled/refueled with a script before, but I'm pretty confident it is possible. The only "problem" as I see it is that you can't distinguish between players in a group that calls the command to refill/refuel. So if you have a group of 4, and 1 of them calls the refill/refuel command then the whole group will be refilled/refueled. Another challenge is that the command will only be added for groups that are existing (have live players) in your mission. The way I've solved this before is I have a function that is scheduled at time intervals. The function removes the command for all groups (that has it), then re-adds it for all groups that exist (in-game players). Here's the code. EDIT: Here's one way to add the radio command (requires the autogft script, version 1.2 download here). Firstly, load the "autogft-standalone.lua" to your mission. Then load the following script: function enableRefillCommand() local enabledGroupCommands = {} local function cleanEnabledGroupCommands() local newEnabledGroupCommands = {} for i = 1, #enabledGroupCommands do if not Group.getByName(enabledGroupCommands[i].groupName) then enabledGroupCommands[i]:disable() else newEnabledGroupCommands[#newEnabledGroupCommands + 1] = enabledGroupCommands[i] end end enabledGroupCommands = newEnabledGroupCommands end --- -- @param #number groupId local function groupHasCommandEnabled(groupId) for i = 1, #enabledGroupCommands do if enabledGroupCommands[i].groupId == groupId then return true end end return false end --- -- @param DCSGroup#Group group local function groupHasPlayer(group) local units = group:getUnits() for i = 1, #units do if units[i]:getPlayerName() ~= nil then return true end end return false end --- -- @param #list<DCSGroup#Group> groups local function enableForGroups(groups) for i = 1, #groups do local group = groups[i] if groupHasPlayer(group) then if not groupHasCommandEnabled(group:getID()) then local function triggerCommand() -- -- DO THE REFILLING HERE, the "group" variable holds the target group -- end local groupCommand = autogft_GroupCommand:new("Refuel & refill", group:getName(), triggerCommand) groupCommand:enable() enabledGroupCommands[#enabledGroupCommands + 1] = groupCommand end end end end local function reEnablingLoop() cleanEnabledGroupCommands() enableForGroups(coalition.getGroups(coalition.side.RED)) enableForGroups(coalition.getGroups(coalition.side.BLUE)) autogft.scheduleFunction(reEnablingLoop, 5) -- <- Checks for new groups every 5 seconds end reEnablingLoop() end enableRefillCommand() EDIT2: I'm struggling a little to see how you can add fuel/ammo to units from a script :/

I don't think it will. It might be a problem if CTLD uses a different version of mist, but I guess it doesn't and won't. Wether you load CTLD or autogft first should not matter either. I'm hoping to make this project independent of MIST alltogether at some point, as we're only using some small bits of code from MIST. Let me know if you run into any problems, then I'll focus on substituting the functions we're using MIST for.

Hi, Suddenly, my script is broken and I've narrowed it down to Unit.isExist returns true even for dead units. I was under the impression that Unit.isExist returns false for dead units. I tried using Unit.getLife instead to check if units are dead but it "31" for units regardless of "state"... Is it broken or have I been using Unit.isExist wrong all along? The strange thing is that it seems to return false for dead units until I've respawned units a couple of times, then it starts returning true regardless of wether the unit is destroyed or not. Anyone experiencing the same issue(s)? EDIT: Solved. Reinstalled DCS World and Unit.isExist now giving proper results. Dunno if it was because of an update or it was my installation that was damaged...

Great! Regarding me not getting the utility to work since I updated DCS: Been doing some tests, seems Unit.isExist is broken in the newest version of DCS (I'm using the Steam version) which is causing reinforcing in autogft to be broken atm. EDIT: Fixed, version 1.2 is now available for download (see initial post)

Came back to do some testing today, and it seems the newest DCS update has actually broken reinforcing (by staging areas) while I was away ... I'm working on a fix, hopefully I can get it working ASAP

Noted, great idea. Probably I'll be renaming the function "setTargetUpdateTimer" to "setAdvanceTimer", and this function should do two things: 1. check wether a zone is captured (i.e. update target zone) 2. (if units have stopped/reached their destination, or the target is changed from previous route calculation) calculate a new route 1 km towards the target zone

Great suggestion, I'll be adding a condition to check if it is necessary to calculate routes. For units that have arrived at the zone they are attacking, I'll think I'll actually keep re-calculation because wouldn't want them to just "stay still" when they are clearing a zone for enemy units. Also since the routes will be very short, it shouldn't really matter. Sorry, can elaborate on what you mean by "Making legs"? Yes, I'm not quite sure if it's the generated waypoints that are "incorrect" or if its the pathfinding algorithms of units advancing to their next waypoint. The bug appeared quite seldom for us, so I've been ignoring it, but I'll try to investigate it some more (issue link). Hmm. I think I'll make route calculations happen at different time intervals for each group in a task force. Also, I'll try to constrain the distance of routes, so the routes will only be a portion of the distance to the "target position". I really appreciate your efforts Pikey! Would you be interested in helping out with testing it further, when I've made the modifications I've planned? Then I can upload some untested versions of autogft to a shared Google Drive folder

Really appreciate the feedback, guys! Thank you :) We've planned to make autonomous combat air patrols, but the system will probably be somewhat different so it requires us to do some re-thinking of things. As to helicopters I'm not sure if it can be integrated into the existing system or if it will be a part of "the next one". I'm going to do some testing and maybe I'll get some ideas. (Link to issue) Thanks! I'm a little involved with the MOOSE framework, already. Currently, this utility have somewhat different applications (goals) from MOOSE so I'd like to keep it independent for now. The projects may seem to have somewhat similar goals but this project is (currently) only concerned with making automatic AI battles while MOOSE is more of a completely improved way of scripting missions altogheter. But we'll see, maybe MOOSE can absorb this project some day :-) I could add a function to set a maximum number of reinforced units (issue). I should have documented it (documentation is coming soon), but the functions "setReinforcementTimer" and "setRespawnTimer" actually both takes a extra parameters to set maximum time. When the parameter is unset (like in the example), it means it will run for infinity. You can use it like this: :setRespawnTimer(300, 3600) -- <-- Respawn dead units every 300 seconds, for a maximum of 3600 seconds (1 hour) -- or :setReinforceTimer(300, 3600) -- <-- Reinforce dead units (from staging area) every 300 seconds, for a maximum of 3600 seconds (1 hour) I'll probably add separate functions to set maximum respawn/reinforcing time pretty soon. Something like "setTimerMax"... Hmm, I'll look into that ASAP (issue link). I suspect it has something to do with generating waypoints. This project uses MIST to generate waypoints, so maybe other MIST users are experiencing the same issue. Have you tried a different mission with Mi-8/Uh-1 and autogft in it? If yes, did it work? Thanks! 1. I actually deliberately disabled the use of roads in waypoints, but I'll add a function so you can make a task force use roads. Something like "useRoads()" will be added. 2. If I understand your question correctly, then yes this is possible. In the example mission, for instance, a single US task force consists of 4+3 M-1 Abrams and 4 LAV-25s (link) Okay, I'll look into this (issue). Yes, I've noticed route calculations are very expensive. If there's a correlation between amount of units (or, groups), I have an idea of how to fix it using scheduling. If the crash occurs even for a single group, then maybe I can add a feature that makes the unit generate only a portion of the distance before advancing (then if the set "target update timer" has a very high time interval, units might be "stuck" while the timer is waiting).

When I created the unit types list, I just ran a script extracting all the type names from a directory in DCS. I honestly haven't tested infantry, but I assume it should work. The same goes for aircrafts. Unfortunately I have noe chance to test it myself until tuesday... I'm planning to get all the available unit types into the list soon. I know people have made quite extensive lists of all the types in DCS (as we discussed here), so it's should be fairly quick to do. Hmm, good question (it should be). For now, you can put the "do script file" for the mission script (the "example.lua") in a different trigger than mission start, but I can add functions to have flag conditions for the task force movement later :) For the next days, I'll be away from my computer (unfortunately ...) because of christmas celebration. So I apologize in advance for late replies :)

I hear you, and as we've stated in the readme: What that means is that respawning units is just an option. You can choose not to respawn the units, and only use pre-existing mission units. Units will only be respawned when they are killed, so there won't be any "flood" of units in the mission :)

Sorry, I'm not sure I understood what you meant. The pre-existing units in the example mission will just stay where they are initially placed. When the task force needs reinforcements, it will "take" the units it needs from the staging area (i.e. the "base zone"). In the example mission, it is specified that the task force should have 4x T-90s, so only 4 units will be used at a time. The rest of the units will just stay put until they are needed. (You can test the example yourself to see what I mean: start the the example mission, go into the map, speed up the mission and you'll see red units are "picked out" from the pre-existing units located in the "STAGING1" trigger zone.) Currently, I'm afraid not. The skill is set to "hard" by default and I havent added a function to set it. I'll add that ASAP :) Hopefully I can add it today or I won't be able to do it until tuesday... Okay. Let me show you an example: - Make two trigger zones, for bases, name them "STAGINGAREA1" and "STAGINGAREA2". - Put a lot of T-90s inside the trigger zones - Add two more trigger zones, for targets, name them "ObjectiveA" and "ObjectiveB" - Then, use this code autogft.TaskForce:new() :setCountry(country.id.RUSSIA) :addBaseZone("STAGINGAREA1") :addBaseZone("STAGINGAREA2") :addTargetZone("ObjectiveA") :addTargetZone("ObjectiveB") :addUnitSpec(4, "T-90") :addUnitSpec(4, "T-90") :reinforce() :setTargetUpdateTimer(300) :setReinforceTimer(600) EDIT: Okay :) I'll leave this post here anyways, in case it comes in handy for anyone else trying to do the same.