Complete transport script

Same here, I want to prevent unloading troops if the gunner door is closed. I can get the state of the pilot/copilot doors using one of the x:command triggers, but I can't find the command code for the gunner doors.

I made a modification that improves the config phase much more, cause know you don´t have to care about commenting or uncommenting the trigger names. If the trigger name that you used is not an existing trigger script will ignore it. This means now you will have a set of predefined names available (simular to the units names) and you just use any of those names in the mission.

My modification of Deck's script uses "template" triggers in the ME to define the trigger zones and pass variable info to the script (like zone name, zone name as used on the menu, pickup or loading zone, smoke color, and smoke altitude.)

Hi,

Finally the script got it´s estable version v1.0. To distinguiss it from the previous test versions I decided to change it´s name to CTTS. Configuration is super easy and flexible (now you don´t even need to use triggers in mission or worry about namings as a wide set of predefined names is available by default). Deployed troops will now move to close enemy positions as well and a couple of standalone functions are included to be used during mission too.

Please read first post for details and updated files. Prepare for a good set of Airmobile missions to come to take the best out of this script. Current pack updated too :-P

Happy transporting!

New standalone function CountExtracted added. Please read first post for details. It´s used to count the amount of extratable units inside a trigger and result can be accessed in mission via two user flags.

I just noticed the new features and have tried them out in a mission. Great work on theis script geloxo. Much appreciated!

So the groupcount can be displayed as a text message? Was thinking of asking if this was possible while working on a mission this week.

I was able to output the flag with the trigger do script and the following

local msg = {}
msg[#msg + 1]='Enemy troops in zone = '
msg[#msg + 1]=trigger.misc.getUserFlag('201')
msg[#msg + 1]='. \n'
trigger.action.outText(table.concat(msg), 20)

I could expand on this to show the value of the 200 flag as well, and would like to have it repeated at intervals during the mission.

Any better ideas on how to display the flag values?

This is similar to the way I use but I would take your solution as is cleaner. To repeat it at intervals the easiest is to activate the message in a trigger continuously upon "time since flag" condition. Then just reset the flag to false and set it to true again in the same trigger. I used that to reproduce the alarm sound on mission 3, for instance.

Example:

1. trigger A fires flag 1 to true 10s after mission start

2. trigger B waits 30s after flag 1 is true, then displays message and sets flag 1 to false and to true again (like a switch, so to say)

3. Another 30s later the loop repeats by itself endless, cause flag 1 was again false and the trigger B is fired every 30s after flag 1 is true

4. If you want to stop it just set flag 1 to false by other trigger at any time or, if the message displaying was stop by you and you want to re-start the loop, set flag 1 to true again at any time.

Sounds like a good solution. Also was thinking of adding a Radio Item that will allow the user to display at will and a switched condition.

I do like the idea that time displays the message rather than a user interface.

Geloxo, I have tried the tutorial mission, and wow... Great script! Now we should wait for infantry to kick the left side arse!

Fresh news guys: logistics are incorporated to the script. Now you can load equipment as well as troops. Read first post for updated information and files.

The next Airmobilie mission will implement these new features as a practical demonstration.

Enjoy!

My oh my...very nice addition to the script.

Thanks much for the work !

Hi Not sure if this is useful but maybe you script guru's could look into it.

Been having a browse through the Huey lua. files and found this in DCS World\Mods\aircrafts\Uh-1H\Input\UH-1H\keyboard

{combos = {{key = '3', reformers = {'LAlt'}}}, down = device_commands.Button_35, cockpit_device_id = devices.WEAPON_SYS, value_down = 1.0, name = 'Open/Close Right Gunner Door', category = 'Armament System'},

{combos = {{key = '4', reformers = {'LAlt'}}}, down = device_commands.Button_36, cockpit_device_id = devices.WEAPON_SYS, value_down = 1.0, name = 'Open/Close Left Gunner Door', category = 'Armament System'},

It's the door gunner open/close functions.

I know there's a "cockpit perform clickable command" Action but I can't find the post regarding it but is was a 3000 something command.

Just looked at one of the campaign missions where the door opens and closes when you land...

Actions: X cockpit perform clickable action: cockpit device: 9, command: 3036, value: 1

3035 opens the other side door. So with luck if someone can figure it out we could have a load unload trigger scripted as left door load ... right door unload instead of a radio menu. For me personally this would be awesome seeing as I have my left and right gunner doors mapped to one of my hat switches.... I like to have the door open prior to jumping to the gun seat that way it's much quicker to get rounds on target(well "near" target in my case) although I don't know what kind of effect this will have on the lua. loading and off loading when you open and close the doors mid flight to use the door guns.... would hate to have the troops try dismount at 80 knots 500 feet above the ground...

Thanks Fuzzy. I know those commands but the problem is to link them to the player´s unit in MP. In SP there´s no problem, cause your vehicle is configured to fire the trigger. In the LUA commands included in the Wiki I did not find any reference to read vehicle status for such a thing so, without that, I can´t tell the script to do anything on the player´s vehicle or depending on the vehicle´s status. Same principle happens with the addition of mass upon loading, and that´s why I did not implement them yet. But anyway I have not so much experience with scripting in DCS but on other sims instead.

If someone has the magic line of code I will be very pleased to implement any of those features.

Cheers

Script updated to fix the not working FM markers on multiplayer. This scripted approach is an alternative to the existing methods which to me, at least, gives a little bit more of flexibility to user.

Something to look at. I have been getting an error (in MP mission)

786: attempt to index local 'leader' (a nil value)

The game will hang, I suppose it is the error message, but I have to hit escape for my view of the game to unhang.

I do have a flag "counting" the number of troops who have been spawned in a zone, and the counter is to stop the respawn when a certain number of troops spawn. Not sure if this is the issue or not.

I have also noticed over time, some of the P51's or choppers cannot be chosen to fly. The message I get is "Shelt is joining Blue in ." and no unit name appears.

In the log it shows I am trying to join a ground unit. Here is the DCS log output.

1172.391 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "UH-1H"(229)

01175.910 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "UH-1H"(228

01177.337 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Paratrooper AKS-74"(230)

01178.992 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Paratrooper AKS-74"(231)

01180.548 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Soldier M4"(225)

01184.945 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Soldier M4"(226)

01186.260 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Soldier M4"(227)

01189.241 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "UH-1H"(228

01189.927 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "UH-1H"(229)

01190.945 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Paratrooper AKS-74"(230)

01192.117 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Paratrooper AKS-74"(231)

01194.791 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Soldier M4"(225)

01195.783 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Paratrooper AKS-74"(231)

01196.359 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Paratrooper AKS-74"(230)

01197.424 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Paratrooper AKS-74"(231)

01198.346 INFO NET: Lua: Client [1] "sheltssd" joined Blue in "Soldier M4"(225)

Each one was trying to select a different UH-1H or a P-51

I also have the Medevac script insalled, so may have to remove it to see if that is the issue

CTTS does nothing to players or playable units except adding the radio action. It should be no problem cause by it on that related to joining units.

Regarding the error on that line 786 i know about it. It seems to happen when one enemy group is killed just at the same time the spawn happens. But I´m not really sure as it happened to me just once during all checkings and indeed froze my server too.

The script checks the list of enemy coallition groups and if the groups are existing then it takes their unit #1 position as reference (the so called leader variable) to order the troops spawned group to move there (for instance when you dropped them). The error seems to happen cause script couldn´t find that unit #1 cause it doesn´t exist but indeed it has a constraint to check before which is that the group exists. So if group exists it must have at least 1 unit inside, which is the one used to calculate the destination of spawned groups

I really don´t understand why the error occurs :-( If someone has any idea please share it

Anyway I have introduced another constraint to bypass this error and updated script to v1.04 just in case. The mission pack is updated as well to use this new release. Please report any further errors like this and I will modify it as well.

Cheers

Thanks, that seemed to fix that error.

The other issue seemed to be with the Medevac script and setting the medevac.clonenewgroups to true. Turned it to false and it no longer seemed to be no problems with the joining units error.

Found an issue with spawned unit taking the unitID of client aircraft in large missions.

I did generate a mission using the "nodes" feature, then customized the mission with "client" aircraft. The client unit ID's, since they were added after the other objects, were in the 220 range. If an aircraft was not occupied at mission start, I ran into an error when a player tried to join a client aircraft that the player was trying to join a spawned ground troop.

The issue was the unitCounter = 100, so I guess the spawned unit took the next available ID from 100 up. Since I knew the aircraft range was in the 200's I changed this to unitCounter = 400.

Just a tip for those who create large missions and add the aircraft afterwards, you need to be aware of a potential issue, especially in MP.

We are still looking for both UUID generator and synchronized function in lua, the only 2 ways to avoid ID collision. ;)

It highlights an issue with using multiple scripts which use coalition.addGroup in that the different scripts can easily step over one another and unintentionally erase objects from the mission. The way I did it with SCT (and Mist 2.1+) is that it searches the mission file for the largest used group and unit Id and starts there for the group/unit Id counter. But it can't really account for whatever other system another script is using however. So it might be best for a large number be used for custom scripts like this, something like 5000+. If all the scripts used group/unit Ids based on the mission file, but never talked to each other or utilized a common script to spawn groups, then chances are the scripts will end up constantly overwriting one another. This is kind of why I wrote SCT and am putting it into Mist to avoid problems like this.

I am reading lua reference documentation and coroutines sounds like the solution for what we need:

see chapter 9

Let's imagine getUniqId() instead of receive() and some counter based on max initial Ids as for producer implementation... We are sure that each call to getUniqId() will be executed with no concurrent access to the counter :thumbup:

coalition.addGroup() is supposed to accept groups and units without unit/group Ids. However I'm not using that within Mist as I am directly updating the mist.DBs as groups are added.

Getting the largest unique Id is probably a better course of action as each script could rely on that and do the needed math for each unit added. Thus any group added will adjust the unique largest Id.

Thus any group added will adjust the unique largest Id.

Yes, but do it into a coroutine to protect your counter/largestId/whatever you call it from concurrent access. I mean, I have a training mission where all clients can spawn units thanks to F10 menu, and I don't want to face concurrent access issues... = spawning2 is reading largestId variable before spawning1 has updated it ! Coroutines allow to read +update value into one synchronized process to avoid troubles.

The same kind of issue in that thread.

Well, I would like to say thanks to both of you for the work on scripting the game. I really wouldn't want to build a mission without both the transport or the medevac script. It sure has brought alot of fun to the missions!

It did take me awhile to figure out where the problem actually was, but I consider it worth the effort

I put in the feature request for a function to find the largest safe group and unit Ids. Considering the game has to have that code or something like it already somewhere, it is hopefully just a matter of making it accessible.