Grimes

Bug. It is reported.

https://wiki.hoggitworld.com/view/DCS_singleton_world Which page were you looking at?

At least with the arty it seems to not want to rearm if it expended everything. Tested with a grad and fire at point. Set to fire 39 it will rearm after the task. Set to 40 it won't rearm. Reported.

Was likely on the wiki because its easy to miss these changes. Likely was removed or renamed in 2.9.0.47168. S_EVENT_UNIT_TASK_COMPLETE now occupies that event id.

Has to be AI and set to take off from ramp.

In DCS.log there will be a line stating mist loaded. The lines are basically it started loading and it finished loading. 2024-07-01 19:24:54.392 WARNING SCRIPTING (Main): MIST|init|1675: Init time: 0.101 2024-07-01 19:24:54.392 INFO SCRIPTING (Main): Mist version 4.5.127 loaded.

It needs a return statement in the condition box. Same goes for the condition in the start and stop conditions for tasks. nullAdd that and it'll work as expected.

It is currently only functional on FARPs. Its a little weird in terms of how the game treats the objects IIRC.

Setting a flag of the group name is the same thing as what that was doing. It was a value, that when it exists means that the group was going to respawn and acted as a lock of sorts to prevent the multiple messages or multiple respawns. Literally just a different way to do the same thing. And yes, the number value in outText is the display time. https://wiki.hoggitworld.com/view/DCS_func_outText With the 3rd value set to true it will display the message in a different format and will overwrite any existing message being displayed.

getPoint might be more directly useful as it only returns the coordinates. However getPosition().p is functionally the same thing. The rest of the values returned with position are used only with the orientation of the object. For example: local heading = math.atan2(unitpos.x.z, unitpos.x.x) Worth noting that the coordinates used in tasks is typically a "vec2" and not "vec3". Which basically means that the vec3.z value needs to be the vec2.y value. So... local point = Unit.getByName("target"):getPoint() local task = {} task.x = point.x task.y = point.z https://wiki.hoggitworld.com/view/DCS_task_mission

I think it is AI path calculation more than anything mist is doing. Most of what that mist function does is it generates the points given to the route table and assigns the task to the AI. Try it without the disableRoads being defined, meaning mist will find the closest road from the start and destination points.

Using a number for the 2nd parameter in mist.respawnGroup isn't a delay in respawning the group. It is a delay for when the group task gets assigned. At first glance you could schedule mist.respawnGroup to occur at a later point in time, however I assume you are constantly checking if not Group.getByName, as a result it'd just schedule mist.respawnGroup however many times between when its dead and when the group actually respawns. One way would be to add extra conditions. if not Group.getByName('RUS-T72B-6') then if not rusB6Respawn then --- checks if a time was saved when the group was killed rusB6Respawn = timer.getTime() --- creates a global variable for that group elseif rusB6Respawn + 120 < timer.getTime() -- checks if the time the group died + 120 seconds is less than the current time mist.respawnGroup('RUS-T72B-6', true) -- respawn rusB6Respawn = nil -- delete value so it can be created again with the initial check end end At that point it might be easier to just create a function that checks and manages the groups you want to check. Maybe it has a table of the group group names and each time they died at, which iterates the table to respawn them as needed. Basically the above lua example is fine for a few groups, but gets annoying fast because you need a unique global variable for when each respawns.

I've only ever done it outside of DCS with python. But yeah, same concept of doing it with something like luazip externally from DCS. Something like the web editor might be the easiest to use since it has a UI and you can modify time of day or weather in the miz pretty quickly.

No. The env.X tables are just a copy of a few files located within the miz file. You could edit the copy by adding triggers, units, or whatever and the serialize the files and re-insert into the miz so that on the next load the changes are reflected. I've done that a few times to fix or change entries outside of the editor in bulk.

I think it is the unique situation that a dead object is being spawned. It has a spawning event, but it can't get data about the object because it is dead, therefore an error. It is a little weird because the mist DB will populate the DB entries for statics set as dead in the mission file, but everything it knows about that is from the miz and not derived from other functions at runtime.