cfrag

Original Condition, mission starts at 0800 on June Condition uses multiple conditions at same time just for clarity This is the condition, to start at time(0),converted to 08:00 Changed mission start time to 09:00 Looking at the conditions: NO CHANGE Clicking on the first condition: updates to 0900 (32400), while the others remain unchanged to now one hour before mission starts. That seems wrong to me. Ignore the images that follow, for some reasons the are just there .

Thanks for the hotfix @BIGNEWY, I believe that this can help a lot. I think that there's a small glitch in the interface: when there are ABSOLUTE TIME conditions in a mission, and the mission creator changes the mission's start time, it seems that these conditions are automatically updated - but at least their name's aren't (you need to click on each and every condition to have it updated). I'm not sure if this is required before save; I *may* have seen some not-updated ABSOLUTE TIME conditions after saving and reloading that lost their update, but I'm not sure. In any event, if the ABSOLUTE TIME conditions all update immediately including title, I think that that removes all doubt.

… and that is good or bad? What is the expected behavior?

"Fast-Roping" will be part of the upcoming release (scheduled for Thursday). It's not great, and all troops appear on the ground, but it's there

I'll have a look. Which of the AI planes seem early (group names, so I can try myself)?

Yes. As soon as there is something worth our time. DCS's current 'Save State' IMHO is an embarrassment to ED.

The missing addCommandForUnit() method is the base for any player-individual feature. Think CSAR missions or Insertion missions where you want to tell your troops to disembark, but your (human) friend in the helicopter behind you waits for you to clear the LZ. Think a score feature where players want to call up their individual score. Think any transport mission where you want to tell your ground team to load/unload etc. Anything that requires player-individual interaction of a script with a player currently requires single-unit player groups. It's one of the bigger impediments/oversights in DCS' mission scripting API, and has been for years.

There is a flaky and quirky "Band select" function in ME that breaks all interface rules, and partially works, but only on days that are divisible by prime numbers. Might be worth a try if you feel lucky. In some version of DCS it only worked on missions that you have opened, i.e. NOT in freshly a created miz. Your mileage will vary.

If I wrote that I was sorely mistaken. One server scripts are put into /Hooks, and mission scripts do not run in server space, they run in client/mission space. Putting mission script files into /Hooks won't accomplish anything except filling that folder with scripts that do not work. Turns out, it is more difficult to implement than I expected: there is no way in DCS to find out if a player died. Their plane - sure. But not a player. That, unfortunately, does not define the term. What is "across", and what is a "front line" from a mathematical point of view (scripts need a mathematical expression like "less than 50 meters from a point"). That could be a first step. but unfortunately won't be enough: what would 'across' mean in this context? And that line must run across the entire map, and there must not be multiple isolated areas for one side. DCS (strangely enough) does not have the concept of a territory/front line, and it may get it with dynamic campaign. Until then, I think I better let that problem rest. At this point this appears to be foiled by a script's (or my) inability to reliably determine if and when a player dies in DCS.

Why don't you just try it? But yes, it should, even with different messages for the first time, and support for audio.

You may also want to take a look at the 'valet' module.

Not right now, and I can certainly have a look at adding this to helo troops. If you think of roof-top deployments, be advised that DCS won't give you that altitude so you'll have to add that to drop alt manually. I'll also look into (and research) max v during drops, and see what is a reasonable maximum speed, and if DCS's resolution is fine enough to return accurate information. The implementation would be rudimentary: DCS has no rappelling animations, and dropping troops would be instantaneous in heloTroops.

AN EVEN BRIEFER NOTE ON DCS MISSION STATE SAVE (MSS) On further analysis of MSS my advice at this point is to not use MSS. It's unfathomable to me why it was released to the public; it makes ED's team look incompetent and out of touch with their players.

You now have officially crossed the line from 'teasing' to 'torture'. My credit card is shivering in anticipation. So am I. Slight correction, perhaps a mis-translation: Teufelsberg ("devil's mountain" transliterated) was formed using the debris and rubble from bombed-out Berlin after WW II. The listening post is iconic, and the Huey tour made me salivate over my keyboard, shame on you!

A SHORT NOTE ON DCS MISSION STATE SAVE AND DML DCS now has an experimental "Mission Save" feature. I feel it is not yet ready for prime time and advise everyone (mission designer and player) to not rely on its ability to save a mission. MSS will fail your expectations 99.99% of the time and produce unpredictable results. Since MSS does not support an API to allow scripts to interface with it, and a saved mission can completely screw up time, flags, locations, paths, unit templates and a million other things, I caution against using it with DML-enhanced missions. If you report bugs, please understand that I expect that you exclusively report DML bugs that appear in missions that did NOT start from a MSS-saved state. Let's all hope that MSS - promising as it is - can advance to a usable form quickly.

Agreed. Resetting all flags, and falsely setting elapsed time to zero should kill 99% of all unscripted, and 100% of all scripted missions. I find it bewildering that something this immature was released.

TL;DR: In its current incarnation, DCS's 'save state' is IMHO unusable and will mostly serve to annoy players who believed that they can save and continue a mission like in most other games, only to find out that they were severely mistaken. While there might be the odd instance where a re-loaded mission behaves almost as expected, the vast majority don't. IMHO, ED would be better served if they did not advertise this feature, it will cause people to become frustrated with DCS. WHAT TO EXPECT? When ED announced that DCS now supports mission state save, they left open what this "state save" actually means. Without guidance nor explanations, people will assume that "DCS Mission State Save" means what they individually hope that it means: a save feature that allows them to save a mission in progress (say two hours into a three-hour mission). A few days later they then try to resume where they left off. The results are ugly. IMHO, DCS state save is in its infancy, unsuitable even for trivial use. If DCS were a word processor, it's "save" ability would be akin to being able to save most upper case letters, and some numbers, but nothing else. Formatting, punctuation, blanks, images, most numbers and all lower-case letters can't yet be saved. You decide if that means 'usable save' in a word processor. In a nutshell: Technically, DCS missions can save some state. Usually, it's not what you need. IMHO, in it's current form, "DCS Mission State Save" is a first experimental step that has no tangible use for players. It barely works, and in a too limited way. Even trivial use cases can fail spectacularly. HERE'S WHAT I TRIED; In a super-simplistic mission with player-controlled hornets (one ground, one air), one blue ground unit and 4 red ground units. I started the mission, performed some simple settings and saved it after a few seconds. I then started the saved mission, comparing what I saw last in the original mission with what I saw first in the restored mission. I also opened the saved mission in ME (and a text editor) to verify what the changes consisted of in-file, how these changes are reflected in Mission Editor. So what are DCS's current save abilities? AI GROUND FORCES (placed with Mission Editor) Units that were destroyed are removed from the mission, there is (sadly) no debris left in the places where a unit was killed. A bit disappointing, but OK. Paths are modified so that if a units was halfway between WP 2 and 3, that point now becomes the new initial points, and waypoints are moved up. Yes, the original path is modified, probably screwing with any WP actions. But that becomes irrelevant, because: Waypoint actions are scrubbed. So if you placed units with ROE HOLD, they are now all ROE WEAPONS FREE. Kiss goodbye any training mission that you saved in progress, it's now become hot. Expended munitions are not saved, so all units return with full health and full stock. Paths can receive a mysterious 'span' tag depicts a completed path Player Planes (used an FA-18 for tests) NO COCKPIT STATE is SAVED. Worse, a hot plane (engines running on an airfield) is turned to a cold one. Radio, Radar, Light, or any other settings are gone, as are weapons programming. If your IND was aligned, it no longer is, etc. This means that using state saving to create training missions that require exact cockpit setup (like setting up your glide bombs) is straight out. Analyzing the .miz shows that on saving the player aircraft, DCS saved the player aircraft as "start from ramp", which was not where the plane was, and means that it will be cold, all settings forgotten. NO PLANE NOR AVIONICS STATE SAVED I then entered the cockpit of a flying Hornet, entered a gentle bank turn, enables AP, BALT, and started a circle, switched the left MFD to HUD and then turned off the left MFD. After 1 minute, I saved, while heading 050 at 6200 AGL. After loading the saved mission, I entered the cockpit with the hornet wings level, AP off, BALT off, left MFD turned on in default configuration. SCRIPTS A script's state (the value of all variables) isn't saved. Scripts start with the mission and do not know what has changed. They assume that the mission has just started since timer.getTime() will falsely return 0 at the mission's beginning. No scripting API for save state exists. Flags All flags are reset to 0, no flag state is saved mission time Mission "time of day" is advanced to the point where the mission was saved. WARNING: timer.getTime() is reset to 0, so if you have any trigger that uses "Time before" of "Time later" you now must use the new "Absolute time" and perform some silly time conversion realtive to 00:00:00 local time, and can no longer rely on time relative to mission start. That means that if you move the mission's start time by just a second forward or back, you must re-calculate from hand all your triggers. This incredibly bad design is hopefully just a stop gap until ED can come up with a better method. Mission.miz There is now a lot of spurious information added to the miz: 15k lines of failure information, and vehicle group's 'unwound' paths are put into "span" records. So, IMHO Mission Save State is unusable in it's current form for for anything but the most trivial missions. ED should be aware that people expect a lot more, and many will be frustrated. This first step IMHO does not reflect the abilities of ED's talent, and should not have been on public display, it opens them up for ridicule. I'm hoping that upcoming releases dramatically improve upon this state. state test 0.miz

Impressive! And I like the UGRA market close to DCS Market. There is one highly unrealistic thing, though, in Leipzig: the weather. It should always be damp, with a slow drizzle and discouragingly low clouds. At least that's how I remember it from my two visits there

That new warning should warn you (it's only a warning) that the zone "CSAR ZONE" and "HOT EXTRACT CSAR" are set to "deferred" (i.e. they do not generate a CSAR at mission start), yet do not have a defined trigger attribute to start a CSAR.

Perhaps this may broaden your view: you want to be able to save and load missions, yes. Missions that someone else created. That can save. How are missions created? With Mission Editor. So you very much do want support for saving in ME and API - you just don't know that you do. You want it a lot. It is. Very much so. Otherwise there would be no missions at all - except what you create for yourself in limited ME. You simply do not seem to see the big picture. I strongly recommend that you try and broaden your view. While Navel-gazing may be en vogue, you seem to leaning towards solipsism. Occasionally, I'd try a new approach. If you even exist, that is.

Asd long as you do not use the new save function and start the miz using DML's persistence it *should* (I hope) behave as before. I've not yet had much time to test the new save feature and miz data structure. I'm hoping that the impact is minimal (except that saving doesn't work with DML as you would expect because scripts cannot save their state)

DCS's current save feature is not expected to work with scripts, provides no API for scripts, and looks very experimental. I can virtually guarantee that it won't work (well) with DML, because there currently is no way for scripts to save their state, so I recommend to not use Mission Save with DML-based missions. I have submitted a first draft for a state saving scripting API (here), and we'll see what will become of it.

We are already way off topic, so I'll just chime in with this: the USA have just become a textbook case of what can happen if a government simply disregards privacy laws and grabs private data. The damage is done, and the flimsy protection that "US laws" afforded their citizens evaporated over night. Here in Switzerland, the reaction is swift and decisive: new policies in most privacy-sensitive industries (read: banks, payment processors, etc.) now implement kill-switches for private data should something similar happen here. Privacy is very important in a world where we increasingly meet, work and purchase virtually, and identity theft is but one of the challenges. Win 11 is intrusive, and - worse - made by a company that resides in a country that many no longer regard as a judicative safe nor reliable haven. I fully understand when people are concerned. How they react is their own choice, ignoring the risk is certainly one way. There are others. What this has to do with DCS is a mystery to me, so I just contributed to the problem without helping, I know

Yes, and I think you know that you are being willfully obscure here. There is no meaningful growth in the Linux share, so even if Win is not growing, at the current growth rate it will take over a decade of Linux growth to reach parity with Win in desktop gaming. You know that. And you are also conveniently overlooking the fact that Linux is hopelessly fragmented, a veritable user hell. Finding the correct driver for a device that works for your distro is hell, the experience is not ready for prime time. You are making two gigantic assumptions here that IMHO are completely unwarranted. First, you assume that the code in DCS for Linux would not be the decrepit old code that now is in windows. What makes you say that? If true, that Linux version would be based on a completely re-engineered core. That is not going to happen. And most DCS clients also are connected to very, very specific hardware. Just the thought of getting my WinWing controllers and VR work in Linux makes me wake up at night, covered in sweat. No, no matter what distro you are talking about, few players would even think about going through that kind of hassle to change something that already works. That's a non-sequitur. Investing in a non-profitable (DCS is free, remember, so developing a Linux kernel for that remove event does not bring a single cent of additional revenue), exceedingly expensive insurance (that greedily gobbles up maintenance over time) is a surefire way to go out of business. Let MS worry about their own problems, and keep your contingency plans to a scope that you can control. If Windows goes under because of Chinese Hackers, there are bigger fish to fry. Yeah, I'd love to see a Linux version of DCS. And let's try and be clear-eyed about the world we live in.

Simple State Saving Scripting API - A PROPOSAL Hi all, as suggested by @BIGNEWY I will put this proposal into this thread for us all to discuss: With the advent of Mission State Save in DCS, we now have a jumping-off point for mission scripts to persist their data without the requirement of "De-Sanitizing" DCS. This could potentially greatly increase the scope of missions and enhance single- and multiplayer game experiences. The current (new) Mission State Save feature does not support a scripting API, and I would like to submit a first draft of an API for everyone to comment on, and (hopefully) ED to implement in a later version. MISSION STATE SAVING SCRIPTING API The goal of this API is to allow script authors to interface with, and harness DCS' new Mission State Save feature. Using this API, a script author can serialize a script's current state, and then use the API to persist the script's state into the saved mission. Note that for this simple API, script state de-/serialisation is entirely left to the script author, and they should use existing methods (e.g. net.lua2json() and others) to save and recover a script's state before invoking the state saving methods. So, how could this work? I propose the following as a first attempt: HOW TO SAVE A STATE DCS sends out a new Event "STARTSAVE" which is invoked whenever DCS gathers data in preparation for persisting the mission. So every time that a mission's state is saved, the STARTSAVE event is passed to all subscribed scripts to allow them to collect, and store, data into a special location that is stored with the saved mission. Scrips can sign up to receive this event by subscribing via world.addEventHandler(luaTableName) When the Event Handler is invoked by DCS, it passes an Event record with the invocation that contains at least the following data Event = { id = STARTSAVE -- value tbd, ED's choice } The attribute Event.id holds a constant that identifies this as a STARTSAVE event, and this constant is to be defined by ED as part of the new API This event can be invoked at any time, and it is invoked once during every mission state save process. Should a script receive the event, it can encode ("serialize") it's current state (i.e. all information that is required to restore the script to it's current state) and then use the new state singleton's methods to add its state information to the mission information. Please see the example below for details. THE PROPOSED NEW STATE SINGLETON A new state singleton in Mission Scripting Environment provides simple, limited methods to allow a script to add its relevant information to the mission's state for saving. It also provides the means for retrieving a script's information (e.g. to set a script's state on startup). Currently, I propose the following methods: function state.setState(string name, string state) This puts the string state's value (a string) into the currently running mission's state information dictionary under index name. If there already is information saved under that name, that value is replaced by the new state. if you omit or pass NIL as state value, the state information for name is removed. If you pass NIL as name, nothing happens. string state.getState(string name) This retrieves a state saved in the mission's state information dictionary under the index name, and returns it as result. If there is no information saved under that name, it returns NIL. If you omit or pass NIL as name, the method returns NIL. A mission script would invoke this method once, when the script starts up. SCRIPT STATE SAVING IN ACTION (EXAMPLE) Let's look at the simplistic scrip 'myscript' that keeps track of a player's number of landings in myscript.landings and number of kills in myscript.kills. We are only focusing on the script's state saving and restoring abilities. THE SCRIPT (hidden for brevity) HOW IT WORKS The script loads and executes via DOSCRIPT action. It first initilizes the state variables 'landings' and 'kills' to 0. Next, it says "hi..." via outText() so we know that the script is being invoked (merely debugging info) trigger.action.outText("hi. I'm about to restore my state", 30) Then, the script invokes myscript.restoreState() Here, it looks if any information is available to restore a past state. local sData = state.getState("myscript") -- ask the state If the mission that is currently running is a saved mission, information is available, and state.getState() returns a non-nil value to sData. If sData is non-nil, the method invokes net.json2lua() to convert sData (which contains serialized data from the saved mission) into the value for data. if sData then local data = net.json2lua(sData) -- more magic! We then retrieve the values for the script's kills and landings state variables. myscript.kills = data.kills -- copy back important values myscript.landings = data.landings Finally, we subscribe to DCS' event mechanism to be invoked for world events, and relinquish control back to the mission. world.addEventHandler(myscript) LATER DURING the mission, the player saves the game, and this in turn causes DCS to invoke the event handler myscript.OnEvent() with the id field of the event record holding the value STARTSAVE. In that case, the event handler invokes myscript.saveState() if event.id == STARTSAVE then myscript.saveState() end in saveState(), we collect all relevant state variables (here the values for myscript.landings and myscript.kills) into a single table called 'data'. local data = {} data.landings = myscript.landings data.kills = myscript.kills Once we have collected all relevant datat (i.e. data that we want to save), we use net.lua2json to convert the Lua table 'data' into a simple string. local sData = net.lua2json(data) -- magic! We save that string into the mission's state by invoking state.setState() with "myscript" as index name, and the to-string-converted data as state.setState("myscript", sData) Aaaaand that's all, folx! With this simple addition to MSE most script authors could add simple state saving to the majority of their scripts. The proposal utilizes a new event ID (STARTSAVE) and a new singleton state for all actions, which hopefully will allow most script authors to quickly add state saving ability by adopting above pattern. Using lua2json and json2lua is a bit geeky, but since ED has removed two known bugs inside those methods, they should be safe for 99% of scripts. FURTHER ENHANCEMENTS I submit an enhancement for DCS missions that can allow safely writing and retrieving arbitrary text (a string) information similar to state.setState() and state.getState(), except that it works in a global context (i.e. it is part of DCS, not just the mission). Using this global set/get method, missions can collaboratively share data using shared names. The onus of ensuring that there are no conflicting names is on the script author. function state.setGlobalState(string name, string state) This puts the string state (a string) into the DCS-GLOBAL state information dictionary under index name. If there already is information saved under that name, that value is replaced by the new state. if you pass NIL as state, the state information for name is removed. If you pass NIL as name, nothing happens. string state.getGlobalState(string name) This retrieves the state saved from the DCS-GLOBAL state information dictionary under the index name, and returns it as result. If there is no information saved under that name, it returns NIL. If you pass NIL as name, the method returns NIL. table of string state.GetGlobalStates() Returns a table of all names that are currently valid indexes into the GLOBAL (shared) DCS state dictionary. YOUR THOUGHTS? That's already my entire proposal for an initial, simple scripting support of mission state save. It relies on the script author to be able to determine and encode/serialize the script's state, and requires only minimal support from DCS. I assert (without proof ) that providing this kind of simple support removes any requirement for de-sanitizing DCS and still provide 99.9% simple script persistence. By adding GLOBAL state support, DCS could also provide a shared, collaborative context for script authors to share and retrieve states across missions. What do you think about this?