cfrag

While scouting for a nice location for a mission, I came across some scenery anomalies. It looks as if the roofs of these buildings are missing of have their normals inverted. The location is directly east of MV, see attached miz and trk Note that I will delete the TRK file due to storage restriction to my account in this forum within two days. roofs missing.miz

The Caucasus is old - people say venerable - and it is flat out the best performing map. It is also very harsh to mission creators who want to throw a bone to our helo drivers. To keep the map as performant as it is, I'm asking for a set of tiny enhancements: Please add Hospitals with helo ports for a few select cities. I'm recommending Batumi, Tbilisi, Kutaisi, Pyatigorsk, Krasnodar and Novorossiysk. Adding just 12 objects could make this entire map so much better for everyone driving a whirlybird (tbh, just adding the H ports could suffice, but adding hospital buildings would be grand).

Hmmm. Interesting, if inelegant. I'll have a look, thank you for the idea! -ch

OK, this newflangled "noSpawn" thang can be really helpful. Here I'm using it to set up three randomly located SAM sites around Baksan, but avoid them being set up in forest or across rivers.

NoSpawn zones Name Description noSpawn Marks this ME Zone as a noSpawn. To work, the center of the trigger zone must reside inside a clone zone. NoSpawn zones only work when the attached clone zone’s rndLoc attribute is active. The following rules apply to noSpawn zones: · A noSpawn zone attaches to the closest clone zone that it is inside. Thus, if a noSpawn zone comes to reside in multiple clone zones, it always attaches to the clone zone whose center is closest to its own center · A noSpawn zone attaches to a maximum of one clone zone · Clone zones can have from zero to many noSpawn zones attached · During cloning, situations can arise when the clone zone cannot find a free location where it can place the clone. In that event, the clone zone simply places the new clone and ignores all noSpawn zones inside it MANDATORY

Something like this? Time to uncork that flask of Pandora Aalto. clone here - but not here.miz

Thank you - that is some interesting data. What is your point, though? IMHO relative speed is what matters in most encounters, doesn't it? And mostly not at ground level. Uh. That's roughly from 2400 to 3900 MSL (a 1500 ft difference), and "uphill" or "downhill" depending on the direction and part of the leg. What weather and wind factors? Pressure alt and temp? Humidity? Also, I'm a bit confused wrt what these numbers tell us. Most fighters aren't designed for top speed at or close to ground level, they shine high up, where the air (and drag) is rare. IIRC, the eagle gets to top speed (some Mach 2.3) above 20k, and the Mig-29 allegedly is even faster than that. So why are you looking for "top speed" outside their respective performance envelopes? Are these numbers relevant? "Mostly"? So when did you not, what route did you use instead, and and for which planes?

I'm looking into this. My first step is trying to put this into mathematical terms so I can easily transcribe to code. Subtracting an arbitrary mask from an arbitrary shape is a b¦7ç%, and can take enormous processing. Consider the following simple example: Only the green edges are open to populate, and when green surfaces approach a small fraction of the total (i.e. the masked surface is larger than unmasked) a simple randomized approach can fail, and when the entire green area is covered, it will always fail. There are some trivial approaches to this, and they will fail with a determinable probability. I don't like it. At all. So this idea has hit a definite snag. I'll try a brute-force approach that trades processing time for resolution, and that will have a definite probability to fail if no solution was found within some bounds. I'll also place some restrictions on the masks: a masking zone can at max belong to a single cloner, so cloners cannot share a mask, but masks can share a cloner. Yeah, I feel that I've just twisted the lid on Pandora's flask.

I see that you've already put a lot of thought into this - thank you! I'll see how I can add this idea to cloners. I feel that cloners have become a "DML deity" in their own right (people are using DML just to get access to cloners), and making them more powerful needs to be balanced with usability and code maintainability ("with great power come great bills" and all that). While I like the mask Idea, I think masking the mask may be taking it a step too far, but we'll see what my little mind can come up with. So, thank you! for the great idea, let's see how far we can take it.

Leaving aside my gaffe at not checking the logs, I believe it would help if the code that is invoked has the ability to use the DCS debug feature (using setErrorMessageBoxEnabled(true) ). Invoking the handler with all debug options turned off (and not being able to turn it back on as it seemingly is implemented now) makes developing code for this feature even more bothersome than it already is. So, please allow script authors to turn debugging on in the invoked code. I also recommend that the documentation mentions that the invoked code has all debugging turned off, as simple-minded coders like I might expect the same scope being active as the rest of the code (I usually code with debugging on).

Huh. Now if that doesn't show me as a complete fool! No excuses, I should also have investigated the logs before jumping to conclusions. I stand corrected, thank you BN!

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)...