cfrag

Shhhhhhhh...! It's DML's best kept secret When this becomes common knowledge, my renown godlike debugging skills become all too common...

I'm building a new tool into the debugger that helps identifying misspelled flag names, should be a great help. I'm running it on "Expansion" as a test case and it already discovered two 'hanging' flags (i.e. one unmatched pair, where I misspelled a flag name on one side)

I believe CA is a bad tarnish on ED's otherwise clean(ish) west. And I have it, of course. Let's fix the mission instead I'd like to get you into the habit of using TheDebugger. It makes that kind of stuff trivial

So let's simplify until we find out what's wrong, and trace the signal back to its source. For my money, the misspelled "ownerairfield" is a strong contender...

So what have you tested, in whcih configurations, what do you get, and what did you expect? Hmmm. I'm not sure I can follow.

At first blush, the logic appears sound to me. Are you sure that the objectDestructDetector fires? Perhaps connect a messenger to it to see if that works. After we are certain that that part works we can go deeper. That's an interesting idea that I could add similar to the way you can add liveries in a table: type/alt. I'll see if I can fit it in somewhere.

Thank you so much for taking the time to test this. Below is an image I just took, with the F7 camera maximally zoomed out from the infantry soldier. I cant even get the entire platform into view And here's the miz, very small, very simple: demo - Inferno at Sea.miz

Thank you so much for the hint - Rctrl-/ in my DCS changes FOV slowly to fish-eye lens, making the apparent size of the objects a bit smaller and distorts the view. But it gives a little more 'distance'. It looks like that for simmy, ham-fisted I, and I would like hints on how I can increase the max zoom.

It seems that unlike before I'm no longer able to zoom out as far as I remember I was able before. I noticed this when I was trying to create some in-game footage, and now (I do not know how long this has been in place, I did not check for at least two months). I can't zoom out the F7 and F2 as far as I was used to. This severely impedes my ability to create imagery for my missions, and I seem to be unable to find a work-around. How can I zoom out further than what DCS allows now (which appears to be some 25 meters)? Any hint appreciated.

Huh. At this juncture I flat-out dispute ED's willingness/ability (from a business perspective) to produce anything except shiny new (EA) modules (which may or may not receive the occasional update post-launch), and some absolutely crucial band-aid tech updates that help keep the DCS ship afloat. ED adheres to the old 'one-off' sales model, meaning that they must sell new stuff every day to stay afloat. New modules, even if severely undercooked, make it to sale early for better ROI and higher NPV. Half-baked Modules that no longer sell well will languish and merely receive must-have support to remove show-stopping bugs, and very little else. I believe we all own at least one pet module that fits that description (I own them all). I deem a dynamic campaign or save/load capabilities currently beyond ED's financial project focus: it brings in marginally more (if any) new customers compared to new models for the same investment and (worse) can't be monetized directly -- so accordingly few (if any) resources can/will be allocated. Sure, features are 'promised', and we all know that talk is cheap. Being able to follow up your promises is gold, and "real artist ship". ED seem to be lacking in that department - for obvious reasons: new complex stuff like the dynamic campaign is expensive to implement, with comparatively little 'sex appeal' for the majority of players (anyone reading this exempted, of course). Financially, it's a non-starter and whatever ED may say in this regard I deem irrelevant. What they deliver counts, and the score in that department has been depressingly low in the past 5 years. Consider Super Carrier, Mission Editor, ATC, Ground AI, Dynamic Campaigns, Vulkan, Dynamic Weather etc. Talk is cheap. Instead, we received an Afghanistan Alpha (which already is behind its update schedule), a Chinook Alpha that barely works, a broken Cargo/Warehouse System that makes your eyes water should you want to use it, and we will soon receive an Alpha Iraq. I predict that updates to these will follow their sales track: low sales = slow updates. Dynamic Campaign? There will be "encouraging status updates" and "progress reports", maybe even "concepts of plans". I highly doubt we will ever see it in-game, with perhaps the same likelihood that we will ever see a "Star Citizen 1.0". It's close to Astroturf. I think that a Dynamic Campaign paid Module would have better chances of ever seeing the light of day - and that IMHO would make more sense (and a day one purchase from me) financially. But even if ED could monetize a Dynamic Campaign, I doubt that it would attract enough people, so that's doubtful as well. There will be general progress in DCS, no doubt. And it will be driven by additional sales of fresh early-access modules -- not new groundbreaking tech that only excites the (hard)core players hanging out in these forums. So, yeah, there are many things that would be cool if we could see them in 2025. More planes for sure, and that will happen. Anything else, especially tech infrastructure upgrades I don't believe to be in the cards. Especially considering that whatever is going to be released in 2025 must be in testing now. So yeah, the future looks bright -- for new modules. Let's see how it all turns out.

While this works for SP, in MP that unfortunately is wholly inadequate, as the new "dynamic player spawn" doesn't work well with helipads (bone-headed "flight is waiting" and it wreaks havok on any attached warehouse logic), so we urgently need a better multi-slot FARP. It's a pity that this has not been given much attention in the past few years. Let us hope that ED wakes their sleeping prices/princesses who work on that aspect of DCS.

That is because DCS's Lua API hates you. With a vengeance. What we have in DCS to support mission scripting is ill thought-out, does not seem to be engineered at all, and is unnecessarily difficult for neophytes who already do know how to program in Lua. That being said, maybe I misunderstood your requirements. What are you trying to accomplish: spawn some units at an in-game event (via F-10) at a pre-determined location, which happens to be a Mark (meaning that the spwan location is known when the mission starts up) or spawn some units at an in-game event at a dynamic, runtime player-determined location Above cases are very different. Both require spawning units. And spawning units at runtime (as opposed to late activation) is one hellish thing to learn simply because it requires you to absorb large parts of DCS's abysmal API and idiosyncrasies. It's one of the reasons why so many prefer using frameworks. Once you get beyond that, however, you have a powerful too at your disposal to create significantly better missions. So, if "all" you need is to spawn units at some player-determined time, you will have to learn how to script spawning. Getting it done is painful, but manageable. Becoming good at it takes longer. Once you can spawn, however, since you know the location, the rest is straightforward. Spawning units at a player-determined location requires a lot more, through. You can try and simplify the coding challenge by off-loading some complexity to the player (e.g. the mark must have a very specific text), but DCS provides very little by way of player script integration, so doing that will require a lot more understanding of DCS's API. So if you are looking to solve bullet two, you'll be in for quite a ride. That does not mean that it's not worth the challenge, though. I'm close to being addicted to coding, and DCS's terrible API doesn't scare me any more. It still infuriates me, yes, but once you learn and abide by the silly nonsense, creating good missions in spite of the terrible API can be quite rewarding.

That's interesting. How? Are you modifying cfxZones?

airfield config zone?

I've modified cargoReceiver in a way that should work according to your needs: Below please find a pre-release version that still needs regression testing, and I award you the honor of being part of that Here's the updated dox - it's backward compatible and I still recommend that you use the new (shorter) cargoReceiver! semantic. Note the new noBounce attribute that defaults to TRUE: Name Description cargoReceiver! Output flag to bang! when the cargo object is delivered onto the ground inside the zone. Marks this zone as a cargo receiver zone. MANDATORY cargoReceiver deprecated Marks this zone as a cargo receiver zone. Value is ignored deprecated autoRemove Delete (despawn and remove from game) a cargo object <removeDelay> seconds after it was successfully delivered. This is helpful for most ObjectSpawnZones set-ups to trigger their spawn cycle Defaults to false silent Set to true to turn off this zone’s directions. Defaults to false (zone will talk to pilots) method cargoMethod DML Method for output Defaults to “inc” f! cargoReceived! deprecated The flag to bang! when the object is destroyed. Use only one synonym per zone. removeDelay The delay (in seconds) after which after a successful delivery of a cargo object is removed. Requires that autoRemove be set to true. Defaults to 1 (second), Minimum is 1 noBounce Prevents multiple deliveries of the same cargo object to the same zone are counted multiple times (e.g. bounces). When set to true, each cargo can only be delivered once per receiver zone. Defaults to true (one delivery per zone) And the new module, I welcome your feedback cargoReceiver.lua

Isn't that expected behavior (unless autoRemove is set)? The receive would register each time that the cargo is on the ground and lifted again, provided that this happens less often than once per second and ups is set to 1. If autoRemove is active, the cargo should disappear (and no longer be able to land inside the receiver). And I think I understand what you may be getting at: once put on the ground, the cargo should be removed from cargoManager's inventory. Currently, it's not set up that way so that you can pick up cargos that you have lost, and transfer cargo after you have dropped it into a receiver. What is your intended use case? Maybe I can figure out something for that.

Here's the updated cicAir that works with buggy Syria. And, wow, Ben Gurion! Note that CivAir is currently still a bit chatty, make sure to disable verbosity. The next DML release will probably have a verbally slightly more restrained version. The text you see now is to help in diagnosing other odd stuff Syria/ECS might throw at us. civAir.lua

Please revisit 4.1.6 "That text in the upper right corner" of the manual to get some step for step instructions. If modules constantly display information, there are two possibilities: I goofed up and forgot to remove some diagnostic code. In that case, please provide me with a screenshot so I can try and correct it. Otherwise, that module's (or a zone under its control) 'verbose' attribute is enabled. In that case, set that attribute to 'no' or remove it entirely.

I think a simple approach would be to insert a delayFlag module between a cloner's "empty!" output and "clone?" input and set the timeDelay to 300 (5*60 seconds).

I looked at the mission, and HO BOY did I get a nasty surprise. I discovered a slight edge case issue that your mission forces and that was easy for me to fix. And then there was a big surprise: the last update of the Syria map BREAKS CARDINAL DCS RULES: it has 120+ airfields that all have the same name (a fundamental no-no in scripting, the map should not even load in DCS nor Mission Editor): "H". No objects in a mission may ever have the same name at the same time. In Syria, there are now more than 120 such items of strategic value that infract on one of DCS's most fundamental principles. This will cause a lot of strance behavior and abends. These "H" airfields aren't airfields: they have no runways. They are helicopter bases, and identify as airbase - another violation of DCS ground rules. This will cause bugs with scripts that look at runways or assume an airfield has an runway. So what happens is that civAir randomly picks an airbase. There's an 80% likelihood that it's one of the "H". Accessing that airfield will yield a nonsense airfield, and trying to get a parking position for a civ flight to start from results in one of the parking slots that you have seen, where the planes then start stacking up. I'm patching civAir now to work with Syria, and I'm very unhappy that ED's QC even allowed this to pass to us customers. This will break a lot of scripts that deal with airfields (and since warehouses are linked to airfields, most scripts that deal with airfields by name). This is a TRULY BAD DCS bug. I'm at a loss to explain how ED have let something of this magnitude slip by - that's troubling to me. Thank you for alerting me to this.

Thank you for the quick response, BN!

It seems that one of the last releases of Syria added a bunch (over 100?) of helipads. That is great! Unfortunately, though, they all have the same name: "H". While seemingly the game itself and ME do not protest, this violates one of SME's strictest rules: Objects must have unique names. In Syria, that is no longer true, making scripts that manage airfields by name unfit for this map: stupid null, cheap tools, ED! The result is that if you now invoke Airbase.getByName("H") you only get one airbase, and the remaining 100+ airbases remain inaccessible. This renders many scripts that access airfields (heli pads) by name inoperable. Was this done unintentionally? If not, what is the recommended work-around? Thank you for any pointers.

Please see below. Docs: convoyMethod DML method that is sent to the output. Defaults to “inc” convoyTriggerMethod DML method that triggers the input. Defaults to “change” convoy.lua

Trap one of the mark events (e.g. S_EVENT_MARK_ADDED), get the pos field for the position, spawn the group there. Your logical next step would be to analyze the mark text and use that to allow you to specify what kind of units to spawn Next thing you know, you have built yourself an interactive debugger. Great exercise, incredibly powerful tool for your missions.

Well, as someone who does have some understanding in this area I can tell you that any software development that takes longer than 18-24 month in the entertainment arena has a 99% chance of failure - simply because the rate of change is so great that whatever was implemented is now based on outdated specs and concepts, so whatever ED are developing, let's hope that they discard anything that's been longer than 2 years in the making. A cursory glance at DCS's 'new' cargo/warehouse architecture/API IMHO demonstrates vividly what happens if you don't, and should serve as a warning to us all. A dynamic Campaign may or may not arrive some day. Let's hope for the best, and reserve judgement for the day if/when it arrives.