1,500 new sounds:
More new sounds for the American, Polish,Italian,British,German and Russian infantry and more new sounds death
More ricochets / penetrations / impacts / explosions / zips/incoming artillery/hits/ricochets
Improved ambient sounds
Italian ambinet (unpack and raplace Z/HQS2.6/background )
Improved small arms
and of course lots of other fixes and improvements
We are pleased to announce that we have completed the first version of the X-Cam-Taunus map. This version is around 95% completed and we want to release the final version later this year.
We would like to thank everyone who helped us with more or less work and knowledge and we hope that the Arma community will enjoy the beautiful places we’ve created. We also want to thank Bohemia Interactive for providing such a great game with the possibilities to built a map like Taunus, even that we have placed 99,99% of all objects with X-Cam 😉
Object count is 5.658.123
Map size is 20480×20480 m
Grid size is 4096 cells
Cell size is 5 m
Sat/Mask size is 10240 m
Citys and Villages 34
– No dust on all surfaces
– Some flickering textures
– Some missplaced objects
– Some unfinished areas
– Some zones with wrong sat and mask settings
There has been a question about Command’s mine warfare model on the forum so we would like to cover our mine model in more detail than the current manual covers.
To start it’s a good idea to have a little background on what naval mines are how they are detected and neutralized. If you’re not familiar there are some really great resources online that do a good job explaining the basics. Please do give these a good read if you’re unfamiliar with the concepts.
Now how does CMANO model mines, mine deployment, mine strikes, mine detection, and mine neutralization?
Mines in the database
CMANO eschews the traditional “minefield area with % chance to stumble on one” wargaming model and instead treats mines as discrete individual objects (yes, that means you can have thousands of them in a scenario. The sim engine can take it.). Let’s take a look at the general mine categories currently modelled in Command:
Bottom Mine. As the name implies, laid on the sea bottom. These are quite hard to pick on sonar and (if they are properly camouflaged) even with visual cameras. They can be used only in relatively shallow waters (if they are laid deep, when they detonate their explosive shock will dissipate until it reaches the surface).
Moored Mine. These are deliberately filled with some light material to provide them with positive buoyancy and then anchored to the bottom, suspended in mid-water. Because of this they can be laid in deeper waters than bottom mines. They are, however, easier to detect and neutralize.
Floating/drifting Mine. These float on the surface. They can be spotted and neutralized more easily than other types.
Moving/Mobile Mine. These are often converted torpedoes, fired from standoff range by ships or submarines, traversing a distance before settling on the bottom.
Rising Mine. These nasty weapons are either bottom-lying or moored, and instead of an explosive warhead their payload is a homing torpedo or rocket. When they detect a suitable target, the payload is launched and homes on the target independently.
Dummy mine. A fake mine, meant to delay counter-mine operations.
The mine attributes listed in the database include fuse types (magnetic, passive acoustic, pressure, seismic), arming delays, different warhead explosives and properties etc. Some of these attributes are not currently used (for example target discrimination is currently listed but not actually used in code) but have been included nevertheless for future revisions to the model. We’ve also provided generic examples of each major type in the database and in case where we’ve found detailed information on real life mines we’ve added them.
Deployment: Pre-fab and in-game
Mines can be deployed in any water area that meets the depth requirements for the mine. You can find these depth requirements in the database viewer or, if using the scenario editor to add a minefield, in the drop down select menu next to the mines name.
Mines are deployable in CMANO in two ways.
The first way is via the mining mission in the mission editor in either game or editor mode during gameplay by an air, sea or subsurface unit. You can create a mission by first defining an area by dropping some reference points, then selecting them and finally creating a Mining mission. This will open the mission editor allowing you to modify the mission parameters and if the mine type supports it an option to add arming delays for fields you want to activate later. Once a unit is assigned it will launch and drop mines about 400 meters apart in random lines dispersed in your defined area.
Here is an example of laying mines via a mission:
Things to note:
Multiple assets of different type can be used for the mining mission. In this example we are using the Iran Ajr in combination with a squadron of B-52Hs based at Bandar Abbas. (Yes, “Red” would not normally have access to B-52s but the Buff is as good a mining demonstrator as any. Cope!). To ensure the bombers have enough mines to sow, we are adding 10.000 Quickstrike mines to the base’s stocks. Submarines can also be used in the same manner.
One of the most useful custom options for the mining mission is arming delay. This can range from 1 second up to years. This can help significantly in preventing the assigned forces from literally mining themselves into a corner. This can happen both in real life and in Command, but the delay option makes it far less likely. It also adds an extra element of uncertainty for third-party observers (“can I pass through that area before the mines are armed?”). In this example the delay is 1 hour, and every sown mine has a visible timer indicating the countdown to being armed.
The laying pattern is highly irregular and very rarely are 3 mines laid in a straight line. This is deliberate, as it prevents the enemy from discovering a few mines and then using their regular pattern to determine the locations of the rest. It does of course mean an uneven distribution of the mines and the possible presence of gaps in the coverage, but with enough density this is acceptable.
If you ever want to add a mine rack to a surface or submarine unit you can do so. We have added a number of mine rack type weapons records which you can add to any mount. Many combatants actually have mine racks in real life (Chinese FF, Soviet Destroyers) but aren’t filled or used unless specifically tasked.
The second way to deploy mines is there is a function in the game editor. To do so simply drop some reference points to define an area and select them. Next, go the editor dropdown menu, select minefields and then create minefields in designated area. A dialog will then appear allowing you to pick the mine you’d like and number. The editor will then do its best to randomly disperse mines in the area you’ve chosen with the correct depth requirements.
Mine strikes are resolved in the game as follows. Once a ship or submarine reaches a certain distance from the mine a calculation is made to see if the mine is armed and triggered. If so then the mine explodes or the payload is released. If it is an explosion than our CEP modeled is leveraged and damage is applied accordingly. If it’s a payload the torpedo hit is calculated like any other torpedo and if it’s a rocket munition it will be resolved using CEP on its own. Keep in mind that any unit in range of the explosion could take damage. This includes mine hunting UUVs and RMVs that could be destroyed as well as minesweepers themselves. This could also occur during mine neutralization involving explosives or a failed attempt.
Here is an example:
A small USN amphibious group (an Essex LHD and a Mars replenishment ship, escorted by a Ticonderoga cruiser and a Burke destroyer) is about to enter the Hormuz straits in order to transit to the Persian Gulf. Unknown to them, we are laying a pre-made minefield using the scenario editor. We are laying approximately 500 mines, half of them moored and the other half floating ones. Despite stumbling on some of the mines and setting them off, the group crosses the minefield seemingly intact – however, close examination of the ships’ damage reports reveals that most of them have suffered substantial hull damage and many of their critical systems have been damaged or destroyed; the group is thus now a significantly easier target for follow-up attacks or may even have to abandon its mission altogether.
Several things to note:
Each mine category (and indeed in most cases each individual mine type) has its own operating depth restrictions. This, combined with the fact that most seabeds are non-uniform in their depth, means that laying a single-type minefield is frequently impractical. A multiple-type minefield is both easier to lay and tougher for an adversary to sweep.
Most modern mines follow a two-step arming & detonation logic: First the detection of an incoming valid target “wakes up” the mine, and only when the distance to the target opens (ie. the target is passing its nearest point relative to the mine, almost certainly beam-on) the warhead detonates. This protects the mine against simple “prodding” sweeps, retains the element of surprise and ensures the maximum damage to the target. Command models this faithfully.
If the mine happens to be right under the target, its destructive potential is magnified because of the “gas bubble” effect; under ideal circumstances the mine can even literally break the ship’s back (similar to an under-keel torpedo detonation).
Mines are very cost-efficient and, if properly used, a tremendously effective naval weapon. It is illustrative that they have damaged and sunk more ships than any other weapon since WW2. So how does one counter them?
Mine detection varies based on the type of mine and technology used to detect them. Floating mines can be detected visually with the constraints of time of day and weather. All mines can be detected using mine hunting sonar. We do mark them as such within the database so you can use the database viewer to see what kind of sonar or gear a unit has. In general, bottom and moving mines are the most difficult to detect followed by floating and then moored and rising.
Sweeping is the most common countermeasure. Basically the sweeper is trying to prematurely trigger the mine so that it detonates (or releases its payload) while friendly forces are at a safe distance. Mine-sweeping gear is included under the sensor grouping in the CMANO database. All sonar detection is impacted by range of the unit and speed of the host unit and all mechanical gear is constrained by speed of the host vessel and usable depth of the equipment. Keep in mind all sweeping equipment has width, depth and speed constraints (ex. Mechanical sweep can sweep down to -70m to -10m at 8 knts.). If you zoom in on any unit with sweeping gear the sweeping arc is visible behind the unit.
Let’s look at an example of sweep operations:
“Red” has created a mine barrier on the entrance to the straits of Hormuz, and side “Blue” has to neutralize it by clearing at least part of it to create a safe transit lane. Blue has access to two Avenger-class and one Osprey-class mine-warfare ships (MCM), plus a dozen MH-53E Sea Dragon helicopters at nearby airfield “Base 1”, fitted with the Mk105 mine-countermeasures equipment.
First, we take a peek “behind the scenes” by briefly enabling “God’s Eye” view, to see what Blue is up against. The minefield looks pretty thick (around 3000-4000 mines). Normally Blue does not have access to this information.
Switching back to normal view, we define an area for the safe transit corridor we want to open. Using the created reference points, we create a new mine-clearing mission and assign all available assets to it, enabling the 1/3rd rule (more on this later). Then we sit back and watch them get to work: The ships activate their HF sonars and plot a course towards the area, and some of the helicopters begin their air ops procedures for taking off. This is going to take a while, so time acceleration is widely used.
Zooming on the MCM ships and helicopters shows their mine-sweep coverage (the blue triangles). Once one or more mines are detected, the vessels maneuver in such a way as to place the target mine inside this coverage area in order to trigger it. (The odds of this happening depend on the tech levels of the sweep gear and the mine being prodded; an old mine is much easier to sweep with modern equipment and vice-versa). If no mines are detected the units will still patrol inside the designated area, aiming to set-off undetected mines (hopefully without being damaged by them).
Helicopters are much more efficient than ships at sweeps against detected mines thanks to their speed (and reduced vulnerability) but are less effective at detecting the mines in the first place. Ships on the other hand have the sensors suitable for detecting mines en-masse but are less effective at clearing them, and more vulnerable. As is obvious in this example, ships and helicopters are most effective in this mission when cooperating to maximize their strengths.
All ships (including MCMs) try as much as possible to avoid passing too close to detected mines (the pathfinding code takes known mines into account when plotting a course). The “minimum safe distance” is estimated based on the ship’s own signature characteristics (magnetic, noise etc.) and whatever information is available about the mine contact. Smaller ships have a smaller keep-out distance and MCM ships have a big advantage thanks to their special signature-suppression techniques (non-metallic hulls & structure, enhanced degaussing, low-noise motors, reduced pressure etc.). This enables them to maneuver much closer to mines than other ship types in order to sweep or hunt them.
Despite these measures however, all 3 ships progressively suffer blast damage. (MCM vessels are designed with the assumption that they will suffer multiple proximity blasts during their lifetime, much more intense than for frontline warships). Even the best MCM ships are vulnerable to this; during the mine-clearing operations off Inchon in 1950, multiple MCM ships and destroyers were lost. Normally the ships withdraw after a certain damage threshold and return to a tender or naval base for repairs, rotating with others.
Midway through the operation one of the helicopters is destroyed by fragments from a surface mine detonation. This is not a bug; helicopters occasionally do get damaged or lost while detonating nearby mines (the USN lost two helicopters this way while clearing the Haiphong harbor in 1973). One of the upcoming new features of Command is gradual aircraft damage; this will enable sending the half-damaged helo home for repairs instead of permanently losing it.
At 8:53 we enter the mission editor and deactivate the mission’s “1/3rd rule”. This option dictates that hosted aircraft & ships will depart for their missions in 1/3 increments rather than all together, in order to rotate and thus provide continuous coverage of the patrol/mission area. Disabling this option allows us to perform a “surge”: All available assets tasked to the mission are immediately launched, providing temporarily a significant increase of on-station assets at the cost of reduced coverage in the long term. This is one of the typical trade-off decisions that the player must make.
Different sweeping gear types have different probabilities of setting off a given mine, based on the fuse type involved and the technological level. Old equipment can only get you so far!
Towards the end of the video, we pause the scenario and activate “God’s Eye” once more, to witness if the sweep team has made a difference. As can be seen, a very obvious dent has been made on the mine barrier; there is still much work, but the safe-transit corridor is beginning to take form. There is also something else noteworthy: Some mines close to the sweep team have not been detected at all. Such is the uncertain nature of mine operations.
This example was presented under favorable conditions for the sweep team: No unsweepable mines were included, and these do exist. Other mine types can be swept but are really hard to detect in the first place. Sweeping in general is efficient but bound to miss some here and there; a hard proposition for the forces that have to pass through the supposedly sanitized area. Thus sweeping is typically complemented by active mine-hunting operations.
Compared to sweeps, hunting mines is extremely tedious and inefficient (it is sometimes described as the difference between using a lawnmower and cutting individual grass leaves one at a time); however, it is sometimes the only way to deal with sophisticated mines that ignore sweeping countermeasures.
CMANO includes a range of equipment types to neutralize mines in the game which gives players a range of options with different degrees of success. The equipment is deployed on traditional minelayers, aircraft, UUV, USV and RMVs and includes: divers with explosive charges; explosive charges hosted on units (killer type ROV/USV), moored mine and mechanical cable cutters (moored mine only) etc. Divers with explosive have the best probability of success, followed by explosive charges and all other equipment after.
Let’s look at an example mine-hunting operation:
In this video we present a typical mine-hunting scenario taking place inside the Persian Gulf. The Scout and Gladiator, two Avenger-class MCM vessels team up with The Sullivans, an Arleigh Burke-class destroyer and the Canadian frigate Halifax. The Avengers are the main mine-hunting force while the warships are screening them against any attacks. To hunt the mines, the Avengers are carrying SLQ-48 and Remus-600 tethered remote-operated vehicles (ROVs); these undertake the brunt of the mine neutralization process so that the ships stay (mostly) out of harm’s way. The Sullivans is also aiding the mine search by carrying and deploying a WLD-1 autonomous ROV.
At some point during the mine hunt, the force has to deal with some surprises. Things don’t always go as planned!
Delegating: The mine-clearing mission
CMANO provides a mine clearing mission within the mission editor. You create it by dropping some reference points, selecting them, selecting new mission from the Reference Point and Missions drop down and then add the units you’d like in the mission editor. The third rule is available for aircraft and ROVs. ROVs never appear in the mission editor but are added to the mission when their host unit is.
To effectively hunt mines in the game it is important to evaluate the constraints of the threat and the capabilities of your equipment.
The ocean is a big place and your ability to successful search any great swath of it for mines is pretty low even with the best gear. It is best to constrain your searches to areas that have the depth characteristics to contain mines and that the forces you are trying to protect might actually transit. Anything larger is a waste of time and resources. You may even consider rerouting transiting forces instead of trying to sweep lanes. It’s a strange game but the only winning move may be to not play.
Evaluating the mine hunting equipment you have is critical. Please do take a look at your order of battle and use the database viewer to see what units you have, the equipment they carry and evaluate their capabilities when developing a strategy.
Here are things we think you should consider and take note when make your decisions.
Traditional minesweeping ships are vulnerable even when successful at doing their job because depending on the size of a mine’s warhead it is likely the minesweeper will take points damage with any detonation from sweeping. We have coded in some things to reflect some of the design features to minimize this but it will happen and your ships have a limit as to how many close order detonations they can take.
Aircraft are preferable over ships because the likelihood of them being destroyed or damaged during sweeping is lower. Likewise UUV’s are somewhat more expendable and their losses hurt a little less than a mothership.
Many modern minesweepers act more as motherships for UUV or USV’s that sweep so it may be best to keep them out of the mine zones themselves thus only assign the UUV’s or aircraft to the mission.
Consider hunter-killer pairings. Aircraft and UUV/USV may have payload constraints so please review loads to make sure you actually have units that can detect and units that can kill mines. If it’s the case that a loadout can do one or the other please do assign both types.
Keep in mind the difference between a ROV and UUV. ROV equipment is tethered to the mothership. When a mothership is assigned to a mission all hosted ROV units will be assigned as well and launch once in the patrol zone or if a killer type once the mothership detects a mine. Keep in mind the tethers have a limited range which will constrain how far the ROV can travel from the mother ship and also means the mothership may have no choice but to move into the mined zone. On the other hand UUV and USV units are independent units that can be assigned directly to a mission within the mission editor. This is modeled this way to reflect their independent nature and lets the mothership standoff.
Do not create massive search areas when creating mine clearing missions. The patrol paths are random and the larger the area the more dispersed they are. Try to create search boxes smaller than 40 nautical miles (even smaller if just sweeping a lane) for best results and then create new ones or move the existing reference points to move ahead and shift the search area. If you don’t like a current plot you can just hit F3 for a new one.
If mines are smaller larger ships could be used to sweep with their own structures. You run an absolute risk of losing those ships but it’s a valid strategy that was utilized during the Iran/Iraq war.
We hope we’ve covered most of the basic questions about how the game models mine warfare and provided enough information for you to devise your own strategies. Please do feel free to contact us with any further questions!
Chernobyl Exclusion Zone is an area with controlled possibility of entry and residence on grounds of radioactive contamination caused by the Chernobyl accident in 1986. It is located on the territory of Kiev and Zhitomir regions of Ukraine and on its northern border with Polesie state radioecological reserve in Belarus.
The Zone is divided into two parts, an inner diameter of 10 km and an external 30 km from the accident site. The inner zone are allowed only employees of the plant, scientists and also limited permission participants of excursions. Into the outer zone has been slowly at their own risk and people returned voluntarily earlier evictions during the evacuation. These people rather a higher age receive from the state contribution for the purchase and importation of safe water and food grown outside the zone.
Map is created by real Chernobyl Zone. Objects are imported from great game series S.T.A.L.K.E.R. Map will not have locations like Stalker, e.g. Cordon, etc…
I’m making map in my free time and alone, so development is slow. Please report issues and errors there: https://a3chz.blogspot.cz/p/feedback.html
Today bis released 64bit executables for ArmA 3 in its DevBranch.
In recent years, a growing number of developers have released their games with 64-bit support. Many of our own community have hoped or suspected that, sooner or later, this simply had to happen to our beloved series as well. To bring an end to the eternal discussion about whether it is (im)possible to bring 64-bit support to Arma – and to live up to your hopes – we are proud to announce that 64-bit Arma 3 is knocking right at your door, now released on Dev-Branch. But what exactly are the benefits of having a 64-bit game, what does it mean for you as gamers, and why did you have to wait until now?
A bit of wait
Somewhere on the forums one of our loyal community members wrote “there is no simple ‘click a button’ and it magically becomes 64-bit.” That is very true. We currently employ no mages, so we had to improvise and hit those buttons a few (tens of thousands) times. Porting a project which had not been designed with 64-bit in mind is no easy task; with a code base as huge as Arma’s, it is doubly true. Other than Arma itself, we had to update our Launcher , too (thanks to that, you will now be able to choose your version of the game splendidly).
One of the main reasons for the delay is that the time simply had to be right for us. 64-bit executables need a 64-bit OS and 64-bit CPU to run. If there are not enough users with such systems, there would be only little reason for us to invest time and experts into working on something this big. Fortunately, the last few generations of processors have been 64-bit. Therefore, it comes down to your OS. According to Steam statistics, over 90% of player machines now have a 64-bit OS installed.
Naturally, it is not all only about programming. In order to make this effort a reality, different departments had to do their part as well. More than anything else, testing has been a huge part of the porting process, taking a lot of time. It is no wonder. There were hundreds of obstacles we had to overcome, some smaller, other greater, and our QA colleagues needed to verify that everything still worked as expected after all these changes. In the end, we feel we succeeded to tame the beast – and we hope you will be just as excited about the results.
A bit of background
In order to understand what this magical number means, we need to get technical. We will keep it as concise as possible (of course, at the expense of accuracy, for which we kindly hope anyone technically gifted will excuse us). When processing tasks, your CPU works with data stored somewhere in memory. This memory can be local to the CPU (registers, cache) or external (system memory aka RAM). What interests us the most right now are registers and system memory.
In general, registers are very small and very fast data containers. They come in various forms and sizes ranging from 8 to 64-bits. The amount of bits determines the largest number a CPU can process without any extra work. 32-bit processors can work with numbers as large as 2^32-1=4,294,967,295 (-1 because we start from zero). 64-bit processors take it a few billion steps further and stop at an amazing 2^64-1=18,446,744,073,709,551,615. This comes quite handy when performing complex calculations and addressing memory.
Speaking of memory, let us translate these huge numbers to something more understandable. In the vocabulary of computer memory, 2^32 can be translated to 4 gigabytes while 2^64 equals to 65 petabytes. In simplistic terms, a 32-bit system can physically address at most 4 GB of memory. On top of that, the address space of a 32-bit application running on such a system is usually split in two parts. On Windows, each of them is 2 GB. One is reserved for your applications, the other one for Windows itself.
A bit more memory
Now imagine you have to squeeze Arma – with all of its large terrains and many things going on during a mission – into this relatively small space. As time passed, and as Arma grew larger, this has proven to be a more and more difficult task. Being able to utilize virtually all of your system’s memory, more than anything, Arma should show a lot more consistent performance.
With the ability to cache a huge amount of data in-game, less loading/releasing of memory is necessary. This translates into less work for the game to do and, ultimately, into more fluent gameplay. One case where an update in performance should be more recognizable is when playing the game with very large view distances. Given that the amount of data to cache is rather large in such cases, the game will greatly benefit from an increased amount of available RAM (but, note, it may be bottlenecked by other factors).
An important side effect of having larger address space is that we expect fewer memory-related crashes to happen. With no free memory, sooner or later the game (or any other application for that matter) is bound to reach a state where it simply has no other choice but to cause us all sorrow. Memory limits are set in stone; whether a crash is caused by a GPU driver or Arma itself does not really matter from a player’s point of view. Trust us, there is nothing more painful then seeing you sad because the game crashed. In 64-bit Arma, this should be less likely.
A bit of caution
Do not expect a 64-bit executable to be a golden bullet, though. Rather than quadrupling your FPS, consider this an important optimization for cases where 32-bit Arma can no longer ‘keep up’. If you never experienced sudden performance drops, you are unlikely to notice any difference at all. However, if you did, this new version of Arma should make your experience even more splendid than ever.
For modders, too, there are some things to keep in mind. If your scenario or mod uses a call extension, the extension has be to provided both in 32-bit and 64-bit versions now. Otherwise, your game will most likely not work as expected. Unfortunately, there is no flexible way for us to work this around for you behind the scenes. 64-bit processes can only load 64-bit shared libraries (*.dll on Windows, *.so on Linux) and therefore it is expected that content creators provide them. This process should be rather straightforward, though, and we do not expect any major complication on our talented community’s side.
To make the transition as transparent for you as possible, we at least made it so that no changes to scripts will be required. All you need to do is build a 64-bit version of your extension and name it _x64.dll on Windows (or _x64.so on Linux). In other words, you add the “_x64” suffix to the name. Similarly, mod creators relying on hacking repurposing DirectX libraries will have to dust off their skills once again and perform their magic on 64-bit version of these libraries in similar a fashion as they did on their 32-bit counterparts back in the day. Of course, it is also worth mentioning that you should not forget to whitelist your new libraries with BattlEye!
A bit of feedback
Before we summon the courage to release the 64-bit exe to the wider public, we first need to gather enough feedback on how well it works outside the company walls. As confident as we are about the new exe’s performance and stability, it is a rule of thumb that things impossible to happen in theory are bound to happen 50% of the time in practice. Therefore, to deliver the best possible Arma experience, we would like to kindly ask you for your feedback on the forums.
However, although it is true the support for 64-bit has yet to hit our Main Branch, we decided to give you all at least something as a small appetizer. Starting with Update 1.66, when run on 64-bit Windows, 32-bit Arma 3 will be able to effectively work with more than just 2 GB of memory. The current limit has been increased to 3 GB. Magic, yay!
As always, we thank you all for your wonderful support over the years and are looking forward to all your observations and suggestions on this next big step in Arma’s history. Have a great time playing the game and may the 64-bits be with you!
Elite Dangerous v2.2.03 Beta is live with a new game launcher!
Fix for a crash when dropping from orbit at Eafots LZ-H b10-0 D 1
Crash fix for a rare case when hyperspacing out of a system that turns into an invalid state en route
Fix for outfitting crash when receiving a web response without a ship loadout in it
Fix a crash in the PlayerPOISpawner if the closest planet in the planet surface manager hasn’t been found yet
Softlock loading in to a persistent POI in multiplayer situation fixed
Xbox One: Fixed low level cockpit GUI crash
Allow a mini USS bubble around Colonia
Fix transaction server error when clearing a save that had lots of exploration data
Reboot-repair now Bump-starts shields when it completes, reducing downtime waiting for them to return. Could also be used in other cases when the player is willing to accept the risk of being idle and defenceless for the duration to focus power on their shields
Shield restore from Reboot/Repair now requires you to be near stationary or it will fail (to prevent in-combat overuse), 50m/s threshold
If saving or autosaving while in supercruise, move the player well clear of star Jet Cones. You shouldn’t ever reload back in after a hyperspace failure stuck in the cones anymore. Note that if you save/log out while in normal space, you will still be in the cone on your return, this safety check can’t be used to escape once you’ve already made a mistake, it’s just covering for failures that aren’t the player’s fault
Added a warning message when a non-flown ship is being scanned
Fixed “Ship scan detected” warning not always appearing
Fix for NPC voice volume slider not working in the audio options
Wings matchmaking improvements
Allow Reload time in Outfitting to be shown to the nearest 1 decimal place rather than rounded to whole seconds
Added some system metadata for the five starsystems holding refuelling bases between the Sol bubble and Colonia
Crew rank does not update on the contacts or ship GUI after ranking up fixed
Fixed missing cyrillic glyphs in module and systems panel
Avoid tinting weapon impacts on environmental surfaces
Fix for the POIs getting stuck loading due to the ReplicatedLevelContainer not activating its advance phase
Allow Reload time in Outfitting to be shown to the nearest 1 decimal place rather than rounded to whole seconds
Don’t clear legal state after a cargo scan! This will make the cockpit “Wanted” warning vanish!
Warning message now appears when player scans fighter or mothership with Kill warrant or Manifest scanner
Fixed a rare cause of triggering the ship rebuy screen when docking an SRV at a planet base
Fixed outfitting with multiple purchases of bobbleheads
Xbox One: Don’t show nameless scoreboard entries. If we have data for a player without a name, then don’t add it to the score summary
Xbox One: Where we have axis bindings, unhide the +/
button bindings so they can be rebound. Also make all flight control axes invertible
Xbox One: Don’t handle a protocol activation if we’re resetting or disconnecting. This means if we accept one while suspended, we won’t process it until we’ve gone through a full reset and reconnected, at which point we should be able to safely join the session
Added passenger seating allocation to allow passengers to be assigned outside of mission board
Added a new mission type for investigating the ancient ruins
Make supply to demand overrides take max distance into account (Stops Colonia making missions which intend to only go 500ly into missions to pop back to the bubble with a ~24 time limit)
Reduce number of missions sent to clients as we’re only sending relevant missions now
Increased maximum mission duration to 28 days
Fix elite rank point calculations from missions so that they are a % of any mission profit earned
Link Gimbal weapon tracking to the sensitivity of ship sensors. Does not affect CQC/Fighters/Non-main-ships
Rather than permanently disabling guidance on torpedoes, it now scrambles them for a short time (randomly between 2 and 8 seconds), after which they will re-acquire a lock and turn back in to engage
Emissive Munitions duration reduced to 30% of what it was, and capped much shorter for missiles
Emissive Munitions Scale reduced vastly, it will still guarantee visibility but no longer maxes out gimbal tracking at all ranges
Feedback Cascade no longer provides a fixed 90% reduction to healing, instead each hit reduces the healing rate by an amount proportional to damage capped at -90% as before. Exact number of hits to reach the cap varies based on size of weapon and shield cell, but will typically be 2-3 (requiring either high skill or multiple railguns) and up to 5 for smaller weapons against size 8 cell banks
Fixed multicannon Clips increased to 100 (from 90)
Fixed/gimbal multicannon reload times adjusted for consistency (generally buffed), fixed are now 4s, gimballed 5s (from an inconsistent 4s/5s mix)
Fixed cannon clip size increased to 6 (from 5)
Fixed cannon reload time reduced to 3 (from 4)
Fixed cannon ammo reserve size increased to 120 (from 100)
All fixed pulse/burst/beam weapons have 10% reduced WEP drain
Gimbal/Turret cannon damage increased by 15%
Fixed cannon damage increased by 25%
Plasma Accelerator reload times reuced to 6s (from 8)
Plasma Accelerator damage increased by 10%
Plasma Accelerators now deal Absolute damage
Reactor power draw for beams reduced 10%
WEP draw of burst lasers reduced by 15% (on top of fixed weapons as mentioned earlier)
Slugshot Armour piercing reduced to 15/25/35 for Small/Med/Large (from 20/35/52)
Slugshot reload time reduced to 2.5s (from 5s)
Slugshot ammo reserve doubled (to 180 from 90)
When scaling Weapon Range up in an engineered recipe , we now display that the projectile speed has increased
When scaling Weapon Range down in an engineered recipe, we no longer scale down the Damage Falloff start, nor the projectile speed
Clip size modifications now always round the clip up to avoid overly punishing small-clip weapons, and the modifier is not shown if it will have no effect
Increase damage buff for Short Range to 45% (+5%) so that it is competitive with Overcharged and Rapid fire for raw damage,but with different tradeoffs
Powerplay consolidation feature added
Powerplay assassins removed
Powerplay pirates no longer spawn in exploited systems
Powerplay pirates must align with an opposing superpower to that of the controlling power
When a crime worthy of an authority response is committed between two ships (NPC or player) who are each pledged to a power, effectively reduce the security level of the system for the purposes of considering strength of response and delay
Power security and pirate ships must now scan for powerplay vouchers, to check for powerplay cargo, and concerning which powers will get involved based on the player’s power
Power Security NPCs attack ships of opposing powers (different major faction) if they are locally wanted, they have powerplay vouchers issued by the controlling power of the system, or are carrying any powerplay commodity relevant to the controlling power of the system. They can not be appeased with cargo drops
PowersPirate NPCs attack ships of the same power as the controlling power of the system if they are wanted, carrying any powerplay vouchers, or carrying any powerplay cargo (any power). They can be appeased by cargo drops as long as the attack was due to cargo, not bounty or vouchers
Ships not meeting these criteria will be left alone, even if pledged to a power
New chatter lines added to support changed behavious
Ensure PowersSecurity ships are given an FSD interdictor by the auto-loadout system
Updating the balance on AI ambient power play ships, as well as tweaking some of Famine and Outbreak AI ships
When Opposing Control or Undermining a hostile power, vouchers will only be issued when destroying NPC ships from the defending power
Cargo used for Opposing Control or Undermining a friendly power will now only count for 1 merit when delivered
Voting for logistics consolidation becomes available at Rank 2 after supporting a power for 4 weeks. The number of votes increases to 5 after supporting a power for 16 weeks
Replaced the 18 second threaten timer on PowersSecurity ships with a 2 second one (they appeared to be broken right after scanning, which was undesirable behaviour). Also adjusted standard Bounty Hunter AI to be the same
Auto loader improved and ammo penalty removed
Concordant sequence regeneration amount doubled and lasts twice as long
Dispersal field damage penalty removed
Overload Munitions ammo capacity penalty removed
Smart rounds flight time penalty removed
Overcharged and Efficient Blueprints now available for Beam weapons
More improvements to restocking weapons with engineer modifications
Ensure the latest version of recipe ingredients are used when crafting, regardless of how long ago a recipe was pinned
Automatically update modified modules to the latest version of the recipe
Fixed firing on fighters launched from already scanned ships counting as a crime
Don’t spawn more escorts each time we transfer authority to a new authority
Tweaks to make NPCs less effective against silent running
NPCs should’t always be so accurate with rail guns
Wanted NPC has clean fighter fixed
Balance pass for AI interdiction ability, to make it slightly easier
Removed wreckage and salvage from tourist beacon USSs
Fixed some broken uplink messages
Improved atmosphere description in player journal
Added “Target” property in player journal when recording a kill
Fixed json syntax for Interdiction event
Fix for getting the correct faction when docking at a station (to write into the journal)
When a ship/slf takes damage, the journal entry now includes whether it’s the ship or fighter, and whether the player is the pilot
Added a journal entry when gaining Federation or Empire rank
Elite Dangerous v2.2.03 Beta starts Dec 7th, 2016!
The update will focus on three main things:
– Powerplay adjustments, Changes to how AI react to players in Powerplay
– Engineer Changes: Balancing tweaks to promote greater variety in recipe use and smooth over a few problems, focussed on combat related blueprints for this pass.
– Combat Balancing: Changes to existing weapons to enable greater choice in how players can effectively choose and outfit their ships for combat.