Stonehouse

Country assigned in description.lua not matching country being used in M-E?

Didn't keep the link but did cut and paste the info into a document of tips and techniques. So hopefully this is what you are after. <snip> If you’d like to place planes on the ground, there’s now a way to do it with a slight ME modification. Take note controlled AI planes explode upon spawning. Set them to uncontrolled in order to avoid it. To spawn planes on the ground, the following has to be added to the plane_one_point and plane_first_point tables in the MissionEditor\modules\me_route.lua file: Code: actions.takeoffGround, actions.takeoffGroundHot Should look like this: Code: plane_one_point = { actions.turningPoint, actions.flyOverPoint, actions.takeoffRunway, actions.takeoffParking, actions.takeoffParkingHot, actions.landing, actions.takeoffGround, actions.takeoffGroundHot, }, plane_first_point = { actions.turningPoint, actions.flyOverPoint, actions.takeoffRunway, actions.takeoffParking, actions.takeoffParkingHot, actions.takeoffGround, actions.takeoffGroundHot, }, DCS will say it’s an air start but they start on the ground. This way AC can be placed everywhere, as long as it’s flat ground. As all the props are able to take off and land on the grass just fine, this could be a great addition to some WWII environments <endsnip>

I have a free dropbox account and that works fine for me, not sure how to get it though these days as I have had it for years and used to use it to do PBEM games with a m8 in the UK. Only 2.5gb though. Also heard meganz https://mega.nz/ is ok and gives you 50GB in a free account. Others in the US might be able to advise of other fileshares that are local to you. Not mediafire though please as it spits up lots of popups and ads and tries to dump cookies etc on your pc. Definitely don't share direct from your own drives. Also just noticed that DCS user files allows a 100mb upload.

Any chance you could use an alternate d/l site for mission 2? I don't really want to give an email to a filehosting site if it's avoidable. Cheers, 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.