JackDant

Awesome, that fixed the crash (not the warning) in my simple reproduction. I'll need to test it in my full mission later this week. Thank you!

Hi, Posting here first as I'm not sure whether this is a MIST or DCS bug (or both). I have a mission where I have a JTAC unit, and a deactivated group for targets. At mission startup, this group is cloned into a random location via mist.cloneInZone and assigned to the FAC as a task. At the simplest, the code for this is: do local tgt = mist.cloneInZone("Target", {"Target Zone"}, true) local groupController = Group.getController(Group.getByName("FAC")) Controller.pushTask(groupController,{ id = "FAC_EngageGroup", params = { groupId = tgt.groupId, weaponType = 1073741822, designation = "WP", datalink = true, frequency = 150000000, modulation = 0, callname = 1, number = 1, priority = 0 } }) end This works great, the first time the mission is run. On quitting the mission, the dcs.log shows the messages: 2018-11-11 19:55:39.377 WARNING DCS: task "FAC_EngageGroup" still exists 2018-11-11 19:55:39.377 WARNING DCS: task state for "FAC_EngageGroup" still exists If I then go back to the mission editor, and launch the mission again, as soon as the simulation starts, DCS crashes, with the following in the dcs.log: 2018-11-11 19:56:12.155 INFO EDCORE: # C0000005 ACCESS_VIOLATION at C49CD7FD 00:00000000 2018-11-11 19:56:12.160 INFO EDCORE: 00000000 00000000 0000:00000000 2018-11-11 19:56:12.167 INFO EDCORE: C49CD7FD 004FE3F0 0000:00000000 C:\Program Files\Eagle Dynamics\DCS World\bin\DCS.exe 2018-11-11 19:56:12.172 INFO EDCORE: C49CB2AC 004FE460 0000:00000000 C:\Program Files\Eagle Dynamics\DCS World\bin\DCS.exe 2018-11-11 19:56:12.198 INFO EDCORE: C49CF833 004FE500 0000:00000000 C:\Program Files\Eagle Dynamics\DCS World\bin\DCS.exe 2018-11-11 19:56:12.199 INFO EDCORE: DB4DF5C3 004FE530 0000:00000000 C:\Program Files\Eagle Dynamics\DCS World\bin\WorldGeneral.dll ?setTask@Controller@AI@@UEAAPEAVTaskState@2@P 2018-11-11 19:56:12.200 INFO EDCORE: DB4DF732 004FE580 0000:00000000 C:\Program Files\Eagle Dynamics\DCS World\bin\WorldGeneral.dll ?pushTask@Controller@AI@@UEAAPEAVTaskState@2@ 2018-11-11 19:56:12.201 INFO EDCORE: D87CBF65 004FE600 0000:00000000 C:\Program Files\Eagle Dynamics\DCS World\bin\Scripting.dll ?regLuaCommunicator@Scripting@@YAXPEAUlua_State@ I believe this is somehow related to mist.cloneInZone, because at one point I was doing a similar process building my own group data and calling mist.dynAdd directly, and this did not happen. I'm attaching a simple reproduction mission. Launching it twice in the same DCS session seems enough to reproduce (stable or open beta both). Any ideas? crash.miz

Then it might be easiest to use a box volume: local vol = { id = world.VolumeType.BOX, params = { min = {x=center.x-radius, z=center.y-radius, y=0}, max = {x=center.x+radius, z=center.y+radius, y=math.huge}, -- Or a high altitude if math.huge doesn't work } } And in the search callback you can calculate the 2D distance between the center and the object and filter on that.

You can search in a sphere, and then use land.getHeight to filter out anything not on the ground. FYI, in 1.5 I've found searchObjects is a bit fragile when the callback has any sort of error. It doesn't report the error, and it breaks searchObjects until you restart the game entirely. So I've taken to use pcall like this this: local searchCallback = function (object, data) local status, err = pcall(function () self:storeBuilding(object, data) end) if err then env.error("Something went wrong searching " .. err) end return true end local vol = { id = world.VolumeType.BOX, params = { min = self:getMin(), max = self:getMax(), } } world.searchObjects(Object.Category.SCENERY, vol, searchCallback, store)

Sorry if this already known or intended, but I think I found a bug in mist.getNorthCorrection. If called with a Vec2, the first thing it does is turn it into a Vec3: if not point.z then --Vec2; convert to Vec3 point.z = point.y point.y = 0 end But because Lua passes tables around by reference, it's changing the coordinates in the caller's scope. I just thought I was going crazy, as my code worked without the getNorthCorrection call, but didn't work with it. But I wasn't even using the returned value!

Thanks Grimes, I've looked into those functions, and while I can get speed from them (another thing I was missing), I still can't get the maximum engagement range. I'm talking in particular about the guns of armored vehicles, not missiles. Is there any other option?

Hi all, I'm working on some scripting to improve and automate ground AI behaviour and reactions, and I'm a bit stumped when it comes to an unit's engagement range. The range is visible in the mission editor and the F10 map, and I can see it defined in the .lua files under Scripts\Database\vehicles as "ThreatRange". But I can't figure out how to read that value from my Lua scripts. Right now I'm just doing an approximation based on unit type, but that's not very scalable. Any ideas? Thanks,

Since Wags already said the Nevada map (which is 360x360km, or 130,000 km2) has different resolutions in different spots, we know the minimum of what's possible for ED and EDGE. I would also assume adding more ocean would be essentially "free" in performance and development time. So, for example, the whole of North Korea is just 120,000 km2, leaving some room in a map for the South, and parts of China and Russia, along with a lot of sea area (this is my bet, especially because it's a map with Russia on it). Or, for another example, Israel is just some 27,000 km2, and Lebanon 10,000 km2. Put in maybe another 30,000 each of Syria, Jordan and Egypt, and a lot of Mediterranean, and you have a decent map. Hopefully, you could make low-res desert similar to water and extend the map east. Especially because the non-desert areas of Iraq are not that big.

This, and it can easily include Vladivostok, giving the russian planes a reason to be on the map (and ED is a russian company with many russian users). We know the Nevada map is 360x360km (129,600km2). North Korea has a total area of 120,540km2. Including all of NK, parts of the south (border to Seoul), and bits of China and Russia (Vladivostok) in one map should be posible. Especially if you make the less relevant areas low-res.

May I suggest looking into a Steam release? I believe greenlight access is relatively cheap. And, in any case, some companies have released DRM free software without issues: If you make it easy enough for someone to pay $5 (via Steam or ED store, for example), very few people will bother pirating it.

That'll buff out. Edit: For those who don't feel like repairing the link on their own:

Quite shocking for everyone. She had recovered completely (except for the eye patch), married, even had a pretty good career going as an inspirational speaker. Then something breaks loose in her head and just dies. RIP

Someone mentioned another variation of this that has been used in flightsims before. Once you "collide" with the "forest" the game checks if you collided with an actual tree. You could make it a 3 step procedure: 1) Is the plane flying below treetop level? If no, don't bother checking for trees, if yes: 2) Has the plane collided with any of the large "tree group" objects? If no, you are fine, if yes: 3) Has the plane collided with any of the individual tree objects? If yes, crash. That shouldn't hurt performance at all unless you are flying close to the ground, since the altitude test or something similar has to be done already for ground collisions. But it could get bad quite quickly if you have 10 players flying at tree top height in MP. And a lot would depend on getting the "tree group" object size right.

With the SDK release coming to backers soon, presumably lots of people will attempt to create their own terrain. What can you tell us about the workflow for terrain creation? What's your source material, how much manual work is needed, what file formats and programs can be used, and so on?

When I was a kid, 2000 was the future. Then around 1995, the future started being 2010. These days, I'm not sure what the future even is, maybe 2030? Anyway, I've learned there is always another future hiding behind the future. But none of them have flying cars:pilotfly: