cfrag

That's good to know, and more power to you. Necroing a thread that rested peacefully for almost 7 years just to tell us that you have nothing to contribute to this thread except that you have never needed Moose nor Mist seems a bit... low effort? Once your missions require spawning, I'm sure that you will re-discover the many wonderful scripts that the community has created, and Mist and Moose may then pique your interest. Until then, enjoy DCS to its fullest.

Ah, perhaps it would also be a good idea to ensure that the persistence module loads before playerScore... Perhaps show a screenshot of the "AT START" trigger's right DOSCRIPT action list.

Please make sure that you receive a save notice before exiting. Persistence only saves if and when you get the notice (you have prudently turned the saveNotification on already, that's good). So you may have to wait a full minute until the data is saved.

How did you tell persistence to save? Angels has a saveInterval of 2 minutes, so it saves every two minutes automatically. How did you set persistence up to save?

Certainly. Here's how "Angels of Caucasus" sets up persistence to guard against the new DCS bug:

Thank you. Wrt persistence config: I strongly recommend that you use the saveDir and saveFileName attributes to work around a bug in DCS that at least affects single player. The log that you kindly included does not point to DML at all; DCS crashes when it tries to spawn helicopters. Are you perhaps using mods? They are immediately suspect after a patch (yesterday was a patch day) 2025-05-22 12:51:25.599 INFO APP (Main): MissionSpawn:spawnShips 2 2025-05-22 12:51:25.734 INFO APP (Main): MissionSpawn:initScript 2025-05-22 12:51:25.734 INFO APP (Main): MissionSpawn:spawnCoalition neutrals 2025-05-22 12:51:25.734 INFO APP (Main): MissionSpawn:spawnCoalition red 2025-05-22 12:51:25.734 INFO APP (Main): MissionSpawn:spawnCoalition blue 2025-05-22 12:51:25.734 INFO APP (Main): MissionSpawn:spawnHelicopters 2 2025-05-22 12:51:25.738 INFO Scripting (Main): event:type=mission start,event_id=2,t=0,linked_event_id=0,ta=28800, 2025-05-22 12:51:25.764 INFO EDTERRAINGRAPHICS41 (29632): surface5 gc() LOD 0 3 squares 2025-05-22 12:51:25.764 INFO EDTERRAINGRAPHICS41 (29632): surface5 gc() LOD 1 26 squares 2025-05-22 12:51:25.765 INFO EDTERRAINGRAPHICS41 (29632): surface5 gc() LOD 2 46 squares 2025-05-22 12:51:25.766 INFO EDTERRAINGRAPHICS41 (29632): surface5 gc() LOD 3 180 squares 2025-05-22 12:51:25.766 INFO EDTERRAINGRAPHICS41 (29632): surface5 gc() 2.579900 ms 2025-05-22 12:51:25.811 INFO EDCORE (Main): try to write dump information 2025-05-22 12:51:25.851 INFO EDCORE (Main): # -------------- 20250522-125126 -------------- 2025-05-22 12:51:25.851 INFO EDCORE (Main): DCS/2.9.16.10523 (x86_64; MT; Windows NT 10.0.26100) 2025-05-22 12:51:25.851 INFO EDCORE (Main): C:\WINDOWS\SYSTEM32\ntdll.dll 2025-05-22 12:51:25.852 INFO EDCORE (Main): # C0000005 ACCESS_VIOLATION at 00007ffdc5f2013d 02:000799D7

I would like to get to the bottom of this - so if you don't mind, a couple of questions: How do you know persistence or playerScore crashes your mission? Do you get any error message? And if you could show a screenshot of the playerScoreConfig and persistenceConfig trigger zones, that could help closing in on the issue if it is indeed related to either. And to make absolutely sure: you do *NOT* use the "SAVE MISSION" feature, correct?

Hmmm. DML Persistence works well in conjunction with Player Score. How do you know that it (persistence? playerscore?) crashes (what do you mean by "crash"?) DCS? In Single Player, be sure that you use the work-around using saveFileName and saveDir attributes as described before until ED fix the bug that they introduced two releases ago.

Version 2.4.91 - 20250522 A new DCS patch, old problems. The mission naming issue wasn't resolved, and something new has crept up: ED published an API for mission save, and I was conducting initial tests to prepare DML to support this feature. Well, it turns out that currently, DCS does not use the API: when you save a mission, it does not invoke the handler that it claims it does. In other words: developing DML state save code has to be postponed, and it makes me wonder if and how ED test their releases. It is a blatantly obvious bug to anyone who develops save code. By which I conclude that, predictably, nobody is seriously considering to develop for this 'Save State' joke of a feature, else this bug it would have been widely reported. Accordingly manageable is today's update - a small improvement for csarManager, and you can see the remains of my "Save State" hooks that are in dcsCommon, waiting for a better time. Changes Documentation Manual QuickRef Demos Modules - csarManager 2.5.3 - removed a bug related to autotrigger when starting the mission - dcsCommon 3.3.0 - detect if "SAVE MISSION" is/was used for a mission

Thank you for the update. It seems that DCS is gradually ramping up the minimal VR requirements; lucky me just significantly upgraded my aging rig, so I no longer see 'marginal system' issues (at least for the next few months, I hope).

That is great news, thank you so much! -ch

I have set up a bare bones test script to test the API. It seems that with the current release (in SP), the handler is NOT invoked, even though a new miz file is created. Here's the script that sets the handler and expects being invoked when I choose "SAVE MISSION". What am I doing wrong (demo miz attached for reference)? Thank you for any help. invoker test.miz

Then again, everyone seems ok with knee-deep grass on the field... So much for regulation football (not "soccer", yanks, real football! What you call "football" is simply a candy-assed, dress-up version of rugby)...

Simple mistake. They took the goal that Oli Kahn used to train with.

This is great news, and the plane looks terrific. Since I own each and every module on offer (a >>1K investment) I can't help noticing that a *lot* of the planes that you sold me as Early Access still haven't reached "Final Release" state after 5-6 years (F-16, WW2 Asset Pack). To encourage us often-burned-and-not-learning-the-lesson: do you have a tentative timeline when you envision the Final Release for this plane to occur? Thank you so much, -ch

I do not experience these issue, so in order to narrow down the possibilities, please allow me to ask some questions: - COLD or hot (standard) version of Expansion? - SP, ad-hoc hosted or dedicated server? - Which airfield are you taking off from? I'm assuming Nalchik. Is that airfield in your possession? - Please ensure that you are staring from a fresh mission, i.e. delete the Expansion (data) folder before you start the mission (after a long time, an old mission data file can wreak havoc on a newer version) I hope that we can straighten this out quickly

It irked me to not be able to provide a better solution. Here it is: as small script to cross-reference all flags that you are referencing in trigger rules (NOT in scripts!), and it will also tell you if a flag is used in a suspicious way (i. e. it is only read or written to, usually the result of a misspelled flag name). Run the script AT START, and you will see something like this: In that miz (see attached), the flags "1", "all is lost", "ghi", "abc", "def" and "jkl" are all only either read or written to (in the rules that are in square brackets"[","]"), while the flag named "123456" is both written and read, and is probably used correctly in that miz. There are a total of 7 flags used in the miz by the trigger rules (again, not inside scripts). Here's the script itself, run at start Demo miz below. Hope this helps. Enjoy, -ch flags in the log ruler.miz

Please be advised that what I say below is merely based on my experience, not a deeper knowledge of MSE's implementation They are nearly identical, with the second approach having a minuscule advantage since it requires fewer main loop cycles, but it really comes down to how triggers evaluate the OR clause. I do not think that either will have a noticeable advantage over the other. If you know how to do that, you would be better served with a script that does these checks. Since they are map objects, you can then change the periodicity of checks from once per second (as is done for triggers) to once every ten seconds (or longer), shoring up performance cycles. Checking if map objects are destroyed usually isn't a time critical task. I believe similar points apply to this. I strongly recommend that you define what you are trying to achieve with this before settling on the method of how to achieve that, lest you fall into the trap of premature optimization. Also, you may want to take into account serviceability: what is easier for you to maintain: 10 rules of one each, or one rule of 10 conditions? Neither is easy nor user-friendly, so your choices are always going to be bad. Not in ME. You could write a script that parses/analyses a miz file and then dumps all the flags that are referenced in the mission's trigger rules. You'd then also want to add a step to see which flags are only referenced once or one way (a good sign that a flag is used wrong is when a flag is only written to or read from). DML's debugger does this, but only for flags that are used/defined in DML's context, but not for flags that are read from or written to with trigger rules nor scripts. That would rather depend on how you placed the static. Using ME, statics are one-unit groups. Using scripts, you can place multi-objects statics. From a logic perspective, it's cleaner to go with UNIT, as it isn't guaranteed that ED will keep that single-unit group for statics, and you are relying on an implicit assumption that the static is in a single-unit group. Use UNIT to ensure that your mission is future-proof.

Agreed. The issue comes with numbers. Let's say we are using low-quality human models, with only 5k tris/3k verts per model, and pre-arranged poses (i.e. they do not move at all, are static). So, how many of these objects to populate a village? Let's say 50. So we add 250k polys (tris) to the scene. No sweat, even with shading, texturing, perhaps even some transparency you are fine. How many of these ultra-low quality models to populate a very small city? Say 500. How many small cities in your visual range? Maybe 10. We should still be OK-ish (2.5M tris added to each frame - not all drawn, but all transformed each frame) Now, how many of of these models would you need to put some semblance of life (none 'end of world' desert) into a city like Beirut, Adana or Tel Aviv on the Syria map? Adana is some 2000 square kilometres, and we put, say 10 people per sqKm (in reality its about 160 people/sqKm). So you need 20'000 models just for a mostly empty Adana, with the other population centers still requiring population as well (20k people at 5k tris = 100M tris). That will put a dampener on your GPU. Worse in VR. Without any tangible benefit (10 ppl per sqKm still looks reaaaaaally empty) So, it'll hopefully be small fry for the GPUs of the future. Right now, they'll drown.

The Subject you chose for this thread still is "Proposal: Free modern onboarding and/or trainer module". This remains relevant, should you write something like this: When you extol a "shared experience [...] without pressure" in this context, be prepared that people think that you mean that the trainer as referenced in the thread's subject can facilitate that. If you were just rambling OT, that's OK. You may want to make that more clear. Sure, and their next question is "why do you think it's good?". I'm sure that you'll provide evidence to your friends. And then we'll be back at the iconic fighters: Falcon, Eagle, Hornet, Apache. Because nobody perks up when you say "they have a good trainer". Hmmm. I'm referring to this written by you (below), which I did read (emphasis mine): There's a world of difference between a crunchy "No binding. No setup" and a limp "manageable" "basic setup". The first is good and universally understood, the other depends entirely on one's interpretation of "manageable", and definitely does require bindings and setup. As an aside: if you want to have a real trainer aircraft in DCS, one that is built along a training experience, it requires gobs of bindings since the average training session revolves around setting frequencies, fiddling with dials and knobs: procedures - all the things that you can go without in an FC fighter. A trainer would require a lot more bindings than e.g. the FC A-10A. That plane has no radios to set. Imagine a trainer that can't train radio procedures: NDB, VOR, ADF, RT, ILS, IFF, the works. In HF (FM/AM), VHF, UHF. You really want to be able (optionally, of course) to bind those in a trainer. Which makes me think: you probably do not want a trainer aircraft - you want something to take someone along for a joyride, something that impresses, and hooks your friend to DCS. A trainer won't do that. That's why, in games, trainers are for enthusiasts, not neophytes. I'm with you on the "no bindings, no setup", btw. I just don't know how that can be implemented. And I want it for all aircraft in DCS. You glossed over that bit, and let us remember that this is a thread where you are advocating a trainer aircraft as means to attract significantly more people to DCS. So, how do you experience multiplayer DCS, and how would a trainer aircraft improve that? I would submit that currently, a trainer aircraft would make a worse experience, and 90% of the issues that people encounter can't be remedied with a trainer. And to add insult to injury: once your friend jumped through all the hoops, once he is inside the trainer, he can't even blow stuff up. "Lame!" -- I submit that it'll leave most people with the distinct impression of a procedures-focused (because that's what trainers are) mil sim. People don't go into DCS to ogle at the scenery, nor being bossed around by an instructor. You don't take driving lessons in a race car sim: Assetto Corsa doesn't give you an instructor mode, and you neither fly with an instructor in a combat flight sim. You can, but that's not the main attraction. The crowd pleasers are what draw the crowds, not the "plain Janes". I love the trainers in DCS - but I'm the odd one out. How do I know that? Because I tried. Only 3 instances, yet they have all been universally negative, they all wanted to fly a "real fighter", not a trainer, even if I offered to help them. Incidental evidence isn't proof, I agree. Maybe they simply didn't like me teaching them. Fair enough. Look, I get that you want to make DCS more accessible. That's what I desperately want as well. You may have to contend with the fact that a 2-seater trainer aircraft is not the solution for that.

Ah, the wonderful world of dreams and wishful thinking, where ambrosia springs eternal, and everything arranges itself to my wishes. Please describe how DCS can become this, as it is lightyears away from that, and I am genuinely interested in ideas how ED can achieve that. A trainer will not magically erase the friction of setting up bindings, an abysmal UX, terrible missions etc. I'm all in with a frictionless experience, sign me up now. How on earth will a trainer aircraft/module magically erase the fact that you still have to bind controls, go online, find the mission where your instructor is, and join their aircraft (I'm assuming that the student is spared having to create a training mission and host it). There's no magic wand you can wave these issues away. Not with a trainer, anyway. Fair enough. Then why would they come to DCS? In five seconds or less, please summarise what DCS does well as a game, why I should try it. It's the Hornet, Tomcat, Viper, and Apache. Blow stuff up, with a dash of realism. Ah, magic tech. I see. So student sits at home, connects their new $20 Joystick generic brand "Funstick" with 5 axes, 10 buttons to their computer; magically joins you (let's not sweat details, we are in a dream). You control the aircraft for a while, then you tell him "You have controls", and by magic DCS knows that that the values read from HID Device A, analogue input 3 at the remote computer should be interpreted as a Yoke's pitch. Axis Inverted, of course, with a 20% curve. Sure. Say, what's the colour of the sky in your world? That kind of tech does not yet exist. For any game. Maybe when AI gets more advanced. And heck, yeah, if DCS could do that, I'll be incredibly happy too. You do realize that this "modern, ride-along" system requires the neophyte to be on-line and connected with you, creating a catch-22, right? To ride with you, they need to be on-line, and to learn how to fly on-line, they need to ride with you. Or is this, too, solved by magic? DCS' on-line experience is terrible, yes, and should be massively improved to make the entire experience more user-friendly. How do you suggest that ED overcome this? With a trainer module that requires going on-line? Are you trolling?

Please check out the demo I included before. It is using the "empty!" output that fires when all objects from the last clone cycle are destroyed, and it seems that was what you are looking for. Below is an updated demo that also uses radioMenus and groundexplosion to force destruction. The empty signal "boom" is sent when any of the combines is destroyed. Random Tech Combine.miz

Use cloners. Random Tech Combine.miz

This had me stumped for a while. I finally found the issue related to a dangling 'else' in csarManager that I unfortunately misplaced when I introduced the "autoTrigger" attribute, and the issue is much more likely to happen if persistence is added to the mix. It is not a persistence issue, it's a plain stupid bug I added to csarManager. Below please find the updated module. csarManager2.lua