cfrag

Version 0.9991 - 20220519 Feature Update: unGrief (PVE rules, griefer deterrent) The original unGrief module was written in February as a response to a request from @DTS_Maton and was then upgraded to DML a week later. I've now had time to complete integration into DML and add some more polish: PvE mode: when active, it punishes PVP activity Wrathful mode: when active, your second transgression is your last. unGrief now is fully documented, and comes with its own demo ("Good Grief") that is also fully documented, so if you want to add some grief-repellent or create a simple PVE-only server, unGrief is just a few clicks away. Change Details - Documentation - unGrief module - Good Grief demo - Demos - Good Grief - Modules - unGrief 1.1.0 - GroundTroops 1.7.6 Enjoy, -ch

Perhaps you are referring to the 'Message History' function? It then shows a message log (is it just me, or is this forum's paste image function REALLY broken?)

I agree, and I'd even go a step further: Check lists are bread and butter to any pilot, and often are treated differently from your "normal" cockpit stuff that goes onto the kneeboard, clipboard or bag. Checklists, with the emergency checklists on top, usually go into a special quick-access location in the cockpit. It's not that pilots really need them - they all know them by heart and exercise most each flight; it's just to ensure to have them accessible should need arise (say, you get disoriented or concussioned). That's also the reason some aircraft (e.g. the Hornet) provide them as pages on their MFD. Personally, I'd love to see a *separate*, module-specific kneeboard analogue that is solely used for check lists and maintained by the module's developer. So, when you are in the Harrier, pressing the (global) Checklist button brings up a window that displays the (developer-provided) set of module-specific check list for the Harrier. If you switch to a Huey, that same button press brings up the Huey's checklists. etc.

Wait, are you requesting a *lower* fps limit? I don't think that is possible. If your card hasn't the headroom to run a scene at 60 fps, that's just it. FPS limiters are for the maximum fps so the fps can't exceed that. I don't think there's a way to force the game to raise that. There are some reprojection VR tools that re-displaying the last frame (i.e. drop the unfinished current) but that still required that every second frame is drawn correctly and can only go so far. If your card goes below a threshold (say, 15 fps) no amount of tech (that I'm aware of) can give you a sustained 60 fps. Did I misunderstand something?

Open Beta, no issues so far. Using VR I can 'click' on the correct buttons/switches by looking at them, and the cursor correctly turns into a green clock or click indicator. Works very well, but I did not have had enough time to stress-test this, so take with a grain of salt Installation was quick, into a dedicated folder in /tech. You'll see it it installed correctly if the logo appears, and it has its own section in the 'Special' tab so you can selectively disable the airframes. Upon mission start, it will tell you the version and airframe it detected. -ch

A good question, and I think what is currently available is enough - meaning no radio controls etc. FC3 functionality is fine. 'All' I'd like to see is some enhanced (visual) button feedback to those functions that are implemented for FC3. For example Otto. A handful of buttons, for most of the airframes; almost all of them already implement some visual feedback, but not all (meaning, in the A-10A you cannot see - by visually inspecting the auto pilot switches - if and which otto is active). Other visual feedback is already there, for example gear lever I'd be happy with that.

Most players use HOTAS controls for these. Not the sharpest knife in the drawer, methinks

Nicely played! -ch

It is indeed - that mod is a godsend. The A-10A (my favorite FC3 plane, even prefer it to the Charlie) has become even better with this little QoL improvement (HUD color and brightness, which used to occupy three buttons are now accessible hands free - yay! Same for flaps and gear - another 4 buttons freed up) Let's hope that ED get around adding some more switch animations to visually represent some of the switches' status. Those FC3 planes don't need to have all buttons animated, just the 20% we use 90% of the time

Actually, that's why the hard-core sim crew will raise a fuss and nix the idea of a Saturn V module: Bad precedent: Neil and the other sissies went into a hot cockpit instead of cold-starting their rocket as god had wanted men to do. Neil entered the capsule less than 2h40m before launch, so that qualifies as a hot start. No self-respecting DCS-blood will go for that. Anything less than the already suspect T-3:30 is practically amateur hour stuff.

I'm pretty sure that some of this is attributed to the way our code is structured. Since people tend to code the way they structure the world in their minds, I can easily imagine (because some of my code works the same way) that one of the first guards in the event processor is something like this: if event.target:getCategory() ~= 1 then return end -- not a ground unit, ignore So their particular implementation for a death event might fire, but since a core assumption (objects don't change category over their life cycle) no longer holds true, it fails. As a result, a lot of code has to be examined, and it makes us wonder what other central unit life cycle assumptions no longer hold true or may change without notice.

@MsKatze, thank you so much for your feedback! DCS is built like a 'Lego' set, with modules building their abilities on others. SpawnZones internally hands off all units it spawns to GroundTroops, where the real trouble lies. Now, this doesn't help, but it hopefully explains my answer and how I'll try to tackle the issues in the coming weeks. Unfortunately, the GroundTroops module belongs to the 'advanced topics' set of modules and needs a basic user interface (which it has, of sorts - I'll explain below) With regards to GroundTroops, that module currently possesses only rudimentary AI supplementary capabilities. It doesn't so much build on DCS's native AI, it merely uses it. And truth be told, DCS's troop AI is currently marginal at best. On my roadmap for 'beyond 1.0' is an overhaul for GroundTroops to add some AI augmentation. The 'guard' and 'attack' loops are currently simplistic; for example in 'guard' mode, GT regular checks to see if the group is unengaged, and if they are, looks for an enemy group in range. If it finds one, the group is ordered to move towards that group and waits until that enemy group is destroyed. GT relies on DCS to handle the task of approaching the enemy, re-loading and attacking; The results can be abysmal. The AI built for lasing shows that GT can be used effectively, but it's also a drain on CPU and works against DCS's native 'AI'. I'll have to revisit the entire 'orders' code soon, and I'm grateful for your feedback and suggestions, as it matches my own experiences and frustration. Now that's a great idea! I'll see if I can design a global 'governor' module that can be configured individually for red and blue. Spawners and cloners can automatically check before they spawn if their side is over that limit. As a stopgap, use GroundTroops' "scheduledUpdates' attribute in a config zone and set "maxManagedTroops" to sensible cap, say 60 groups. GT then no longer manages (i.e. issue orders) to more groups than the cap, although more can exist. Whenever a managed group is destroyed, GT then fills it's management queue back until the cap is reached. I'll have to check, but I suspect a CTD is triggered by DCS running out of memory on a pathing task inside DCS's AI itself, and is often the result of a combination of long distances, many roads, difficult terrain, and (mostly) lots of groups. Lua script can't cause a CTD, but calling into DCS with Lua can (simply set a flag to a sting, and see how quickly you can CTD ), and my own experience with pathing/ordering is that yes, giving move orders to a a group can crash DCS under the right (or better: wrong) circumstances. It's one of the reasons that GroundTroops has the optional cap on managed troops and scheduledUpdate options. It will merely delay the onset of slow-down/crash, but it may help. As you suggest, putting a definite cap on spawned units is probably the only surefire way to avoid CTD. (image of Lua break on Line 262 in GroundTroops) Yes. (blush). Fixed. If you are interested in the fix right now, please replace line 262 in version 1.7.5 of Ground troops with this one: if not group:isExist() then I'm working on this, and the existing 'attackZone' attribute is a first attempt at this. However, I'm not at all impressed with my work here, and I'm looking for a better, more intuitive and flexible way to 'attract' groups to a zone. Since the entire GroundTroops module is slated for overhaul, this will have to wait, and I'm always open to suggestions ideas. Unfortunately, that's a DCS limitation. Orders can only be given to entire groups, not single units. Yes, and it is already implemented in GroundTroop's "Tie Breaker" functionality - but that only works with groups managed by GT. I think you are on to a great idea indeed, that I may need to flesh out later - a designated "auto-resolve combat zone" where one side wins if they achieve a significant advantage. Is that what you suggest? Cheers, -ch

Many people forget that building software is like building a house. Not every task can (nor should) be completed by a mason. Each task should ideally be done by the person most skilled to do this. So if a task calls for an electrician, it's not good to have the plumber do it, even if s/he can hack it. Methinks that many people with different skill sets are working on many modules. If a skill comes available, it gets assigned to the most important task; lower prio tasks are pushed back. It's an endless cycle of importance vs urgency. If the radio skill is required, but not available, that will block the A-10's progress. That's how software dev (and most other projects that require multiple skill sets) works. Let's hope the 10C's radio gets updated soon.

10 years from today? Undo in Mission Editor. Maybe also band-select/edit objects as a stretch goal.

Version 0.999 - 20220512 Feature Update: Changer, pulse, "lohi", "hilo" (not a Disney reference) One of the last releases before we go Full Monty, we now (finally) have the changer module that is a bit like the combination of duct tape and swiss army knife: a way to on-the-fly transmogrify a flag value, and provide a 'switched gate' to regulate the flow of information. The demo 'Gate and Switch' is there (fully documented) to illustrate that use. And finally, after much deliberation, the 'pulse' method and Watchflag counterpart 'lohi' have made it into DML. In conjunction with switched gates and the opportunities they allow in mission design, adding this advanced control method outweighed it's obvious drawback: complexity. Unlike other methods, a pulse isn't a one-time change of a flag value, but two: one to set, and - a few seconds later - a re-set. It's fully automatic, so there's no up-front cost to using it. Just be sure to understand how a pulsed flag works, or you may inadvertandly get two activations of your module instead of one (because, from DML's 'detect change' default behaviour, a pulse is *two* value changes of a flag rolled into one. So Caveat Emptor. Changes: Documentation - changer documentation - Pulse, lohi, hilo documentation - Gate and Switch documentation - Quick Reference: Changer Documentation Demos - Gate and Switch Modules - ALL MODULES - support for pulse bang! Method - support for 'lohi', 'hilo' Watchflag method - Changer 1.0.0 - cfxZones 2.7.8 - cloneZone 1.4.6 - unitZone 1.2.2 Enjoy, -ch