cfrag

I have to ask: In 1974 the Köhlbrandbrücke (Köhlbrand Brdige) opened (my granddad took me to the opening) to the public, and became one of Hamburg's easily recognizable landmarks, and it's smack dab inside Hamburg's port. Will it be in there? Please? Please?

Talking about learning to swim in the deep end of the pool -- DML becomes a lot easier when you feel somewhat comfortable around Mission Editor, as that application comes with a lot of, uh, "idiosyncrasies". It hates you. That being said... Check Chapter 4 of the manual. I believe @DD_Friar was already kind enough to provide you with a very elegant way to do what you want - it also underscores my adage "when in doubt, try a cloner" Have fun, and don't be discouraged by Mission Editor

While certainly possible, I can't see a good interface for DML, and this appears to be an extreme edge case. How is this used in your mission, what is the objective of such a an ability (besides firing off a flare)?

Unfortunately, the F2 menu is clipped by DCS. Depending on your setting it should say "(You are carrying xx Infantry; land to deploy)" or "(You are carrying xx Infantry; fast-rope or land to deploy)" It's only a comment not a valid menu option (the brackets were intended to signify that) but that menu manager screws with it. So while airborne, only F3 is viable, provided that you are slow enough. Looks like I'll have to simplify the menu options.

You are too fast. Story of my life, I know

You did notice the date when this was posted? In many cultures there's a lamentable tradition to be not entirely forthright on this date, and there are people wo think that this can be the cause of great mirth. Yeah, people tell me I'm great fun, too - especially on this date.

I would hazard a guess that there is very little engineering in DCS for modelling this kind of damage for ground units. To me it seems ground units are merely there to serve as targets and provide some form of hazard (hence the infantry soldier that can one-shot a pilot with their rifle), nothing more - and damage modelling is simplistic at best. A realistic damage model is a complex can of worms, though. It's not merely the way how a munition hits, it is how it interacts with the target and target's surroundings, how the munition works. A blast wave, a kinetic impulse, a kinetic transfer that transforms into a blast wave, heat (as in napalm) etc. -- all have different properties, and interact differently with a vehicle, it's armor (none, reactive, ablative, ... ); especially larger vehicles (and I think naval damage modelling is minimal if present at all) and more. From what I see it *seems* to me that there is very little damage modelling beside deducting a number of points from a unit's 'hit points' based on the centricity of the hit, plus some "resistance" to some ammo types (like in role-playing games: tanks are resistant to small-arms fire). So how hard would it be to model damage? If you want it to be accurate, immensely. But maybe that is not what ED are aiming for (ooh, pun!), and they are merely looking for something that makes a game playable. And there I think is some room for improvement. For example, I'd like some better damage modelling for naval units: take out their radar or receivers, and you take out their missile capability etc.

You forgot the Manta mit Fuchsschwanz. Only that guarantees a genuine 80s Wehrdiensterlebnis.

That may be a future ambition of state save, it is currently very far removed from that ability. The current version to me appears immature, rough and incomplete. I'm not sure if it will ever support save/continue for individual flights, we are waiting for ED to announce planned capabilities. At this moment, my experience with save state has not been positive, so I will withhold further comment, except that you should make very, very sure that when saving a state you do not accidentally overwrite your original mission (currently it is the default, be careful).

The deployment formation can be set at any time and is applied to any subsequent deployments. If not set, it defaults to a circle around the helicopter, troops facing out. That may be part of the issue. Menus are set and updated triggered by the 'take-off' and 'land' events. Ground units do not receive these, and this may contribute. I suspect something else though: Fully exiting the 'Other' menu (through 'back' and going to the top level) should cause DCS's notoriously unreliable menu structure to re-load, so I'd like you to try and see if that changes anything. Does that make a difference? DCS sound for clients in multiplayer has been hit and (mostly) miss for a while. Let us hope that the kind people at ED fix the client audio issues one fine day.

Version 2.30 - 20250329 - Maintenance update FOR GOODNESS SAKE, DO NOT USE DCS' NEW "SAVE MISSION" - THAT WILL DESTROY THIS MISSION. PLEASE DO NOT REPORT BUGS FROM A SAVED MISSION. IF YOU SAVE A MISSION IN DCS, IT IS DCS THAT IS F***ING UP THE MISSION. HARD. DCS'S "SAVE MISSION" FEATURE IS NOT PRODUCTION-READY. This is no joke. DCS' "Save Mission" feature should not have been released and is not ready to be used. It makes DCS a worse game, a worse experience for the players. Shame on whomever released something of this low quality to their customers. Have you no pride in your work, Sir? -ch

So I understand that you aren't a rotor head?

Version 2.4.6 - 20250327 The good news: DCS State Save has arrived. The bad: it's <expletive>. Really, really <expletive>. I deem it unusable for even the most simplistic missions, that it's an embarrassment for ED, and can only serve to make people angry at ED because it is most definitely not what 99.9% of players expect. Most Players expect that when they save a mission, they later can continue *exactly* where they left off. DCS doesn't deliver. Not even 1% of that. IMHO it would have been much better if it hadn't been delivered at all. For mission designers, this is worse because not only is a saved state a much worse, broken version of the original mission, it also by default overwrites the original (the UX people must have been absent here). The result? Mission creators will be blamed for the Fuster-Cluck that ED delivered. Oh, and support for mission scripting? You must be new here. How about saving flag values? Good one, who uses flags? That little 'ABSOLUTE TIME' thing that just came out? An ill-conceived Fuster-Cluck. Worse than useless, because it exacerbates a bad solution. To me it looks as if nobody at ED with experience in mission creation was involved. DCS has become a worse game, and judging by this, to me ED seem completely out of touch with their players and content creators. So, I spent the last two weeks submitting proposals to ED for a rudimentary Save State API, testing what is there, and finally resorting to serious drinking to forget what I saw. It's bad, and no-one in their right mind should use it. Mission scripters will now have to live with the fact that they'll invariably be blamed for this incomprehensible disaster. How do I know? By looking at my inbox: "Bug in Expansion", "Angels Caucasus doesn't work", "Can't seem to continue". ED: please pull Save State from DCS until it is more mature, I believe that you are trampling your own reputation with it. Don't get me wrong: Save State is an important and fantastic addition to DCS. Its current incarnation is a carnival of ineptitude, though. No serious software developer would have released something of this low quality to production. ED, I think you can do better. When sober, I managed to add a requested feature to heloTroops: the ability to let troops fast-rope to the ground, i.e. have them disembark without the helo on the ground. So, nothing much in this release except a cool new heloTroops addition. Documentation Main - Fast-Roping for heloTroops QuickRef - heloTroops Demos - fast-rope from helo (not yet documented) Modules - autoCSAR 2.2.2 - DCS bug hardening - heloTroops 5.1.0 - fast-roping ability - playerScore 5.2.3 - fixed a bug in victim category Enjoy, -ch

Understood. What is the intended functionality if you set the starting point at 08:00:10 (ten seconds after mission start at 08:00:00) and then advance the mission start date by 1 hour? ME does do something to the conditions, and what it does seems not consistent. Phrased differently: what is the intended functionality given: you set an absolute time condition that happens to be 10 seconds after mission start time you then move mission start time forward by one hour (e.g. from 0800 to 0900) Are absolute time trigger conditions updated, and if yes, when and how? I assume that there is some intended functionality to auto-update ABSOLUTE TIME conditions, else they are just marginally less useless than the pure absolute time we have now. Mission designers need their conditions to trigger relative to mission start time. I believe everyone agrees that no automatic management of ABSOLUTE TIME condition with respect to changing mission start time wouldn't be helpful at all. I believe it's obvious that mission designers need some QoL management with their trigger time condition, hence the somewhat quirky, non-standard way that ME behaves now when you click on an ABSOLUTE TIME condition now after a change in mission start time, and it auto-updates that (and only that) time by the amount of time that the mission start time was moved. The idea looks good, the execution looks flawed.

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.