lukrop

Please check if there is any error message in the logs on the Server, in your case your friends computer. The ge tDir in local dir = mist.utils.round(mist.utils.toDegree(mist.utils.ge tDir(vec, ref)), 0) is just a pasting error right?

Just pushed the fix to the repo. I'll release a second rc soon. I want to fix the "mid-air crash on spawn" issue first.

That's from one of these wrapped actions. I thought I already had if clauses around them to catch this error. I'll have a look.

This is because git records changes per line. Because of all the indention changes it starts to look messy, I know. That's perfectly OK. I just pointed out what would make collaboration easier. 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. 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.

Checkout the DCS User Manual in DCS World\Doc\. Starting at page 59.

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?". 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. This is true. Decent deprection warnings would be needed. It's of course very important to maintain backwards-compatibility.

I just made a pre-release here. Would be cool if someone could test it a little. Let's see if we can fix those issues and release a stable version.

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. 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. 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. Got sniped by Ian :D 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: 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 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.

Awesome findings! Didn't think of that. I'll commit a patch and will test ASAP. :) Thanks! Yep, had that in mind while checking for inAir.

I just sent you a pull request with a bunch of changes! ;)

Hey Grimes! I just forked the MIST development branch on github and I'm in the progress of making it use some code styling guidelines or at least be coherant (function declaration syntax, function names always in CamelCase) as well as adding LDoc comments to all functions for a easy generation of API documentation. I'm also adding a logger which should allow faster debugging by supporting log levels and easy shorthands. If you want to checkout the progress here is the repo.

I never doubted that ED has an internal bug tracker to which the staff and testers have access. I'd say this doesn't mean there is no right to exist for a public bug tracker. IMO a good example of a (successfull) public bug tracker is the ARMA3 community feedback site.

Verwendest du eine Achse für horizontalen und vertikalen slew? Vllt. brauchst du einfach eine dead-zone bzw. eine Kurve auf den Achsen.

Very good idea! As soon as both points Teeter mentioned are separate options everyone should be happy. There is no need to change anything in the current setup apart from making both points Teeter mentioned into separate options. The "sagging" part of this option already works fine with head tracking. You still control the head movement with your head tracking setup just that your virtual head is influenced by g-forces and e.g. "pushed" into the seat or "pulled" out of it.

I'd love to see ED setting up a official bug tracker for the open beta and alpha releases. Using a bug tracker like bugzilla, mantis or trac instead of a bulletin board has many advantages. (less dupes, required fields, bug status, ...)

They are different internally but actually, as long as you mind some different default values, they should appear almost the same to the mission designer. The mission designer has to place template units (same name, just a different default amount), trigger zones with the airbase names and CAP trigger zones. Optionally a group (same default name, redborder/blueborder) whose waypoints mark a border. Some kind of EWR units on each side and you should be good to go. Both scripts have good documentation on their variables. Mine has them above the variable, maybe I'll add them to the README.md too if someone misses them there. But yeah, one can not strictly apply the manual of the one to the other. Some (IMO minimal) adoptions are needed. Thats sad to hear Pikey. :( Unfortunately I can't say/fix much without any error/hint. Do you remember what the error was? On a side note, I just added a check at script initialization for the presence of the template units.

Is ED aware of this issue? IMHO one of the most immersion breaking bugs (followed by the HUD Z-layer issue). And it's in the current stable release. :/ e: title should probably be something like "Most 3D models not affected by dynamic lights".

Today I had some time testing the script in 2.0. I experienced the despawn bug Pikey and some others mentioned. I'm not sure how the heck this could be happening. The script only destroys a group on event handling and after some conditions are met. Those events are crash, pilot dead and engine shutdown. The only explanation could be that somehow those events are triggered at the wrong time. The next very odd thing is, that the units were removed but their flight (internal table holding information about this group) was not. If the script destroys a group it also always removes it's entry in the flight table. Also the script only destroys a whole group and I saw those units disappearing at different times. The units even disappeared before they met any enemy, they were the first flight to spawn, they were just on route to the target area.

I'll have a look at it. Thanks for the feedback so far! edit: yep! Actually currently, as Pikey already noticed, this is the only way a CAP is considered "finished" now. I guess we'll have to spawn new CAP flights as soon as they (active CAPs) decide to go RTB. If you change your mind, the part which matters is right here. This function is responsible for handling the despawn and removal of flights.

This is because I changed the default template unit count from four to two. Effectivley this means you have __CAP__red1 and __CAP__red2 as well as __GCI__red1 and __GCI__red2. This is also the way they are defined in the latest showcase mission. The script seems to believe there are still flights in the air and patrolling. Probably because something went wrong while detecting if they got shot down or started persuing some intruders. Though I think this is working and only the detection of their death/crash seems to be the problem. If the script believes all 3 zones are still patrolled there is no reason for it to spawn any new units. The border detection solely relies on MIST. I think this is working too and is affected by the fact that the script believes it has CAP flights on station for intercepting any intruders. The whole thing falls apart as soon as it's "feeded" with false information (e.g. the script believes flights are still there which aren't). I'm unsure which event is the best to catch. I went for PILOT_DEAD because I believed it to be the one which would be fired in any case. Maybe we should also try to detect crashes? I though in a crash the pilot also dies... well not in the case he ejects beforehand right? This might actually be the reason why the script misses those "unit deaths". I think I might have found the bug while writing this. :D e: The problem with the template units is very strange though. Since it works for a decent amout of time and then seemingly randomly mid-mission stops working I'm not sure if this bug is to be found within GCICAP or the mission itself. Maybe something within MIST or a newly introduced problem by 1.5.

A quick glance at the logs tells me there might be something wrong with one of the template units as the script can't find it. I should probably make the script write a decent log message about it. Double check your template unit's names. It's very likely there is a typo in there somewhere. 09673.041 INFO SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "e:\temp\DCS.openbeta\/~mis000067A2"]:881: attempt to index local 'template_unit' (a nil value)

At this point in time in the mission, were all CAPs already down? Also it seems that the function which handles detections from the EWR doesn't find the group of the unit which is intruding. Since the script fails at this point, strange things might happen afterwards. I just added a check if the group exists, please try it again.

Thanks that's a good list! I'm sure I'll be able to implement most of the stuff or change the way it currently works. :) edit: Or anyone that feels like he is able to. I'd love to see some pull requests on GitHub (your contributions, for those who are unfamiliar with GitHub). I think I should write something on "how to contribute" into the README.

Not that I'm aware of. That's why I wrote dedicated under inverted commas. :)

Actually I am/was testing on a "dedicated" server. The showcase mission is running pretty good for some hours now. Regarding the error you posted: Looks like one of the zones is not existing. You could check the names of the triggerzones.