cfrag

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.

The mission requires a mod "WWII Armour and Technics". That would be my first suspect.

In that case I don't think that DML would do anything with anything in the miz.

Version 1.52 - 20240912 -- Maintenance Update • Fix for FARP slot accessibility edge case (single/multiplayer) • Added a single Su-25T (DCS free plane) Frogfoot to Nal, so everyone can start the mission. • Set all AAA infantry orders to “wait-guard” while all Assault set to “wait-captureAndHold” • Slightly upgraded the AI Cobra’s bite Enjoy, -ch

Interesting. How does DML interact with the flaks? In other words, what do you use DML for when it comes to making the flaks fire?

Version 2.3.2 - 20240912 Feature Update: Inferno, Airtank A couple of very busy weeks. I've put finishing touches on the two new modules airtank and inferno, and put them together in what I wanted to build for almost two years: a firefighting mission (please see here for details). The two new modules are now fully described and cross-referenced, and all that is left is to document the demo, which I put on my to-do list for the next update. Also part of this update are more bug-fixes for the damage that ED did to their great product, but for some modules I unfortunately can't undo all. It seems that the kind people at ED (unwittingly?) changed the way that DCS signals how and when a unit or object is destroyed. As a result, some modules (e.g. PlayerScore, objectDestructDetector) are diminished in what they can do. We'll have to wait and see how this develops in the future, and I hope that ED find the time to better communicate their intentions and improve their QA. Changes in Detail: Documentation Main Inferno (new) Airtank (new) Various updates & corrections Quickref Inferno (new) Airtank (new) Demos (none) Modules - airtank 1.0.0 - initial Release - inferno 1.0.0 - initial release - objectDestructDetector 2.0.4 - DCS bug hardening - playerScore - diminished services due to DCS bugs - sittingDucks 1.0.1 - DCS bug hardening - TDZ - 1.1.1 - now correctly sends a signal on touchDown Enjoy, -ch

HEROES OF FLAME - CAUCASUS ======================== V.20240909 Download: here (ED User Files) "Heroes of Flame" is an endless, entirely non-violent single/multiplayer helicopter fire-fighting mission. You are tasked with extinguishing large to very large fires with your helicopter. The more fires you extinguish, the better your reputation (if you enable persistence by de-sanitizing DCS, the mission remembers your past accomplishments). stupid null, ED, please fix your editor Summertime...! ... and living is easy? Not if you are one of Krasnodar's "Heroes of Flame", an elite helicopter firefighter corps. This summer is particularly hot and follows on the heels of a string of hot and dry months of spring. The ground is dry, the forest has become tinder waiting for a spark. The ground in and around Krasnodar's city proper is so parched that the municipal office has released orders that disallow citizens lighting fires outside of controlled environments. Last week, vacation season started, and people - along with tourists - stream outside to enjoy nature and recreation. If last year was any indication of things to come, there will be fires, caused by a myriad of things, most of them caused by human exuberance. The local fire brigades are prepared for smaller flare-ups. Due to the extreme heat and drought, this year the authorities have prepared well: they erected an Airtank Center that has few rivals worldwide. A veritable armada of Hinds, Hips, Hooks, Hueys and Kiowas, fitted for firefighting are stationed at Krasnodar-Pashkovsky and are staffed with the best. You are one of them, and ready to become one of the "Heroes of Flame". Jump into the cockpit, top off your retardant tanks, and lay claim to your title. Heroes of flame supports the following helicopters / carry capacities: Huey (1200kg) Hip (4000kg) Hind (2400kg) Hook (9000kg) Kiowa (500kg) To fight fires, you first top off your tanks with flame retardant (from Krasnodar refill zone, marked with white smoke) or water (from a lake/river), and then drop it into the blaze. Topping off your tanks: When inside a refill zone (white smoke): go to communications - Other - Firefighting and choose "Activate Intake" to fill up your flame-retardant tanks. Filling your tanks is instantaneous. When hovering over open water (lake/river), and at 10m AGL or less: go to communications - Other - Firefighting and choose "Activate Intake" to fill up your flame-retardant tanks. You’ll hear your intake pumps activate, and your chief starts giving you live updates. Your pumps can acquire 100 liters (kg) of water per second, so keep this in mind while hovering. Filling up the Huey (1200l) takes 12 seconds, while topping off the Hook at that rate takes 90 seconds. Once your tanks are topped off, your intake pumps disengage automatically Dropping Flame Retardant / Water into fire: Note: currently, there is no difference in efficacy between water and flame retardant (this may change in later versions) Move towards a fire cell and prepare to drop water. You can choose between two different methods: MANUAL: choose Comms - Other - Firefighting and select "Manual Release". This empties the contents of your tanks at 1000kg/sec until they are empty. The impact point is derived from your current speed and direction. While the tanks are emptied, you can hear the turbo-pumps pushing out the liquids. I recommend that you bind the F2 key for manual release using some appropriate software for greater precision. ALT-triggered: Go above 300 m AGL (900 ft), and then Comms-->Other-->Firefighting and choosing "Arm Autodrop Trigger". An aural soft tone blips once per second to remind you that the altitude trigger is armed. Once your altitude gets below 100m AGL (328ft), that triggers release. Note: Altitude-triggered release is more difficult, and intended for advanced pilots who can judge their approach. Once release has started, it ends after the entire contents has been emptied. The drop pumps are rated at 1000kg/sec, meaning that the Huey (1200l capacity) is empty after 1.2 seconds, while the Hook (9000l) has 9 seconds of water/retardant, and can therefore cover larger areas. After you successfully drop water/flame retardant into a cell, the amount of fuel left in that cell is reduced. Once all fuel in the cell is consumed, that fire cell dies out, and can't re-ignite. Dropping water around a burning cell can prevent the fire from spreading in that direction. If you succeed in extinguishing all fire cells in a blaze, all pilots that have successfully contributed to fighting that fire are awarded an number of points based on the size of the conflagration. The points accumulate any you can always query your status from Mountaintop. Initially, your Rank is "Probie", and that rank increases with the number and size of fires that you help to put out. Note: Refueling Keep in mind that in order to carry more flame retardant, your helicopter is only fueled to 50%. Keep an eye on your fuel gauge, and when you return to the airfield to refuel, do not top off your gas tanks. Fill them to 50% to avoid falling out of the sky. Since it's summer, and people are in a festive mood, there will never be a point where no fires require your attention. OTHER NOTES: “Heroes” supports persistence of features if your DCS installation is de-sanitized “Heroes” uses 'stopGap' for eye candy. On multiplayer, the server (only server) must run the 'stopGapGUI' script to fix a DCS synchronization bug. For stopGap, please see here: https://forum.dcs.world/topic/326213-stopgaps-script-to-fill-empty-player-slots-with-planes/ Created with DML

Oh joyful news. Yes, the kind people at ED also have changed the events sent when a map object is destroyed to "dead" and no longer invoke "Kill". As a result, killing a map object can no longer be tied to a player. I'll look into it to see if I can change this to attribute the kill to a faction instead. Thank you so much for setting up a test miz. TBH, it feels to me as if DCS's API is rapidly going down the tubes quality-wise.

It seems a recent change has done away with kill events for map objects, doing away with the ability to attribute a map object kill to a player. Now only dead events are invoked for the map objects, making it impossible to tie a map object kill to a player. This change makes it much harder to write engaging missions, please bring the KILL event back (and while you are at it, please also restore it to the scenery objects that have dropped invoking the Kill event in favor of Dead/Unit Lost).

Thank you for the heads-up. How did you configure PlayerScore to recognize the object kill? Can you please show that trigger zone as well? [EDIT: silly me, the blueScore attribute is there, thank you]

Unfortunately, I see no reaction from ED, which I find disappointing, and it makes me question why this entire forum chapter exists. @NineLine - is anyone from ED monitoring this? I see far too few (if any) tags from you and your kind colleagues, and I am wondering if there might be a better way to spend my time than posting here. My understanding is that we (customers) post here to help you (ED) to make a good product even better. I hope that your views are somewhat aligned with mine. In any event, here's some copy from a very nice and helpful submission from a fellow contributor, who I am absolutely sure did not include the blanks, and had the silly ED bot mangle their thoughtful contribution: To begin using the DCS Mod Manager, you'll first need to sel ect the main directory where your DCS mods are stored. This is usually located at: [...] Reload: Refresh the list of mods fr om the selected directory. Use this if you've added or removed mods manually and want to update the list.  Please, please, please turn this silly feature off.

Thank you. It's difficult to predict if a bug in DCS that affects one item (missing kill event for some static objects) will affect others (map objects). Thank you for taking the time to investigate.