Jump to content

cfrag

Members
  • Posts

    2938
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by cfrag

  1. Version 2.2.0 - Update 20240320 Often, it's the small things. Last update, 'all' we added to DML was the ability for persistence to share data. A small thing, but it opens a lot of fun new possibilities. This update adds another very small change than can greatly multiply the possibilities. Background: DML uses attributes to control how how modules work. Mission designers decide when they create the mission, what values to use. If they want to introduce an element of random, some attributes support ranges (for examples "5-9" which means "a value from 5 to 9"). There is one 'type' of attribute that mission designers to turn something on or off. In Geekspeak, attributes that have only two values to choose from are called 'boolean'. Cloners, for example, have an 'onStart' attribute that controls if a cloner should run a clone cycle on start. Possible values are 'yes' or 'no' (or 'or'/'off','true'/'false', '1'/'0'). Well, no more. As of this release, you can set this value to 'MAYBE'. In that case, DML rolls the dice at mission start, and sets the attribute randomly to either "yes" or "no". This allows you to randomize any attribute that uses a formerly boolean (true/false) attribute. Note that setting this 'maybe' to either 'yes' or 'no' happens once, at mission start, and that value remains set to this value for the entire duration of the mission. It's re-rolled every time that the mission restarts. So why is this such a big deal? Because in an instant, you can now randomize many missions simply by changing the value of a formerly true/false-values attribute to 'maybe' and have your mission randomize its setting every time that the mission starts. The other big change is that finally, after a lot of stress-testing I am able to add the ability to intelligently drop units into densely populated areas (like cities in Syria or Sinai) with a good likelihood that they are not dropped on top of buildings. This is controlled by the new 'inBuiltup' attribute that you can use to control the minimum free space that a unit must have around it. Changes is Detail Manual Main - boolean "maybe" - changes to cloner Demos - (none) Modules - cfxZones 4.3.0 support for "maybe" - cloneZone 2.1.0 - despawn option - inBuiltup attribute - csarManager 3.2.5 - useRanks option - groupTracker 2.0.1 - better verbosity - PlayerScore 3.1.0 - shared data - rndFlags 2.0.1 - better verbosity - sequencer 2.0.0 - dmlZones - stopGaps standalone 1.1.1 - filter "start from runway" - stopGap 1.1.1 - filter "start from runway" - valet 1.1.0 - hysteresis now time-based Enjoy, ch
  2. Definitely. There are many ways to do this, and you don't even need DML to do that. There are 'vanilla' ME trigger conditions that can do that for you, albeit using them is (at least to me) somewhat more of a hassle than what DML offers. We'll get to that soon - I like your mission's idea because they are straightforward, and to a point. In ME (and DML builds on that) we always separate things that units/troops do (fighting), and checking if some situation happens and then tell DCS to react in a way that modifies the mission, for example spawning new troops, blowing stuff up, or adding smoke. The first part is DCS's turf, we (mission creators) currently cannot change how AI works. The latter part is where DML offers us a ton of help: doing stuff. DML can't work miracles, it just makes many complex tasks more accessible to average (and in my case: lazy) mission creators. Let us look at the situation that you describe that we are looking for: "all the troops are eliminated". To nit-pick (which is unfortunately necessary for the task of writing missions), by 'all the troops' you mean the red units that you have placed on roof of buildings in southern Poti. And by 'eliminated' you mean that they are dead. So the situation that we are looking for is 'all those units that I placed on the roof of buildings in southern Poti are dead'. And when that happens, we want to do something. Let's say we want to show some blue smoke close to those buildings (we could also display text, play sound effects, or initiate fireworks - something I only recommend in a mission at night time - or, or, or. The possibilities are limitless. So the description of 'all the units that I placed...' is the condition WHEN something happens. In vanilla DCS, this is put into a rule trigger's condition and is evaluated roughly once per second, for the entire mission. In DML, you don't use rules as much as you simply place a specialized module that also perpetually looks for these things, except you don't write those rules in logic code, the module implicitly looks for these because that is why they were made. Once we determine that a situation that we describe has happened, in vanilla DCS the 'Action' part of a rule is enacted. There are a lot of things that you can put into DCS's actions, and some of them are even nicely documented. DML, on the other hand comes with very specific (and often helpful) things it does when the wanted situation arises: it spawns troops, sets off fireworks, starts smoke, plays sound and/or text, blows stuff up, etc. What makes DML a bit easier to use is the fact that since we use trigger zones to place modules, we not only control when stuff happens, but WHERE. This allows us to rapidly move our effects around. Oh, and usually use copy/paste to duplicate this all over the map (that's 90% of the work I did for the 'Angels' mission: copy/paste DML zones ) Now, let's come back to WHAT you want to do when 'all those troops' are dead: let's say that you want to start some blue smoke. DML has a 'smokeZone' module that does just that: it places smoke on the map. It has some nice-to-have additions that make it (IMHO) easier to use than DCS's plain colored smoke, but that's just the icing. So, let's use a smoker and place it close to the houses with enemy troops on top. I name that trogger zone 'We are done here'. Since this is DML, we also add a couple of attributes. If you look up smokeZones in the docs. you'll find that 'smoke' tells DML that this is a smoke zone, and the value 'blue' tells itg that the smoke to produce should be colored blue. The attribute 'paused' tells DML that the smoke zone should wait for signal to start smoking. Meaning: it will not produce smoke when the mission starts up but waits for a signal to start smoking. Which signal? Glad you asked. The 'startSmoke?' question tells DML that the smoke zone should keep its eyes peeled on the flag named 'done', and when the value of that flag changes, it should start doing its thing. And the last sentence is 90% of what DML is: waiting for a signal, and then doing what it should do. A smoke zone smokes. Cloners clone. Messengers send text or sound messages, etc. But how do we find out that "all the troops" has happened? There are lots of ways to do that. In vanilla DCS, you'd create a new trigger rule that concatenates the conditions "GROUP DEAD (Ground-1)" and "GROUP DEAD (Ground-2)" and when this has happened it will increase (change) the value of the flag named "done" Above produces a "signal" (a change in the value of a flag) on the flag named "done". That will work, is quite straightforward, and a classic example of how you can easily integrate DML with vanilla DCS. When groups "Ground-1" and "Ground-2" are dead, the value of the flag named "done" is changed. The smoker, which is always looking at the flag named "done" sees the change, and reacts: blue smoke starts erupting from the center of the trigger zone "we are done here". Above is "the vanilla way". Definitely not Mandalorian: it's also boring, so let's kick this up a notch: let's use DML's built-in abilities to automatically provide a signal when it's time. The problem (for you right now, but probably not for very much longer) is to know which modules can produce such a signal at the right time, and when. If we browse the shock block, you'll find a module called 'groupTracker'. It's sole raison d'etre is to provide signals if something happens to groups that are inside the trigger zone. So we place a trigger zone over the two groups on the buildings, call it "Tracker" and add attributes: "tracker" tells DML that it should create a tracker with the name of this zone (which is "Tracker"). "trackWith:" tells DML that the units inside this zone should be tracked with a tracker named "Tracker", which happens to be the tracker attached to this zone (you can attach the "trackwith:" attributes to other zones as well to track multiple groups with one tracker, a quality of life thing). As a result, we tell DML that it should track all the groups inside the trigger zone with the tracker we attach to this zone. And "allGone!" (see the exclamation point. That's DML for telling you: this is a signal generator) tells DML that when all the groups that are being tracked are dead, it should send a signal (change the flag's value) of the flag named "done". That completes this small 'automaton": tracker tracks until all the units are dead, and then sends a signal on the flag named "done". smoker waits until it receives a signal on the flag named "done", and once it does, it produces blue smoke at the center of the trigger zone. You may have noticed that the smoke zone "we are done here" has come to sit inside the "Tracker" trigger zone. This is just to show that this is of no consequence at all, and you don't have to mind other trigger zones when building with DML. And that's it. Now, there are way cooler things that you can do with DML, and my challenge to you is to re-build above with a cloner (yes, it can place units on roofs - not actively, it simply places them where you have placed them in ME), and use the cloner's ability to signal when all clones are dead. Can you do it? Have fun! 000 DML Test_B - CFR.miz
  3. Someone may have slightly misrepresented what DML can do. Those zones that you see is what tells DML where, when and what to do. But DML rarely controls troops - they do what DCS's AI tells them what to do. So, for example, you can use a 'cloner' from DML to spawn troops at the location that you put them in Mission Editor and then let them do theirt thing. For example, you place troops on rooftops exactly how you like them. Then place a "cloner" zone above them, and they disappear - until you trigger the cloner, and they magically apear, the perfect ambush. Triggering is where DML excels at - and randomizing the spawn locations. So, DML might work for you, and it can greatly shorten the time it takes to create missions like that. The downside: you need to learn a bit of DML before you can use it, so it's a mixed bag. Personally, if it catches you interest, look at some of the demos that come with it, and the descriptions - each demo has its own chapter in the shock block - then try for yourself. But beware... designing missions can be exceedingly addictive.
  4. Version 1.1.1 - 20240318 This version adds filtering for client planes that start "From Runway" Enjoy, -ch
  5. There may be a couple of issues with your code: You may have been bitten by one of the many idiosyncrasies of DCS. Remember that StaticObject.GetByName() works on the name put into the "UNITNAME" field for static objects, not the "NAME" field. That silly issue has gotten me more times than I care to admit More to the point, though: when does rmBaseDamage() execute? Because, if at that point a static objects was completely destroyed, it will no longer respond to getByName(). Meaning: it may well be that only those buildings respawn that weren't completely destroyed. What you would need to do is to read all bases fully at mission start, cache their description, and use that to re-spawn them all. Hope this helps, -ch Wait... two more things to check: make sure that those trucks are also static objects when you spawn them, make sure that the "dead" flag isn't set to true (as it can be if you getDesc() ), else most static vehicles spawn without a model.
  6. It would surely possible, but it would be a bad experience all around. The reason for that is that DCS has no API for unit-individual commands, just for entire groups. So all group members have the menu items available, and only that one plane would elicit a response. It would also introduce a source for frustrating and difficult to detect bugs (name-matching from units to what you specified in ME), and some more checking in the WP code (not that difficult). So what I would prefer to do is wait until ED get around to introducing unit-specific missionCommands (after all, it only took them some 10 years to do the same for textOut() and soundOut(), even though it currently does not work correctly in multiplayer yet), and then re-code WP (and all the other modules like HeloTroops, csarManager etc) to support single groups without ugly hacks.
  7. Unfortunately, DCS (currently) has no concept of a player in the game; that is only an attribute of a plane. In your case, though, you can get around this since these x-commands are highly type specific (and I don't know if they work in multiplayer at all). So since you know which planes are client/player planes, and you know their type and which is their unit, you can go the old 'unit in zone' route. And yes, it would be great if there were a) a standardized player API b) a standardized cockpit command API We can only dream...
  8. I think there are multiple ways to approach this. have the helos bring the troops along (using helotoops) and have the players drop them where they deem correct If you are going the route that a helo that lands triggers a spawner or cloner, and run into the problem that multiple landings result in multiple triggering signals to the spawners, use an output method from the LZ that will not cause multiple spawns, e.g. 'on'. Note that in this case you may want to use individual LZ and spawners for each helo.
  9. Hey everyone, I'm putting the final touches on my new 'combat rescue' sandbox mission "Cesar Caucasus" - if you'd like a sneak peek, provide feedback, and help stress-testing the mission, please head over to "cfrag's DML testbed" (a hosted server, no password) and take your favorite helicopter out for a spin. In short: pick up the blue guys by landing close to them, then bring them back to the field hospital (marked with red smoke). Be advised, this is a COMBAT mission sandbox. If you feel that you are a member of the sierra hotel club, cross the yellow line to the north. If you do, bring a buddy. Please provide any feedback here or pm me. Thanks to all (especially @bitboy and @HungryCoyote) for their feedback - much of it has found its way into the mission. After the stress-test completes in a couple of days, I will make the mission available to everyone for download from ED's user files. Thanks, -ch
  10. You know I always value your opinions, @draconus, even if passive aggressive and dead wrong I surely won't oppose wishes on a wish list. Like diamonds in the rough; I'd like to help and polish them to find the valuable core. That elusive core has evaded me on this one so far.
  11. Possibly. Then again, I've written my fair share of missions. If you are in a fast mover and eject, you usually are some 50 km (30 miles) away from a friendly FARP, usually a lot more. If your CSARS are based on an airfield, way more than 50km. So, let's assume that your hot-started helos can be manned within 5 minutes of a splashdown (I'm assuming that your CSAR pilots aren't sitting in their cockpits doing nothing, but can end some other job within 5 minutes -- quite not likely at al). So, ingress 50 km at 200km/ is still at least 15 minutes (more if the LZ or ingress is hot). Pickup & return trip another 15 minutes. Best case scenario here, the downed pilot must wait more than half an hour and can't do anything in that time. I've written missions where the players rescue downed pilots before they can fly again. The consensus was 'replace the downed pilot with an NPC and let some player eventually get around to rescue them' (the NPC). Players hated waiting on the ground for the helo to arrive, and consequently preferred (and made sure) not to survive the downing (meaning they did not eject even if they could). Being the evacuee is no fun and boring. If you have 2 hours of quality time this week, you would not want to spend a quarter of that twiddling your thumbs. I'm sure that there will be the occasional player who likes this, but my impression is that they will be few and far in-between.
  12. That scenario where the player sits on the ground and waits for hours on end to be picked up and flown to a base - that is MP only. How is that going to be a good game experience for the person who first waits and then is being flown home?
  13. That's a distinction without meaning to me. You are either paying for an FAA (or other) licensed 'real' sim for your job (or advanced hobby), or you are playing a game to entertain yourself and spend your quality time. If you want to 'hardcore' it in your quality time, by all means, have at it. But if I don't want to, please don't make me. I happen to like the option of hot-starts, labels, external views and field repair. They - to me - make DCS a better game. So we can completely fantasy our way around that (a multi-year education, medical and mental fitness, political and national affiliation), but we should not fantasy about some grass-lenient gear? Seems a bit arbitrary to me. To me, it's "whatever makes a better game". And let me bring up the "Progressive Overlay" that people enabled for me when I had the opportunity to PIC in a (fully licensed, full motion, and prohibitively expensive) A340 sim. That overlay is not available in reality, yet it helps sim pilots (during training) to find their way around unfamiliar airports without stressing the Tower guys (who, as sim crew, aren't familiar with all airfields either). So even professional sims can bend reality. That's exactly why we use sims: because it is possible to do so there. So, as long as it's optional, I feel it's great to have things that are not 100% realistic - as long as it increases enjoyment for some.
  14. Not IRL, no. Luckily, DCS is a game and provides the "three-minute-repair" that can bring a FUBAR Mudhen to stellar, flight-worthy condition. So why not a plane that accidentally was driven off the ramp by an unlicensed pilot? Remember -- this is a game, and we can do stuff that isn't realistic (like flying a jet fitted out for Armageddon without being licensed nor authorized). Actually, that's one of DCS's strong points. So even if it wasn't realistic, IMHO it's still something worthwhile to discuss.
  15. I usually start my Vive via Steam first (which will run the SteamVR Home app). I then switch the Audio back to normal (I don't like the Vive's headset) Then I start DCS, and I'm presented with multiple option, TWO of them relating to start DCS in Steam VR (one as single-threaded, one as multi-threaded). I usually choose MT (you will have to scroll down the options, especially if you also get the Oculus Options which I do NOT use). And yeah, once you go VR there is no turning back. DCS is the killer app for VR (well, that, and Alyx). MS can't touch this.
  16. You can, but not in ME - you can spawn units via script. Remember to convert lat/lon to DCS's internal coordinates with the coord.LLtoLO() method.
  17. Yes, the new model comes with an FM antenna and internal audio cassette player pre-installed.
  18. TBH, if this was entirely optional and supported in VR, I'd love this as well. I feel the same, even though I don't need a shutdown of the plane at all. Simply being able to exit the plane (or chopper!) in its current state, even if we could only stand in one spot - silly as that may seem, but that would scratch an itch I have.
  19. Ah! That explains it - thanks! I prefer to have one app to only focus on stellar experiences rather than having a host of shoddy ones -- ones that I can have much better in other apps. But that's merely my preference, and it's as valid as yours. Happily, DCS currently fits both our bills and we both immensely enjoy it
  20. Tell your friend that they should look at the roadmap and they shall see the answer
  21. Stopgap works by creating static objects that use the same DCS type identifier as the player model. If they do not show up on clients I’m *guessing* that this is because they create nothing on the server, and that nothing then gets synched to the clients. I propose that you try this: also install those mods on the server and all clients. This is just an educated guess, I have no experience with mods.
  22. (I believe you mean the root menu after "Other...") Unfortunately no, you can sort-of control the initial order of menus (they are added in a first-come basis). But that can get reshuffled by any script that adds or changes menus, and you quickly have a random sort. It would be great if DCS's missionCommand API gave us tools to manage that.
  23. No reason why this couldn't also be great and immersive for single player. If AI could do that, it would be truly excellent. Unless you believe that people would love the idea of sitting around in a simulated fire engine for hours on end in the hopes that someone would declare an emergency. They won't. It's pretty much like those manned guns on my helos (Huey, Hip, Hind). Everyone thinks 'hey that's neat if players can man them'. What they really are thinking is "that's neat if some OTHER players man them". Because, as I found out, manning guns in a helo is boring. I've more than 400 hours in the Huey. and some combined 30 minutes as gunner. I contend that riding shotgun sucks for 90% of the people 99% of the time. I've yet have to come across an interesting DCS mission written for gunners. A mission where people man a firetruck to wait for a disaster can't be much better.
  24. Just imagine running DCS to experience that. I may sound a bit snarky here; I simply don't think DCS would be a great experience for FPS gaming, while it's great for flight simming. I've already spent too much time in discussion if boots and wings mix well in DCS, and I'd love to be proven wrong. Until then, my experience has been an emphatic no. Again, I'd love to be proven wrong, it would mean even more fun in DCS.
  25. No doubt that is possible to implement. I'm merely lacking the ability to see that this would in any way be a popular choice: "hey, let's wait for a chopper to hop on, and then wait some more". Maybe we could get an inkling of how this feels if CA allowed people to control infantry (instead of vehicles) and then we could gauge interest in this. Still, playing an infantry soldier seems relatively more interesting (but still not interestingly enough for me - there are dozens of games that can do that better; why would I settle for a sub-par experience?) than playing a downed pilot with a dinky sidearm. To me, it's not a question of "is it possible?" It definitely is. My question is "is it worth it" - will there be gobs of new players joining DCS for the "wait simulator" experience to offset the development cost for that feature? I truly don't know the answer to that, although I am skeptical (tbh, I also hated "death stranding" for an exceptionally boring experience, so maybe I'm simply not geared towards this kind of experience).
×
×
  • Create New...