cfrag

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?

Will do, thank you BN - this thread it will be

I'm happy to see this important new feature make its appearance in DCS, @BIGNEWY, my congratulations to you and the team for this important milestone. As someone who writes many scripts for missions, and that can't yet take advantage of Mission Save State, I would love to share my own thoughts and ideas with everyone to in improve, and ultimately for ED to bring into DCS Mission Scripting Environment. Do you already have a section where I could go to, or do you have a recommendation where I could start a thread in this regard to get the ball rolling? Thank you and kind regards, -ch

DCS Pathing is not well. At all. But It's entirely possible that I could tell a spawner/cloner to pick a random point in a circle with range, and have the troops go there at some sedate pace. It won't be pretty, but it should work in some fashion. When they get there, what should they do then? Simply sit around, or despawn?

Huh. Full wipe on die, that's harsh. Certainly not difficult to implement. As @DD_Friar already asked, you want this ON TOP of deferred scoring, right? Although interesting as a concept, there are multiple questions that we need to resolve first: - How do we handle Helicopters that land in "enemy territory" to rescue someone or to insert troops? - What is enemy territory, and how would silly me discern that from neutral and friendly territory?

Well, Goldfishbrain I thought that it did. I think I even created a demo for that: 8.95 Yes you CAn score (CA and PlayerScore) Note: This demo requires the Combined Arms module 8.95.1 Demonstration Goals This demo shows how players who control ground units via “Combined Arms” can also receive score points using the PlayerScore module. The restriction is that CA scores are awarded immediately and can't be deferred. I'll try and amend the main doc itself to make this more clear.

Because those who play games on their 'daily work' machines happen to have a Win machine, and aren't going to get a second computer for gaming. Also few developers who today develop for Win are going to switch to a different OS and infrastructure on a chance. It's a chicken-and-egg issue. If and when (as was predicted for a decade) Linux overtakes Win for gaming, we may have a chance for our dreams come true. Until then it's just that - a dream.

Which is, IIRC, the original definition of the Touring Test. Today's generative AI systems (that generate the next word based on rules and some vector algebra derived from a big pool of words that their responses are conditioned with) can fool an amateur, yet are still a far cry from passing the test

In other words: Will there PLEASE be a "German Asset Pack" with some civ objects like Trabis, Mantas (there simply must be a Manta car) and Golfs? PLEASE PLEASE?

Version 1.72 - update: deploy formation for helo troops, bug hardening All Changes: - You now can set group formations when dropping troops - General updates to guard against DCS bugs - smoke from CSAR pilots vanish immediately - more DCS bug hardening in playerScore and autoCSAR - troop deployment player UI for helos

Two things can be true at the same time: ED can be awake and they can know that Linux is superior in many ways. Except one: DCS doesn't run on it. That's the killer. I'm a Unix/Linux (Ubuntu and Mach) head, and I'd love to see DCS (at least server) on both. I also accept the realities of business. Saying so doesn't make it so. Linux market share in gaming is minuscule. I remember when Red Hat started and people screamed the same. That was in 1993. Yeah. Boy do they look foolish now, don't they?

As someone born in Hamburg I can tell you that nobody needs the Bavarians (all we need is some of their beer, but only as ersatz-water)