To apply: Unzip on the existing installation of CMO + "Tiny" update.
NOTE: This is a public beta. Standard disclaimers apply.
Build 1261.1 Release Notes (changes from B1260.1)
========================================================================
* NEW SIM FEATURE: Very coarse sim fidelity (aka "Double Flamer" mode): https://i.imgur.com/xP38CJn.png
When selected, the simulation engine uses a 5-second sim pulse. If weapons are in the air (either guided or unguided), the simulation automatically switches back to coarse (1-sec pulse) execution until the weapons are gone. This hybrid mode confers the scalability/performance benefits of a coarser sim pulse without sacrificing fidelity during weapon engagements.
* NEW SIM FEATURE: Cargo 2.0 - Containers and cargo-transfer mission (requires DB v495+). Summary description here: https://docs.google.com/document/d/1p4C ... ue&sd=true
* TWEAK: The dynamic noise values can now be enabled/disabled from the "Game Options" window.
* Fixed: On group fuel listings, Suppress units without fuel records
* Fixed: Group lead not being saved on scenario save
* Fixed: SetDoctrineWRA Bug prevents missile from auto firing
* ADDED: [Lua] Added command to allow transfer of mounts: ScenEdit_TransferMount(fromUnit As String, toUnit As String, mounts As LuaTable) <-- "mounts" has a to be list with the GUIDs of mounts to transfer
* ADDED: [Lua] Basic split/merge commands: ScenEdit_SplitUnit, ScenEdit_MergeUnits
* Fixed/Added: Extended Split/Merge feature to all mobile faciliies
* Fixed: Split/Merge of unit not accessible to player.
* FIXED: [B1260.1] Flights set to an AAW patrol mission seek fuel as soon as they launch
* TWEAK: Added Mission Editor window support for low-res monitors
* TWEAK: The checks for vertical/horizontal boresight weapon limits now provide better feedback
* Fixed: Slug trail RPs did not clear from the right RP render list, causing accumulation of RPs and potential large memory leak.
* FIXED: [B1147.45] F9 Group EMCON management sonar not working correctly
* Includes the v495 release of the DB3000 & CWDB databases, together with updated Tacview association files and numerous 3D-model additions courtesy of KJohnston.
DB3000 v495 changelog: https://drive.google.com/file/d/1pdNiYS ... sp=sharing
CWDB v495 changelog: https://drive.google.com/file/d/1pa28Aq ... sp=sharing
Ethan Hermanson on functional changes & additions in v495 DBs:
Though members of our team were out-of-office for part of the cycle supporting various Pro events, we’ve still managed to put together a release we hope you’ll enjoy. 495 includes over 500 new platforms between DB3K and CWDB (not counting over 700 new loadouts), and solutions to about 340 tickets from the public DB requests Github.
DB 495 also brings some new schema changes “under-the-hood.” Most of these support the continuing OODA overhaul we began in 494.
Aircraft Cockpit Generations
The flying equivalent to the “Combat System Generation” for ships, the “Cockpit Generation” is a way for us to approximate pilot load – and subsequently reaction times – based on cockpit design.
Aircraft can be assigned one of six cockpits: “Basic Instruments Only,” intended for the simplest aircraft; “Steam Gauges, ” as for WW2-era fighters; “Complex Steam Gauges,” for the nightmarish mid-Cold War fighters; “Partial Glass Cockpit,” for transitioning aircraft of the ‘70s-90s; “Glass Cockpit,” for most modern aircraft; or finally a “Panoramic Cockpit Display,” representing the new single-screen touch displays coming to a fifth-generation fighter near you.
Just as a ship is only as good as its CIC, your aircraft are only as good as their cockpits – and whether your pilots are forced to fiddle with a forest of knobs, switches, and dials or able to glance at an easy-to-read LCD will affect their performance. Of course, the difference between aircraft cockpit generations is far less than the difference between ship CS generations, measured in seconds rather than minutes.
But in a dogfight, seconds count.
Ergonomics
Not every aircraft built with steam gauges was equally difficult to fly; not every ship built in a certain decade could react with identical speed. Certain platforms gained a reputation for being especially easy to operate (the Viggen, for example, had a remarkably well-designed cockpit); others, like the Komar-class missile boat, were the bane of their operators. Much of this can be ascribed to ergonomics, the consideration (or lack thereof) of human factors in design.
The new “ergonomics” field – ranging from “Awful” to “Excellent” – is intended to reflect these intra-generation differences, acting as a sort of OODA “buff/debuff” and giving the ability to adjust values to reflect upgrades, etc. without needing to take the drastic step of upgrading the combat generation.
And, of course, you still have proficiency in the mix. Players now have an interesting mix of factors to consider:
- "Tech generation," e.g. CS/cockpit generation: when was your platform designed/built, and what sort of tech was in play at the time? Are you working with ancient WW2 plotting boards or Aegis?
- Usability/ergonomics/design: are you working with beautiful, top-of-the-line COTS human interface tech or the nightmare that was mid/late-Cold War Soviet systems?
- Proficiency: Do you have well-trained, well-rested/motivated crews, or are you dealing with bottom-of-the-barrel conscripts?
Those three factors will all have to play into your operational planning.
Definable Sensor Arcs and Vertical Scan Limits
495 also sees a small but important improvement to our sensor modelling: at last, sensor arcs can be defined in degrees, rather than in set sectors! We’ve also implemented vertical sensor arcs, which were especially important during the Cold War. Older air-to-air radars were often limited to a small chunk of vertical space (20 degrees or so), which meant that fighters would struggle to detect aircraft far below or above them. For air planners, this meant “Low CAPs” and “High CAPs” were necessary. Soon you too will have to consider altitude in your CAP coverage.
(Note that v495 does not have vertical sensor arc data backfilled, so this won’t have an immediate effect on gameplay until we can do a bit more research. Expect to see an RFI in the public Github for arcs and scan limits.)
Unmanned Autonomy Levels
Though still a work-in-progress and not yet supported sim-side, 495 also includes early work on “Unmanned Autonomy Levels” for UAVs. Essentially, this is intended to define the capabilities of a UAV when communications are disrupted. Some UAVs, nothing more than remotely controlled aircraft, will on loss of signal become “ghost planes,” flying off on their last heading until eventually crashing. Some can self-recover, i.e. search for a new signal and return to base if reconnection proves impossible. Newer UAVs are proving increasingly more autonomous, able to complete their last orders, self-analyze their ability to continue, work together, or even “think” for themselves. Once this is implemented, jamming drones will have platform-specific consequences beyond simply losing communications: some drones will crash immediately, while others may go off and hunt down John Connor.
