cfrag

This may be a silly question, but considering that the pyramids are solid (not hollow), made from some 5 million tons of limestones and some 5000+ tons of Granite, why would some puny 2k iron bombs even put a dent into them? Those things were built to last. 3K+ years of humans couldn't put a dent in them... So even if ORT put some collision detection and damage modelling into them, I don't think that realistically, mere bombs that are dropped from above could damage them all that much.

Does it matter? Neither is very accurate, and you can only fly one map at the time. So if your mission is on one map, it doesn't matter what the other map looks like. From my personal (cursory) inspection, The Haifa region has more 'realistic' landmarks in Syria, Tel Aviv more realistic landmarks in Sinai. neither are very accurate, and I find both regions (the two with realistic landmarks on different maps) worthy of a local helicopter rescue mission. Otherwise, the remainder of the map (the stuff without landmakrs) dictates to me what to choose. That, and the fact that Syria simply is much more popular than Sinai (the bad rep that ORT got for the one-year gap between releases may have contributed strongly to this) on MP servers.

Huh. Spoken words are certainly a bold choice - even if the theme evokes strong echoes of Frankie's "War" and "Two Tribes". It's still too jarring and distracting for me. I'm sure others will love it.

Some good wine there, I guess

Version 2.3.6 -- 20241107 -- Feature Update Recently, while assisting a fellow mission designer, I ran into a communications challenge: I tried to convey how modules talk to each other and realized just how inadequate all explanations that involve flags and methods and whatnot were. I needed a new, better approach that allows non-technical people to easier grasp how this works. As I so often do, I kicked the issue up to a bright friend of mine, who also happens to be an artist. It took us more than a bottle of wine, and some of her free-associative thinking, but we came up with what I now call the "Yeller Model". It's become part of the documentation, and I hope that it may help many aspiring mission designers to grasp more easily how modules interact, and it allows most of them to craft great missions without ever using the word flag. Please see the documentation. Other than that, this release also sees a major new feature for one of DML's prime modules: heloTroops. Based on a request I added 'dropZones' that can kick up heloTroops' functionality a notch, while (of course) staying completely backwards compatible. It comes with its own new demo 'Inferno at sea', which is basically an endless extraction mission for helicopters, put together in a few minutes. Also, The Debugger has received a feature update which will bring great relief to a tiny goup of mission designers who actually use it: it now sports a feature to identify misspelled flag names ("commands" in "yeller" parlance). If you build a mission and for reasons unknown two modules seem to have problems talking to each other, a misspelled input or output is often the root cause. The Debugger's new "-x !" command (appropriately cryptic, don't you think?) lists all outputs that do not connect with an input (and vice versa), making it very likely, that one of the names was misspelled. Oh, and finally - which has unfortunately been par for the course in the past few months - a new DCS update came with game-breaking changes: this time on the Syria map. For reasons unknown, that map breaks one of DCS's cardinal rule that no two objects may have the same name. In Syria, well over 100 airfields now have the same name "H", which can break any existing script that accesses airports by name. I hardened DML's modules, and I am sure that there will be lingering issues until the kind folk at ED/Ugra correct this breathtakingly obvious blunder. All Changes in Detail Documentation Main Yeller Model (new) HeloTroops Debugger cunconnected in-/output detection Yeller Model demo (new) Inferno at Sea demo (new) Quick Ref Yeller Model HeloTroops Demos Inferno at sea: dropZones (new) Yeller Model (new) heloCargo (update) Modules cargoReceiver 2.1.0 new noBounce Attribute cfxZones 4.4.3 additional hardening of property processing civAir 3.1.0 hardening for Syria's 100+ airfields known as "H" convoy 2.1.0 new convoyTriggerMethod heloTroops 4.0.0 new dropZone new enforceDropZones playerScore 4.0.0 improved event handling suppress landing event after player spawn theDebugger 3.1.0 new detect unconnected inputs/outputs tool Enjoy, -ch

Yes and no. DML is not designed to be code-modified. It's not intended for code heads at all, it is designed to be used as is, from people who do NOT want to modify, or dabble in, code So if all you need is some script that plays some sound file, and you feel sure enough about mission scripting, you can take DML's modules as some source of inspiration how to go about that. Bomb Range could be such an inspiration, Guardian Angel another. Your scrip would center on an event handler that traps 'shot', lhen looks at who shoots, analyses the weapon that was shot, and if all matches as desired, you play the sound file. On your way, you'll probably discover some of DCS's idiosyncrasies. To quote Calvin's Father: "they build character". I do not discuss code in this thread, though. For code discussions, I recommend that you open a separate thread or PM me.

Or you could tell players to log off, e.g. via chat. You can if you know how to create and maintain server-side script modules. It would be net.get_player_list() - but that is not something that you can invoke from inside a mission, it must run inside the server context.

Ah, perhaps. But even if so, that's no excuse for DML to work that way. I thought I added code to remove leading and training whitespace, and I hope to have it in place for toworrow's (planned) update Good thinking - but as of version 3 of raise flag, persistence is supported for raiseFlag and it knows if and when to fire on reload - so you only need one version.

This is a truly odd one. There is a trailing blank at the airfield's "ownedBy#" attribute. It seems that this is something that some attributes don't like, and therefore do not register as an output. If you remove the trailing blank, it works. I'll try and see if I can guard against this in the foundation itself so that this silly oversight will no longer matter.

That is true. I can't check before the mission starts. If you want a convoy to start at mission start, I think that the best way to do that is use a raiseFlag that runs 0.5 sec after mission start. Indeed. That is default module behavior. It seems you want to exploit a particular implicit setup that may result in a flag change at mission start-up, but does not. I strongly recommend that you always make these things explicit - for example by using raiseFlag.

I did indeed - thank you. I did not see a question to answer. Always remember that I'm not a native English speaker, so a direct approach using small words helps silly me to better understand. And according to the most important person in my life, I "don't understand obvious hints to do things", I'm just a silly male.

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?