Stonehouse

If it is a script issue then you'll need to PM lukrop. I believe does something along the lines of spawning the aircraft group, waits a short period like 3 secs and then assigns the flight path to the group. It was to get around a DCS quirk at the time I seem to recall. Possibly a set of waypoints is never assigned to the spawned group.

Double check your template aircraft and make sure they have fuel and are correctly named with no leading or trailing blank spaces in the name. Other than that I don't know and you might have to eventually post up your mission. I'll be on vacation from tomorrow for a while so hopefully other people who use the script regularly can help you.

Definitely needs to be the airbase names recognised internally. Without seeing the mission I would probably check there are no leading or trailing spaces in the trigger zone names and that you definitely have the case etc correct for the name. Don't quite understand your later comment about 1.5.5?? The NTTR map only works under DCS 2.x. and the NTTR airbase names have no relevance to 1.5.5.

See here Invisibull https://forums.eagle.ru/showpost.php?p=2958124&postcount=1150 I think that the internal base names do not match the name shown on the map so when you set up the trigger names they are not the real base names and therefore the script doesn't find any GCICAP designated bases and will not generate flights. Perhaps between you, Grimes and Sierra99 you can confirm or deny this theory. If you can't do a script to dump the base names then you can use the attached miz at the above link and just make every base a red coalition base and you'll get a list on screen of the internal names. Heading off to crash, a very long Sunday in the office today.

Really don't have much time as I said, however I squeezed in a quick test a bit before heading off to sleep after a long day at work. Don't know for sure if this is the issue but perhaps someone can try a quick test set up of lukrop's script using the names in the attached pic or set up a little script to dump the airbase names for NTTR. I think that the issue may be that the map names for bases do not match internal names so there is a disconnect between the zone names people enter and the actual airbase names. They need to match for the script to use the base for spawning GCI&CAP groups. The zone designates the base as a GCICAP capable base if you will. Ideally it would be nice from a scripting viewpoint if the internal names match the map names but if they don't or can't then that's how it is and we'll need to adjust. If it was an easy change however for the dev team to make at this point in time then it would definitely make life easier in the long run. Probably for everyone actually, not just the non ED scripters. Anyway test results below along with the test mission. Best wishes, Stonehouse testgetairbases.miz

Invisibull made the same comment that GCICAP has stopped working on NTTR. I haven't got time to follow up on it at the moment due to work stuff but the obvious change is the additional air bases. A lot of stuff hangs on the script getting the details of airbases into a table so possibly something is going wrong there. Perhaps the returned values from coalition.getAirbases are different somehow and the script can't deal with it??? That's just a guess anyway. Invisibull was PMing lukrop so perhaps he'll look at it.

I'm flat out with a software release for work this week and next (at work now on Sat since 8am with a 9pm go-no go time and ditto tomorrow) so while I have the odd moment to check the forum while waiting for stuff to migrate I don't have time or indeed access to DCS this weekend (lol funny how employers don't appreciate flight sims properly hey?) to check. Perhaps someone can create a quick check script to see if getAirbases is working still or if the returned values have changed. That at least will narrow the scope of investigation. No idea if lukrop still comes by to look after his version of the script or not but perhaps also PM him. Does it work on 1.5.5? It might need an interim 2.0.4 version.

Haven't looked at it (for a long time especially on Nevada) but only thought that comes to mind is that assuming all your set up is correct that the addition of the extra airfields may have broken something to do with coalition.getAirbases. If this doesn't return the airfields properly or something in the values returned has changed and the script can no longer deal with it then the script will not be able to correctly place GCI or CAP groups on bases.

Ok I did say "as far as I know" and I've never pretended to be an SME on either creating mods or lua coding. I don't do the EDM side of things so it sounds like Markindel would have to build something as well as the lau. Skatezilla's comment is very high level from my point of view and doesn't give any detail about how to actually achieve the end result. Are there particular parameters to set on the declare loadout or pylon definition to rotate the bombs to vertical? If the bombs are internal does it still require the rack object to be built? Any examples of similar things I can look at to try to figure it out? I am not aware of any aircraft in DCS that hold their stores vertically, is there one? Obviously from both of your comments the matter is something that is easy to resolve if you know how but if you don't know how then it isn't so easy :music_whistling: Sometimes even knowing the right question to ask or even that something is theoretically possible is half the issue. It would be really useful for the community if this sort of knowledge was held in a wiki or some sort of document - I know the A-4 team has considered posting something like this when they have time and I hope that comes about. It really would help people who are trying to build user content for DCS

The way we actually released the B17 mod was to have two internal "racks" each carrying half the bombload. This translated to two internal side by side mounts in DCS terms. This appeared to best match cutaway diagrams and pics of how the bombs were loaded into a B17. For the Betty you'll see the bombs are loaded in line astern - as Bettys also could carry a torpedo internally in the bomb bay meaning a long narrow bay the bombs were held differently. Couldn't do the He111 correctly as the current DCS pylon setup (as far as I know) won't support holding the bombs vertically only horizontally. The P38D was actually a pretty early model and was pulled from service fairly quickly and classed as unsuitable for combat and according to the research info I found didn't have any hard points at all. However Markindel had already included them in the model. So the P38D mod is really a fictional hybrid between a P38D and probably an L model (in terms of loadout not shape). I actually do most of the research and lua set up for these aircraft mods and endeavour to make them as accurate (P38D excluded) as I can as far as the defined speeds heights and loadouts etc they are released with. The other limiting factor is my level of knowledge of getting the lua side correct. That said I have no problem with people pointing me towards better data and making corrections and freely acknowledge that all of them are not correct so far in the SFM config - most of the aircraft B17, PBY, DC3 etc climb much too well for instance in Markindel's "official" releases. This is due to lack of knowledge of how to do the SFM setup and information to get it correct at this time. Also the amount of ammo for the turret guns - the AI is set to spray and pray and to have realistic ammo loads would mean the bomber would defenceless in under a min. So I felt forced to increase the amount of ammo to allow for "realistic" gameplay even though it bugged me to do so. Personally I don't like the idea of changing the ammo explosive power and fictional loadouts and unrealistic "improved" performance changes but have no objections to other people having fun with it. They are all Markindel's mods in any case so it's his call and he'd say something if it bothered him.

v1.15 mentioned in first post but v114 found in the dropbox location? Typo or just tired and (like I often do) made a mistake uploading the file? Enjoying your work! Thank you!

Thanks. OK sounds like trial and error time with the forward gear values for me but at least I know for sure now that gear 1 is forward.

Vehicle question for anyone who might know - top speed and acceleration and gear ratios - how does it work? Any clues? Some obvious ones - max_road_velocity = 72.2222, --260kph max_acceleration = 4, --about 0-100kph in approx. 4-5secs But then the gear ratios X_gear_1 = 3.636, Y_gear_1 = 0, Z_gear_1 = 0.842, X_gear_2 = -1.215, Y_gear_2 = 0, Z_gear_2 = 0.769, I assume gear_1 are forward gears and X is probably first and Z is top and gear_2 is reverse??? Can anyone explain these parameters at all? Does r_max affect top speed and how fast you get there? Best I seem to be able to get is about 130 kph and it takes quite a while to get there. Thanks, Stonehouse

Possibly the waypoint for the bombing action is too close to the target. Working on the B17 mod I found it needed about 10:1 ratio distancefrom target:bombing height. So bombing from 8000m needed the waypoint for the action to 80km out from the target. Also needed to make the flight path between the action waypoint, target and first waypoint after target as straight as possible. Also on the action itself it may help to specify bombs and ALL rather than auto. Not saying the above will definitely work for you but perhaps it may help.

It's a bit of a grey area for the first. You should be ok but I always used to specify mist then GCICAP as it minimises the chances of other scripts clashing with GCICAP. Realistically this mostly comes down to global variables and table names that might accidently be in common between GCICAP and some other script. So the more scripts you have between mist and GCICAP the more chance for a conflict. On your second question yes you should be able to - a mission start trigger is a trigger after all - but realise that a mission start trigger fires before anything else in the mission happens and therefore any pauses etc etc are already done before the players see it. It is the reason why I advise people to use a mission start trigger to load scripts like mist and GCICAP rather than the once, time +1 method. The once trigger loads the scripts after the mission starts. Anyway so the quality of your results may vary and it's going to be all trial and error but technically it should work I believe.

Essentially the redborder and blueborder waypoint path would need to be redefined every time territory changed. I guess you could try rebuilding their flight path on the fly via another script but in a hot war situation it doesn't really matter about borders. What matters then is the radar unit locations and airbases. One of the last wip versions I was doing did take into account airbases changing hands and would spawn GCI and CAP on newly captured bases. I didn't release it because of other bugs remaining and stopped work on it in the end as there was no point. I guess perhaps you could start with a radar unit placed at each base and when one changed hands use another script to destroy any of the old owners radars within a given radius of the base and spawn in a new one for the new owners. That way radar coverage would be aligned to the airbases you hold. No idea if lukrop's version is checking for dynamic base ownership. That would tend to generally move the front and the CAPs and GCIs along with it I think.

As far as I am aware the borders are still defined by the path of a late activation unit that never spawns and are therefore static. The best available at present is the ability to change the variable controlling hot/cold borders using an in mission trigger. eg at a certain point the cold war goes hot. To do what you want Drexx would require more code changes to use something else (probably use airbases and ownership) to define the border. Add an enhancement request to lukrop's github site is my suggestion.

A present I believe that the current script will not stop an interception once the aircraft is assigned to the target unless the intercepting aircraft is low on fuel or out of ammo. The only real solution is to contact Lukrop and ask him to modify his script so that if borders are turned on interceptors will RTB when they pursue their target across a border.

Any trigger but I would recommend a mission start trigger for what you seem to be wanting. Don't specify a condition so that the trigger will always fire and put the trigger action as explode unit and specify the unit and explosion strength. If you put one of lilkiki's fire objects (they are invisible objects that when destroyed give off smoke and fire) at the same place as the static unit when the static unit is damaged you should cause the fire object to start generating smoke and flame too. The tricky bit is getting the explosion strength right so you have a damaged plane object that is smoking and burning rather than just a black smudge. The stock smoke and fire stops very quickly so if you don't use Lilkiki's fire objects you'll need to trigger smoke on the wreck when players get close. Mind you it will be white smoke at best unless you change your story line to support survivors popping smoke and flares when the players get within a certain range using trigger zones etc)

Lilkiki's fire mod actually comes in different sizes and does definitely work under 1.5.x https://forums.eagle.ru/showpost.php?p=2311051&postcount=18 FYI need to do an explode strength 1 or 0.5 on these fire objects to destroy them to activate the smoke and flame. Suggest using a mission start trigger.

I actually meant a code change to the GCICAP script to force them to return to base. You'd need to talk to lukrop these days.

Introducing CAS missions and Helo's would be essentially creating parallel versions of GCICAP with the appropriate skew as the waypoint actions, mission profiles etc etc are totally different - so pretty much "some work" really is a lot of work in translation. It was on the list at the time I was working on it and I had test bed recon stuff reporting sea, ground contacts as per the GCI radars so theoretically could then have generated cas flights (which was the aim) but that was a long, long while ago now, perhaps contact lukrop and see if he is keen? If you are talking about a cold war situation and stopping the pursuit continuing too far into your airspace then that was another one on the to do list that didn't get done. Probably the easiest way would be to RTB the interceptors once they get into the opposing air defence territory as long as it is a cold war.

Ok hopefully the attachment works this time - my JSGME set up which I believe works ok. DCS_Animals_Mod_V0.1.zip

They are the same in concept as lukrop wrote his script using the functionality of the old one for his design base. Setups are basically the same from what I recall so probably can be switched with minimal effort. His code does things completely differently though so while the net result is similar there are some differences. Quirks if you will. If you are seeing just the first CAP group start on the runway rather than out in their CAP zone it probably isn't that it is borked just that you need to change the startairborne flag to 1 if the latter is your preference. If you have the spawn mode set to spawn GCI and CAPs on the ramp and they instead appear on the runway then perhaps there is an issue. There are a whole block of parameters at the head of the script for the mission designer to customise to get the behaviour they want.

From memory that should only affect the first group of CAP aircraft at the start of the mission. Basically it was to either have them on the runway ready to roll and heading for their cap zone after take off (when it is set to 0) or to spawn already in the zone (set to 1). There should also be a spawn style parameter where you choose what should happen for all other groups. This can be set so groups spawn onto the ramp, the runway or already airborne - the variable used be Spawnmode in the old script. The mission designer needs to set these two parms to suit what they want to happen in their mission. I don't believe lukrop changed the functionality of the script in this regard even though the code to achieve it changed. Could have a bug in his code of course as happens to everyone.