MIssion Scripting Tools (Mist)- enhancing mission scripting Lua

[Grimes]

I can't reproduce the bug at all. Could you post a mission where it is occurring?

[Olddog]

Grimes, I'll have to do some more testing on this. I just tried one of my missions that was giving the mist error on my laptop and had no problem. On my desktop is were I was getting the error.

Both computers are running 1.5.6 OB. I try and see what is different.

Thanks for your time.

[Olddog]

With the DAWS package enabled, I get the mist.teleportInZone #1 parameter missed, in .mist line 3342 error.

WithOut DAWS package, no errors and everything works fine. Not sure why there is a conflict but will leave DAWS disabled for now.

[Grimes]

What is strange about that is it would be occurring because it doesn't think the trigger zone exists. I could add some error protection in mist, but that doesn't outright fix the issue since the code wouldn't fully execute if given the same parameters.

 

Is it a new mission or a mission created from a version that DAWS saved? I don't use DAWS but I just did a quick look through of its code and I didn't see anything specifically related to trigger zones. Frankly it doesn't make a whole lot of sense if the exact same mission works without DAWS running but doesn't with it running. I don't think it is outright deleting the trigger zone, but it is clearly doing something, just not entirely sure what exactly.

 

Could you post the mission file?

[chromium]

The file should be helpful to me also. As said, DAWS shouldn't interact with trigger zones... but I'm still working with some flaws in the new version (i.e. saving date/time).

Also please retry disabling any of the three AI enhancement options.

[Pikey]

Doesn't DAWS package MIST though? It certainly used to. I'd rather it was removed and the dependency was dealt with seperately, it might need more testing but so many missions use MIST that having it twice will cause issues somewhere for sure

[chromium]

DAWS load mist, last version if I recall correctly, when it's loaded ONLY IF there isn't an already loaded mist version. If MIST is loaded another time after mission launch, then some info might be replaced.

 

 

I included the check cause in the past somebody were loading mist after DAWS, creating issues about scheduling functions of mist. Might be a good idea to include the "mist check" even in mist? Grimes what do you think?

 

 

Separing mist from DAWS mean a double overhead for che system that use DAWS+mist and a great amount of code that I don't have the time to do, while the simpliest think should be not loading mist if a mist version is already running :).

[Olddog]

Here is I quick mission I just threw together, 2 ships teleport to 1 of 4 random zones.

Without DAWS package, no problem.

With DAWS package enabled and only auto save selected,getting the mist #1 zone error at line 3342.

 

I'm loading Mist at mission start. I see in the above post that DAWS is loading Mist also, So I tried the mission with just DAWS and not loading Mist at mission start. Same error.

 

1.5.6 OB

Mist 4.3.74

DAWS package.

test_temp.miz

[chromium]

Ships, which are not supported in DAWS. Still can't understand why DAWS might have to do with zones... but that might be another thing to investigate.

[Olddog]

Same problem with 2 ground vehicles. This seems to be more of a DAWS issue, so maybe we should move it over to that thread?

test_temp1.miz

[chromium]

Since mist-only it does work, it's likely a DAWS issue. If you want you cant post next one there but... I'm already aware of the issue. Sadly I don't have much time in those months (and this is the reason of the very slow developement and fixing of the DAWS package beta version), so can't ensure that will be fixed in the coming days (given that I can reproduce that).

[Grimes]

DAWS load mist, last version if I recall correctly, when it's loaded ONLY IF there isn't an already loaded mist version. If MIST is loaded another time after mission launch, then some info might be replaced.

 

I included the check cause in the past somebody were loading mist after DAWS, creating issues about scheduling functions of mist. Might be a good idea to include the "mist check" even in mist? Grimes what do you think?

 

When exactly does DAWS load and how critical is it to when it loads? As in is it automatic or dependent on the user setting a trigger?

 

I ask because it could be just a relatively easy check within DAWS that runs for a few seconds and if mist never loads, then it could load the one embedded within before doing all of the DAWS code. Or you could just heavily encourage users to set up the mission in a specific way so mist is always loaded first or tell them not to load mist because DAWS takes care of it.

 

That said I could probably add a simple check to mist, it should be relatively simple to do, but I could be wrong. The problem I see with it is that it depends on mist to be updated within the DAWS script to remain up to date. What I mean is you are packaging mist with your script, people may be getting mist from my github, which could be a more recent version, but due to how the scripts get loaded they might be getting an older version within DAWS.

[chromium]

DAWS is (should) launched before the initialization script. In the very firsts line of code, it load a mist.lua file that is locaded inside the DAWS folder and that is your last mist version renamed by me.

 

 

The user can't interact with this, is before triggers and before anything (but mods) that the user can load or control.

 

 

Anyway for increase compatibility some time ago I added check:

 

 

if not mist then

--> code that load mist

end

 

 

I did that cause in the past DAWS was loaded by trigger, and sometimes users load first daws and after mist... deleting any "mist.schedule" function that was triggered by DAWS and viceversa.

 

 

I already wrote in the manual about mist being inside DAWS and should be there in the previous release manual, but as this is a beta testing version the updated manual (which takes care of every new feature, including the option menù) is not ready yet.

[Pikey]

Removing MIST from the package and loading it manually won't work for DAWS as it wants MIST before the Mission environment loads as you just said and i tested it, basically even if you load MIST 'mission start' it's already gone and looked for it. And then if you load MIST second, it will load it second anyway, with whatever consequences that might have (I don't actually know). I don't think with the plugin method, now that I tested some different combinations, we can split out MIST from DAWS as I suggested originally.

 

I'm not trying to influence anything, just discussing, but to me i would have thought, that forcing a MIST environment through the addon forces the addon to align to MIST's update schedule, which would be extra work for you Chromium, rather than the other way around to let the users manage their MIST versions. Would it not be better to remove the functions you need from MIST, put them in the plugin and maintain them more stably and then allow the MIST environment to load if the user wants it? Might be more work but at least you can control it? Just thinking out load....i'm no genius here, sorry, just a user :)

 

I woudl like to know what happens with the double MIST environment load, as you mentioned schedules.

[Pikey]

I tested this mission and got the same error with the following differences:

 

I took a known good version of Mist .74 and replaced the one in DAWS package.

I removed the MIST call from your triggers int he mission, since the MIST env is already loaded before the mission environment by DAWS.

 

I ran the mission and got the same error. Almost the same method, cept I verified the MIST version. The only differences I can see are the timing of the loading of MIST, it's done before any loading screen effectively. It makes me wonder what needs to initialise from MIST at a later point.

 

I've already tested mist teleport in zone on this version with a standard load at the start of the mission MIST and I know it works. So its a timing issue. Does MIST require to see the mission and read it at load time to see the zones perhaps?

 

Here is I quick mission I just threw together, 2 ships teleport to 1 of 4 random zones.

Without DAWS package, no problem.

With DAWS package enabled and only auto save selected,getting the mist #1 zone error at line 3342.

 

I'm loading Mist at mission start. I see in the above post that DAWS is loading Mist also, So I tried the mission with just DAWS and not loading Mist at mission start. Same error.

 

1.5.6 OB

Mist 4.3.74

DAWS package.

[chromium]

Pikey the main problem is that I don't have the time to simply modify 10, 12 lines in the DAWS code to fix the date/time issue... therefore I won't have the time for some weeks to do something that I'm planning since years: duplicating the necessary mist function inside DAWS and split them to ensure complete compatibility (as I did before with other pieces of code).

 

 

For sure I'll first look into the issue that seems DAWS related, then once DAWS package could be considered release (and DAWS Weather fixed) I'll try to do this thing :).

[Pikey]

Hi mate,

I think you missed my roundabout point in my second post. It's a different point, I'll try to make it again because it looks important (to MIST users).

 

By loading MIST before the mission environment is loaded, it seems it breaks things that MIST can do, at least one of them, the teleport to random place in zone.

 

There's also no workaround, as loading MIST again, afterwards still produces the error. It's not that DAWS has an issue. It's not that MIST has an issue, it's a result of loading MIST early via DAWS.

 

I tested it already and can't seem to make it work, it's one of the issues I had with the package. It wouldn't appear in normal testing that is looking for DAWS issues, because you aren't looking for issues in MIST functions.

 

Is there anyway to prove this by just having MIST loaded early as a plugin and removing all DAWS code? I don;t think it needs proved because I really don't see it as a DAWS issue, I see it as a MIST issue when loaded as a plugin, but I can't prove that and remove the DAWS entirely from the scenario without code change.

 

It's important, because MIST is used so widely that to exclude MIST from any DAWS mission would not be satisfactory for many server operators.

 

 

Furthermore, It's my workign hypothesis that MIST is looking for the zones in the mission when it is loaded and that's why loading early causes a problem, but it's just a hypothesis and Grimes would know.

Pikey the main problem is that I don't have the time to simply modify 10, 12 lines in the DAWS code to fix the date/time issue... therefore I won't have the time for some weeks to do something that I'm planning since years: duplicating the necessary mist function inside DAWS and split them to ensure complete compatibility (as I did before with other pieces of code).

 

 

For sure I'll first look into the issue that seems DAWS related, then once DAWS package could be considered release (and DAWS Weather fixed) I'll try to do this thing :).

Edited March 17, 2017 by Pikey

[chromium]

I have to recheck this, cause in almost 3 or 4 previous DAWS version mist was loaded the very same way and both clone and teleport function were working in 1.5.5 and previous version. That could be possibile if something has been changed in mist in 4.73 versions and after... or if something is changed in the way DCS mission is loaded since 1.5.6.

[Pikey]

I don't mind checking for you!

You say it worked before. So if I swap to mist 4.73 inside the DAWS package then the mission above should work, right?

I will report back.

 

I have to recheck this, cause in almost 3 or 4 previous DAWS version mist was loaded the very same way and both clone and teleport function were working in 1.5.5 and previous version. That could be possibile if something has been changed in mist in 4.73 versions and after... or if something is changed in the way DCS mission is loaded since 1.5.6.

[Grimes]

Stripping the needed functions out is one way to do it, but from the looks of things he is relying on the databases, specifically the parts that update in near real time. So if DAWS was running and the mission also used mist then some of the functionality would be run twice.

 

If mist is run twice then all of the globally accessible values will be overwritten. In terms of the databases if you run mist once, spawn in a bunch of units, and then load mist again the databases wouldn't have the newly spawned units since mist relies on an event handler to know when to update. Those DBs would effectively be the same as what they would look like at mission start.

 

I'm quite certain the two event handlers for updating DBs would effectively run twice since they are both local within mist and get added to the in-game event handler. I'm not certain about the the scheduled functions because it would be a mix of locally stored values and a global function that gets replaced. I think the previously scheduled ones might be "forgotten" about since the reference to them would be replaced.

 

Furthermore, It's my workign hypothesis that MIST is looking for the zones in the mission when it is loaded and that's why loading early causes a problem, but it's just a hypothesis and Grimes would know.

 

Mist looks at env.mission to initially build the DBs. I don't know specifically when it is accessible but it is sometime before the initialization script gets run. Mist doesn't need to know the name of the trigger zone for that function since I am directly using the scripting function to get info on it. The line in question is using: trigger.misc.getZone(). I'm up way later than I need to be, but since you have been testing it, verify that the function is actually being given a string name for the zone. If it is given a valid zone name then that is extremely weird.

[chromium]

I don't mind checking for you!

You say it worked before. So if I swap to mist 4.73 inside the DAWS package then the mission above should work, right?

I will report back.

 

 

 

Dunno, cause it could be related to something else.

[Pikey]

Test 1 - Using .73 MIST (same error)

00134.426 INFO SCRIPTING: Mist version 4.3.73 loaded.

00134.426 INFO SCRIPTING: loading Save Mission

00134.428 INFO SCRIPTING: Found DeadObjCode variable. Value:

00134.429 INFO SCRIPTING: DAWS is using this path: E:\temp\test_temp.miz

00134.431 INFO SCRIPTING: DAWS Save Mission version: 2.1.2260 loaded

00134.431 INFO SCRIPTING: Save Mission load done

00134.431 INFO SCRIPTING: loading AI enhancement

00134.432 INFO SCRIPTING: DAWS AI Enhancement version: 0.2.2260 loaded

00134.432 INFO SCRIPTING: AI enhancement load done

 

then later:

 

00176.297 INFO SCRIPTING: Mist version 4.3.74 loaded.

 

then:

 

00190.961 ERROR DCS: Mission script error: : [string "e:\temp\DCS\/~mis00006118"]:3342: Parameter #1 (zone name) missed

stack traceback:

[C]: ?

[C]: in function 'getZone'

[string "e:\temp\DCS\/~mis00006118"]:3342: in function 'teleportInZone'

[string "mist.teleportInZone('rus1', {'SP1', 'SP2' , 'SP3' , 'SP4'}, true, 10)..."]:1: in main chunk

[Pikey]

Second test, removing MIST from the mission entirely so it can only refer to the DAWS loaded one, which is the .73 that is loaded pre environment

 

Same results, same error, just without the second MIST being called.

[Pikey]

So my conclusion, given if i remove DAWS and use MIST run at mission time, is that its just MIST being called early that's the issue, since the code is all the same.

 

Now...I know you said Chromium, that you tested it and it was working on .73, so if nothing else has changed, its the DCS version that does something different? I'm not going to revert a version to test, as much as I love my QA job here at Eagle Dynamics :) :)

[chromium]

Probably yes, i'm sure about 1.5.5.

 

Inviato dal mio SM-G920F utilizzando Tapatalk