gromit190
-
Posts
167 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by gromit190
-
I agree :megalol:
-
Hey EasyEB, I've scripted such a feature for my missions once before. Basically I added a radio command for players to ask for "Intel on closest enemy vehicles". When fired, it prints out a message saying type of units, number of units, heading and distance (from player group lead) to the closest "cluster" of enemy vehicles. I've recently broken the feature (because it was a part of a project where I changed some core stuff), but I'm quite eager to fix it again. I'll let you know when it is ready :) Here's the output format: What do you think of the format? The current "name" for this feature is "IOCEV" which is ugly af, so I'm looking for suggestions for a different name.
-
Cool! AutoGFT should be flexible enough for however you want to implement the task forces. Just for the record, EasyEB asked about how to control (override) the task forces during the course of the mission before, here's the walkthrough how to do it: It's not very clear, but I can try to show you. Firstly, you need to assign the task force declaration (in the script running on mission start, like the example.lua) to a global variable. Current example autogft_TaskForce:new() :setCountry(country.id.USA) (... more example code) Change it to myTaskForce = autogft_TaskForce:new() :setCountry(country.id.USA) (... more example code) So now you have variable called "myTaskForce" which you can use later. So then you can add another trigger event, which calls this code myTaskForce:stopReinforcing() And the reinforcing/respawning for the task force should stop. If you want it to happen to multiple task forces you have to declare multiple variables (myTaskForce1, myTaskForce2, ...) and call "stopReinforcing" for each. Hope this helps :) I guess what would really help you would be to have some object that the task force "depends on". Like a base warehouse or similar. When the warehouse is destroyed, the task force will stop respawning. Or would you rather have some other condition for the task force?
-
Awesome! Great, thanks! I'll try to give it a go within the next day or two.
-
Hey guys For any experiencing the same problem, there's a "collision" with different versions of MIST. This is fixed in the next release (AutoGFT will stop using MIST altogheter). Ah, this happens because group lead was killed just as the group was about to advance (i.e. a bug in my code). It's a quick fix so I'll try to do it ASAP (issue link), thanks for reporting :) I had a look at the logs, but I couldn't see any clues as to why it's failing to work properly in MP. To diagnose I need to create a "minimal" mission where it is failing, unless perhaps you have such a mission that you could share?
-
I've discovered the bug, and fixed it (one character modified :doh: ). Released a new version, where the bug is fixed. Download here. Thanks so much for reporting the error! It should definitely work now (tested your code, all ok). Please let me know if it doesn't :)
-
Thanks for showing me the code. I'll try to implement it in a mission later today, to see why AutoGFT is failing with it. What kind of units have you put in "red_base"?
-
Sorry I haven't got back to you sooner. So you got rid the hesitations, great! And thanks for showing how you've used the script. Your code should definitely not respawn units, only use idle ones. If setReinforceTimer is only provided with 1 argument (like you have done), then it shouldn't use spawning. If you give it two arguments, and the second argument is not false it will respawn units instead. https://birgersp.github.io/dcs-autogft/TaskForce.html##(TaskForce).setReinforceTimer Did you modify the code at all from the code you posted here? If you did, please post your new code. Or, if nothing else works, try invoking "setReinforceTimer" with a second argument "false" like this: :setReinforceTimer(600, false) Regarind "addUnits": If you don't invoke "addUnits", the task force will assume that all (!) the units in the base should be used for a single reinforcement. This means that if the task force units are killed, it will spawn all those units over again. "addUnits" is there to tell the task force that it should only use a selection of units, not all. So for using "staged units" (not respawning) you need to invoke addUnits or the TaskForce will just use all the units in the base.
-
Okay, the "setTargetUpdateTimer" function was rewritten and renamed a couple of versions back and its replacement ("setAdvancementTimer") shouldn't cause any lag. Hmm. May I see your script? The "setAdvancementTimer" sets a "looping" timer, meaning you should only have to set it once to enable your task force. But I understand you are invoking it multiple times, perhaps to halt and re-enable task force advancement? EDIT: To clarify, unless you want to manually control the duration between advancement time intervals, or halt/re-enable task force advancement, you can remove the timer commands. They are invoked automatically (when you invoke autogft_TaskForce:new()) anyways, to make the task force automatically advance by default
-
Hi, My pleasure! I assume you're not on the latest version. Please update to the latest version (link), and the hesitations you mention should go away. There's probably going to be some differences between the version you're currently using and the newest version. For instance, you no longer need to invoke methods like the "setTargetUpdateTimer", there are default (overridable) timers automatically set for you. Also, functions are renamed. Have a look at the new examples, and just let me know if there's something I should explain or demo better in the examples. If you want help migrating your code to the newest version, I'll be happy to help with that. You can go ahead and upload your code here (or send to me) and I'll update it for you, if you want :)
-
Thanks! Yes, we've discussed this quite a bit. We've decided against it for now. Let's discuss this on on the MOOSE Slack domain instead
-
Hi Assaf, Sorry to hear you're running into problems with the script. Also, sorry that I haven't replied sooner, I've been quite occupied with other projects lately. Had a look at the mission, and seems it should be working the way you've coded it... Could you tell me if there are any error messages in the log?
-
Maybe a stupid question, but did you save the mission after deleting the zone? I've noticed that the Mission Editor doesn't prompt me to save the mission if zones are the only thing I've changed in it since the last save...
-
Hello everyone, I just wanted to post an update here on the latest changes in the project. The key focus has been making it simpler to use by various means. Firstly (and, perhaps, most importantly) you no longer need to declare the units you want for your task force in the script. If you put units in a base zone, the task force will assume that this represents the unit layout you want for your task force. Also, I've removed the need to manually start the reinforcement and advancement timers in the script. Thus, a complete task force declaration with units respawning and advancing through zones is reduced to autogft_TaskForce:new() :addBaseZone("BLUE_BASE1") :addControlZone("CONTROL1") :addControlZone("CONTROL2") :addControlZone("CONTROL5") (There are 2 M-1 Abrams located in the base zone, so that'll be the "unit layout" for the task force. This means 2 M-1 Abrams will reinforce the task force when units are killed off). Furthermore, task force units will now always move through the objective zones when advancing. This prevents reinforcements from taking "shortcuts" when moving to the objective. It also enables mission designers to add "intermidiate zones" (see misc example), which the task force will use when advancing (not retreating to these zones if enemies are present). Happy hunting! :joystick:
-
Thanks! But even then, would you be able to tell which task is active for the group? If you assign three tasks to the group, how would you read out the current state?
-
Thanks for the reply. Even though it seems we can't figure out which tasks the group currently have, all I really need is to know if the group is stopped or not. To do that I'm simply compare the position of a unit in the group over a small time. I've got what I need for now.
-
Hi, I'm trying to read out the current task of an AI group. I've the Controller for it, but I can't see a way to read the tasks for this controller (doc). I can only see how to set it, not get it. local controller = Group.getByName("SomeGroup"):getController() controller:getTheTasksOrSomething() Anyone tried this before?
-
Ah, okay. Sorry, I think I misunderstood both of you before. The units should "disperse" "as normal", meaning that they'll "disperse" just like they would if you didn't use AutoGFT but just gave them a waypoint and attacked while they were moving. Regarding additional dispersion features: I'll write it up, thanks for the tip
-
Could add that. A task where the target is not a zone but an enemy group. What kind of mission are you thinking? Perhaps the players must defend ground units, where enemies keeps coming. Pretty interesting, and actually not hard to add this feature at all... It could be scripted, but if it's not a built-in feature in DCS then I'm not really seeing a clean way to do it. Is this a popular request?
-
Hi, You're right, the two functions (almost) does the same thing. Let me try to rephrase it. addUnits adds a number of units of a certain type to the task force. addGroup adds a group and (if you've specified the optional count and type) it will also call "addUnits" to add units to that group. So if you want a group of some units of the same type, you don't have to invoke both functions. You can create the group and add the units by one command instead of two. So, these two codes does the exact same thing autogft_TaskForce:new():addGroup(4,"BMP-1") autogft_TaskForce:new():addGroup():addUnits(4, "BMP-1") I've made it this way for backwards compitability (there was no "addUnits"-function before, only "addGroup"). But now that I think about it, and from your feedback I realize it does more harm (confusion) than good. So "addGroups" will take no parameters starting from the next version, so this will be the only correct way to do it: autogft_TaskForce:new():addGroup():addUnits(4, "BMP-1") Thanks for the feedback :)
-
Sorry, what are you asking exactly? Maybe this will help: https://birgersp.github.io/dcs-autogft/taskforce.html##(autogft_TaskForce).scanUnits Thanks for clearing that up. Pikey confirmed that ships are in fact not working in this script atm. I'll do more tests later to try and figure out whats going wrong and how I can fix it.
-
Thanks so much for the great feedback and support, guys! Hmm, very interesting idea! Groups taking heavy casualties could even stay "pinned down" while they wait for reinforcements. I'll write it up (issue link), thanks! Hello. I haven't gotten around to testing naval, I'm afraid. But unless there's some big differences in the waypoint logic, I would assume it would work the same way. I can try to test and create an example for naval a little later, right now my hands are a bit full. It's on the list (issue created). (Sorry, but I have to ask) Did you re-load the script (example.lua) to your mission after you modified it? Did the units not respawn, or not move, or what went wrong exactly?
-
You're right, but it's a little cumbersome to do and I think the ability to declare a "warehouse"/"base object" of sorts would be an easier alternative for some mission makers. Interesting ideas! I could quite easily make spawn zones "disabled" when there is enemy presence (issue link). Regarding random units I'm hoping to add that too, would be nice not to know exactly what kind and count of units that gets put in to action :) (issue link). How would you prefer to declare the randomness (if you could just write it in the task force declaration)? Maybe like this? autogft_TaskForce:new() :setCountry(country.id.USA) :addBaseZone("SPAWN1") :addControlZone("Combat1") :addRandomizedGroup():setRange(2,8):addType("M-1 Abrams"):addType("LAV-25") (... more code)
-
It's not very clear, but I can try to show you. Firstly, you need to assign the task force declaration (in the script running on mission start, like the example.lua) to a global variable. Current example autogft_TaskForce:new() :setCountry(country.id.USA) (... more example code) Change it to myTaskForce = autogft_TaskForce:new() :setCountry(country.id.USA) (... more example code) So now you have variable called "myTaskForce" which you can use later. So then you can add another trigger event, which calls this code myTaskForce:stopReinforcing() And the reinforcing/respawning for the task force should stop. If you want it to happen to multiple task forces you have to declare multiple variables (myTaskForce1, myTaskForce2, ...) and call "stopReinforcing" for each. Hope this helps :) I guess what would really help you would be to have some object that the task force "depends on". Like a base warehouse or similar. When the warehouse is destroyed, the task force will stop respawning. Or would you rather have some other condition for the task force?
-
New release is out (download link here). I've added a "stopReinforcing" function which kills the reinforcement/respawning timers. You can assign the task force to some variable and then "stop" it with another trigger. Perhaps not very useful, but I can give you an example mission if you'd like. Later I'm going to add a function to define base "objects". When these objects are destroyed, the task force will stop reinforcing/respawning. The new version lets you define units of multiple types for a single task force group. I've updated the example to show how you can use it. The example adds two groups to the task force: First group: 4 M-1 Abrams Second group: 3 M-1 Abrams + 4 LAV-25s
