Stonehouse

bump

Hi Grimes, Yep confirmed that it works fine in cockpit for a player. It was only spamming the messages when in the game master or observer slot. Thanks. PS AWACS 1.7 works pretty well too

Ok thanks Grimes. Unfortunately it does update pretty often as it's giving BRA info on intruders that have been detected by EWR. I will try to rethink it. Perhaps I will end up having to release the new version with that as a known issue and have the GCI messages turned off by default especially if Ajax's AWAC's function is ok under 1.5 as that is a much more elegant solution in any case which I often recommend to people using GCICAP. So first thing I will check Ajax's script as if that is ok then the priority is much lower than the other issues.

Ok that's useful to know. The only things I know in the script that could cause that is the resettask function and the RTB function. Both do a reset of the current task for the aircraft in particular tables. Perhaps the CAP flights are ending up on these tables by mistake. So I can add some more debug and see whether that is the case.

Brief update. Generally the conversion to a 1.5 version of the script is going well but I have two issues causing grief; A CAP flight will at times head off in a random direction. While not 100% sure I don't believe this is being caused by the waypoints being generated by the script but something else happening. Unfortunately it doesn't always happen and it doesn't seem to happen at a predictable time when it does - which makes it hard to track down. The other one is the GCI messages, again while not sure I think this is a Mist issue or some quirk of this script and how it interacts with Mist. I *think* Grimes is investigating this so I am currently hoping he comes up with a change to Mist that makes it go away. If not I will have to look into it more. There have been some other things introduced along the way like configurable formations for the CAP and GCI groups, fixing the start airborne issue so that only the first cap flights start airborne not all of them. It also is now possible to have it set for each faction. ie blue 1st CAPs starts airborne, red doesn't. Dynamic airbase handling has been introduced as well so capturing an airbase makes it available to the capturing faction - at the moment its a bit like magic in that if it has been set up with a trigger zone so it is usable by GCI and CAP, groups of planes will launch from there as soon as it's captured. I hope to change this in the future to make it driven by an event or at least build in a delay. There are a few other things as well. Will have to go through and update the manual again anyway. Quite a bit of tiding up still to do in the script as there is masses of debug floating about at present and quite a bit more testing to do so it will still be awhile before I make it available and I would hope to at least get the insubordinate CAP group problem fixed before you see it. Cheers, Stonehouse

Ok thanks Grimes. Will have to be the 2nd method you mention though as only a portion of the first waypoint gets written to the log. It finishes part way through the advanced task list for the first waypoint and doesn't display all of it. I have half confirmed that it isn't the waypoints points being built that cause the CAP flights to wander off as what I did manage to do was to write the y,x co-ords out for each waypoint to the log and I was able to use those in conjunction with a hand edit of a dummy mission to demonstrate that all the waypoints are within the cap zones. So it may be the switch waypoint command to go from last waypoint to 2nd is failing intermittently (don't really think so) or possibly the waypoint options are causing grief or some other part of a waypoint (your 2nd method will help there) or some other event in the script is making it happen. It only happens sometimes and it only seems to happen to a single group of the 4 spawned (as in 2 red and 2 blue). Question: would a Controller.resetTask change the points for the route or make the AI not potentially follow them? no enemy is close by the way. These guys have been following the generated waypoints and then just head off in a random direction. Sometimes they head back after awhile and seem to start following their route and other times they just go off the map. It's an irritating problem because it causes a new cap group to spawn at least and if they head over the border they trigger an unplanned war for the mission builder.

Using mist.utils.tableShow to try to dump the table of waypoints being generated by the GCICAP script for each group of CAP fighters and I am finding that I only get about 75% of the first waypoint listed in dcs.log. I assume it is just too large for something and is truncating the remainder of the table. Any ideas on getting the full table dumped into the log? Thanks, Stonehouse

Ok apologies. I got fooled by my settings in 1.2.16 - which are metric - and therefore show kmh. I have it set up as imperial in the beta but just assumed it would show mph but going back to 1.2.16 and setting it to imperial gives kts there too. If a mod wants to delete this or mark it solved so someone else doesn't repeat my goof that would be appreciated. Thanks.

I would expect ground unit speeds in the M-E to be either kph or mph however I'm seeing them as kts screenshot attached.

Hi Grimes, Yes reworking GCICAP using v4_0_55 of mist. I haven't changed this chunk of code but have noticed the issue since first beginning to test under DCS1.5 beta. I assumed I had code that was no longer valid but reading through the mist doco I got the understanding that you had updated the message.add so that it should work as per 1.2.16 without us changing code. So was obviously puzzled why it wasn't working. The group id is populated as below slightly higher up than the previous code snip: local actualintrudergroupID = Group.getID(actualintrudergroup) So if it isn't a mist issue is kind of sounds like it may be something going wrong with Group.getID and so I get a different message name each pass through??? That sounds wrong though because Group.getID is used all over the place and if it was buggy you'd think there would be heaps of people posting about it. Thanks, Stonehouse

Seems to be broken under 1.5 so if you have time to have a look at it Lilkiki that would be great. Thanks, Stonehouse <edit> Fixed it Lilkiki by adding the entry.lua file to the mod. If you remember I changed things a bit to have a large medium and small version of your fire object by fiddling with the lua entries so my entry.lua looks like the attached. It may differ to what other people have and they will need to edit the attached entry.lua to make it work. It goes in the actual mod folder so for me under jsgme the folder structure looks like Fireobjects\Mods\tech\Fires and the entry.lua goes into the Fires folder. entry.lua

Question about messaging via the mist message.add function. I'm getting the issue where the same group of intruders are triggering a separate message line. Additionally each message is taking two line due to the "----------Combined Arms Message-----------" By my understanding because the message name is the same I should just get the same message line updating because Mist sets the extra value in the mist function to make it work like it did previously. Have I done something incorrect in 1.5 terms? For the Combined Arms thing the message is going out to red or blue. How would I send the message at the faction level but not to the CA slots - I assume this would mean it would go back to a single line per message. Thanks for any help anyone can give. Cheers, Stonehouse

All the script files end up in the new folder structure \l10n\DEFAULT in the miz file under 1.5 for a DO SCRIPT FILE. Don't DO SCRIPT lua end up imbedded in the mission lua?

The released September script had some problems people had noticed just prior to 1.5 coming out and I was already trying to fix. The January script + updated Mist does kind of work but there seems to be some problems there too. I do not know at this point whether it is entirely due to 1.5 bugs or script bugs. Things I have noticed are no GCI alert messages (probably not that important unless it is causing a function call to end in error), aircraft sitting in HAS and not taxiing and also not hitting the stuck time limit and despawning. There may be other issues I have not seen. Realistically though I have limited time and resources so feel at this point that spending time fixing the January script is not very efficient use of time and so I am presently trying to get the September script issues corrected and also 1.5 compliant. Can't really offer an ETA as how much time I can spend on it is subject to a real life happenings as well as sometimes you get lucky with an issue and sometimes it's a bear you spend ages wrestling with until the light pops on and you go "Hey wonder if I did this..........". So pretty much I should retract the September release back in and make it WIP and just keep on working on trying to get it going under 1.5 as that is where things are going to. I did have most of the September issues sorted just prior to 1.5 except for CAPs wandering off at random. Chameleon_Silk suggested it might be badly formed waypoint definitions and there does seem to be differences between spawning airborne and on the ground so the suggestion seems to have merit. That is pretty much where I was up to and then 1.5 came out so making it compliant to 1.5 is on top of that. I can say that my first attempt today resulted in no aircraft being spawned so not so good so far and a bit depressing.

Thanks Grimes. I'm guessing from your reply that all is ok but also noticed a maxDictId (in my case this was 33 which seems quite low and possibly related to just the units I placed) - where we are spawning aircraft into a mission via a script do we need to worry about what the value is? if the base mission is built via the mission editor with various units doing their thing and we have something like GCICAP spawning in units is there any issues around this number? ie the spawned units + mission editor placed units exceed it. Cheers, Stonehouse

As the title suggests while trying to figure out issues in GCICAP, I've noticed that in a mission editor generated mission now all waypoints have a name by default eg DictKey_WptName_16 The numbering scheme seems unpredictable to me at the moment with waypoints starting from DictKey_WptName_7 for the first group placed. Anyway what I wanted to ask - most likely Grimes I guess at this point - is are waypoint names now required and do we have to include this when building the table of points in a script. If so how does the numbering work? Thanks, Stonehouse

Ok thanks. Comparing to some of the other shots around the place was starting to think it was new video card time. I mean it probably is anyway but at least now it doesn't need to be straight away and I can wait for my tax return lol.

Updated MIST if used yeah? You need 4.0.55 for 1.5

If the mission is still 1.2.16? There was a change in the internal format of mission files in 1.5 so for a 1.2.16 mission to work with 1.5 the minimum is to resave the mission under 1.5. Mind you that will break it for 1.2.16 users.

Thanks Ajax!

It seems to be completely related to the chosen skin for the aircraft. I was testing GCICAP earlier today and noticed that the F86 now has several official skins so I tried them out. One of them has polished leading edges and in game they appeared much as other people's screen shots. Can anyone confirm that is true and the original default skin for the F86 doesn't produce the polished metal look in game for me? Thanks, Stonehouse

Ok I felt obliged to look at it now so I copied one of the January demo missions over to my beta install and via the M-E updated the version of Mist to be 4.0.55 which I think is Grimes's latest for 1.5 beta. Anyway generally the January version of the script does work but even this short test showed me that the GCI alert messages is broken (which is expected due to the changes in messaging) and that there is either a taxiway problem at Kutaisi or the script has an issue as some planes seemed to get stuck in the HAS there. I guess that also means that the stuck planes logic has a problem too as they should have despawned. The spawning and intercept logic seems to be ok from what I could see in a short test. For me I think the best way forward will be to leave the January 2015 version as the 1.2.16 version of the script even though it has some warts and to try to bring the new September version up to scratch for DCS 1.5 and that will be the proverbial fork in the path for the script. Hopefully I can get it sorted out by the time 1.5 is out of beta.

May help http://forums.eagle.ru/showthread.php?t=114030

I've been hoping to find time to try it out over this weekend along with (assuming it works lol) continue on with trying to fix the version I just released. I will check the January 2015 version first though as that was the last "good" version.

There was a mod around if you search that sub forum that added bombs to their payloads.