Pizzicato

Ha! Great job, Raptor. I think the key difference between the older manuals and the Apache manual is that the old ones just used to focus on "Here's what the system is and here's what it does." The Apache manual does that too, but also adds "...and here's how you use it, here's why you use it, and these are the bits that are most important to pay attention to." That additional context and the "decluttering" of the information by focusing on the most practical stuff is hugely helpful.

I just wanted to give a quick shout out to whoever wrote the manual for the AH-64. I feel as though a lot of the earlier ED manuals were incredibly dry and full of ultimately useless technical info that would be more useful to mechanics and engineers than aircrew. The AH-64 manual, on the other hand, is written in a way that's much more practical and digestible, and which takes the time to explain concepts in a way that's engaging and player-friendly versus reading like a technical manual. It feels as though they've taken some good cues from Chuck's Guides. Appendix A which concisely articulates the various different flows for pretty much every major action you'd want to take in the cockpit is especially useful and appreciated. So yeah... awesome work, whoever put this together.

@Grimes Here's what got output to the dbUpdateERror.lua file. static = { ["y"] = 760119.6875, ["type"] = "S-300PS 5P85D ln", ["name"] = "Dead_SAM - SA-10 Grumble-4", ["x"] = -124575.9375, ["heading"] = 2.8198712957479, ["dead"] = true, } -- end of static

Hey @Grimes I'm wondering if something changed in the last patch? The mission engine that I'm writing still works fine, but I've started seeing a bunch of MIST warnings in my DCS.log along the lines of: 2024-05-26 23:36:48.181 WARNING SCRIPTING (Main): MIST|dbUpdate|990: Dead_SAM - SA-10 Grumble-4 is not a Group or Static Object. This should not be possible. Sent category is: static 2024-05-26 23:36:48.181 WARNING SCRIPTING (Main): MIST|dbUpdate|990: Dead_SAM - SA-10 Grumble-2 is not a Group or Static Object. This should not be possible. Sent category is: static 2024-05-26 23:36:48.181 WARNING SCRIPTING (Main): MIST|dbUpdate|990: Dead_SAM - SA-10 Grumble-1 is not a Group or Static Object. This should not be possible. Sent category is: static 2024-05-26 23:36:48.181 WARNING SCRIPTING (Main): MIST|dbUpdate|990: Dead_SAM - SA-10 Grumble-3 is not a Group or Static Object. This should not be possible. Sent category is: static nullThe objects in question are just static objects that I'm spawning with the default coalition.addStaticObject( ) as opposed to the equivalent MIST function. It's not causing me any issues aside from bloating up my DCS.log, but I figured I'd mention it in case it's meaningful from your side. The "this should not be possible" comment makes me curious. I can share the mission if necessary, but it loads a bunch of Lua modules/classes from my hard drive so I'd need to create a new version of the mission that embeds them first.

So we're obviously talking at completely cross purposes. There's no missing point B in my initial file. There's a start point for the orbit, and there's an end point for the orbit. The aircraft does what its supposed to do according to the documentation - it starts the racetrack at the waypoint labelled Start and completes the loop at the waypoint labelled End. That's how the race-track has worked ever since DCS's inception and beyond. It also works just fine in the mission and in every other mission I've ever made. The only issue is the inability to climb. The suggestion that there isn't enough time to climb doesn't make any sense to me either. It can do this just fine (with nautical miles to spare) outside of the Orbit. It can also do it just fine within the Orbit if you set the speed a little higher. The weirdness is that the climb behaviour goes from 2ft per minute to 3,000ft per minute if you just set it to go 100kts faster. That's not a feature. That's not user-error or PEBKAC. It's just a clear behavioural bug. If you can provide an file demonstrating a reasonable climb during - not prior to - an orbit task being given then I'm happy to be proven wrong, but until then it's a Class B bug as far as I'm concerned. With regard to your underlined sentence, are you saying that you had the aircraft climb while orbiting while you were editing my mission but then didn't provide that version? I'm really confused. Anyway, this discussion is getting neither of us anywhere. I genuinely don't understand what point you're trying to make and why you're trying so hard to explain away a demonstrable problem. Ironically, we're both just wasting daylight going around and around in circles without gaining any conversational altitude, so I'm going to leave it here.

That's not what your fix is doing as far as I can tell. nullThe aircraft starts at 20,000 ft at WP0/Spawn. You then get it to perform a climb to 30,000ft from WP0 to WP1. It then flies to WP2 where it commences its orbit which is conducted entirely at 30,000ft. There's no climbing at all during the orbit. Did you upload the wrong version of the file?

Yes, the bug extends to the blue aircraft. Your fix is a workaround, but it doesn't address the underlying problem which is that the AI can't deal with an Orbit task that asks them to climb above their current altitude unless they're travelling at absurd, fuel-draining speeds. That being the case, you can't push an AI Orbit Task that has a randomised altitude unless you ensure that the aircraft has already attained an altitude above that. If you want to set a randomised orbit altitude between 50,000 ft and 20,000 ft, as an example, you've first got to send the aircraft up to 50,000 ft just to be sure that it'll be capable of reaching whatever altitude the randomised value lands on. The edge case here is that the ascent gets interrupted by the AI having to intercept an enemy aircraft, after which it struggles to climb back to the altitude in question. Yep. That makes sense. Thanks Buur.

Thanks for the pointer, @buur - that definitely helped. It also confirmed that there is something problematic going on under the hood. I was only able to get the Flanker to cleanly climb from 20,000ft to 30,000ft by setting its speed to 800 kts / Mach 1.29 in the editor. I'm no aeronautical engineer, but I'm pretty sure that the Flanker shouldn't need to be travelling at 1.3x the speed to sound to make it to 30,000ft and stay there. That's also suicidal from a fuel consumption standpoint, as it requires the Flanker to stay in full burner for the entire orbit. I tested it, and the same Flanker can take off from Maykop (effectively sea level) and climb to 30,000ft at just 500 kts / Mach 0.8 over a shorter distance with no problems. It's only when climbing out with the Orbit task that it struggles. In terms of the 20,000ft to 30,000 test over a 35nm leg using Orbit, I tried the following: 500 kts / M0.8 - The Flanker can't climb at all. 600 kts / M0.97 - The Flanker climbs to 28,000ft then stops climbing. 700 kts / M1.13 - Weirdly the exact same as above. It maxes out at 28,000 ft and then stops climbing. 800 kts / M1.3 - Perfect climb with no issues. There are very clearly shenanigans going on here.

Thanks for taking the time to look into this and supply a solution and explanation, Tempest. I really appreciate the time you put into this. I'm not convinced that this isn't a bug, though, and that the altitude change is too much for the AI to cope with. The Flanker in the mission had 10nm to gain 10,000 ft which is pretty trivial. I ran the mission again with a 500 ft delta instead of 10,000ft, and it still struggled. Similarly, the ability to set a discrete altitude and speed for the orbit is surely intended as an override for the waypoint parameters - not a redundant set of fields that need to be arbitrarily matched by the mission designer. The Hoggit page reinforces this (although Hoggit is obviously inferred documentation, not official): https://wiki.hoggitworld.com/view/DCS_task_orbit It's also clear that this functions perfectly if the group's starting point is above the assigned orbit altitude. If you start at 40,000ft and ask the AI to orbit at 30,000ft it behaves beautifully. It only has an issue if it has to climb - even if that's only a few hundred feet. That's a bug from my perspective, not a misunderstanding. Regardless - there are two specific use cases that I want to accomplish through scripting but without dynamic spawning (because I hate how DCS only supplies random GUIDs in the mission debrief for dynamically spawned groups). 1. I want to randomise the orbit position, altitude and speed of CAP groups that are already in flight at the start of the mission. I can make this work by setting their start altitude at 50,000ft and having them descend to their orbit altitude, but that's a workaround to the issue above. 2. I want to have delayed start CAPs taking off from the ground that have similarly randomised CAP orbits. I haven't figured out a functional workaround for this yet, though. I'm definitely open to ideas, though. Again - I really appreciate your time and input, but I disagree that this isn't a bug. I have no issue with the AI needed to climb to orbit altitude over the course of several loops of the orbit, but they should be able to do it at more than 10 ft per nautical mile.

Hey all, It appears that AI aircraft don't seem to be able to climb to their assigned orbit altitude from a lower altitude. In the attached mission: An Su-27 is flying at 20,000ft and commences a Race-Track orbit when it reaches Wpt 1. The assigned altitude for the Race-Track is 30,000ft. The Flanker commences the orbit and starts climbing, but almost imperceptibly. By the end of of the first leg of the orbit, the Flanker's nose begins bucking up and down like a rocking horse. This oscillation gets very extreme over time with each passing loop. This can be seen really clearly with time acceleration. The Flanker does eventually reach 30,000ft, but it takes nearly 40 MINUTES of orbiting. Once the Flanker has eventually reached 30,000ft, it resumes normal flight. The example in the attached mission just shows the Flanker, but I've repeated this test with a Mig-29A, an Su-30 and the F/A-18 and the same issue occurs with each aircraft. This is really problematic for mission scripting if you push an Orbit task as an Advanced Waypoint Action when the aircraft is below the assigned Orbit altitude. RockingHorseOrbit.miz

Thanks for the explanation, @cfrag and thanks for the tangible example @Wrecking Crew.

Hey much-smarter-than-me-folks, My old nemesis math(s) has raised its ugly head, and I could do with some help. How would I go about calculating a random point in 2D space that's an exact distance from a known point? Specifically, I'm looking to create the second point of a racetrack orbit that's exactly X nautical miles from the first. I assume it's got something to do with finding a random point on the circumference of a circle, but that sounds suspiciously like trigonometry to me... Any guidance from the resident math(s) masters would be much appreciated.

@Wrecking Crew Feel free to keep adding to this thread. The more we can share the knowledge, the better for everyone.

Did you add a failsafe in case the missing event.initiator was the Hosta Bridge, and you'd therefore missed an important mission event?

Hey @TEMPEST.114, When I'm referring to OOP in Lua, I'm just referring to exactly the table-based "classes" that are described in the manual you linked to and here in the Lua-Wiki: http://lua-users.org/wiki/ObjectOrientationTutorial. The "class instances" that I'm creating are effectively just new tables that have metatables that fall back to the original class template (which is itself just a table). I think that's how DCS's Lua implementation functions, and also Moose's from when I tried deconstructing it for educational purposes a few years back. Again, though - I'm an enthusiastic amateur as opposed to a trained programmer. Your suggestion about maintaining a single table of targets and a single Lua script that handles events makes a lot of sense, and I did start thinking about that after yesterday's issues. I'll have to think about what that means for the rest of my code, though. It's all fairly clean and nicely encapsulated, but it'd still probably be a little tricky. It may well be the smart approach, though. The issue you raised about Unit tables being garbage collected before the event gets sent is infuriating, and I've had to fall back on the exact same approach of collating all of the Unit data in my own scripts as opposed to relying on DCS. It feels really hacky and inefficient, but it also seems like the only valid solution. Thanks for taking the time to reply and provide suggestions and insights.

Yep. That definitely helps. Thanks cfrag. I did do a couple of night school courses in C++ about 6 or 7 years ago so I have a foundational understanding of OOP and its underlying principles, but that's about as far as it goes. I do know just enough to have a reasonable sense of the limitations and shortcomings of Lua's approximation of OOP, though. I've definitely been caught out many times by the whole getCategory() thing - even over the last few days. I'm definitely finding myself having to script much more defensively in order to be 100% sure of the object type that I'm dealing with, but my checks are currently rather case-specific and hacky. I've started leaning into using more <Class>.isExist() checks recently, but not as rigorously or consistently as I should. If nothing else, DCS is slowly forcing me into more robust and considered scripting as I encounter more and more pitfalls and edge cases.

Thanks cfrag. I did actually add those checks anyway after posting this thread, but they make me a little uncomfortable in that it's now possible that I'll miss receiving a mission critical death event. I guess I can just run an occasional sanity check to make nothing's been missed, but it's a bit of an ugly workaround. Thanks as ever for the response and the confirmation that I'm not going crazy.

I'm pretty sure this is a bug, but I need a sanity check in case I'm misunderstanding something fundamental. I have a Class of type Target that I use to create class instances/objects that contain data about key strategic targets on the map. Each Target instance has an Event Handler that listens for an S_EVENT_DEAD Event and checks to see if the initiator is the DCS Object that it wraps (e.g. an EWR station, an AWACS, an ammo dump, etc.) I created 7 of these Target class instances in a test mission, but I started getting a crash referring to a null event.initiator parameter. It turns out that the last instance to receive the Event does indeed receive an empty event.initiator parameter. My only thought is that the DCS object has been quietly cleaned up and destroyed by the time the last Target class instance receives the Event, but that seems really bizarre. Does anyone have any insights? --- ON EVENT -- Handle the death of the DCS Object associated with this Target. -- @param self -- @param event #table The event table from DCS. function AW.Target:OnEvent( event ) if event.id == world.event.S_EVENT_DEAD then env.info( "AW MED: Event Initiator is type: " .. type(event.initiator)) AW.Utils.OutputTableDebug( event ) <...snip...>

The most user friendly way to edit a kneeboard's size and position is with DCS Kneeboard Builder: https://dcskneeboardbuilder.com/

Yeah, I get that. In this instance, though, I'm just looking to overwrite the file contents. I'm wondering if using dofile part of the problem. Maybe I should be using io.line, but I'm not sure how to use that to read a table. I'll keep reading around and see what Zi can find. Thanks for the links, Tempest. Edit: From reading the docs, it looks like the issues might be that i haven't been capturing the returned reference from my io.open calls. Looks like it's this reference that I should using for further file operations, whereas I was just reusing the explicit filepath and filename. I can't test it right now, but that seems promising.

Thanks cfrag. Your explanations are super-useful, so thanks for taking the time to respond.

Hey all, I'm having a bit of an issue with writing to a file that's already been created and written to. I can create a file and write a table to it, then read it back in using dofile, but when I try to rewrite to the file I'm getting the following error: EDCORE (Main): [C:\Users\pizzi\Saved Games\DCS.openbeta\Missions\AW_Kola.lua] CreateFile(REWRITE): The process cannot access the file because it is being used by another process. I suspect it's a case of not properly closing the file after reading it at Mission Start, but I can't figure out what I'm doing wrong. I assume I'm misunderstanding something fundamental about the IO and LFS libraries, but I'm not sure what. Here are the code snippets for the Mission Start (file reading) and Mission End (file writing) test I wrote. -- Reading the file at Mission Start. if io.open( self.savefile, "r" ) then env.info( "AW HIGH: Save file found." ) dofile( self.savefile ) io.close( self.savefile ) end -- Writing the file at Mission End function AW.Mission:OnEvent( event ) local self = self.parent if event.id == world.event.S_EVENT_MISSION_END then env.info( "AW MED: Mission is processing Mission End event.") local file = io.open( self.savefile, "w+" ) local saveData = { state = "PEACE", deadUnits = { "Jim", "Fred", "Quentin" } } local serialised = mist.utils.serialize( "saveData", saveData ) if file then file:write( serialised ) end io.close( self.savefile ) end end Any help or advice would be much appreciated. Thanks in advance.

Thanks for the explanation, cfrag. That sounds simple enough. I think the only challenge is that there appears to be a bug (feature?) at the moment where units are removed at the moment of destruction. That means that any calls to the unit from the event.initiator property of S_EVENT_DEAD generate an error which isn't super helpful.

I'm trying to create persistence between missions, so I'm saving out a table of dead units at the end of the mission and then reloading it at the start of the next one and adjusting the world state accordingly. That being the case, I'd need to get the types, positions and orientations of the "should be dead" units, destroy them, and them find the equivalent statics and spawn them in their dead state. Definitely doable, but I've always been a bit intimidated by dynamic spawning. It always seems super complicated, but maybe now's the time to learn.

I use Glogg which is a very similar (almost identical by the looks of it) tailer. I'd be absolutely lost without it. It's invaluable. I really like your approach of having different colours for your different Lua classes. I hadn't thought of that, but I can see how it would be really valuable. I think I'm going to have to rework the output from my classes to work the same way. Thanks for the tip, Tempest.