Hardcard

@Frag @Sickdog Hi guys! Glad I could help! Truth is that I encountered this problem months ago, I've been wanting to solve it ever since. When Frag suggested that he wanted a customized offset landing point (which, ideally, should be turning with the ship), I decided it was time to find the solution :book: Btw, the script I provided works, but the explanation from my post was partly incorrect. I edited the post to correct some things, now it should describe what the script does more accurately. :thumbup: Next step is figuring out how to do this with planes, for instance (handling rotations around Z and X). EDIT: Some of the guesses in the spoiler are incorrect, others are simply approximations... Need to keep digging! :book:

It makes the group/unit "go to sleep", so to speak.

@Flappie Last update before going to sleep. Trains do not respond to :Destroy() (which is the typical MOOSE method I use to get rid of stuff). Perhaps trains haven't been fully implemented with regard to the DCS scripting engine, that might explain this. Right now I can't think of anything that would destroy those trains... I'm not even sure they can be destroyed with "conventional" methods (like shooting at them). I'll try tomorrow, I guess. If that fails, I'm afraid you'll need to keep an eye on the trains and stop "tracking" as soon as they reach their last waypoint... sorry.

Ok , mystery solved! You forgot to actually add the locomotives to the train units you created (this is an extra step required for trains). That's why none of the scripts were finding anything. https://i.imgur.com/qn6TE6t.jpg On another note, are you sure you want to use a separate script for each train group? You know that a single script can handle it all, right? Is there a particular reason you're doing this? Going to work on making those trains disappear now :D

@Flappie Going to have a look at the buggy mission first, but yes, I also noticed that trains don't stop while performing tests earlier. I might have a way to "stop" trains... :gun_smilie: :D

@markbond I might be mistaken, but I believe that :SpawnScheduled(30,0) will spawn groups on its own. If you combine it with flight1:Spawn(), then that'll trigger another spawn. You might have a situation in which several spawn triggers are running at the same time, messing with each other. If I were you, I'd get rid of :SpawnScheduled(30,0). If you want to spawn new groups, do it "manually" ( use flight1:Spawn() ), that has always worked for me. Also, spawning individual units from a group might not be possible. As far as I know, this method only works for groups as a whole. You could always use single unit "groups", that would work. Finally, perhaps you'll find :OnSpawnGroup() useful (you could use it to program new spawns when the group dies, lands, etc.)

@Flappie I like a mystery! Please, post your buggy mission here, so we can have a look.

Ok, I've tested it and seems to work without issues. I'm attaching a demo mission + the script it uses Since there's no "train camera" in ME (as far as I can tell), I've included a gaz tigr vehicle that will travel with the train (roughly :D). Just use the vehicle camera to see what the train is doing. Train mapping demo DMS coordinates.miz Train mapping DMS.lua

@Flappie Hi there! Glad to hear that you've been able to map all the roads! :thumbup: Don't worry about this error, I tested the script with trains in the Caucasus map and it worked. 6: attempt to index local 'BTRRoadMapper' (a nil value) This is simply saying that "BTRRoadMapper" (which the script is trying to target) can't be found in your mission. To fix this, check the following line in the script: Make sure that the UNIT name specified in the script (between those quotes) matches the UNIT name of the train in ME. It can't be the GROUP name, it must be the UNIT name! Watch out for typos! Also, you must remove any such line that refers to a BTR unit that's no longer present in your mission (otherwise you'll get this error). I'll test this anyway, see if I notice something odd :thumbup:

No harm in trying! Anyway, I've finally figured it out, so you don't need to worry about that anymore! After a few days of study + trial & error, I can finally see the matrix :matrix: (DCS uses a 3x3 matrix to perform transformations) I've learned quite a lot about how vectors and positioning work in DCS, might write a tutorial about it (or even create a YT tutorial :music_whistling:). Long story short, our cargo ship is using orientation vectors in order to turn, these are actually sines and cosines of its heading. EDIT: Well, not quite, things are more complicated than this! In DCS, the Caucasus map has 3 axes (centered at a point on the Crimean Peninsula). These 3 axes define the POSITION of objects on the map, but not their ORIENTATION. Map's X axis = South(-) , North(+) Map's Y axis = Ground(-) , Sky(+) Map's Z axis = West(-) , East(+) For object orientation relative to these "map axes", each object in DCS relies on its own set of 3 orientation vectors. This is the format of the Lua orientation table that DCS uses for objects (keep in mind that Vec3 is a vector table itself. So this table actually contains 3 different tables): [color="Blue"]-- Simplified form[/color] Orientation = {x = Vec3, y = Vec3, z = Vec3} [color="Blue"]-- Full form (example of ship's rotation around Y axis, values range from -1 to 1)[/color] Orientation = { x = { x = cosine of ship's heading, y = 0, z = sine of ship's heading}, y = { x = 0, y = 1, z = 0}, z = { x = negative sine of ship's heading, y = 0, z = cosine of ship's heading} } EDIT: This is just an approximation, things in DCS are more complicated than this! This is basically a 3x3 transform matrix (in this case, it's a rotation matrix around the Y axis). Thanks to this realization, I immediately understood the practical difference between orientation vectors and position vectors in DCS. Anyway, here's the solution to the offset landing point problem: #1 First, point the ship to the map's North (heading 0). Once that's done, find the X and Y position values for the offset landing point (you can either use the ruler tool in ME or actually land on the containers and get the position readings via script. You can use :GetPointVec3() for this) #2 With the ship still pointing North, get its X, Y and Z position values (You can use :GetPointVec3() for this) #3 Now subtract the ship's X and Y values from the landing point's X and Y values, in order to get the relevant offsets for the transformation. The Z offset isn't needed for this. It's 0 anyway, since both points are located at 0 Z (the ship's Z orientation axis, that is). #4 Now that you have the correct offsets, it's trigonometry time! :yay: Offset_X = The offset value for X * cosine of the ship's heading Offset_Y = The offset value for Y -- We don't need to do anything fancy here, since the ship only moves along the map's X and Z axes (unless Godzilla decides to make an appearance :D ) Offset_Z = The offset value for X * sine of the ship's heading -- Yes, we need to use the offset value of X here too, but we multiply it by the sine of the heading instead! EDIT: Again, this is just an approximation! Instead of using the heading's sine and cosine, it's better to use the values from the Position3 table itself (for a ship, we only need to get Position.x.x and Position.x.z) #5 Now we need to add the "transform offsets" to the ship's PointVec3 that we used earlier. LandingPoint_X = Ship's PointVec3 X value + Offset_X LandingPoint_Y = Ship's PointVec3 Y value + Offset_Y LandingPoint_Z = Ship's PointVec3 Z value + Offset_Z The ship's PointVec3 has now become our new offset landing point, which will "turn with the ship" :thumbup: #6 Use :Get3DDistance() to get the distance between our offset landing point and the chopper's PointVec3. This will enable us to set up the landing logic. I've attached a demo mission + script, so you can see all this stuff in action Here's the script: I REALLY hope that you'll find this useful! :thumbup: Cargo offset landing point test.miz Cargo offset point test.lua

@Frag I've spent the day learning about transform matrices, if I manage to implement them in a script, it would be possible for the custom offset point to "turn with the ship". Right now I'm at the :shocking: stage. PS Yes please, keep those doodles coming! :D

@Delta99 Thanks man! It took me a while to realize that LAND events could be used for this :D @Frag Loved your helicopter doodle ;) Do you want to land on a carrier or on a cargo container placed on the bow of a non-landable ship? We're talking oranges and apples here. For carrier landings, use the last script that I wrote (the one that uses LAND events). No zones required, the script will work as long as the choppers land on a carrier's deck, it's pretty neat. Now, regarding the experimental landing from the picture, I don't even know if that will generate a LAND event (I doubt it very much). If it does, then you'll simply need to include the unit name of that ship in the script. If it doesn't (which is likely), then we'll need to get creative :juggle: You could get the POINT_VEC2 from that Yakushev cargo ship by using :GetPointVec2() , then modify its position, so it would be located on those containers. If I were you, I'd try the following: - Get the ship's POINT_VEC2 - Find out what's the exact altitude of the containers by landing on them and then checking your altitude (for instance). While you're at it, use a script that returns the following information (via text message): #Ship's POINT_VEC2 X value (use :GetX() for this) #Ship's POINT_VEC2 Y value (use :GetY() for this) #Chopper's POINT_VEC2 X value (use :GetX() for this. Take the reading while landed on the containers) #Chopper's POINT_VEC2 Y value (use :GetY() for this. Take the reading while landed on the containers) - With the information gathered above, you should be able to calculate the correct offset for the ship's POINT_VEC2 - Use :AddX() and :AddY() to set the correct offset for the ship's POINT_VEC2. - Use :AddAlt() to set the right altitude for the ship's POINT_VEC2. - Now you should be able to use :Get2DDistance() in order to find the distance between the ship's customized POINT_VEC2 and the chopper's coordinate. This should be enough for landing detection, without the need for zones or altitude checks. Keep in mind that this method isn't perfect. In order for it to work, the cargo ship must be either static or moving in a straight line... it mustn't be allowed to turn, otherwise all hell will break loose :devil_2: Our custom offset won't "turn with the ship", it'll remain in the same position relative to the map, that's the problem (I mean, a 180º turn should be easy enough to handle, but anything else would be more complicated to calculate). In order for the offset to "turn with the ship", fancy maths must be used... this is beyond my current skills, I need to do some :book: >> :shocking: >> :book: >> :wallbash: >> :book: >> :doh: >> :thumbup: >> :smartass:

I'd use an altitude check + a tiny moving trigger zone (small enough to be contained within the carrier's deck). If that's not enough, you could also try adding an extra coordinate point distance check (which would make the carrier zone kind of redundant). Here's a basic MOOSE example: You can use this method with UNIT/GROUP sets as well, just need to define the set and include the check in a suitable iterator function, like this: Hope this helps!:thumbup: EDIT: Actually, you can simply use LAND events to do this (and capture all the relevant EventData that you need), zones and altitude checks aren't even required. I didn't mention this earlier because I mistakenly assumed that carrier landings didn't generate LAND events (they totally do, fortunately). I've tested it and works perfectly with choppers and carriers from both coalitions (test mission attached): Carrier Landing Test.miz

The script you posted contains some interesting tricks, thanks for sharing! :thumbup: Well-intentioned remark:

I use sets and iterators for that (and for many other things). For instance (MOOSE example): Check the the MOOSE documentation for CONTROLLABLE class, you'll find all the relevant ROE functionalities listed there.

@Frag Wild idea: Use a scheduler to capture your coordinates regularly, then have the enemy chopper go to those coordinates. For instance, I'd try using this (the documentation is kind of confusing, though, it might only work with ground vehicles, but it's still worth a try) Alternatively, you could create a tiny moving zone based on your helicopter, then have the enemy chopper travel towards it, by using this

@ICEVIPER 1- There are two different types of Moose.lua as far as I know: "source version" and "include version". If you try to load the "source version" in your missions, it'll generate the error you mentioned. The "source version" is the one included in the source code zip file for each MOOSE release, btw. Always use the "source version" to set up LDT, the "include version" is the one you need to use in your missions. 2- Every time a new MOOSE release comes around, I do the following: - I go to the MOOSE release section on Github - I look for the latest release (first on the list) - I download both the source code zip file and Moose.lua (which is the include version for that release) - The source code zip file contains all that I need to set up LDT (including the source Moose.lua file, which mustn't be used in missions) - I use the Moose.lua include version for that release in my missions (ie. the Moose.lua file that I downloaded separately from the release section) 3- I'm not sure I understand what you mean :huh: Are you talking about setting up LDT using the latest MOOSE release as source? Simply repeat the steps you followed the first time you set it up, but with the new build. 4- What issues are those exactly? The error you mentioned? As I said, that happens when the "source version" Moose.lua is used instead of the "include version". The docs page that you mentioned provides a link to the MOOSE release section, which is where you'll find the latest releases (forget about the "patch" bit, consider them full releases).

You need to combine different types of AA and radar units in order for them to fire. Anything that's not an autonomous AA vehicle will need to be combined with compatible radar(s) in order to fire (sometimes comms vehicles are also needed)

Ok. So the script doesn't use any kind of airfield information, it relies on unit categories, LAND events and velocity checks. If there's a problem with any of these, the script won't work. Regarding those 3x groups of 4, do they work in the Caucasus map? Also, it would be great if you could share your dcs.log (C:\Users\YourUserName\Saved Games\DCS\Logs). Just clear all its contents (leave it blank and save it), then perform a single run of your mission, until you start detecting problems with aircraft not being removed. Then post your dcs.log here. PS. Btw, when any of those problematic units land, do you at least receive the landing messages? If not, that probably means there's a problem with the LAND events (or the unit SET). However, if you do receive the landing messages, either they take too long to come to a stop or there's a problem with their scheduled checks. It should be easy to fix.

@philstyle I don't have the WW2 assets nor the Normandy map. However, if it worked for the B17s in the Caucasus map, it should also work in the Normandy map, I believe. Question for you: In the Normandy map (Chailey Airfield), how long does it take for the B17s to actually come to a stop after landing? If it takes them more than 10 minutes, the script will need to be modified :doh: Find this line: Also, as it's written, the script should only work for units that are already present in the mission when the script runs. If you want it to work with late activated planes as well, it might need to be modified. You can send me the mission details via PM, if you want.

:D

@marginal I haven't tested anything yet, but after opening your mission script, I noticed that there's a "Z" at the end of line 24 (typo, I'm assuming). It generates the following DCS scripting error: :26: '=' expected near 'CapEngageZone'

Here, this MOOSE script should have you covered (you'll need to run Moose.lua at mission start for it to work with your mission): The way I've written it, the script will apply to ALL planes in the mission, but it can be made to target any units you want, really. I've attached a MOOSE demo mission + the script file, so you can see it in action. Aircraft Cleanup Test.miz Aircraft cleanup after parking.lua

Nice! :thumbup:

Hi Delta! Funkyfranky told me that he was going to note my findings in the MOOSE development branch. But sure, I can also create a new issue on the MOOSE Github, just in case :thumbup: