lukrop

This might be me hairsplitting but posting a link to a github repository is no release in my opinion. First of all it generates user feedback. If I draft a release (aka tagging) on github I found the code at that specific time to be mature enough to use it in a production environment mission. There is always the possibility of tracking the master branch's latest commit and might get some fixes faster, at the expense of the changes not being thoroughly tested, until another release is drafted. :) gcicap is a global table. Child elements of this table like gcicap.red or gcicap.blue.cap are tables too. Every function is a global function as of now. This is something I still have to change because external code shouldn't mess around with most of them, though some still need to be global (init, main and some others). Currently it's possible to read (and alter) any of those variables from "outside" the script. For example one could tamper with gcicap[side].cap.flights and remove/add flights without proper handling and so on which needs to be addressed by making them local to the script scope. After that is done one could use getters to make those variables values accessible to export scripts for storing them somewhere for persistence. As you see there is still very much room for improvement. The first thing would be writing a decent logger since I'm tired of those if statements everywhere, which I'm currently at, amongst other things. (hint: I didn't push as of yet but I got a repo for all that stuff called MSE. I hope to push some useful tools for us mission designers/scripters there.) I think you just lead me onto a bug in my script. The logistics counter just gets increased by one where it should be increased by the group size. Regarding despawn of the whole group: IMO every removal of a aircraft on the ramp breaks immersion if a player sees it. But sadly we have to do it for the scope of this script. Maybe we could delay the removal of each unit differently so they won't get removed all at the same time if this helps some as you stated. Even more sophisticated would be a check if a player unit is inside a given radius of the unit to despawn. If there is a player the despawn gets delayed again and the check is run again later. This way we could make sure players would almost never see the despawn (excluding F10/F2 and other external views).

Good idea and good point. Though I actually didn't release something per se as of yet. If we are super correct this is bleeding edge software. :P Actually I'm thinking of drafting a release in the next few days. After sorting out/identifying this issue. whoops, sry for the double post.

Just sent SNAFU a PM. ;) If a airbase changes its coalition it won't be listed anymore by coalition.getAirbase(side) of the given side so my script would just ignore the airbase. As if you placed the triggerzone at a neutral airbase. The script checks for airbases roughly every 30 seconds (if using default gcicap.interval).

One should be able to workaround the unit:destroy() issue just by scheduling it to a later point in time. In regards of performance this is a good idea since code inside event handlers should run/be done as fast as possible and the deletion of an object could take some time. Though I dunno what the engine really does behind the scenes of course. Maybe you can dissect/adapt this function for your purpose, essentially it does what you want but checks if all members of the group are on the ground.

This mission is, as the rest of the repository, licensed under a slightly modified MIT license. Do whatever you please with it as long as you move inside the license terms. :) The license basically (too put simplified) just restricts making money off of the stuff inside the repository. Yeah, this is because the version in github, which i forked was a failed release IIRC. I'll fix those default values. The pilot name is all that matters. If you don't change the default value of 4 template units the script will never use the template unit 5. You would have to set: gcicap.template_count = 5edit: Actually I already fixed this. This was just to demonstrate that it's possible to have them in one group or seperate. Both is possible since only the unit's (pilot) name matters to the script. Thanks! Noted. :) Just noticed that my email notifications were turned off. Sorry! As you see, sometimes I need longer to respond and this might not change the next weeks since I'm fixed up pretty good at work right now (one doesn't rebuild an entire network infrastructure everyday). If you, as current project leader, think this would still work out I'll take over. ;) Cheers!

And I'm glad you mentioned/suggested it. Maybe I underestimated the support side and got intimidated by it for a second. :) Fixed and pushed to github. Still need to update the showcase mission reflecting those changes, though.

First of all, sorry for the late answer. Had some very busy days at work. If a user has a mission running with the original GCICAP ideally he could just change the trigger to include the forked GCICAP script (instead of the original one, hence the "drop in replacement") and everything should work as before but including improvements (performance, GCI/CAP limits and so on). Keep in mind though this only works as long as the user didn't change any variables (talking about zone count, group count for example). Of course if the user did so, he has to change the same variables in the forked version too. The master branch on github contains a version which is almost feature complete. The only thing missing is the airport cleanup code if AI goes mad and collides or gets stuck (they do get removed if they correctly park and shutdown their engines). So I would consider the current version a fully fledged replacement. I really have a great deal of respect for your commitment to this project, to this extent and over this long period of time. But I can't and (this might sound harsh but please don't take it the wrong way) do not really want to bring up all that energy to search through pages and pages of posts to filter out bug reports, dupes and build missions for other users. What I will do: (regardless of what you decide to do with the original version) Try to fix issues reported on github in a timely fashion. Check on a forum thread but maybe not as frequently as you did. I really don't want you to think that I want to toss you my code and burden you with the support of it. Honestly I'm not sure what would be the best way to handle this. As I stated I can provide support only the way I mention before. But I really see it the same way as you regarding you putting more time into the original script. I think I would like the idea of just adding the link to my repository in the OP and add some comment about how I would handle support, keeping the name of the script and keeping this thread for discussion about it. But I'm not in the place to decide that. If you think the way I would handle support is not enough I would just open a new thread and probably rename the "fork"/rewrite. :) It actually started out as a fork but quickly became a rewrite. I'm using the word fork to prevent confusion between the GCICAP scripts and to some extent to make clear who came up with the initial idea. On a side note: the community should be glad that it has members like you Stonehouse. Not many people would show that much dedication. (probably including me. :D) GCICAP is logging to the DCS logfile which can be found in your Saved Games\DCS\Logs directory. Looks like you are missing MIST. Maybe you didn't "load" it before GCICAP or missed it altogether.

Please follow these instructions or take a closer look at the showcase mission. If you still have problems you can open a new ticket here. It looks like the script is called too early. Didn't experience any problems with the trigger singleton until now. Please check if the showcase mission is working. You should double check your units names regarding the template errors. But let's not hijack this thread just yet. ;)

As I have always stated, it's a rewrite (working in 1.5). I completly support your point regarding rewrites and the co-ordinated enhancement of stuff that is already there. Initially I wanted to do exactly that, enhance/fix the original version. I don't want to offend anyone, as I'm sure everyone here is doing their best (in their freetime, for a long while) but I thought it would be easier to rewrite the script instead of analyzing the code as it seemd a bit overcomplicated. I see no benefit in selectively merging code of the fork back into the original version since it's a complete rewrite. Besides that, as you have already stated, it would take even more time (still I wouldn't see a reason behind it) But the rewrite is written with backwards-compatibility in mind. In most cases you can use it as a drop-in replacement. I see two options: The fork superseeds the original. I rename the fork and it lives as seperate project. I would highly appreciated the first variant. This could be achieved by either, me sending you a pull-request Stonehouse, which would effectively replace the old version, or we link to the repository of the fork everywhere. Again, I really do feel you guys. I've been there myself. I have a simple policy regarding that. I use a bug tracking system. In this case the issue tracker of github, for bug reports and feature requests. Both the developers and the users benefit from a decent bug tracking system and honestly, I don't know why ED is going through the hassel of handling all the public bug tracking, for the OpenBeta and the OpenAlpha, on the forums. Of course I would look into a forum thread now and then but for the most part a good README, maybe some wiki entries (also github) and the issue tracker should suffice. If you deceide to pull the changes into your repository, you would need to give me the appropriate permissions to the repo for supporting it (e.g. push, manage issue tracker and so on). But in the case you want me to I can always rename the fork and create a seperate forum thread. Supporting the fork as I wrote above.

What is the license of this project? I couldn't find one in the github repo or the guide. Or is it not licensed under any open source license? I'm asking because I wanted to fork it and change some stuff and send you a pull request. But in the case you don't want to merge my changes back into the main project I don't want to have to trash them (= not releasing them on github under any OS license). So I'm asking beforehand. :)

Since the code, in the github repo, is licensed under the MIT license everything should be ok. ;) Whoops, didn't even notice that. That was the part I didn't want to do, without checking in on this thread first, since my stuff could be merged back into the original repo. Thats how open source should work. So we don't have masses of forks, outdated main projects and users confused which version to use. But this is entirely up to the original author(s). I would send a pull request if anyone wants me too. Woha, nobody retires. :D That's the good thing about version control systems, we can collaborate. I feel you though, didn't get much flying this weekend either.

I forked your repo and almost completly rewrote this gem. You might want to check it out. If you want me to, I could even send you a pull request but I still got some plans with it so maybe I'll wait with the pull request. https://github.com/lukrop/GCICAP Here are the biggest differences at a glance: https://github.com/lukrop/GCICAP#fork-changes

I just noticed that since 1.5.1 it seems that whatever countries I moved around the factions didn't have the desired effect. E.g. I moved the Ukraine from RED to BLUE. Saved and started placing units. I soon noticed that my ukrainian units all still were RED. I worked around that by creating the scenario with the stable release and kept editing afterwards in the beta mission editor. Retrospectively a game restart might have sufficed. The weird part was that in the .miz file the missions file containing the coaltions array was correct but still the editor displayed them as RED. Maybe this is related.

Giev! need haz M2000C! :P