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:

I thoroughly agree with the sentiment, but I can understand ED's point of view. Most of their non-gaming products are helicopter simulators, or like the A-10C, avionics trainers. In those, the curvature of the earth is mostly irrelevant and a complication. For the gaming market, I think they are missing a great opportunity. A true world model with pluggable scenery ala FSX, combined with their flight models? They could even compete in the civilian sim market. Who knows, maybe in the future...

The goal is to have a successful game and platform that attracts the highest possible number of customers who keep buying extra modules/DLCs for years. For that, ideally, you would want at least one free plane for each side so the online scenarios remain balanced. If that's not possible, I think it would be better to make the whole thing a paid module. Then, as with RoF (or even DCS), you can go free to play with the base planes later on, when they have a solid offering of extra planes.

And where is the "substantial free base game"? Not really. You can fly Su-25T's for the blue coalition, as Georgia. Now imagine the reaction of the forums if the normal scenario for DCS:WW2 had German P-47s instead of 109's.

Oh noes, I want to play a "free to play" game for free! The horror! The F2P model works by offering a substantial free base game, and premium content at a price. You hook people with the free content and then they spend money. Those "freeloaders" also provide content, in this case people to play with and shoot down, and they are essential to the experience for those who pay. If Luthier wants to drop the F2P model, let him do it. Then it's just another DCS module. But a F2P game with only one playable side cannot work. PS. Funny that in a topic about how to get more pledges, people who haven't pledged are told to shut up. PPS. Oh, and also massively negrepped :D

One free aircraft for each country made perfect sense and is not a "mistake" until you take the limited budget into account. Even then, fixing that "mistake" reeks of desperation and strong-armed tactics and is exactly the opposite message to the one doubtful pledgers need.

I have been holding off on pledging, and at this point I'm unlikely to. So take what I say with a grain of salt. Threatening those of us who haven't pledged with taking away the free planes will not get you to the stretch goal. If anything, it strengthens my doubts: you cannot run a simple kickstarter without flailing all over the place, how can I expect you to run an actual project? In exchange, you will cripple your end product by having not just one plane, but only one side freely available. As a platform, DCS:WW2 will need multiplayer to become popular, like all F2P games do. How will that work if every new player flies for the Allies? You set up the kickstarter with an unrealistic set of goals, then made constant and confusing changes even you can't understand now. Your promotional material consists mainly of guys talking in a language 90% of your customer base can't understand, and screens and videos of other games. Now that it hasn't worked, you are threatening to take your toys and go home unless we throw money at you. Nothing of this inspires any confidence.

I suggest you also set a 50% deadzone on the brake axes. My CH pedal brakes are very sensitive, and for some reason the "raw" signal starts at 50%. It made the aircraft very hard to taxi until I set the deadzone (actually at 51% so it ignores the accidental presses entirely)

Honestly, if a 60% discount yields you so many more sales, perhaps your original price was too high. Personally, I'm quite happy about the sale, and I may buy Mi-8 key now which I wouln't have otherwise. I got slightly burned with the Steam sale on the Huey (considering it was just a week after you released a non-working version there that you took two days to fix), but with everything else I got at the sale, I still came out ahead.

I do feel that, in the tradition of AIs everywhere, the tank MGs are too accurate. Shooting at a moving aircraft with a tank-mounted machine gun cannot be easy, and even worse for the coaxial one. Yet the AI hits more often than not if you get close enough.

An easy, quick, way to fix this: Create an autostart sequence for the SU-25T (I'm not sure it has one at the moment), and allow it to be run from the radio menu. Easy to find for new players.