CakeSorbus

New version 1.4 out now, check the first post in this thread! @AKA_ClutterDisregard my last post, I think I got it fixed in this new version, but please report (with logfile) if the problem still exists.

Hmm...there is a bug that causes the laser to stop functioning after leaving and then reentering a slot. I'm currently still working on a fix for that. Not sure if that's whats causing you problem, though. Can you please send me your logfile of the session? That would be a great help. You find your logfile in Saved Games/DCS/Logs/dcs.log Note that this file only logs your last session, if you played DCS in between testing the script and reporting the bug, it won't be of any help to me. In that case please cause the bug to trigger again and then send me your fresh logfile directly afterwards. Cheers Cake

You got the basics right, in the end the script file that is in the .miz file must be updated. There's an easier way to do that, though: 1. Make your changes in the script file in your scripts folder 2. Reselect the script file in the ME in the "DO SCRIPT FILE" action. 3. Save your Mission. The updated version of the script file has now been copied into the .miz file.

Hey Clutter, regarding your questions: 1) No, you only have to load the script in your mission with the "DO SCRIPT FILE" action, the script will then automatically be included within the .miz file. You don't have to place it anywhere manually 2) Yes, CTLD, MOOSE and MIST will continue to function normally while this script is loaded. 3) Exactly, just use the "DO SCRIPT FILE" action Cheers Cake

New version 1.3 released, check initial post

Hey Caveman, did you ever find a solution for the missing controls? I seem to have the exact same problem as you had, almost a year later! Update: Found that a Key bound to "Fire Minigun" fires Gun and Rockets as well, seems that somehow the control labels got corrupted on my system. But it works now!

You execute your script in the server environment, right? As far as I understand the documentation on Hoggit, functions related to the timer singleton are only included in the mission scripting environment.

New Version 1.2 out, see post above!

Hey Shrike, from what I can see you have the order of the parameters mixed up. Your entry: -s-RUSSIA-t55 How it should be: -s-t55-RUSSIA Parameters that I flagged as optional (like the country) in the documentation can be entered in any order, but always BEHIND the mandatory parameters shown in orange!

Hey, fellow Gazelle pilots, just a quick notice: I created a script that gives the GazelleM a laser designator. It even slews with the Viviane sight! The main thread is over in the Mission Editor section, I just wanted to let you guys know! Cheers, Cake

Hey helicopter pilots, if you (like me) just can't wait any longer for the OH-58D to finally be released, and want to get in on the action of designating targets for our fast and high flying buddies a little earlier, I created something that might interest you! This script adds the ability for Pilots of the SA342M to designate ground targets by laser. It includes the following features: -Configurable laser codes and laser code presets -Automatic tracking of the Viviane LOS and recalculation of the lased point -Configurable snapping function to automatically snap the laser to nearby targets -Lasermodes: IR (Visible in NVG), Laser, or both -Configurable load time before menu options are created -No MIST or MOOSE needed Laser configuration and activation is done through options in the F10 radio menu, I highly recommend the use of macros. To that end I included an option in the config section of the script that allows you to delay the creation of the menu entries. That way you can control where in the F10 menu the scripts main menu option is located. How do you load the script? Including the script in missions works similar to CTLD. First you must enter the pilot names of all Gazelles, you want to use the script with, into the list of names at the top of the script. The name must be the same as the one specified in the Field "Pilot Name" in the mission editor. Please note that the script only works with the M-variant of the gazelle. All other Gazelles will be ignored. While you have the script open anyway, maybe take the time and see if the options for delaying the menu creation are configured to your liking. You can also enter lasercodes into the provided list, or change existing ones. Please note that only the last 10 entries in the list are loaded into the ingame radio menu. Once you made your adjustments, don't forget to save. Now, to get the script into you mission, you have to set up a trigger that performs a "DO SCRIPT FILE" action at the beginning of the mission. To do that either use a trigger of the type MISSIONSTART or use a ONCE trigger, with a condition of TIME MORE (x seconds). Now you should be all set up. After entering a Gazelle M you should first get a message, that tells you that GazDesignate is loading. After a few seconds (or more, depending on how you configured it) the loading message will update to tell you that the script has loaded. Check the F10 - Other radio menu. There you should now find an entry that says "Laser designator". Congratz, you are ready to go! How do you use it? If you take the time to read the menu entries, the use of the script should be quite self explanatory. I will only highlight a few things. The range setting is only there in case the automatic laser point calculation fails or is to inaccurate. Note that I included an option to make relative changes to the range currently dialed in. I have macros bound to these options...very useful for quick adustments. You can check the accuracy of the automatic range calculation by comparing the number it returns on laser activation or slewing, to the number your rangefinder in the Viniane gives you. If the deviation is higher than the blast zone of the weapons you want to lase onto your target, you need to make some manual adustments. Range adustments can be done while the laser is active. Note that I included a snapping function that can be configured in the script file. Per default the snapping distance is set to 30 m. This means that, once the script has calculated a target point for the laser, it searches for units within a radius of 30 m around that point. If it finds a unit, the laser is automatically pointed at the position of that unit. You can turn off the snapping function by setting the search distance in the config section to 0. Once you activate the laser in one of its modes, the activation options are removed. Instead you get a "turn off" option. If the option for deactivating the laser sits at the same place where the "Designate (Laser) option was before, so it can be accessed by the same macro. I'd like to take credit for that, but it's just a "happy little accident", that i had not planned for but am more than happy about! Once the laser is turned on, it will automatically follow the sights orientation, the laser point is recalculated at an interval that you can adjust in the config section of the script file. Out of the box the script recalculates every 0.1 seconds, but only if the sight has been moved. I use a Ryzen 7 3700X and the cpu load induced by the recalculation doesn't rise above the "background noise", but on some smaller cpus, or on servers with a high player load, there may be permormance issues. Thus I included the option to increase the interval between recalculations. The more acute the angle to the ground gets, the less accurate the calculated range will be. Curiously the deviations in the calculated ranges provided by the script are about the same in magnitude as the deviations in the measurements with the Gazelles own rangefinder. As you know, the Gazelle is not really that stationary in auto hover, but is always swinging side to side and up and down. Therefore I had to dampen the sensitivty of the script to orientation changes of the sight a little bit, because otherwise it would constantly try to recalculate the laser spot. This dampening is mostly felt on the y-axis of the sight. The x-axis has less variation and can be updated at a higher resolution. My recommendation: When lasing targets in the distance (>5000 m), first place the sight left or right from the target and then, with the laser activated, slew the sight over the target. Sometimes you have to wiggle around for a bit, but you should in most cases be able to get the laser to recognize the target. If that method fails, you can still put in the range manually. When first starting it, or slewing it around, the laser is only stabilized in the horizontal axis, I recommend to only adjust the lased point from a leveled out hover position. When the laser is active, and you don't manually move it, it should stay on the position targeted by the Viviane sight, even if you move your helicopter. Abrupt maneuvers will still cause the laser to veer of. One minor bug stills exists, that I could not yet snuff out: When you have the autopilot in slave mode, it does not update the horizontal orientation of the laser on rotation of the helicopter, only once you wiggle the sight up and down a little, it will update. Probably a mistake in the logic of the script, I will look into that some more. How does it work? The script uses the functions spot.createLaser, spot.createInfraRed, spot.setPoint and spot.setCode to create and update the laser. The orientation of the Viviane sight was a bit more tricky, but I found out that you can use Unit.getDrawArgumentValue(), to access the curent animation state of the Viviane sight (ArgumentValue 215 and 216). The rest was math (and a bit of logic)! A quick note on how the range calculation works. The main problem that I faced was that I could not acces the rangefinder readings through the scripting engine. Manually entering 5 digit ranges through the F10 menu is not exactly convenient so I tried to find a way to calculate the range with the numbers I had: Helicopter altitude (BARO and AGL) and heading + vertical angle of the Viviane sight. I first attempted trigonometry, but that only worked (semi-accurately at best) in cases where the target area was significantly lower than the helicopter and at about the same elevation as underneath the helicopter. In all other cases the results where highly inaccurate or just plain wrong. I ended up having to "brute force" the diagonal range to the target area: I run a for loop that calculates the elevation of points increasingly further away from the helicopter along the Vivianes LOS. The calculated elevation is checked against the land height at the given point (land.getHeight). The point where the calculated elevation slips below the land height is where the laser from the rangefinder touches ground. I first run a loop with very high distances between the checks. The range resulting from that loop is then fed into the next one, that works with smaller intervals. This cycle continues until I'm down to increments of 0.1 m. In that way I can calculate a very accurate diagonal distance without having to run a loop that checks from 1-20000 with increments of 0.1. Changelog 2021/02/24 v. 1.2 - new version is attached to this post Fixed a minor bug that prevented status messages from being shown when changing the laser code digit per digit Tweaked the sensitivity to changes in sight orientation, laser spot follows the sight orientation more closely now 2021/03/11 v. 1.3 - new version is attached to this post Script now returns the coordinates of the targeted point in LatLong-Format (decimal minutes) and MGRS as a message Message display time for information about the targeted point can now be configured in the script 2021/03/19 v. 1.4 - new version is attached to this post Laser would not activate after respawning - fixed (hopefullly) Known Bugs none at this time, if you find one please report it as a reply to this thread (with attached log file, please) GazDesignator.lua

Hey guys, thanks for keeping this thread alive! :) @Catweedle Yes, that would work in regards to restricting access, thanks!

That would be included in the feedback system I have planned (see the section about planned features in my release post). Due to a bug in the scripting engine it is currently not possible for the script to know which player issued a command. Any feedback messages would therefore have to be visible to all players on the server. The resulting loss of immersion is why I have decided not to implement this feature at this time.

@monkie Tested this and can confirm your observations for OpenBeta, in Stable everything still works as intended. Guess they changed something about unit behaviour with the latest OB patch, maybe this is a consequence of the fix they did for the disembarking of units. I will try to find a workaround but can't make any promises.

I'll add that to the to-do-list. I'm pretty busy in RL right now, so it might take one or two weeks before i get around to implementing it, though.

The liveries are not specified in the template file, thus the game falls back to the default livery for the combination of plane and country you are spawning. You can not select liveries on spawn. I could in theory implement a method for players to specify a livery as a parameter for the "-s" command, but this would require me to research the names of all liveries currently in the game and which aircraft they can be applied to. I tested the "-lz" command again in MP and SP but it worked for me. You should not have to setup anything beforehand, just enter the command and give the name of the helicopter group as parameter. Did you maybe have a typo in the group name when you entered the command? That's the most common error with commands that are directed at groups.

Hey folks, new version 2.1 out today! :D Check out the changelog at the beginning of the thread! Leider muss ich ankündigen, dass das Deutsche Handbuch von mir nicht weiter gepflegt wird. Mir fehlt einfach die Zeit.

Hey, thanks for the scriptfile. I finally found the time to look at your additions. Your approach is to use the marker commands to spawn the infantry groups and crates that are predefined in CTLD. Looking at this i had an idea for a different approach. What if I could instead make CTLD recognize Groups that have been spawned with the "-s" command and the "-cargo" parameter? After a bit of testing i got it working for ground units. You can now, for example, spawn an infantry group from Gamemaster_Templates and load it as an extractable group with CTLD. All you have to do is use the "-cargo" parameter in the "-s" command. It works for both infantry and vehicles. With regards to crates I will probably just merge your method into my script. I have also made progress on my own command to spawn static units. It is currently possible to spawn duplicates of statics that you have already set up in the mission at the map marker. You can also choose the country and heading of the new static. I will send you the new version of my script shortly, maybe you can give it a test run with your squadron? The "official" update will be out sometime this weekend, once i've found time to update the manuals.

Yes, please! :D I just started coding my own command for the spawning of statics, but I'm very curious to see your code on that. And I hadn't even thought about creating an integration with CTLD...nice!

Hi, it's pretty late here, so I apologize beforehand if I misunderstood your question due to tiredness. I understand that you want to spawn a MiG 21 on the ramp in an uncontrolled state and turn it on at a later time. There are three different ways to do this with the gamemaster script: 1. Method: Set the group up as late activated, start from ramp and uncontrolled in the mission editor (ME), then activate it ingame with the "-act" command (see Section 5.2 of the manual). The group will then spawn in an uncontrolled state. To turn it on you can use the "-ctrlon" command (see section 5.13). 2. Method: Set the group up the same as above, but ingame use the "-s" command (see section 5.1) instead to spawn it. You will have to add the parameter "-kt" to ensure that tasking of the group doesn't get overriden on spawn and "-op" to have the group spawn at the location you set it up at and not at your map marker. You can later turn the group on with the "-ctrlon" command. 3. Method: In the ME set the group up as late activated, but let it start in the air. Ingame you spawn it with the "-s" command but you add the parameter "-ground". The group then spawns in the air, at your map marker, but will then almost instantly respawn on the ramp and in an uncontrolled state, at the airbase nearest to your map marker. You can then turn it on with the "-ctrlon" command. *Edit* I just reread your question now that I'm a little more awake...you want to spawn an uncontrolled MiG 21 and have it turn on automatically when an external condition is met (by use of a triggered action and a corresponding trigger that you have set up in the ME) I must confess that I never really did much with these triggered actions you can set up in the groups tab of the ME. They should work though, as long as you use the "-act" command to spawn the group ingame. Why the "-act" command and not "-s"? The "-act" command mirrors what happens when the ME trigger action "Group activate" is used, it just activates the group in the exact state that you have set it up with in the ME. The "-s" command on the other hand uses the SPAWN class from MOOSE to create a copy of the group you have set up and then activates that copy. The copy that spawns has a modified group name and a different GroupID than the group you have created in the ME. In consequence it won't be affected by triggers that target the original group because as far as DCS is concerned it's a completely different group.

You're welcome ScopeDope, I'm glad my script is being put to good use!:) If you find any bugs, please report them here.

Huh, so that caused the problem! I actually read what you wrote about the start time, but since the group could be activated by command, I wrongly dismissed this as the cause of the issue. :doh: My guess is that the start time somehow keeps MOOSE from recognizing the group as late activated...but it works now, and that's the important bit! :)

Hmm, I have looked at the mission file you uploaded and I have to admit that I'm stumped. I first confirmed that the groups you have set up do not spawn with the s command on my system as well. Then I added another group and gave it the same arrangement and naming scheme and set it to late activation. That one spawned just fine! What confuses me is that I can see no difference between the group that I have set up and the ones you had already placed in the mission. I've attached my edited version of your test mission. Please check if you can spawn the groups that I added (ARV_Star2 and APC_Star2). Could you describe to me in detail which steps you take when setting up a group for late activation in the ME? Maybe we can find the error that way... I like your suggestion of a selectable delay with the explosions, I will add that to the list of planned features. Zeus Test_Edit.miz

They do work alongside each other, as long as you don't accidentally name one of your groups the same as one of the template groups that I have set up in "Gamemaster_Templates.lua"

Whoops, that line is a bit misleading! :music_whistling: What I meant to say was that my script takes the late activated group that you have set up in the mission editor and (utilizing SPAWN from MOOSE) uses it as a template to spawn unlimited copies from. You don't have to create a template of the group in the templates tab of the mission editor. Just set up the group as late activated and then let it spawn ingame with the -s command. Regarding the SA11: The air defence templates should actually spawn as completely functional air defence groups. With the SA11 you have three different templates at your disposal: -A low strength group consisting of command post, launcher, search radar and resupply truck -> sa11l -A medium strength group that has an additional launcher -> sa11m -A heavy strength group that has a second launcher and additional close-in defences (Igla MANPAD & Tunguska) -> sa11h I tested these templates again in stable and OB and they spawned just fine (small bug with the medium one, but nothing critical) for me. Please give it another go, and report back if the SA11 does not spawn as described.