Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by gromit190

  1. Attached is a version where deactivated units will be ignored. But there's a catch I've been working on renaming the project and it is easier for me to implement this fix in the renamed project. So to use this version you'll have to change the "autogft" prefix in your script to "gws". e.g. you'll need to change your lua mission script from this: autogft_Setup:new() :addBaseZone("BLUE_BASE1") :addControlZone("CONTROL1") To this: gws_Setup:new() :addBaseZone("BLUE_BASE1") :addControlZone("CONTROL1") gws-1_19.zip
  2. Maybe. Depends what it is that you want to do. You can spawn them in to the base zone later in the mission, to use as reinforcements if you invoked useStaging(). Are you using useStaging()? I think it is km/h, but honestly I am not sure. It is not converted in my code, so it is the same as it is in the mission editor/DCS internal scripting engine.
  3. Hey guys, Sorry for being so afk. Been really busy lately with house remodeling and taking care of my kid. I guess in theory it could be anything, but when testing this I used a couple of buildings. Short answer: no. Long answer: it depends. Usually (unless you scripted otherwise), "scanUnits" is triggerred on mission start. So only the units that are present when that happens will be used. But for staging, you could send units to the staging area and they will be used if they match the type that is used for reinforcements. No. Keep in mind that you need to use setSpeed before using addControlZone etc. Maybe you could post your script where the error occurs? That should be an easy fix. I didn't consider that when I coded scanUnits. Will fix this.
  4. Great :) This is true. I seem to remember that autogft just uses the origin point of the zone (idk what that would be in a polygon but for circles its the center) and looks at units within the zones radius. Added fixing this to the issue list: https://github.com/birgersp/dcs-autogft/issues/123 Also keep in mind its the same when a unit goes to "capture" a zone. It will use the radius. So currently I guess autogft really only has support for circle zones.
  5. Since you didn't specify any units, autogft will scan "BlueSpawn1" on mission start to see what units it should be using. if there are no units on mission start (which I guess there aren't since you spawned them perhaps later) then autogft thinks there are no units. Perhaps this is what happened
  6. For those interested, there is something mentioned regarding a "script API" change here: I would guess the implementation of this (during development, beta versions you know) was the cause of the error. Anyways it should be working now for both stable and open beta.
  7. Seems ED fixed the scripting engine again! So everything should be in order now. Just tested the example mission myself on latest version of DCS World open beta. https://github.com/birgersp/dcs-autogft/releases/latest/
  8. It seems like the problem was that the function was called too soon (immidiately) after mission start. This is a working script: local waypoints = {} local function addWaypoint(x, y) waypoints[#waypoints + 1] = { x = x, y = y, speed = 20, action = "Cone" } end local function foobar() env.info("WAYPOINT TEST") local group1 = Group.getByName("Group1") local group1Pos = group1:getUnit(1):getPosition().p addWaypoint(group1Pos.x, group1Pos.z) addWaypoint(group1Pos.x + 2500, group1Pos.z) addWaypoint(group1Pos.x + 2500, group1Pos.z + 2500) addWaypoint(group1Pos.x, group1Pos.z + 2500) addWaypoint(group1Pos.x, group1Pos.z) local task = { id = "Mission", params = { route = { points = waypoints } } } log(group1:getController()) group1:getController():setTask(task) end timer.scheduleFunction(foobar,nil,5)
  9. I recently got back into DCS so I've started investigating the error again.
  10. Hi, I am trying to understand how to assign a task (route of waypoints) to a group. I want this to be a "vanilla" script (no script tools/mods). In my attempt, I am simply trying to make the unit go from its current position to a point 200 units away. But the unit does not move. Can someone please point at what I did wrong here? local function foobar() env.info("WAYPOINT TEST") local group1 = Group.getByName("Group1") local group1Pos = group1:getUnit(1):getPosition().p local waypoints = {} waypoints[1] = { x = group1Pos.x+200, y = group1Pos.z, speed = 20, action = "Cone" } local task = { id = "Mission", params = { route = { points = waypoints } } } group1:getController():setTask(task) end foobar() I am checking the logs, and I see that the info message "WAYPOINT TEST" is written. Furthermore, I am certain that the group is found and that the position data is really retrieved because I tried printing them to log too. I see that the data exists (is not nil). So I am not sure why this doesn't work.
  11. Glad to hear this is interesting for others aswell. What is sno views?
  12. Hi, I want the MFCD to be visible on-screen, but obviously only when I need to see it. I know how to make it visible in the multi-monitor setup lua, but is it possible to hide it with a key press? (I am refering to the shkval as "mfcd" here because that's how it is named in the lua. And my question is really about viewports in general and not really only about the KA-50) MFCD visible: I press a key, and this is what I want to happen: Can somebody help me?
  13. Hi, No, sorry. I probably won't spend time on investigating this further. I don't use the beta, so I am not really that dedicated to debugging it. But when I checked, the error was that assigning waypoints in lua does not work the same way as it did before. So the scripting docs (what little there is) doesn't correctly explain how to create routes. (Unless they changed it since I last checked). Whoever wants to investigate the bug, feel free. I and others would really appreciate it
  14. Hi all, I just tested the Steam version, non-Steam version and open beta. Steam version and non-Steam version works with autogft 1.18. I just tested a basic example and the example mission (which uses a lot of various features of autogft). Open beta does not work. I don't know why, but there is some kind of bug where only the second waypoint of a two-point route will work. For those of you that experience an error, please state what version of DCS World you are using. Download autogft here.
  15. Been trying to solve this. Honestly, there must be some kind of bug with DCS. I can't explain it any other way. For some reason it seems that the unit is only moved to the first waypoint in the route. But only if the route has more than 1 waypoint (?). This is the same case even when I script some route "manually" (not using autogft) for the units. For those of you that have the bug, what DCS version are you using? Please keep your eyes and ears open if anyone else has this bug. I tried asking on the mission editor channel on ED discord, but it seems idle.
  16. Okay. I did just to a quick test before generating 1.17 so I might have missed something. Will keep trying to solve it. One thing I struggled with yesterday was creating a simple script that just gives a group some simple task (route). Because that would really help me debug this error, by comparing the task data that autogft generates with raw task data that is manually made and works. Will continue fixing this later. BTW I am using the open beta version now for testing.
  17. While I investigate how to properly fix this bug, you can probably use this version with a temporary workaround: https://github.com/birgersp/dcs-autogft/releases/tag/1.17 This might be a bit buggy, especially considering running on roads. But give it a go if you want. Also if you have any information that would help me identify what has changed on the DCS scripting engine. Tried looking at the hoggit wiki but it gave no answers to why the autogft logic stopped working.
  18. I've isolated the problem at least. What autogft does is it creates 2-6 waypoints (depending on the setup and how far it is until the next objective). It will appear like the unit does not move at all but actually the first waypoint is just really close to the unit position. So it moves just a couple of meters to get to it in the beginning of the mission and then it stops. For some odd reason, DCS only moves the units to the first waypoint and stops at it. It just ignores the next route waypoints. Has anyone heard of other scripts experiencing a similar problem? Right now I'm going to test a regular route with 2 waypoints to see if that works.
  19. Thanks! Tried to find the bug tonight, but no joy. Will investigate this more later.
  20. Thanks! Can you try adding a unit to your mission, and give it a route? I mean the regular way, not using autogft. If that unit moves then there must be some kind of difference between a units "autogft route" and a regular route.
  21. This mission works as it should for me. Units gets routes and moves as they should. Let's take a different, minimalistic test mission (test.miz attached) for debugging. This mission works 100% for me. The unit gets a route, and it starts moving towards its target. Please test this mission, and answer the following questions: 1. Can you load this mission to the mission editor without any error? 2. Does the unit get a route? (Play as tactical cmdr to see the route) 3. Does the unit move at all? 4. Are there any error messages in the log? test.miz
  22. Hi, You're right, there seems to be an issue with the 1.14 example. Not exactly sure what it is. But anyways, I fixed the example now with 1.15 code. Tested, does not crash for me. (download 1.15 here) Gonna test your (non-crashing) 1.14 example now
  23. Sorry, I can't test this mission. It won't open. Probably since I'm on the (older) Steam version. To be able to fix this bug, I'm gonna need some investigation from you guys.
  24. Thanks @Taslehoff. Haven't tested your mission yet. Can you upload a completely minimalistic mission? No Mist, no Moose, no scanning/staging/misc scripts. No extra units except a single one that illustrates the problem. Just absolute minimum.
  • Create New...