cfrag

When you pass an array with a zero ('0') index, that index is not written to json when converting a table with net.lua2json. This can be reproduced at will: take the warehouse inventory from any base, and convert that to json. The liquids are defined as an array, with liquids[0] being jet fuel. Now look at the json result of lua2json conversion and see that liquids never contains array item index 0.

It took me two entire days to track some of this. At the end, I discovered a bug in net.lua2json (it can't correctly save arrays that have a zero (0) index, like for example a warehouse's jpl index), and I discovered that a warehouse's inventory API for weapons and aircraft is so incredibly braindead that it removes entries with a zero item count even if that entry was formerly present. In case you wondered: yeah, that the same as unlimited supply. Or rather, it's not documented how an airfield implements unlimited supply, and airfields with unlimited airframes have no entries, so it is impossible to tell those two apart by code. So, if you have an airfield with 1 Hog, take it and ship it to fly it somewhere , the A-10 item disappears from the originating base, and it is impossible to tell (from a script perspective) if there are no, or unlimited aircraft left for that type by getting the inventory. Whoever signed off on that API seems to be a rather low-rent help to me. Still working on it, just an update. WHpersistence will require a significant update, though.

Yes. A killed unit is no longer tracked by persistence, hence will not be reallocated.

Alright! I'm busy trying to replicate this, thanks!

Units cloned with a cloner, irrespective of their template are tracked by unit persistence They are dropped from tracking after they are destroyed, individually (I hope) After spawning from persistence, the units spawn at full health and munitions

Ah, that is interesting, thank you! I'll try to see if I can replicate that and replicate the mechanics, and see if I can detect the change in the warehouses, if and when planes get added (do players have to leave their aircraft, or are planes ferried my AI)? Are there any special conditions that I need to observe to make a flight count as a ferry flight (I assume that you need to use a dynamically spawned slot from A and fly it the B and then have the plane added to B after you exit the plane)? Is there any in-game messaging that confirms that the plane was added to the WH inventory? I can't seem to find good documentation on these mechanics.

What is your issue in detail? Also, what is your issue with team (faction?) score? Currently, there is an issue in DCS (i.e. the issue was created by a change from ED) that makes is very difficult to tie map object kills back to player. The most recent change to PlayerScore may make this work again, but I haven't yet checked yet. What issue have you run into doing that? I'm, sure we can resolve that quickly. What issues have you run into there, or put differently, how are you currently trying to score them. I believe that since PS now supports wildcard naming, scoring spawned destruction should be easy. Let's see your approach and hopefully it's just a little tweak.

I don't know, do you think it should? I don't think that it's fully documented yet, but if warehouses also keep stock of aircraft, adding WHpersistence to your mission should (may?) resolve this. The warehouse API is one of the (many) low points in DCS, and I haven't yet had the nerve to create a mission that relies on that. It'll come, I'm sure, and I'm happy to pass off the role of Guinea Pig to you on this one The important question here (since I don't know how this works) is: do aircrafts show up as available on the new airfield after you ferry them over and exit there? If now, that may be something that I can try and add as a module. What are DCS's current capabilities with this (does it already support some form of ferrying), and how would you imaginne that this works?

I believe that I corrected this (along with squashing some remaining little critters in the code). Does this work for you correctly now? playerScore.lua

Although I strongly support your wish, I even more strongly want to encourage you to not resort to 'click-baity' thread names. I only read this thread because of someone else's response. I think it's best if we make our point in the headline to help people decide if they want to participate in a thread. So, "yay!" to @currenthill's work and inclusion into DCS (although the murky ownership of IP is going to make that highly unlikely), and "boo hiss!" to this thread's subject line.

Can't find any new civ trucks either, so I'd be happy for any pointers. It think it would really help if ED could include the typeName (e.g. "MAZ-6303") for us silly mission creators to make our obviously all-to-easy life even easier. /sarcasm

Since we currently cannot influence AI or AI units in a meaningful way (except through drastic ways just like the ones that you suggested), your approach seems to be workable. Setting zero fuel should get most AI planes to have the pilots bail out and the plane plummet to ground - if that was possible (spoiler: it's not). The good old explosion(unit:getPoint(), 30) should also do it, albeit a bit more visceral. Ah, then an explosion seems fitting I think (and that does not mean a lot) that current implementation of unit AI only kicks in with that event when the unit runs out of fuel (? undocumented) or damage (somewhat documented). So, re-top up regularly so they don't run dry. The spanner in the works is of course that we currently cannot set a unit's fuel nor life. A colossal oversight for a military sim scripting engine, but that's DCS for you. It won't fail in MP. The script runs on the server, and all clients sync to the server eventually. If the server thinks that a unit is dead, it is dead and removed from all clients). It will work in MP. IMHO, the most reliable way to remove a unit is destroy(), but 'setting them up the bomb' by explosion() is a lot more satisfying, and you can probably forego the destroy() yourself (schedule a timed destroy() two minutes in the future just in case) There is the kludge approach: in the event handler that detects the unit aborting, set a named flag (I use the unit's name plus "_k" to keep this part short). Then create a trigger rule for every (messy, messy, messy!) unit that triggers on that named flag (e.g. FLAG TRUE "aerial-1-1_k") to execute the trigger for the actions (unit set life, explode). So, if you have 20 units that can abandon the mission, you'll have to create 20 separate trigger rules, one per unit. Very kludgy, very messy, extremely difficult to maintain, and wholly depressing from a scripting perspective. It really is a shame that DCS's mission scripting environment is in such a bad, amateurish state.

That's some very bad UX on my side, and I'll try and change that in the next update. You should see a warning when the miz starts up that the range for the pulser is illegal, and that it defaults to 1. Long story short: if you want infinite pulses, please delete the 'pulses' attribute to have DML default that value to -1

Thank you, I'll have a look. When you were taking out a large number of units, were you flying or in a CA vehicle?

Agreed. I don't have hard numbers, and all I wrote is conjecture/BS. Then again, when you read some books yourself, you may find out what the term "educated guess" means. It's still a guess, yes. The difference is... you'll find out. Not at all. MAC was supposed to be an entire game, similar to, but not DCS. That was the point. Perhaps watch the 2018 'trailer' (link is to a yt commenter, not the trailer). We can argue that with FC 20245 ED re-purposed and salvaged what remained of MAC. I'm not squabbling over details, and usually would have let that slide -- yet you seem to be the one insisting on hard, accurate facts.

That would be nice, yet entirely against gamer social patterns. Behavioral patterns tell us that those who do purchase would probably buy a lower-cost/high return module (e.g. Flaming Cliffs) or iconic FF module, play for a while, and eventually lose interest. That's typically around 50% of those who purchase. A part of the remaining 50% progress to a FF module, and we again face a 50% fall-off after some time. Prime issue here is the - compared to other entertainment titles - relatively high acquisition cost of modules, and dearth of high-quality content (missions, campaigns). To me it's similar to titles with low end-game content: nothing left to do. These are strong gating functions for entertainment titles. From there, the remaining 25% will see a stronger tendency to remain, meaning that those who do remain will be likely to purchase an additional map, and have a good likelihood to slowly acquire more modules. This is also the crowd that is likely to supply on-line players. But indeed, although we may come up with great models for customer distribution, retention, price elasticity and spending habits, I really know nothing, and all I'm writing is purely (mildly educated) conjecture, and a lot of wishful thinking - I want ED to be as successful and around for as long as possible.

You presence here alone virtually guarantees that you are part of the multi-module owning, probably 10+ module-owning crowd. This is a self-selecting group. We are not the majority. We are, however, the connoisseur, so to speak. Those who know and enjoy a good thing.

Yes.

They are now: PlayerScoreTable To use a score table in your mission, you · Place a Trigger Zone on the map (anywhere) · Name that Zone “playerScoreTable” (note: name must match exactly) · Add the names/types and their score to the table The playerScoreTable uses the following format: Name Description <tape or name of Unit / Group / Static Object> Type Exampe: BTR-80 Name Example: Big Kahuna Wildcard examples: BTR* Big K* <Score to award as number> Example: 15 Example: 130 Note: The name is first checked again a unit’s name, and then against the unit’s group. The name//type designation support wildcard ending. A name that ends on an asterisk (“*”) matches all names/types that start the same (anything up to, but not including the asterisk). So, for example, BTR* will match all DCS typeNames that start with “BTR”, e.g. "BTR-80", "BTR-82A" and “BTR_D”. Recall that DCS type names are not their “displayNames”. Type names can be found here: https://github.com/mrSkortch/DCS-miscScripts/tree/master/ObjectDB Note that types/names in the playerScoreTable are case insensitive. “A-10C” is the same as “a-10c”, “Big-K*” will match “BIG-kahoona” @DD_Friar - if you have the time, I welcome you early-testing the new additions and provide some feedback. playerScore.lua

I probably agree. I've never played LSO nor Air Boss, nor have I ever seen that position filled on my servers. The good thing is that we have the option. And yeah, I'd absolutely pay for a "DCS Tower" module. If that's AI only, I don't care as long as it's good.

Thank you BN, that is indeed good to hear.

No - the fix is in the bedrock zones module. It catches this change for all modules that build on 'zones'.

That's an assertion that I strongly question. I posit that the total income from customers who bought 3 modules or less is much higher than the total income generated by customers who buy 4+ modules. DCS is on a one-off payment schedule, only future sales count, past sales are irrelevant. My take on DCS's current portfolio is that 2 planes and one helicopter are in active support (Hornet, Viper, and Apache), and ED now bet the farm on Fat Amy generating massive future income. It must be a success after their past couple of launches faltered. That's the consequence of not having a steady income stream. So, if there are planes that people buy in droves it would be one or two of those three, not much else, and many depart from DCS after a few years. I daresay that the percentage of all ED customers who own less than 4 modules is 80%+. So I assert (without proof) that ED lives on the spur-of-moment buyers, not the loyal customers. TBH, if the latter were the case, I posit that ED'd engage with their long-time customers very differently. Strangely enough, at least to my badly-tuned, non-native English mind, your posts do seem to have a tendency to come across as abrasive. Probably not intentionally, and maybe only to foreigners. Please take this as well-intentioned feedback, not an attack. That's popular democratic Europe for you: all inclusive. In stark contrast to managed-democracy AIM-120s that are very picky whom they interact with One thing I do have to mention: I rather enjoyed the 'leaves reading session' what which word from a post meant in which juxtaposition to other words. Reminds of the good old times "Half-Life 3" divining sessions. Hopefully the Rafale and Typhoon make it some day to DCS. There is no guarantee that they will. One thing is sure, though: no matter how much hassle HB got when they delayed the F4, they need to create excitement from a business perspective, so of course they and ED will hype it up. Nobody will be able to miss the uptick in chatter, should the time approach. And remember: even if these new models are talked up, there's a good 30% chance that they still won't make it. IIRC, that's DCS's current hit/miss ratio with modules (yeah, MAC, I'm looking at you)

And of those 5 perhaps 2 are current in procedures. Definitely a niche product. There is a very interesting ATC/Tower application for DCS available (here) for people who want to become traffic controllers.

Here's an updated cfxZones module that accounts for the silly change in DCS's mission data. cfxZones.lua