CoconutCockpit

Don't have much to add to the topic, just wanted to thank everyone who has been posting in here for the absolute quality research. Great work!

Just came back to DCS after a long time and noticed this is still an issue. If you air start the jet, the QNH in the cockpit says 29.92 even if the QNH in the mission editor is set to something else. I would expect it to copy over the settings from the .miz file.

Have you found a way to do this by any chance? I'm looking for the same thing right now.

I believe it is.

Ah yes, that’s me. For anyone wanting to use this, it’s based on MOOSE. -- -- -- ### Author: **nielsvaes/coconutcockpit** -- -- === -- @module StrobeUnit STROBE_UNIT = { ClassName = "STROBE_UNIT", } -- Function to find a unit by name and initialize it with strobe properties function STROBE_UNIT:FindByName(unit_name) -- Inherit properties from the UNIT class and assign to self local self = BASE:Inherit(self, UNIT:FindByName(unit_name)) -- If the unit is not found, log an error message if self == nil then self:E("Couldn't find a unit with the name " .. unit_name) end -- Initialize strobe properties self.strobe_active = false self.on_time = 0.08 -- Duration the strobe is on self.burst_interval = 0.5 -- Interval between strobe bursts self.visible_chance = 85 -- Chance for the strobe to be visible return self end -- Function to start the strobe effect on the unit function STROBE_UNIT:StartStrobe(bursts) self.strobe_active = true -- Activate the strobe bursts = bursts or 2 -- Default number of bursts if not specified -- Call the private __Strobe function to handle the strobe logic self:__Strobe(bursts) end -- Function to stop the strobe effect on the unit function STROBE_UNIT:StopStrobe() self.strobe_active = false -- Deactivate the strobe self:LaseOff() -- Turn off the laser (strobe effect) end -- Private function to handle the strobe logic function STROBE_UNIT:__Strobe(bursts) -- Check if the strobe is active before proceeding if self.strobe_active then self:LaseOff() -- Ensure the laser is off before starting -- Loop through the number of bursts for index = 1, bursts do -- Check if the strobe should be visible based on chance if UTILS.PercentageChance(self.visible_chance) then -- Schedule the laser (strobe) to turn on based on timing calculations BASE:ScheduleOnce((self.on_time + self.burst_interval) * index, function() self:LaseUnit(self, 1688, self.on_time) end ) end end -- Calculate the total wait time before repeating the strobe effect local wait_time = 2 * bursts * (self.on_time + self.burst_interval) -- Schedule the next strobe effect after the wait time BASE:ScheduleOnce(wait_time, self.__Strobe, self, bursts) end end Use it like this: for _, unit_name in pairs({"strobe_guy_01", "strobe_guy_01", "strobe_guy_01", "strobe_guy_01", }) do local su = STROBE_UNIT:FindByName(unit_name) su:StartStrobe(3) end

@aterfax Just wanted to say thank you for this! Have it up an running on a Contabo Ubuntu VPS right now without too much hassle. Awesome work

Thanks for posting this! My calibration got out of whack for some reason, following the steps outlined here made it behave again.

True, but I think it should still return to the first point in the sequence after it reaches the last point. It doesn't explicitly say that in the manual... ... but it is what the A/G radar does when you step through the points there. Unless someone actually knows for a fact it shouldn't, I think it makes sense the behavior is the same on the TPOD.

Sequencing waypoints on the TGP stops at the last waypoint Version: DCS v2.8.6.41363 Open Beta MT Reproducible: 100% Reproduce steps: Make a mission and add a couple of waypoints Open TPOD page on a MFD Press the OSB (Pushbutton 17) to cycle through the waypoints Observed result: After the TPOD points at the last waypoint, it doesn't cycle back to the first waypoint when Pushbutton 17 is pressed again Expected result: TPOD should cycle back to the first waypoint tpod_sequence_issue.trk

+1 Would love this as well

I understand, that's fine. I managed to copy over everything I needed from the old `mission` into a new one so it didn't end up being much work as all. Thanks for pointing out where it went wrong though!

Ah, you're right. The QNH for the mission where the mark points get created in the air was set to 30.08. I completely forgot and never changed it during my start up of the jet. I don't remember when exactly I saved the first version of this mission, but I'm pretty sure it was before the multi threading client was added. I then saved over it dozens of times using the MT client. I did try in both the normal and the MT client though and got the same results. Some things to note though: `mission["weather"]["qnh"]` in the `mission` file was set to 764 (torr), which converts to 30.08 inHg. So just like I set it in the Mission Editor I air start in the .trk file, and you can see that the value in the jet reads 29.92. Looks like it's not set to the same value that is set in the Mission Editor I attached another .trk file where I start hot from the ground The value in the jet reads 30.08, so that seems to be correct When I make a mark point, it still floats above the surface it seems I don't know, maybe there's another problem with the QNH settings? It seems that when I make a mission and just leave it at 29.92, everything works fine. I don't have the time to further investigate this now though, but might be worth looking over from your side. jhcms_mark_point_in_air.miz jhcms_mark_point_in_air_hot_start_ground_qnh_ok.trk

Preface: I have a particular .miz file where this problem happens. If a make a new mission on the same map (NTTR), the problem doesn't occur. Problem: Mark point made through JHMCS starts drifting after pressing TMS up once to ground stabilize. Press TMS up again to save the mark point and it continues drifting. Happens both in single player as in multiplayer Happens both on normal server as well as dedicated server Question: Why is this one .miz so special that it's causing this issue? Attached are both track files: one with the problem and another one where the problem doesn't happen. I know I can remake my mission in a new .miz file, but it was quite big and had a lot of things on there already. So if there's a way to fix this without having to remake it from scratch, that would be great. jhcms_mark_point_drifting.trk jhcms_mark_point_ok.trk

I stumbled across this as well at some point, I remember having a bunch of little menus that I could put bookmarks in. But I can't, for the life of me, find how I did this again. Does anyone know what keys or keybinds I should be looking for?

Invaluable tool for anyone wanting to do any scripting in DCS! I truly believe MOOSE is by far the best way to quickly and easily get whatever functionality you need from DCS. A huge thanks to everyone who contributed time and effort into getting MOOSE where it is today.

Did we ever have system failures in the Viper? The window is just empty for me, but I seem to remember it not being like that at some point. For the A-10 the list of failures is populated, but not for the Viper. Is this a bug?

To reproduce: Enter offset aim points either through the DEST page or using the TGP Verify offset aim points show up in HUD With TGP SOI press TMS down or press OSB CZ Observed result: Offset aim points are reset and are removed from the HUD Expected result: TGP goes back to either the selected STPT or OA cz_removes_oa.trk

Also make sure the TGP is not in MAN mode but is set to AUTO. This was one of those things that I completely forgot about when coming back to Mavericks in the Viper.

Are you willing to share the actual document instead of a screenshot of it? I'm writing my own implementation of an IADS and this seems like nice resource to do range tweaking on it. Totally OK if you don't want to though!

Hey @BIGNEWY could you maybe share your track file of where you show it works flawlessly? Because I've only had it happen to me a once or twice and it was just a single tank somewhere in the middle of nowhere. In any other more "mission-like" scenario -where it's not just a solitary tank waiting to be shot- the handoff always fails for me. However, if I just put the TGP on the target, switch to MAV page and TMS up, I get a good lock and can engage. Seeing a working handoff would be like seeing a unicorn to me

Oh right, I was trying to get to the `mission` table but didn't realize that was in the `env` table. Thanks man!

I haven't figured out how to clear the message from the HUD after you've received a SPI/Markpoint. Can anyone enlighten me?

I think it's "AH-64D_BLK_II"

Is there a way using scripting to get the points of a drawing done in the Mission Editor? For example, if I draw a line in the ME, can I somehow find the (x, y)-pair of the two points while the mission is running?

Alright, thanks for the update