MIssion Scripting Tools (Mist)- enhancing mission scripting Lua

[Grimes]

I'm definitely going to be keeping the versioned file. Its more of a question of whether or not I should enable the mist.lua file to be downloaded when you just download the whole script. At present I have it disabled because I figure having both would likely cause a bit of "which one do I use!?" type of questions. Admittedly I am pretty bad at updating both files whenever I make a commit, I generally only update the versioned file when I intend to form a release.

[lukrop]

Thought there might be a new function or something, not a major re-write. Some of these changes make me think that nerve that bursts when reading someone else's code might have been bothering you. :lol:

Actually it's mostly just a restructuring of the file and some variable and function names have been "renamed" (camelCase) to be consistent with the rest of script. Nothing changing the API.

 

Its mostly from a habit of only making commits when I am done with a series of changes. I often modify the dev file while testing both bugs/issues people are having with mist and while testing DCS in general. So I tend to only commit things when I'm going to post an update after I check the file to make sure there isn't any evidence of testing specific things within mist.

For testing stuff you could always use branches. If stuff works you can merge them back into development or master, if not just drop the branch. As soon as you fixed something just commit. Of course you can also have long commit messages and one commit with many changes. It just makes it harder for contributers/other project members. Since they maybe redo the work someone already did and the danger of merge conflicts rises because all work is done in one file.

 

I did that once before when I first added mist to github. However people didn't really like it that much because they weren't always sure if they were on the latest revision or not. So I reintroduced the versioned copy.

You can always attach a file (e.g. zip archive) to the release which contains the versioned mist lua and all the other stuff.

Maybe interesting in this regard: documentation for releasing on github and using semantic versioning.

 

Ian;2643135']Why not have the best of both worlds? Keep only one "mist.lua" in the repository. Attach an appropriately-named copy of the file to each GitHub release. That also gives people a direct link to download just the .lua file (without having to right-click the "raw" button on GitHub and selecting "Save As").

Got sniped by Ian :D

 

I prefer a table for anything that has more than 5 to 6 possible input variables, might have alternative values that accomplish the same thing, or could see expansion of the function requiring more variables. Include only whats needed instead of having a function call look like someFunction(req1, req2, nil, nil, nil, nil, opt5) sort of thing. Aside for that I do try to use multiple input values for the majority of functions.

Functions should have a minimum amount of parameters so why would one have "alternative values that accomplish the same thing"?

 

IMO it's better to have to write some nil parameters than running into these issues:

EDIT: Damn. Found my mistake. "stopFlag" should be "stopflag"...capital letter bested me again...tore my hair for 3 hours over this...

Which happens because the index names of the parameter values are sometimes in camelCase sometimes with underscores and sometimes just plain. Sadly not consistent. This approach needs the parameter table to be super carefully crafted.

 

Writing a parameter table for functions with four parameters seems also overkill to me.

 

After all those are just ideas and suggestions and should be treated as such. :) The actual changes I made in the pull request weight far more I think.

Having a decent logger is crucial to me. If I see functions whose first parameter is a string containing the calling function's name to write debug messages it hit's that specific nerve you mentioned. :lol:

 

I'm a big fan of the devs versioning their own work in file, once we download the scripts we have no way of knowing what the version is from the oputside or the inside is. I've had to do it twice now with yours Lukrop, go back to the github and re download it and it's pretty annoying.

I didn't draft any releases yet. As soon as a release is drafted the user would download a zip archive with version name in the file name (as per github default). If extracted properly the user would know which version he is using just by browsing to the file.

 

And if people are really having so many problems with that I'll be happy to include a GCICAP_version_here.lua file in the release zip archive. But this file won't be in the repository.

Edited January 15, 2016 by lukrop
sniped

[FSFIan]

Regarding parameter passing: any function that does something slightly complex should use a parameter table. I didn't do that in DCS-BIOS and now regret it alot (I am so looking forward to throwing certain parts of that code away when I get to build v2.0).

 

Parameter tables allow a lot more flexibility with adding optional parameters in the future and make the calling code easier to read when dealing with more than one or two parameters of the same data type (no more "which order were those supposed to be in again?"). The problem of misspelling parameter table keys can be solved by validating them in the function itself.

It's even more important in a library like MiST, where you don't have the option of changing the API and fixing all places where it is used at the same time.

 

By the way GitHub has a well-documented REST API, so releases are easy to automate using the scripting language of your choice. For DCS-BIOS, I have a Python script to create a new release -- compile the documentation with AsciiDoctor, bundle it up in a .zip file, create the release draft on GitHub, attach .zip file, open the draft in Chrome so I can add release notes, and upload the new documentation to the website.

[lukrop]

Ian;2644391']Parameter tables allow a lot more flexibility with adding optional parameters in the future and make the calling code easier to read when dealing with more than one or two parameters of the same data type (no more "which order were those supposed to be in again?").

I don't really see how the calling code is easier to read using parameter tables but this might just be me.

 

It's either "which order were those supposed to be in again?" or "what naming convention was that specific parameter having again?".

 

Ian;2644391']The problem of misspelling parameter table keys can be solved by validating them in the function itself.

This is a (valid) way of working around a problem introduced by design. Having to have functions or code, in every function using parameter tables, that needs to sanitize parameters just for their table keys names is not that awesome in my opinion. Of course one could extend mist.utils.typeCheck to do something like that. (Also mist.utils.typeCheck is another piece of code which comes with those parameter tables).

 

But I don't want to lead a witch hunt against parameter tables. They sure have their right to exist and be used in some places. It's just some ideas on problems I've been experiencing while using MIST before diving into it's code.

 

Ian;2644391']

It's even more important in a library like MiST, where you don't have the option of changing the API and fixing all places where it is used at the same time.

This is true. Decent deprection warnings would be needed. It's of course very important to maintain backwards-compatibility.

[Grimes]

Actually it's mostly just a restructuring of the file and some variable and function names have been "renamed" (camelCase) to be consistent with the rest of script. Nothing changing the API.

 

Point was you modified a large portion of the script, even if most of the changes were minor. Enough had changed that the github desktop client program was being a POS when checking the different commits and I decided to download a better program to look at it.

 

For testing stuff you could always use branches. If stuff works you can merge them back into development or master, if not just drop the branch. As soon as you fixed something just commit. Of course you can also have long commit messages and one commit with many changes. It just makes it harder for contributers/other project members. Since they maybe redo the work someone already did and the danger of merge conflicts rises because all work is done in one file.

 

I'm simply not used to other people contributing to the project. I've literally been the only person working on it for well over 2 years now. Even when its been up on github the vast majority of proposed fixes were made on the forum in the vein of "hey Grimes I found a bug, here is the fix." Being the only person working on something doesn't really reinforce making commits every few changes. When there was active collaboration on mist it was over dropbox and Speed and I pretty much hung out on a teamspeak every day. So there was a lot of active communication for what was getting changed along with the changes responding "live" since we shared the same file.

 

Functions should have a minimum amount of parameters so why would one have "alternative values that accomplish the same thing"?

 

Flexibility. It isn't super common, but it can happen.

 

Which happens because the index names of the parameter values are sometimes in camelCase sometimes with underscores and sometimes just plain. Sadly not consistent. This approach needs the parameter table to be super carefully crafted.

 

Pretty sure it is consistent when compared to when functions were implemented. After a certain point camelCase became the norm, while lots of older functions use_params_like_this.

 

Writing a parameter table for functions with four parameters seems also overkill to me.

 

Depends on the function, but within mist it isn't exactly unheard of for multiple parameter functions to exist only to package the params into a table for another function that accepts a single table to do the actual work. Ultimately though its up to whoever wrote the function. I've used both methods and have stated my reasons. I do try to keep things consistent so if I am adding multiple functions that are related I will try to have them all use the same parameter format. Mist will keep using both methods.

 

The actual changes I made in the pull request weight far more I think.

Having a decent logger is crucial to me. If I see functions whose first parameter is a string containing the calling function's name to write debug messages it hit's that specific nerve you mentioned. :lol:

 

The logger is the most appreciated addition. The documentation within the script itself is alright, but not as necessary due to the wiki and PDF already existing. Changing all the tabs to spaces is just annoying to me. Especially because it seems to stem from what is effectively dependent on the editor you use and your personal preferences.

[lukrop]

Point was you modified a large portion of the script, even if most of the changes were minor.

This is because git records changes per line. Because of all the indention changes it starts to look messy, I know.

 

I'm simply not used to other people contributing to the project.

That's perfectly OK. I just pointed out what would make collaboration easier.

 

The documentation within the script itself is alright, but not as necessary due to the wiki and PDF already existing.

It might seem not as necessary to you now (besides that it's not complete yet) but if new functions are written and instantly documented using LDoc while writing them, one could just fire one command and have the complete API documentation updated. Without the need to fire up a word processor and start coloring return types and parameters and after that create a PDF from it and redistribute it. LDoc seems more convenient to me. Which by no means makes the PDF or the wiki less valuable.

 

Changing all the tabs to spaces is just annoying to me. Especially because it seems to stem from what is effectively dependent on the editor you use and your personal preferences.

That's not true. My editor can handle tabs perfectly fine. I would choose spaces instead of tabs for the same reason I mentioned in the pull request, if the programming language doesn't dictate otherwise (python). The tab character can be of variable width. Code that looks good on my screen might just look terrible on the screen of someone else, unless they configure their tab-width to my preference (speaking of forcing my preferences on someone else). But this was not the reason I changed the whole file. I can work with tabs, though I would not recommend them. I changed it because the file had mixed indention and this is not an option in my opinion.

Most editors are configured to insert (a configurable amount of) spaces on tabulator key-press anyway.

[Grimes]

LDoc stuff is just more documentation and there is nothing wrong with that. If anything its most useful for anyone looking directly at the code. Yes the PDF is a little annoying to make, but its not to bad. Especially when I can rely on the wiki for more detailed and useful information. Plus the wiki doesn't require commits. I could potentially see a whole "release" be nothing but LDoc updates. :)

 

I'll probably accept your pull request sometime tonight. Expect me to make some changes once it gets merged though.

[lukrop]

LDoc stuff is just more documentation and there is nothing wrong with that. If anything its most useful for anyone looking directly at the code.

I found the HTML output quite useful too (hyperlinks for datatypes, syntax coloring in usage examples).

 

I'll probably accept your pull request sometime tonight. Expect me to make some changes once it gets merged though.

Cool! If you need me to change anything before merging it back to upstream, just tell me and I'll do it. ;)

[Grimes]

Ok lukrop's pull request was accepted. Although something got screwed up merging and caused a few issues. I was unable to revert it, but I fixed it by manually editing the file taking out any errors or oddities. The only changes I made specifically to lukrop's pull request was I commented out some of the new logger info lines that belonged to already commented out print statements, re-added the old "mist version loaded" message, and re-tabbed the whole document. I also re-enabled the trigger messages that occur when when writing data to a file.

 

For anyone who didn't have a look, lukrop made a sizable number of changes to the mist file reorganizing the script around and changing some internal variable names. You shouldn't really notice anything other than the new logger which is a nice little feature that can come in pretty handy when debugging your code.

 

I loaded up this version of mist on a few existing missions that use it and also re-dumped all of the DBs to see if any issues existed, and I didn't notice anything. So if you find a bug please report here and I'll have a look.

 

EDIT: Damn. Found my mistake. "stopFlag" should be "stopflag"...capital letter bested me again...tore my hair for 3 hours over this...:doh:

 

I made a change to the flagFuncs to also accept 'stopFlag' in addition to the usual 'stopflag'. I also added versions of the flagFuncs that are done in camelCase. I'm not gonna remove the originals though, its just an alternative way to call the flagFunc functions.

Edited January 18, 2016 by Grimes

[lukrop]

Ok lukrop's pull request was accepted.

Cool!

 

The only changes I made specifically to lukrop's pull request was I commented out some of the new logger info lines that belonged to already commented out print statements, re-added the old "mist version loaded" message, [..]

 

You could probably remove them altogether if they are not needed anymore. Unless the log level is raised from the default ("warning") to "info" they won't be printed anyway.

 

Essentially there is no difference between the "old" mist loaded message and the "new" one. Both are the last statements executed by the script and always shown (mist.Logger:msg disregards the log level) ;)

[Majinbot]

I often use mist.flagFunc.mapobjs_dead_zones for bridges and buildings, is there a script to detect is the obj is only damaged? Some objects like bridges need a lot of bombs to "die", i need to set the flag true with only a minimum damage. Is it possible? THX in advance

[Quax456]

I often use mist.flagFunc.mapobjs_dead_zones for bridges and buildings, is there a script to detect is the obj is only damaged? Some objects like bridges need a lot of bombs to "die", i need to set the flag true with only a minimum damage. Is it possible? THX in advance

 

Why don't you simply put an Infantry Unit on the Bridge? When this unit dies you gonna react on this????

 

Infantry needs by nature a minimum damage to die! :D

[blaueente]

I often use mist.flagFunc.mapobjs_dead_zones for bridges and buildings, is there a script to detect is the obj is only damaged? Some objects like bridges need a lot of bombs to "die", i need to set the flag true with only a minimum damage. Is it possible? THX in advance

 

You can also try Weapon in Zone.

[Quax456]

You can also try Weapon in Zone.

Yea and make an explosion under the bridge. Could mean to do some testing how much volume is needed to blow her up! ;-)

[Majinbot]

You can also try Weapon in Zone.

 

But the bomb in zone trigger works even if the bomb flies over the zone without hitting the target...correct?

[Wrecking Crew]

But the bomb in zone trigger works even if the bomb flies over the zone without hitting the target...correct?

 

Spherical zones work well to limit the height of the volume. A Cylindrical zone does go straight up. I haven't used the bomb_in_zone(?) function, if it has the zone_type variable try setting it to sphere. Hmmm, did not see anything in the Mist Guide about this function.

 

WC

[rvotri]

Editing a mission (miz) downloaded from Internet, i saw this callout (load mist) or something like, then i'm confused, this callout reffers a script already embedded in this mission, or is calling an external script?

[Grimes]

Its calling an embedded file. All files that you use within a mission like sound files, briefing images, or script files are automatically embedded into the .miz file. If you need to update any of those files you need to reload the relevant file where-ever it was added at.

[Steggles]

If I have a group set to late activation, am I correct in assuming that it will not be in mist.DBs.aliveUnits until after it's activated? I'm at work and can't start DCS to test it.

[Grimes]

If I have a group set to late activation, am I correct in assuming that it will not be in mist.DBs.aliveUnits until after it's activated? I'm at work and can't start DCS to test it.

 

No, they are alive. DCS has always defined alive units by whether or not they exist in the mission. Only units that are killed, deactivated, or set with a probability to spawn and never do are considered "dead". Units that are late activated are considered alive.

 

Edit, meant to attach links for the Unit.isActive and Object.isExist which can be used to determine useful data on objects. Specifically the Unit.isActive for checking whether or not its active. :)

Edited February 22, 2016 by Grimes

[Steggles]

Oh cool. Glad I asked now, that actually solves a few problems for me. Cheers for taking the time to reply.

[kievbsm]

Good afternoon, pilots!

Could you please tell me, is it possible with script's help to start mission with helicopter which should be in "Cold and Dark" state and not at FARP or Airbase?

 

Now, if we need to start Helicopter, for example, on city square, at the first step we need to land this Helicopter there, than save this activities as track, after that put this track to mission as Intro_track and as final we can start to use Helicopter in the mission in correct place and correct state.

 

Is it possible to start some script, which can put this Helicopter to the right place in "Cold&Dark" state without Intro-track?

[rvotri]

So any file mentioned in the editor is already saved? I ask about this because when i try to OPEN this file i can't read its contents...

 

Do i need to have Mist installed, or MIst is already there too?

I saw lots of scripts that says only works with MIst VXXXX. So if i don't have the correct mist version, will this MIZ still work?

 

Sorry, too many questions, but i'm little confused..

[Steggles]

rvotri, In the ME, you need to have MIST loaded into the mission. Do this via triggers preferably at the start of the mission with ONCE - TIME MORE THAN 1 - DO SCRIPT FILE, and chose the MIST file. This will embed mist into the mission and be available to use by yourself or any other script after that trigger has been run.

 

A mission with a script that requires a certain version of mist or above, and you do not have the correct version loaded, the mission will still load, but your script will not run correctly and will receive errors.

 

To see if mist is already in your mission - check the triggers in the ME to see if any load mist. An alternate way is to open the .miz file (in windows explorer or something alike) and check manually inside if the script is there.

 

Now for my original reason for my visit here - mist.dynAdd - adds the units it creates to mist.DBs.dynGroupsAdded. A few things I wanted to ask - Does it add the units to DBs.aliveUnits as well? Do they get removed from DBs.dynGroupsAdded after they are killed?

 

Edit: Think I figured it out myself.

Edited February 24, 2016 by Steggles

[Stonehouse]

So any file mentioned in the editor is already saved? I ask about this because when i try to OPEN this file i can't read its contents...

QUOTE]

 

The .miz file is basically the other files compressed into a single file similar to a zip or 7z file ie an archive file.

 

7-Zip will open a .miz file and allow you to navigate the folders and look at the scripts and other files outside DCS. Although I understand from recent discussions that pay missions encrypts some stuff by turning them into dll files within the .miz