cfrag

Which file? The miz (mission) file iteself? Yes, it is fully self-contained, replace the miz and you are done. If you are talking about the server side stopGapGUI, you install it once and then forget about it. It does not need any updating (hasn't for over a year now). I wish it did. It would make DCS so much better if shared missions would be integrated, like Steam does with Workshop. Made it a wish-list item to Eagle Dynamics: integrate publishing of missions into Mission Editor and discovering/downloading of missions into the main game. Even made some Interface mock-ups. Never heard a word from them back, so there's that.

Agreed - the currently available FARPs look fugly, like a relic from 1990 (which they probably are...). I don't understand why they at least can't have some "livery" - textures to paint on, many vehicles have that already. One texture each for woodland, one mountainous, one desert, one snow, one gravel, one jungle, one "city"/urban. I'm currently working with the invisible FARPs as a stopgap. The problem with those is that they only have one spawn point, and are heck to integrate with warehouses.

Here's to tooting one's own horn... Perhaps have a look at this:

Update 20240921 - Version 1.72 Changes Nicosia civ helo new placements to avoid collisions Adana civ Helo repositions to avoid collisions better Scribe module log keeping Enjoy, -ch

Update 20240921 -- Version 1.72 Changes added 1 more csarFX vehicle some more scenery at hospital drop-off Batumi improved logging via "Scribe" hardened persistence Enjoy, -ch

Or some other software, agreed. And I guess that is the root cause: the maps are auto-created and optimized for minimal size/best performance and complete disregard for user accessibility; after all, anyone with access to to the original model and software can rely on the app to resolve all mapping. I’m not sure that a module’s vendor prioritizes a modder‘s convenience over their own or the product‘s performance. Sad, perhaps, and understandable. I surmise that the absence of a paint pack is a dead giveaway that the vendor hasn’t (yet) prioritized modders. Give it some time, and only work on modules that have a paint pack. That could help teaching vendors about priorities…

Dear ED ( @BIGNEWY or @NineLine to pass along perhaps?), for many of us mission creators it's a bit of a mystery what happens during mission start-up. More precisely, it's not clear what happen when, in what order. This is usually not important for ad-hoc missions, but many of us wish to produce quality missions, and for this some added understanding of the mission startup process could be immensely helpful. What I'm looking for is the order (or sequence) in which the following steps happen, and if you can add more information, the more the merrier: Mission Startup Sequence: please order the following from the standpoint of a (client) mission map is loaded weather is loaded and applied all flags initialized / ready to access (synched with server) All map objects allocated and initialized (synched with server) static objects allocated and initialized All AI units (ground, air, naval) allocated and initialized FX allocated (smoke, fire etc) All map airfields initialized All FARPs initialized All naval airfields (carrier) initialized All warehouses initialized AT START triggers invoked (i.e. the fist moment that a DOSCRIPT ACTION Lua script can start intercepting events and check for the existence of objects and spawn or change warehouse contents) Mission's INITIALIZATION SCRIPT (from TRIGGERS) invoked Single-player: player interface invoked Multi-Player: ready to synch with clients First check if an airfield is contested/captured Multi-player: object synch with host complete (note: server-existing colored smokes aren't synchronized, bug exists and has been reported years ago) First moment when events are posted to world.eventHandler First point in time that the mission triggers are invoked (outside ATSTART) (this point may warrant its own breakout) Point in time, condition if/when, and order, of events when a player enters the cockpit (i.e. Birth, engine start-up, player enter, weapon add, etc). Thank you so much for any information that you can share on this topic. Kind regards, -ch

Goodness, please don't, or make a confirmation dialog optional. I'm purely selfish here, since confirming that I really want to quit is not something that I feel should be especially safeguarded against and adds one more step (in VR especially). I'm quitting missions a lot (I spend a lot of time designing and testing missions), and accidentally quitting missions has happened to me (since it's such an automatism: ESC-look at quit-click), but not so often that I would want to add another layer of actions. Yes, you can lose some of your mission playtime that way, and I feel for you. But adding some safeguard that affects all and prevents an edge case seems excessive to me. The kind people at ED seem to be quite heavy-handed at UX, and I prefer they keep their attempts at user interaction at a minimum. For a quick demonstration at just how poorly DCS implements user UX, look at the CH-47 cargo interface. "Abysmal" would be a shocking compliment.

Note that while some of the (terrific) new objects (endless Kudos to Massun) do come with lighting, these lights are limited by DCS's (inferior, tuned for performance not eye candy, a choice that I will not fault) lighting engine; these lights aren't fully emissive in nature. This means that they don't cast shadows, nor light the interior of the cockpit, and are often too dim to be of practical use for helo flight simming. They do show up in some NVG, though (for example Huey), so another deep bow of THANK YOU to Massun. null

I strongly recommend that you only share missions that you have the author's permission to do so. Although obviously well-intended, the version that you have posted here is an older version that does no longer correctly run with current DCS, and it may reflect badly on the author. Just share a link to ED's user files where the mission has its home, and people can always find the most up-to-date version, and perhaps similar missions.

DCS's event API is a cruel joke on us mission creators. That event ID is only invoked every second blue moon for players who have two children or less and can't be relied upon.

Ah, the joys of DCS, mixed with one's own expectations. You already have all the pieces of the puzzle, and I think that you implicitly believe that one thing means the other (in a perfect world it would, but not Lua/DCS). Let's go through the the steps one by one. You enter your aircraft "Crasher" and depart. A status display call is scheduled in 20 seconds with a reference to your unit "Crasher". In computing terms, a 'reference' points to the memory location that contains data, here the data for unit "Crasher" One second later you crash your aircraft "Crasher" and it is removed from the game. The memory for that unit is freed - made available for other purposes. Your reference to "Crasher" still points to the memory location formerly assigned to "Crasher". 19 seconds later, your scheduled status display function is invoked. As part of the params that are retained is a reference to the (now crashed and invalidated) unit "Crasher" in uObject. Your code checks if uObject == nil. Your reference to "Crasher" STILL points to to the memory location that formerly contained the (now deleted) unit, meaning it is not nil, so the check correctly fails in Line 395 you now access uObject's method getLife() member via "uObject:getLife()". Unfortunately, uObject is no longer a valid object, and you get the "Unit doesn't exits" error So this is correct. A reference to a unit isn't nilled when the unit is destroyed, and a nilcheck to a cached unit (a saved unit reference) will not save you from this. So, how do you protect against that? Many ways, one is to save the unit's name instead, and directly retrieve the unit by name before you try to access it: uObject = Unit.getByName(uName) if not uObject then trigger.action.outText("Sorry, but unit object is nil",15) -- some spelling corrected return end

It's hardly our fault that some people do not know what the world 'simulator' really means -- I love to show them the 'flat earth simulator' to make that point. And when people go the 'it's not a game, it's a simulator route,' we can show this. Hasn't helped for years, won't help in the future. Hopefully we get an API for refueling so we can put this tired thread (to which I'm contributing, so I'm part of the problem, I know) to rest.

That is your assumption, which seemingly is contradicted by ED marketing copy from the past years ("Can you fly DCS with only Mouse and Keyboard? YES!"). It would be a bad business move to actively restrict your market to a niche. ED is positioning DCS to appeal to as many people as possible, for obvious reasons. They are a business venture, not a religion or country club. Since they follow a one-off purchase model, it is therefore imperative that they grow their customer base - or wither financially. Erecting or keeping entry barriers (real or imagined) is counter-productive business-wise. Agreed. And (OP's assertion notwithstanding) few people are claiming that "straight" AAR is holding back DCS. Assisted (in whatever way) ARR could only be one additional accessibility facet among the many that are already available. It would make the game more accessible to some players. The point being: You are the customer, you decide which you want to use. Three-Minute repairs? Auto-start? Labels/Symbols? Padlocked enemies? Easy Comms? Unlimited Fuel? Assisted AAR? There is only once certainty: a choice not offered is a chance missed. So if you offer a choice, it may help to grow the customer base. Not offering it guarantees not taking that chance.

Indeed. I advocate adding a fuel API to the mission scripting environment. Just a single Unit.setFuel(theUnit, percent) method is all I'm asking for. The week that ED adds the ability for mission scripters to set (increase or decrease) the amount of fuel in player units is the week where passable scripting solutions for AAR become available. Good scripting solutions will follow a few days later, and we can finally put this tired thread (and its suffering brethren) to rest. Oh, and adding said API would not break the bank effort-wise: we know that all the methods already exist for single- and multiplayer (how else would today's rearm & refuel dialog work). So here's to hoping that ED takes a heart and allows mission creators a tiny, tiny additional functionality. Note that this would also allow us to finally create mission profiles with dead-stick landings where your fuel runs out 20 nm before touch-down (we currently can't script leaking fuel-tanks either...)

That's strange indeed, as (seemingly) it works for me. To get the bearing from Point A To B, I use function dcsCommon.bearingFromAtoB(A, B) -- coords in x, z local dx = B.x - A.x local dz = B.z - A.z local bearing = math.atan2(dz, dx) -- in radiants return bearing end which returns bearing in rads. To convert rads to degrees, simply multiply by 57.2958, i.e. local degrees = rads * 57.2958 -- 57.2958 = 180/pi Now, if the result is < 0 add 360, if it's greater than 360, subtract 360. function dcsCommon.bearingInDegreesFromAtoB(A, B) local bearing = dcsCommon.bearingFromAtoB(A, B) -- in rads bearing = math.floor(bearing * 57.2958) if bearing < 0 then bearing = bearing + 360 end if bearing > 360 then bearing = bearing - 360 end return bearing end Can you give an example where your code fails?

and Ah, team "git gud". Tell me, when you embark on one of those multi-hour missions, do you also strap on a piddle pack? Because there's the same argument to say "easy comms yes, easy pee no"? It is realistic that you need to learn to sit in your own juices for hours on end? "Git gud" my left foot. Let's roll another 20 pages of silly arguments.

While I agree that using ON/OFF is something better not used and it would be much better to set a flag to a specific value, I feel somewhat compelled to comment: Flags in DCS now ARE implemented internally as integers. OFF is logically defined as "flag == 0", and therefore ON is "flag ~= 0", which is decidedly different from "flag == 1" There is no action named FLAG SET VALUE [EDIT: SIlly me. There is an action called SET FLAG VULE. It's just not grouped with the other FLAG actions. Yeah, DCS...]. Use FLAG SET RANDOM VALUE instead and set min and max to the same value (silly, yes. But this pretty much encapsulates the entire DCS ME experience: annoying, user-hostile quirks abound) FLAG SET ON will set a flag to the value of "1". Flag SET OFF will set a flag to the value of "0". Still, testing for ON must be done via "If flag ~= 0 then .. end" Never try and interpret flag values as bools in your script as that will always fail. Here's a small miz to illustrate above. Note that due to my laziness and the silly way radio menus work in DCS (see "annoying, user-hostile quirks", above) you can only use each menu command once. flaggerbasted.miz

If we had a proper unit fuel API (heck, a frigging stop-gap unit:setFuel(percent) for the main tank(s) would probably suffice to tide us over) these ridiculous discussions would be a thing of the past. Any scripter worth their salt would have created a good air-to-air refueling script quickly.

Version 1.20 - 20240914 -- Functional Update Thank you all for the feedback! I've added some of the kind suggestions that you have made. Summary of Changes Added recon mode Added ability to turn recon on and off via comms Mission starts with recon turned OFF (backwards compatibility) Recon suppressed for non-convoys to not clutter map Better status for mission Improved: full status of all villages Added new report sound Enjoy, -ch

And I was looking forward to 20 pages of "git gud!" vs. "screw you" comments. Drat.

And, if I may say, a nice, succinct summary of Lua. Thank you for that. I believe the answer to your question "how deep should I go" lies in answering the question "do I want to know 'how' or 'why'?". Let's look at an analogy. Many people know how to make a fire. They can use this knowledge and make many fires, and over time they learn what works well and what doesn't, and they become very adept at making fires. This has worked well for humanity for millennia and served us well. And then there are people who delve further, trying to understand the why. Why does making a fire it work, what are the components, why does this work, yet other stuff does not? Understanding the intricacies and how components interact allowed us not only to make better fires, but, ultimately, split the atom and fry breakfast bacon (the latter of which is still more important to me than the nuclear stuff). So, understanding "how" mission scripting works boils down to looking at code patterns, and cleverly imitating them, stringing together bits of code, noting what works and what doesn't and gradually learning how to put some unrelated bits and pieces together so that you can eventually accomplish impressive things. You don't know exactly why it works, there's still lots of mystique (what's this '_' doing in a for loop?) -- the important thing is that it works, and that's good enough. Not to be too subtle here -- from what I see of DCS's API, I get the impression that some of ED's fine people use that same approach to designing the DCS API... If you choose to go deeper into the rabbit hole, and here's DCS's particular challenge and the reason for my unsubtle dig at the kind people at ED, you may soon discover the why. Now, with DCS, there are two parts of this: Lua and MSE (Mission Scripting Environment) API. You appear to have left the nuts and bolts of Lua behind you, the whys of Lua scripting are known to you. That rabbit hole probably won't go much further (maybe metatables, but that's really no longer relevant for our discussion). What remains to learn are the particulars of how DCS's game engine fits together, and how it interacts with Lua through its MSE API. Unfortunately, from my personal view, that API has terrible design flaws, and to understand the why, you will first have to suss out what does not wok even though it should, and then accept that you won't understand why it won't. It just doesn't. That's part of the discovery, and it's an integral part of the DCS rabbit hole. The API is riddled with inexplicable really, really bad idiosyncrasies. You are now through the looking glass, deep in Alice's abode. There are wonders to discover, and knowing the how nots and whys of this wonderland can be worth the effort. It will allow you to craft missions that you would never be able to build otherwise, yes. But with this, like so many other deep excursions, the journey is the reward, your new abilities will not cover the cost. So how far should you go? As far as you are having fun. You are already way past the required minimum. Welcome to wonderland. Now, let's go and look for the Mad Hatter. I hear he lives in a a warehouse API, having tea at 1800 sharp.

Good to see you back, @Multiplayer team! Great server, lots of fun and good memories!

In multiplayer, clients do not support the concept of "I", they do not know who they are. The closest that you can get is via missionCommand and install a callback when the player invokes a function. This is currently only implemented on group level, so at this point, a client can't know who they are, and in multicrew they can't know which seat they occupy. That being said, LoGetSelfData() is part of the export package that runs outside the mission itself, and may provide that info and I am not familiar with it. So if you want a mission script to know who "I" (the player) is, that is currently not possible. It might be possible outside of the mission, and it is definitely possible on the server.

It would indeed be a nice gimmick, and we know that the infrastructure is in place: you can walk around and be seen by other players if you control a MANPAD soldier in Combined Arms. So walking around the airfield should not be that difficult to implement. A peculiarity of DCS is that it currently does not show unoccupied/uncontrolled player aircraft, so entering other uncontrolled aircraft would require a fundamental (albeit not difficult) change in DCS. Although it would, I'd be hesitant to mention this. If you are the evacuee in such a mission, your mission profile would be sitting around and waiting to be picked up for 45 minutes, get in, then sit and wait to be flown back to base for the next 30 minutes. Few people would find that fun and willing to do. But yeah, it would enable that feature.