In Developement Cockpits: Simple solution (remote core access)

[Nosajimiki]

I like the idea of helm control... but I can think there are at least 3 major issues that deserve attention first. And that is assuming helm control is really high on a lot of ppl's wishlist.

 

[Coyote27]

Helm controls need to come with movable ship cores, or deprecate ship cores altogether. With the way 2.0 creates variable distance requirements, not being able to move the ship core to adjust for this has gone from a small annoyance to a very large one.

 

[Valiant70]

or deprecate ship cores altogether.

This would be the better option, but for now I'd settle for having the ability to control the core remotely.

 

[Maramonster]

Helm controls need to come with movable ship cores, or deprecate ship cores altogether. With the way 2.0 creates variable distance requirements, not being able to move the ship core to adjust for this has gone from a small annoyance to a very large one.

I was actually having this issue myself, there are a lot more distance based mechanics, and building for them, with a fixed ship core is troublesome. This is true especially since we have to be able to access the core. I cant just cram it in a wall or keep it out of reach.

 

[alij331]

right, time for a mind dump.

i have a huge mind map going on at the moment in the hopes that one day i will get time to mod starmade, and create a MASSIVE mod.

part of that would hopefully be managing to implement VR if its not fully in there by then, which a lot of the following bits allude to. the idea though, is that this system would be useable as flatscreen or VR on a per-client basis, as opposed to having dedicated iterations for one or the other.

i have made just the bridge-related items into little spoilers (now that ive worked out how to do that!) to try to keep the post organised. all of the categories are still WIP, but as you'll see, some are quite in depth!

I will try to include anything relevant that references other ideas around the mind map, but apologies if i missed anything.

...end of preamble.

first section: control categories

Spoiler: Command

command control functions

• objectives list (can be added to manually as a to-do list, and list objectives of any active missions)
• transfer conn button
  • brings up 'page 6' sharing menu to select new control station/screen to transfer conn to, with optional 4 digit pin
  • turns into 'reclaim conn' button once transferred (prompt for pin will be brought up if one was used)
  • transferring conn allows hot-swapping ability of conn chair to be temporarily given to appointed control station/screen (conn chair can still do it too)

plus any other command-specific items that cant be classed as anything else (see the other sections below)

*more on these bits later

Spoiler: Helm

helm control functions

• axial controls assignable to any axis of sliders or XY circular controls
  • strafe LeftRight
  • strafe UpDown
  • throttle ForwardBackward
  • roll LeftRight
  • pitch UpDown
  • yaw LeftRight
• motion damping button (hold for momentary, click for toggle)
• fine control button (reduces output of controls for intricate manoeuvres)
• full stop button (takes over controls to stop entity from moving as quickly as possible)
• warp coordinates (allows keyboard or on-screen numberpad input when selected)
• warp factor (draggable cursor on Y axis slider with colour changing background based on entity power usage - maximum warp charge while weapons firing could overheat power core)

*more on these bits later

Spoiler: Navigation

navigation control functions

• heading - bearing and mark (direction-of-flight relative to entity orientation or galaxy-centre, toggleable)
  • heading explanation
• proximity map (entity CoM centered in middle of a large circle as a translucent outer shape, with bearings based on direction-of-flight or galaxy-centre around outside of circle)
  • view select buttons at top to switch between centering on entity orientation (default), or galaxy-centre (if the entity is rolling out of control, switch to galaxy-centre-based so that objects aren't spinning around the screen too fast)
    • when centering on entity orientation, galaxy-centre is displayed as a translucent spiral icon and is always persistent, displaying similarly to bodies in elite: dangerous radar
  • elevation slider on Y axis at left side to adjust view from looking down from above (slider fully down), panning down to looking from behind (slider fully up). defaults as looking from 45º up (like elite: dangerous) when page is activated/reset
  • map zoom slider on Y axis at right side to zoom from entity's longest axis being equal to circle radius (takes up half of the map element) to being 1/20 the radius (takes up 1/40 of the element). defaults to 1/3 radius
  • heading drawn as green line from CoM to half-radius of outer circle, with dotted line running from tip, to meet bearing-plane (mark000)
  • other entities displayed in similar style to elite: dangerous radar
  • logarithmic scale (things far away stay at edge of map for good distance, fade away based on distance after certain threshold - close entities have a clearer scale of range from main entity)
  • shows max range of each weapon in a selected group as 'pizza slices' if a weapon group is selected on the same console (if the map is used on a tactical console, for example)
    • slices will only be used if it is possible to limit turrets' axis, else whole circles will have to be used for turrets
    • fixed weapons wont show slices/circles
    • every weapon (mounted on turrets and fixed) has a dotted, interface-coloured line aiming out of it to show its current targeting, which goes solid and thicker whenever firing. the line reaches max range of the weapon.
  • small 'default view' button next to view select that resets all view settings
• system map (centred on star when fully zoomed out - only shows current system, not neighbouring)
  • linear scale, with depth perspective
    • depth is from primary colour to secondary colour, closest to furthest
  • bounding cube of system shown
  • default zoom is fully zoomed out - closest face of system cube is full extent
    • full zoom is closest face of 1 sector (if sector were centred on selected) taking the whole element
    • zoom centres on star unless other body or entity is selected - centred on selected unless further out of system than the full extent cube allows
      • if selected is an entity leaving the system cube, it will deviate from element-centre once one-or-more system boundaries are reached by the element. once it has left the system, it is deselected according to the map, and map zoomed back to default
  • currently occupied sector of selected entity (no stellar bodies) is shown subtly as a point of reference, with bounding lines smoothly fading out into adjacent sectors (lines are longer than just 1 sector)
  • no view selection - top-down view is oriented with X axis across the bottom and Y axis up the side, with Z axis aiming towards the view
  • no elevation slider - top-down view only

Spoiler: Tactical

tactical control functions

• target information panel (target selected with navigation's 'proximity map', 'system map', or by standard target selection)
  • name
  • bearing and mark
  • shields
    • max power
    • recharge
    • current power ('0' if disabled)
  • armour
  • power
    • max output
    • current usage
    • temperature
  • weapons (per weapon)
    • type
    • damage
    • size
    • fire rate
    • current state (including damage to system)
  • speed
    • max
    • current
  • direction of travel (relative to own entities orientation)
• target visualiser (shows translucent view of outer shape, and relative orientation - like elite: dangerous)
  • modules/systems/weapons are selectable; brings up relevant details listed from target information panel
• weapon group creator (allows any weapon - including turrets - to be associated with custom groups. allows multiple groups per weapon.)
• weapon group selector (can add as many to the page as will fit. small squares, each associated with a weapon group)
• firing method (fire on selected target, fire on closest, fire on largest, fire on smallest, AMS)
  • selected target includes if a module/system/weapon is selected on the target visualiser
• cease-fire button (also re-centres turrets)
• preset fire-pattern button (to trigger all turrets' 'default targeting behaviour')
• tactical alert button (activates shields if not already, balances power to engineering's 'tactical mode', makes turrets select targets based on 'default targeting behaviour', but dont fire)

Spoiler: Engineering

engineering control functions

• power usage monitor (X or Y axis scale for each section)
  • shields
  • weapons
  • thrusters
  • jump drive
  • transmitter array
  • scanner array
• power core monitor (2x X or Y axis scales)
  • power core temperature (with overheat alert)
  • 'safe' power used (overheating temperature is 100%)
  • overall power usage (% of 'safe' power) as single decimal number
  • 'shutdown' control
• armour hp
• armour percentage
• armour max hp
• shields hp
• shields percentage
• shields max hp
• max safe jump factor
  • based on 'remaining 'safe' power' and plotted coordinates

Spoiler: Comms

comms control functions

• ship tannoy (volume based on distance from any light block on the entity, with a max volume limit)
• frequency analyzer (XY frequency-amplitude graph, updated via sweeping up and down the 'spectrum' between 1 and 255)
  • sweep button (toggles a repeating sweep up the spectrum - new frequency every 0.5 seconds, but smooth fade - sweep encompasses 3 bands at full volume, then 1 either side of that being faded in/out - when sweep stops, adjacent channels fade out)
  • spectrum needle can be dragged to-and-fro along spectrum (imprecise)
  • listen/mute button (toggle)
• signal visualiser (shows real-time wave of whatever audio is being output)
• frequency scrub (spin-wheel control that dials single increments up and down in the spectrum to seek out frequencies - fades between last and new channels with 0.5 second fade)
• jam all frequencies (puts random noise across all frequencies via transmitter array, considered hostile by neutrals if not already in a firefight with their non-allies, always considered hostile by enemies)
• transmitter array power (X axis power slider - takes power based on range)
• transmission band & modulator (for all outgoing transmissions)
  • 3 sets of 3 digit numbers - up to 255 - that define the transmission state
    • set 1: transmission band (assigned to faction upon creation, unchangeable)
    • set 2: first stage modulator (randomly generated, changeable)
      • clicking on the number box brings up a number pad, allowing any number between '000' and '255' to be typed
      • randomize button
    • set 3: second stage modulator (randomly generated, changeable)
      • clicking on the number box brings up a number pad, allowing any number between '000' and '255' to be typed
      • randomize button
    • open channel button (temporarily sets modulators to '#, 0, 0')
• hail targeted (used with navigation's 'proximity map' or 'system map', or any faction ship within range of a reachable repeater - sends via transmitter array - hail lasts 10 seconds)
  • 10 second countdown overlay over button until timed out or accepted
  • if accepted, turns into 'end transmission' button
  • hail transmits on faction frequency and uses whatever modulators are currently set. the receiving ship gets these numbers to successfully communicate.
  • option to direct transmission to any screen or control station with the 'hail targeted' module, or to the viewscreen (if applicable)
  • option to send a message (max 100 characters) with the hail to be read while receiving
• hail receiver
  • accept and ignore buttons
  • 10 second countdown shown
  • receiver selector
    • viewscreen (if applicable)
    • <current station/screen title>
    • select by name (any screen or control station with the 'hail receiver' module)
  • ship-wide broadcast button (feeds both halves of conversation over 'ship tannoy' system, plus viewscreen if applicable)
• mayday button (button gets a 5 second countdown overlay before starting to transmit mayday message on repeat - always transmits on band '0', modulated with '0, 0': no modulation)

*more on these bits later

Spoiler: Science

science control functions

• life-sign scanner
  • range based on scanner size - accuracy shown in percentage (100% up to a certain distance, then accuracy drops by 1% every time 1/10 that distance is added)
  • if targeting a ship, shows total life-signs within bounds of outer hull, number of each type of life-sign within bounds of outer hull, and number of each type of life-sign in open space within 20m of any block on the ship (but outside of bounds of hull)
  • if targeting a single living being, shows number of each type of life-sign within 20m of the being
  • if targeting a planet, accuracy is determined by each 1% involved in scanning the planet, then divided by how many 1% arcs are involved (so if all arcs - 1% through 100% - are involved, then it would be [(1 + 2 + 3 + ... + 99 + 100) / 100 = 50.5%] so it would read 51% accuracy).
    • if the entire radius of the scanner cant reach the whole planet, then the total number of life-signs is calculated by how much of the surface has been scanned as a percentage, then multiplied to estimate the total planet: [(life-signs / percentage of surface reached) x 100]
      • if this is the case, then the accuracy is also decreased in a similar manner: [(accuracy / 100) x percentage of surface reached]
• geology scanner
  • radius of scanned area based on scanner dimensions - outline of scanner applied vertically down, centred on surface block that centre of scanner ring is aimed at (angle of ship therefore doesnt affect area of surface that can be scanned). the power of the scan, however, is reduced by 1% for every degree of divergence from being aligned with the centre of the planet core (so up to 90%).
  • depth of scan based on distance and number of scanner blocks - a 1-block thick ring with the minimum blocks to make the ring connect would be many times weaker than one of the same radius that was 3 blocks thick and only had a 1 block hole down the middle

plus more items that i'm yet to refine in my head enough to put into writing!

*the scanner as i imagine it is basically along the lines of the activation gate where it must be a solid ring. the thicker, deeper, and greater radius of the ring, the more powerful the scanner.

there is also another category that i thought of called 'logistics (inventory) control functions', but i'm yet to populate it with ideas...

second section: chairs and screens

Spoiler: New blocks - Chairs

standard chair

• able to sit in it by pressing the 'sit' key
• chair rotates smoothly when the user looks side-to-side
  • chair has hard limit of 100º head-turn before it moves however fast it is pushed, or if an elbow collides when reaching sideways (VR)

conn chair

• only one permitted per entity
• can hot-swap into any NPC crew member using a control station/screen (leaves player body in conn chair - forced to hot-swap back if body is injured)
  • can hear everything from sitting in conn chair as if over radio, as well as hearing hot-swapped location
  • pressing 'activate' to step away from station/screen hot-swaps back to conn chair

Spoiler: viewscreen

• only one viewscreen permitted per ship, but can be whatever size desired, as long as each block is touching at least one other
• hails (both to and from the entity) can be routed to the viewscreen by any control station/screen with comms' 'hail receiver' or 'hail targeted' elements
  • hail video is rendered from centre of viewscreen, elevated up or down to aim at centre-line of 'conn chair' (if the chair is below-and-to-the-side of the centre of the screen, the camera angle will look down slightly, but wont be panned)
  • hail 'microphone' listens to all sound sources with line-of-sight, and volume is based on proximity from beyond distance of captain's chair (everything closer to the centre of the viewscreen than the 'conn chair' is at full volume)

Spoiler: Control Stations and Screens

(turn 'decorative consoles' into 'control stations', and 'decorative screens' into 'control screens')

pressing the standard activation key accesses the 'control station' or 'control screen' when aiming at the main station/screen or something slaved to it

• if a 'chair' is slaved to it then the player/NPC will sit in the 'chair', else a 'floor' block at standing height must be slaved to be able to use the console (otherwise it is just an information display)
  • a chair can only be slaved to a station, and the chair and station must be correctly oriented (facing each other and 'within reach') they can be at any orientation as a pair
• if extra stations/screens are slaved to it then they are also accessible while standing/sitting at the main unit, for wrap-around personnel stations

stations and screens have a layout GUI (accessed through a new key command) to select what control elements they have and how they are displayed

• elements are listed down the side (which can be filtered from a drop-down for the different categories) and can be drag-and-dropped onto the layout designer (some can be added multiple times, such as tactical's 'weapon group selector' - these can be assigned and modified individually)
• each element is a 2-1 scale rectangle or a 1-1 square. each can be independently rotated in 90° increments, and the primary, secondary, and text colours can be chosen in hex code for each individual element
• elements can be resized from a single square (or 2x square rectangle) up to the full available space on the display
• each station/screen can have up to 5 pages that are selectable down the left-hand side
• the primary, secondary, and text colours of the border and permanent elements can be set by a master colour picker, which has a button next to it to force all elements to match

all controls are to be designed so that they can be used with VR as well as mouse & keyboard

each unit can be given a name (the entity name by default) that is displayed on the top-left. multiple units can have the same name

• all units can 'share' element information to each other by unit name - if multiple units have the same name, all will receive the shared information
  • all have a 'share' button on the bottom right - when clicked, a list ('6th screen') of all qualifying unit names on the entity is brought up (with a list of 8 'favourites', configurable through the unit's GUI)
  • when a receiving unit is selected, all compatible information will be mirrored onto the receiver until the user changes the settings, or it is shared new compatible information
  • a unit only qualifies to receive information if a compatible element is present on one of its pages (i.e. if a unit doesnt have a 'proximity map', it would still be able to receive the selected target if it had a 'system map', but not if it only had a 'tactical alert' button)
    • non-qualifying units are not shown on the full list, and can not be added to 'favourites'
    • if a receiving unit has the same elements (i.e. another 'proximity map') then all settings and information (apart from things like colour, that are setup in the unit GUI) would be mirrored from the sender's elements

third section: warp

Spoiler: Warp Travel

the bigger the jump, the bigger the bang: if a large entity jumps a long way, it uses a huge amount of power and creates a bigger visual ordeal.

the transition to warp space could create a portal big enough for the entity to fit through in any direction (equivalent to 2x longest point-to-point of its bounding box), which then closes after it - but the bigger the entity, the slower the hole closes (so that the entity can be chased through warp inside its stream). the entity's speed would increase at normal acceleration speeds up to 3/4 of its top speed (if not travelling that fast already) but without using thrusters. any other inertia would be forcedly dampened, and its manoeuvring would be locked until it was fully inside the wormhole so as to stop it changing direction and colliding with the edge of the portal on the way through. the warp would not start until the entity's direction-of-flight was within 5° of aiming at the destination, and the orientation was within 10° of the destination. the portal would then calculate - from dampening inertia and accelerating towards the destination - where and when to open so that it is centred on the entity's profile (even if the entity is at an angle when going through) and is wide enough upon contact that all blocks will fit through, even though the portal is still opening. this could mean that the entity is still spinning as the damping is taking a while to stop its inertia, but the portal will still successfully consume the whole entity due to where it appeared.

the exit portal from the wormhole would work by calculating what point the entity would need to reach at maximum portal speed to be fully open when the first block of the entity reached it. when the entity reaches this point, the portal would start to open, but the entity's manoeuvring would not be changed. once the last block of the entity has exited the portal, the manoeuvring lock would release and revert back to whatever state it was before the jump.

the portal would be cancelled if the entity's movement deviated from the calculated path by more than 5%, and would start to close again. this would only be possible if another entity collided with it hard enough to throw it off course or an explosion was big enough to do the same. at this point the simulated acceleration would cease and the manoeuvring controls would be unlocked.

during entry, it should distort the view in some way, like if the whole 360 view was stretched into a flat circle at the end of the wormhole, and wraps around the entity as it exits (similar to this). as the wormhole opens it would also do the opposite looking backwards.

the wormhole would be a separately formed region whose length is determined by the amount of power used in the jump compared to the distance being travelled; more power shortens the tunnel, but a longer distance increases it.

entities can manoeuvre inside the wormhole, but controls are locked to maximum manoeuvring speeds of the entity that generated the wormhole. ALL entities are pushed through at 3/4 the maximum speed of the entity that generated the wormhole (± manoeuvring). this allows multiple entities to have a slow-motion dogfight during warp, but would not be able to reverse thrust so much that they stay in the wormhole forever - even trying to reverse at full, they would still be deposited at the destination.

if an entity gently collides with the boundary of the wormhole, it will bounce back into the middle. if it collides at-or-above the server collision damage threshold, then blocks will be broken off the entity and scattered into normal space based on where they were along the wormhole at the time of breakoff. this would destroy an entity if it could not recover its direction-of-flight quickly enough, and would scatter carnage all along the warp path. this effect could be used as a tactical advantage in battles if entities warped across the battlefield, firing dud entities from rails at the sides of the wormhole to scatter debris in front of the enemy.

as a final note, it would be cool if trying to enter a wormhole exit the wrong way would take you back along the path in the opposite direction - at the same speed - but only as long as the portal is open - as soon as it is closed, the tunnel collapses and spits the entity into the spot that it would be in at that point in time, using a different exit animation that drops it out through a wibbly-wobbly effect that is a sphere 2x the size of the entity's longest point-to-point of its bounding box (similar to this) with some foggy, sparky effects whilst throwing the entity into a crazy spin, turning off auto-dampers, resetting shields (start recharging from 0%), and doing a random (but fairly minor) amount of damage to the entity (this animation, spin, and auto-dampers-off could also be used if implementing interdiction, but no damage to ship or shields). this would also happen to an entity that went in the correct direction after the entity that generated the wormhole, as long as the wormhole fully closed before the following entity reached the end.

in short, if an entity warps into the vicinity and a ship is losing in a fight, it might be able to dive through the portal in the hopes of losing its foes, and if they follow, they will be dropped a reasonable distance apart, as they will have entered the wormhole at a different time, but will be dropped at the same moment (and therefore further back along the line).

also, any ship/other entity that is straddling the portal border and does not fit as it closes gets cut up... this would be a special cutting where the block occupying the same space as the edge of the portal is destroyed, so if its stationary, a flat cut goes through (or as flat as can be if the entity is at an angle) but if it's moving as the portal closes, the cut is conical - as the hole gets smaller, more of the entity is left behind (any blocks behind the ones that are destroyed). the remaining section of the entity inside the portal is deposited - along with any debris - in the same manner as previously stated, but as the travel would then only be the time it takes for the portal to close from 1m wide, it would not travel far at all, but it would make for some epic destruction if anything got caught in it.

I hope you like my ideas! they dont require the core to be modified in any way, they just interact with the entity as a whole. we then get all of the ship controls without ever disappearing into the core; we can just sit in seats or stand at screens!