Jump to content

cfrag

Members
  • Posts

    2940
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by cfrag

  1. Can you check the typestring? According to DCS that type is 2B11 mortar Note "B" (letter, not number), and case
  2. That's a good point. I've done some more tests, and think that there are some more rules involved. If FARPS have functioning services, the can't AFAIK use static objects, they must have AI Units. Now, looking into their descriptions, many of those vehicles have an attribute ["NonArmoredUnits"] = true, and all infantry have the same attribute ["NonArmoredUnits"] = true, which leaves me to posit that DCS looks for the "NonArmored Units" and if so, discounts any unit when a unit appears that has an attribute ["Armored vehicles"] = true, like the BRDM-2. To test this, I used @bitboy's test mission, and exchanged one of the infantry soldiers with a Refueler ATMZ-5, which has the "NonArmoredUnits" attribute. The entire zone was captured when the "Armored Vehicles" Scout entered the zone. So I think that this adds evidence to the hypothesis that there is a (as of now undocumented) more complex rule set at work than simply 'any unit captures when empty, else contested'. Somewhat belatedly I now realize that goldfishbrained me even participated in that discussion <blush>>
  3. This one had me stumped for a while. Then, on closer analysis I noticed this progression: In other words: first AK trooper doesn't cap neither second neither RGP (not pictured) BRDM caps Batumi even though there are boots on the ground in Batumi WTF? Then I realized that all blue units are infantry, and the capping red unit is armor. Could that be a factor? I broke out the big guns (debugger) OK, so who is "Batumi Harbor (A) 76551-4"? It's the BRDM-2 scout. So, I theorized, maybe armor beats infantry, like a silly 'rock-paper-armor' type game. To test this hypothesis, I switched one of the defending blue units to armor (an APC), and ran again: Now red no longer caps. Preliminary conclusion: There now is (new?) airfield capture logic in DCS that (maybe) goes like this: If NO OTHER oppo units are present, ANY unit caps if ONLY oppo INF caps present, any ARMOR can cap, but not INF Since you may have some contacts within ED, can you ask someone with knowhow what the current capture rules are? Knowing this may come in handy. In the mean time, a workaround seems to be to place an armored vehicle (maybe a Hummer) inside the cap radius to prevent other armor to insta-cap. Just a hypothesis for now.
  4. If possible, please PM the mission to me so that I can have a look
  5. Ah, but your screenshot revealed a glaring issue: The text is missing a closing bracket ")"!!!!!one
  6. I don't think that I coded such a function, but the Communications menu for helo troops - while in air - should tell you how many troops are on board if your helo has picked up a group. I'll have to check this, though.
  7. I'm quite sure there is, but I can't think of one right now I'm waiting for the "real" (from Airplane Sim Co) Herc to make a showing and see if by that time DCS provides a paratrooper/airdrop API (it seems a bit strange that currently there isn't, especially given the fact that paradrops was kind of a thing in WWII, especially in the Normandy area). I'll go from there. DML has no issues coexisting with other frameworks. There's one thing to keep in mind when it comes to persistence: it it wasn't spawned by DML, it won't be persisted by DML. But IMHO, that's an edge case.
  8. Hmmm. That's interesting. IIRC, carriers can't change factions, so I've never tried this, but now I of course can think of some interesting scenarios where an AC only opens up after you capture some targets. Do you have a mission for my to test this out so I can see if I can track down the issue?
  9. All I have is what's in the manual. I'm hoping that the defaults for the config zones would be good enough for most, if you have any questions or additions, I'm sure we can hash something out here. Adding them to the Quick Ref would IMHO only make the QR bigger, but not better.
  10. Confirmed - thank you! Fixed in the script below, will be part of the next release. radioMenus.lua
  11. Yes. That function is singularly bad explained. When I write 'hidden' I only mean the FARP capture circle around the FARP that is not shown for the faction that is 'hidden'. All vehicles are shown, and the FARP itself too. Unfortunately, the mission may see it differently. If the template for the cloner is within the FARP's capture zone, and it contains red or blue vehicles, DCS will see the units - if only for a split second - and capture the FARP for that side. So be careful when setting up cloners within the FARP that have a non-neutral affiliation. A better strategy is to tell the cloner to derive ownership from the FARP zone, and create the template from neutral (combined joint neutral). That way, the FARP stays neutral at the beginning, and the troops spawn red and blue when the FARP is red or blue.
  12. Sure, I'd love to. Please (if possible) tell me what to look for or how I can try and force the issue. Cheers, -ch
  13. Yes- FARPS, aircraft carriers and airfields cannot be cloned, their number is fixed and if you spawn a FARP via script, it is not synchronized across clients: -ch
  14. Not in the classic sense, but you can often achieve similar effects. CloneZones support a 'masterOwner' attribute that can link the cloner's faction to an ownedZone. Owned Zones have outputs for who owns them (ownedBy# - use it to trigger an input that detects a change) and conquered! that you can use to trigger a cloneZone's production cycle. When a cloner is linked to a masterOwner, all clones that it produces are owned by the faction that ownes the master zone, so even if the template units are neutral, if the current owner is blue, the resulting clones are also blue. This helps a lot with templates that have routes. A hint: to not confuse DCS unduly: use neutral clone templates. Alternatively, if you are using FARPs/airfields, the 'airfield' module is even easier to use than owned zones, with many of the same outputs, and a managed 'owner' attribute that cloners/spawners can masterOwn to. Both also support outputs for red! and blue!, so you can use them to trigger different cloners/spawners whenever the FARP is conquered by either red or blue.
  15. This is a long-reported bug with DCS multiplayer: when a client connects, DCS does not synchronize colored smoke. The result is that connecting clients do not see any colored smoke that was started before they connect. In DML this is luckily self-correcting because DML "re-smokes" all smoke zones every 5 minutes. This results in the effect that smoke starts 'late'. It doesn't. The server does not synch existing colored smoke, all connected clients synch colored smoke with the next iteration of re-smoke. This issue is known to ED since at least 2018 more than 5 years ago, I myself reported it almost exactly a year ago so far no reaction, no acknowledgement, no fix. That is odd indeed. DML is entirely written to be agnostic to the number of clients, so it should not matter if you run a game single- or multi-player: what runs in single-player should run in multi-player. Now, DCS itself has some strange multiplayer quirks (see item above). Let's try and find out if there is something else that may be different (i.e. some logic blunder in DML) or if this is a "DCS thang". Do you have a simple mission that can re-produce the issue? Failing that, let's see if we can track down the culprit by turning on verbosity for heloTroops and the spawners, and if all fails, bring out the debugger. No. DML can't tap into anything a FARP does (else I would have changed a lot a long time ago ). Who owns the FARP? That might make a difference since you can't rearm/fuel if you don't own the FARP. Same goes for the issue above, by the way: who owns the FARP/spawners?
  16. ... but the message text appears, doesn't it? If that is the case, this may be DCS issue that's been reported in a couple of threads: messenger invokes soundToGroup and soundToUnit at the same time that it invokes outTextFotGroup and outTextForUnit, so if you receive one but not the other, it's very likely a DCS issue (and of course you have made sure that the sound file is loaded... )
  17. Thank you so much for taking the time to play and provide such extensive thoughtful feddback, @Emble!
  18. Hey everyone, after the (presumed) demise of one of my favorite servers, the fabled "Rescue" server, I have now put together a (small-scale) proof of concept server mission that I'd like to enlist you to stress-test over the next few days so that - if everything checks out - I can begin on a bigger, badder and better version. Here's "Angels of Caucasus", which after about a week of stress testing I'm planning to release (free of course) to the public on ED's User Files. Right now, it's live on "cfrag's DML Testbed | Fox3ms.com F4-231" (of course a fox3 server ) for your enjoyment Angels of Caucasus Helicopter Rescue single/multiplayer [Huey, Hip, Gazelle, Hind] - endless mission, persisting scores You are an "Angel", a member of Batumi's elite Air Rescue organization. Your task is to evacuate injured people from all over Batumi, and return them to Batumi's Field Hospital, located at Batumi Airfield. Since Batumi is big, and accidents happen, there will always be more people requiring your assistance then you can provide - so bring a friend or two if you can: this mission is fully multiplayer capable, and keeps track of your accomplishments, even between mission restarts. There are four slots available (two each hot and cold) for Hueys, Hips, Gazelles and Hinds), allowing for a maximum of 16 pilots simultaneously. You perform a SAR by flying towards the evacuee (they all have locator devices for your ADF). Pearly Gates, your Command Authority can vector you towards your target. Once you get within 1km, help on the ground will mark the spot with smoke, and you'll be guided by your chied for the last 100m. Land close enough to pick up the evacuee. If landing is not possible (rescue over open water for some hapless swimmer, or forest), you can attempt a winch rescue which requires you to hover within range and altitude for some 20 seconds. Once the evacuee is on board, you are to return them to Batumi Field Hospital for triage. Batumi Field Hospital is located at Batumi airfield, and is marked with red smoke. This mission can persist all your accomplishments (landings, time, rescues) per airframe if you have persistence enabled (this requires that your DCS is 'de-sanitized'). Features Up to 16 Players, supporting the Hind, Huey, Hip and Gazelle rescue missions in Batumi city proper, forest, over water (Batumi Harbor and bay) Dynamic Airfield Scenery (provided by stopGap) Persistent log Civilian air traffic Endless "dynamic scenery" for evacuees PearlyGates performed by elevenLabs Enjoy, and be an angell!
  19. Turns out it was an error in processing the heloTroop's confg zone. Please find the corrected module below. Please let me know if this is working for you (I haven't had time yet to regression test) heloTroops.lua
  20. That helps a lot. Did you do anything to remedy the errors in the startup? Cloner requires cfxMX and failed to run, factory requires ownedZones.
  21. Confirmed. A silly typo that escaped my regression testing. Here's an updated version that should work. messenger.lua
  22. Here's a new version (3.1.0) version of messenger that allows you to list multiple group names, separated by comma in the group attribute, and the same for the unit attribute (group and unit are still mutually exclusive). Will also be part of the next update. messenger.lua
  23. That's a good idea. I'll see if I can add this into the group/msgGroup and unit/msgUnit attributes by allowing groups as a comma-separated list. I may have something for you to test soon, so don't run away
×
×
  • Create New...