Oolite Bulletins

JazHaz wrote:

[*]Ranges we're talking about is everywhere between metres to tens of kilometres (unlikely to be able to push that out further despite our best wishes)

cim wrote:

Mike Evans wrote:

• Ranges we're talking about is everywhere between metres to tens of kilometres (unlikely to be able to push that out further despite our best wishes)

This is interesting, then: the bigger ships may well be detectable visually long before scanning can pick them up. The cruisers should be visually detectable out to several hundred kilometres, for example. Even the bigger freighters I'd expect to be able to see (as a pixel or two) at ranges in the upper "tens of kilometres".

cim wrote:

bigger ships may well be detectable visually long before scanning can pick them up.

cim wrote:

Which gives an interesting scan method: parallax scanning. Scan a direction; move a kilometre or two sideways; scan again.

Tom Kewell wrote:

Hello DDFers!
It's Friday and time for an update on Injected Events!

INJECTED EVENTS
Injected Events allow Frontier to inject situations into the Elite: Dangerous galaxy, allowing us to be reactive to player habits and actions, and to influence and direct the community of players.

GOALS

• Create large scale events for all players to enjoy within the ED universe, outside the scope of the background sim.
• Use player influences and system data from within the galaxy to feed into a meta-game system.
• Provide story and content for missions and other environmental encounters.

Injected events rely on a number of systems and information:

• Background simulation – The background simulation manages changes to a systems status, based on player actions, nearby systems, events, and injected events
• Faction information – every faction will have status information, including relationships with other factions, assets owned, Government types, local specialisations & NPC hierarchy.
• System Information – Assets within a system are listed here as they are discovered. Discovery of new assets within a system may trigger different faction behaviours. Injected events may require, or create certain assets in a system
• Player influence – players will be able to influence a star system or faction through many different avenues (see Player Influence below).

This information will be held & controlled by the meta-game, and then used by the developers to create these larger events and happenings. The idea is to create injected events that are relevant to the situation.

In the future, we would hope to create a system that maintains a semi-autonomous approach to this, creating these events without the need for developer interaction, but also still allowing the team to inject separately.

META GAME
The entire system will be based off of rules dictated by a meta-game system, which will look at each location and calculate a set of factors by which an injected event can best be initiated. What this will mean is taking the influencing factors mentioned above and seeing where events would be best placed.

For example:

• A colony with a large population, nearby to a newly found, uninhabited Earth-like world might colonise that planet. A colony suffering from famine or being under-populated would not.
• A star system with low wealth, low development or low standard of living levels would be more likely to suffer from pandemics, famines, governmental collapse and other serious planetary failures.
• Star systems that are contested by 2 opposing forces may suffer from war, be it civil or between factions.

This shouldn’t stop the developers from injecting more random events, such as extinction level asteroid collisions or alien influences if the need arises. Its function is to create relevance and a sense of a living, evolving galaxy.

OUTCOME OF INJECTED EVENTS
These events have the ability to significantly affect the ED universe, changing systems and locations, allowing us to keep it as interesting as possible.
The repercussions of injected events could cause long term changes to the background simulation in a system. Players may also get opportunities to mitigate changes to a system through events in the background simulation.

E.g. An Injected Event causes two factions to go to war with each other in a system. As the background simulation now has influence from the warring faction, it will generate events and missions linked to that war. If players complete missions relating to negotiating peace and ending the war, and react in the right way to events, they could stop the war and mitigate the effects of the Injected Event.


PLAYER INFLUENCE
Players will be able to influence this system, since the meta-game will feed off of changes in the simulation from many different sources, including players. For example:

• Missions – generally these will have the largest positive or negative effect on the system, depending on faction, success or failure, nearby enemies or allies, the importance of the mission undertaken, and various unforeseen consequences.
• Trade – player trade will have a minor effect on the system, although a star system already under the effect of an injected event may be exploitable (i.e. food sold to a star system suffering from a famine would fetch a very good price).
• NPC interactions – attacking, defending, interacting and killing NPC’s within a star system or faction will have an effect. The everyday NPC’s met won’t be high level, so their influence will be limited to small changes. For example, killing a trader will negatively affect the wealth of his faction or star system, but not to a vast extent.
• Exploration – discoveries made by players, once sold into the system, will be unlocked for the system to use for injected events.

Players news feed will regularly refer to Events and Injected Events that are nearby to, have been interacted with by, or pertain to the player.

Injected Events can only be added to online players games. Offline players will still have changes applied by the background simulation, but will not get the broad influences of Injected Events.

Several Injected Events can be occurring at the same time in the Galaxy. They may be linked together (such as a famine that affects multiple systems), or could be unrelated and seperate. Injected Events can be linked with each other and could form a sequence of events, creating a narrative around the events that are occurring.

Backer influence over injected events will be a topic to be discussed at a later date.

Please keep your examples of Injected events coming and any feedback on the system coming!

Mike Evans wrote:

Here is the updated proposal. I've tried to streamline the whole thing and included some missing points. We're quite happy with this system however any mention of VFX are to be discussed and decided upon later (any ideas are welcome).

SENSOR MECHANICS

• Default Sensors for all ships
  • Upon arrival to a new location a picture of potential contacts around the player based on their distance and signature appears (see Signature and Sensors below)
  • More detailed sensors are located in a forward facing arc that have better range capabilities thus resolving contacts where the default all-around sensors cannot (usually a multiplier to the default sensor range)
  • In addition to the above false positives are put into the mix depending on the quality of the sensors and/or any environmental factors (see Signature and Sensors below)
  • To resolve a contact the distance between the ship and the contact needs to be reduced and/or the signature of the contact needs to increase (see Signature and Sensors below)
    • A low signature contact won’t resolve until it’s quite close where as a high signature contact can be resolved from quite a long way away
  • Signature can be based on several factors including heat and engine emissions
  • Only contacts that have been validated can be targeted by the targeting computer so that weapons can provide assistance/gimballing/lock-on etc.
• Advanced Passive Sensors
  • These are deployable sensors that dramatically improve the ship’s forward facing detection abilities by significantly increasing the range at which a specific signature value can resolve a contact
  • As they are deployable they take up a valuable hard point on the ship
  • Passive sensors like these don’t affect the ship’s current signature to other ships sensors other than the potential heat increase through power used
• Advanced Active Sensors
  • These are deployable sensors that actively search for contacts using strong EM pulses and other forms of detection that dramatically increase the ship’s own signature as a result
  • They are extremely powerful in that potential contacts within their sensor range can be validated instantly at the cost of also lighting the ship up to everyone else
  • They come in both forward facing only and in fully spherical configurations
    • Forward facing typically operate to much larger ranges and are quicker than the all around types
  • Activating an active sensor will “ping” the area and instantly reveal any potential contacts that the sensor is able to detect
    • The further away a contact is the less likely it will be able to be detected
  • After activating a contact will be told they have been “pinged” and can then look out for possible new sensor contacts that have just resolved to find the likely suspect

SIGNATURE AND SENSORS

• Sensors are tuned to be able to fully resolve a contact at a specific distance providing the signature is equal to 1
  • For example a sensor with range 8000m will be able to fully resolve a contact at 8000m with a signature of 1
  • If the contact was instead at 4000m away then it would only require a signature of 0.25 to be resolved
  • Likewise a contact at 16000m away would require a signature of 4 to get resolved
• The environment can affect the stats of the sensors such that ranges are reduced, default signature values increase or lowered, arcs widened etc.
• Additionally special equipment could be used to affect other players scanners such that effective ranges or signatures are reduced when they being scanned
• If the contact is unresolved because their signature isn’t high enough for the range they’re at to be detected instead a scalable VFX is applied on the sensor UI to indicate the possibility of a contact
  • The close the contact is to being resolved the more focussed and consistent the VFX is so the player can try to get closer or turn to point their more powerful frontal sensors at them to finally resolve the contact
  • Distant and low signature contacts might have zero VFX applied or barely show up as a sensor glitch at all
  • False positives are mixed into this to add a layer of uncertainty to the above

TARGETING MECHANICS

• Once a ship has been resolved on the sensors the player can target them to provide a more detailed readout on the type and status of the ship
  • Targeted ships are highlighted on the sensors as well as on the HUD
• Detailed readouts of the ship are displayed in a dedicated panel on the cockpit whilst the ship is targeted
• By having a ship targeted several other mechanics can come into play based on the equipment installed and/or deployed on the player’s ship:
  • Missile lock (described below)
  • Subsystem scanning (described below)
  • Cargo Scanning (Mechanically identical to subsystem scanning)
  • Bounty Scanning (Mechanically identical to subsystem scanning)
  • Weapon gimballing (ability for gimballed weapons to provide aiming assistance on targeted ships)

MISSILE LOCK

• To begin the missile lock sequence the player must...
  • ...have a ship targeted
  • ...have a seeking missile weapon deployed
• Once the above conditions are met the HUD will indicate an acquiring lock symbol which will, over time, move from the centre of the HUD to the onscreen position of the targeted enemy
• When the acquiring lock symbol is maintained on top of the targeted ship icon for a short time the missile system will acquire a lock and the symbol will change
• Whilst a lock is acquired the symbol will overlay the target providing the enemy is within the FOV of the player’s ship
• If the enemy ship ever moves outside the FOV of the player’s ship any missile locks will be lost and will need to be reacquired
• Players can speed up missile lock by aiming their ship such to bring the acquiring lock symbol on their HUD on top of the intended target faster than if just leaving it to do it automatically
• Firing a seeking missile with a lock acquired will result in the missile being able to either:
  • Independently track the target and no further action by the player is required (they can break lock without affecting the launched missile)
  • Track the target providing the player maintains a lock throughout the missiles flight path (losing lock will result in the missile maintain its last heading until the lock is reacquired or the missile runs out of fuel)

SUBSYSTEM TARGETING

• To begin the subsystem targeting sequence the player must...
  • ...have a ship targeted
  • ...have a subsystem scanning module installed and/or deployed if necessary
• The scanning sequence will take time based on the quality of the module and also requires that the target ship to be in the FOV of the player’s ship the entire time (like with missile lock)
  • The target ship will know they’re being scanned unless the player is using specifically stealthy scanning modules
• If the target ship moves off screen or the lock on is disengaged for whatever reason the scanning will be cancelled
• Only when a full scan for the required time is made will the enemy subsystems be available to target through the cockpit interface and other appropriate input
• Once a full scan is completed the player doesn’t need another scan to reacquire the subsystem list if they change targets in the mean time (i.e. the ship remembers the results of the scan on a per target basis)

CARGO SCANNING

• Mechanically identical to subsystem targeting, cargo scanning just requires the specific scanning module to be installed to enable it
• Subsystem scanners, cargo scanners and bounty scanners can both be installed at the same time and will also run at the same time provided they are both powered and/or deployed if necessary

BOUNTY SCANNING

• Mechanically identical to subsystem targeting, bounty scanning just requires the specific scanning module to be installed to enable it
• Subsystem scanners, cargo scanners and bounty scanners can both be installed at the same time and will also run at the same time provided they are both powered and/or deployed if necessary

DISCUSS!

Michael Brookes wrote:

Welcome to a new feature here on the Private Backers Forum - Peek of the Week. In this feature we will release a new piece of art or screenshots along with a comment from David or one of the team.

We start with an image used by David in his recent TED talk:


(click on the image to get the full-sized version)

And a comment from David:

David Braben wrote:

"Here is a view of a profoundly cold, volcanic world, with the odd active
volcano, surrounded by yellow, sulphurous deposits at the balmy temperature
of -40 C. Maybe rare gems have formed in the areas of volcanism, if they
haven't already been mined out?"

Michael

Wolfwood wrote:

To me, that picture seemed to be missing something important...

Michael Brookes wrote:

(click on the image to get the full-sized version)

JazHaz wrote:

What does everyone think?