Sensors

CalenLoki

Master endo
Joined
Aug 9, 2019
Messages
637
#1
I believe game could benefit from more sensors.
All those are meant to output yolol values, not UI elements.

It's debatable how much automation should be possible, and how much should be left for players invention.
So I'll just list all of them and leave it open for discussion and devs decision.

  1. Safe zone detector. Outputs 1 when in safe zone. Use: mostly noob protection. Also useful to avoid cluttering UI with extra elements.
  2. Gravity detector. Outputs angle difference between sensor and gravity. Two/three fields: pitch and roll and maybe magnitude. Outside moon gravity it could point at eos.
  3. Accelerometer. Shows acceleration 4 fields: x,y,z, magnitude. Kind of redundant if we get speedometer.
  4. Rangefinder. Already in game. Would be nice to have check frequency inversely proportional to length. I.e. at 1km 10 times per second, under 100m 100Hz, 5km 2Hz. Or scale power use by range.
  5. Proximity sensor. Outputs distance to closest object within cone. Range*angle*frequency/power use=constant
  6. Material detector. Single ray that outputs 4 fields: core and shell names and volumes. Or case of aiming at ship/station components type (i.e. plate), material, volume, mass (?)
  7. Speedometer. 4 fields, showing direction x,y,z (relatively to the sensor, not normalised) and magnitude.
  8. Gyroscope. Shows orientation relatively to universal orientation. Yaw, pitch, roll.
  9. GPS. Shows universal position. I'm personally against it, but I'll leave it there.
  10. IFF. Single ray. Point at ship with transponder to know the owner and ships name.
  11. Laser sensor. Outputs pitch/yaw between the sensors front and object painted with laser designator. Same as the one on torpedoes,but for ships. Can be set to read only one laser frequency. Also an "laser decoy" that acts as part painted by laser. Useful for drone-ships seeing each other, ship-ship colision avoidance, automatic docking, ect.
  12. Ship detector. Radar/sonar/heat/radiation. There's plenty of threads about these, so I'll just mention it.
  13. Receiver. In game. Would be nice if they could receive some variables too. I.e. name, signal strength, frequency, var1, var2, var3. Could be enough to remotely control some drones.
  14. Seat track-IR. Outputs pitch and yaw of seated endo head.
  15. Radiation/corrosion detector. For those dangerous places in the belt. Should output magnitude, not only 0/1
  16. Damage detector. Either switch to 1 when ship takes damage (reset manually/with code) or counts missed voxels since last reset. Could be for the entire ship, or only within certain distance.
  17. Structural integrity. Outputs warp class of the weakest object. Could be localised or whole ship.
  18. Mass indicator: displays mass of the whole ship.
  19. Endo detector. Outputs 1 when there is endo within set distance. Use: alternative to lifeline, automatic doors, security.
  20. Celestial body detector. Works as receiver, but treats Eos and moons as transmitters. Very long range (unlimited for Eos, tens of thousands km for moons). To make it funnier, they should have unique, unknown to players signal strength.
I've probably missed some. Feel free to suggest more, I'll add them to OP
 
Last edited:

five

Master endo
Joined
Jun 15, 2020
Messages
279
#2
1. Safe zone detectors should be implemented into the UI in my opinion, because having a seperate detector for that seems unnecessary. Maybe you could add as a side function to the receiver, like that you get a stations exact coordinates and data once your inside the safezone.
2. Gravity detectors would be very usefull in my opinion, as they would allow you to land a craft more safely and easily. Though I would also implement this as a function of the gyroscope, since I would want to reduce the overall amount of sensors having to be implemented into the game.
3. I dont know if you need an accelerometer if you want to implement a speedometer.
4. I like that idea of a change it would limit their potential in a good way, because I think there will be much more use of range finders for automation once the game hits EA or Release
5. Again a good idea for a sensor needed in Automation
6. I like the idea of this material scanner, though i would limit it to mining ores because it would make really easy otherwise to reverse engineer a ship
7. Speedometer is a must have for me since I want to test my ships speed, without having to add a quadruple ISAN System.
8. Gyroscope very much needed for atmospheric flights and maneuvering in general, a ship could also transfer its gyroscope data to a factory so the factory can work perfectly, even if the ship isnt placed perfectly.
9. I get why you would want to have a GPS sensor, but first of all we have ISAN and secondly we would have to build the satellites all around eos to manage that system.
10. You could also implemented into a function with the receiver and maybe make like a real life pilot radio system
11. Usefull for automation I dunno?
12. I NEEEEEED THAT SHIT
13. I think this is mandatory to be implemented into the game
14. I get why you would want that but I imagine those controlls to feel really wanky.
15. Definetly needed for mining
16. You know when you hit your ship, you dont or shouldnt need a sensor for that, I think it would be annoying, especially if you have an audio signal as output, like SHUT THE **** UP I KNOW I AM BEING SHOT AT!!! Its in my opinion like having a oversensitive parking sensor for a person that can park their car without one
17. There is a hand tool for that and how do you wanna access that mid flight???

Now for my own ideas:
1. I'd like to see a sensor that could detect an error within a system, like a debugging system for YOLOL you have to add, that tells you if what you are doing is done by the controlled device. If it doesn't work it gives you an error code for said system, like lets say you have a turret on your ship and it gets sabotaged, you'ld know that for example your guns arent responding to a firing order. This would also be helpfull to know what was hit during a battle. Like I said you know when you are hit, but you don't neccesary WHAT has been damaged on your ship.
2. A sensor for torpedos that tells you either if you have a successfull lock on your enemy or if you are being locked on.
 

CalenLoki

Master endo
Joined
Aug 9, 2019
Messages
637
#3
  1. I'd rather keep UI to the minimum. Also it could be used for some sort of automation: change internal/external lights, turn on/off collision avoidance/silent mode/transponder/radar, turn on alarm lights and siren on station when safe zone drops during siege, ect.
  2. Cramming so many functions into one engine isn't always good. You may end up paying for function you'll never use.
  3. You're right. I'll keep it there just so the list is complete.
  4. .
  5. .
  6. Don't see how you could use it for reverse engineering. It gives you material and type, but not rotation or precise position
  7. .
  8. .
  9. I actually don't want built-in GPSGPS. I've put it there to have complete list.
  10. True, receiver could do that too. Especially if it had some more data fields.
  11. That one is already confirmed as planned. Same as the used for guiding torpedoes. Could be also used to remotely control drones (i.e. point at asteroid you want to be mined), or to aim turrets mounted on other ships. Or if you point it at your own ship, you'll know if someone is painting you as a target.
  12. .
  13. .
  14. So far IMO that's the best way to implement mouse control. Especially when you're a gunner on a ship hosted by someone else, as it reduces imput lag.
  15. .
  16. On a big ship you may not notice that someone is shooting at your butt. But I'm not sure if we need it or should have it.
  17. Hand tool can't automate stuff. I.e. you could turn on alarm/lock controls if you overload cargo crates/beams/frames. Or your drone may refuse to pick asteroid that would break it.
  18. I can see what functionality you wan from that sensor, but I can't see a way to implement it. Maybe it'd output name of the most recently removed/added device field? It can be done with yolol: afaik it'll skip rest of the line if you refer to nonexistent device field. I.e.
    Code:
    a=Turret1 goto 3
    Alert="Turret 1 destroyed"
    a=Turret2 goto 5
    Alert="Turret 2 destroyed"
    a=Turret3 goto 6
    Alert="Turret 3 destroyed"
    (not tested)
  19. Afaik torpedoes are only manually guided with laser designator.
 
Joined
Nov 9, 2020
Messages
8
#4
I really like the idea the sensor 14. That would allow to make easier lots of things. Piloting and using turrets of all kind, plus, on a large ship you could make pop-ups with information, depending on where you look. That is like mouse control, but implemented through yolol, innit?
 
Joined
Feb 25, 2020
Messages
14
#5
Structural integrity. Outputs warp class of the weakest object. Could be localised or whole ship.
I need a robot voice in my cockpit saying "Warning: Warp class compromised"...

I like all of this. Except GPS, because we already have tools for that.

About the rangefinder updating more slowly depending on range: instead of that, there could be a randomness amount to the readings, the farther away the reading, the more randomness, therefore yolol would need to be created to average it over a longer time.
But maybe this is overcomplicated. Idk.
 

CalenLoki

Master endo
Joined
Aug 9, 2019
Messages
637
#6
Scanner-rays?
I hope im on the same page here, but pointing a device to read information is a generally preferred asset, and for a number of reasons.

We can go all out on this and maybe start a separate thread over "Information tools(?)" , but lets go ahead and list a couple other items we can toss in the mix since its still relevant to transponders.

Trasponders to give us a ship location(already here) its affiliation or group(as suggested) and maybe tell us at a glance its Status? such as if it is operable or not?

YOUR Idea, for a directionally aimed 'scanner' (my name for it, bear with me) can have a number of different routes to follow, even Multiple Variants.

Firstly, lets branch over Ship-mounted and Hand-held. Ship mounted scanners should be able to read *just* the basic glance over a broader area of data stats upon another ship. I'll go by category here, but bear in mind none of these have to be exact or on the point, Hand-helds can give us more specific information.

Movement:
Ship's available top speed/ acceleration/ current speed/ mass/ Bearing and Direction ---- And as a challenge to any Yolol Techie, see if you can find a way to steal someone's intended course or destination coordinates before I suggest that.

Armaments: -This one calls for a lot of heavy data; its a stretch and a daydream
Tell us if the ship we are scouting has mounted or active weapons. Does not need to include whether these weapons are functional or if they have ammunition, just " X number of Auto-cannons/ X Railgun mounted weapons detected/ X torpedo Bays." or even vaguer, and not tell us how many arms are found.

Integrity:
Expand on the Ship's current Mass is in relation to what it's base mass is. Is the Ship Powered/ low on reserves? How much further can it travel (flight-time) ?

* And for anyone that sees opportunity in just this category alone: If a ship is Heavier that its base mass, it has cargo. Lighter means damaged. Go Salvagers and Pirates!

And if we really want to push coding and information retrieval in the game:
Resource Scanners:

To tell us, at a glance, What resources can be expected inside a stowed cargo crate, or loose ammunitions/ fuel rods/ torpedoes.

No numbers or specifics necessary, just tell us if we can see it there or not.

Hand-held scanners can expand on these qualities and show more precise information over different areas, with the trade-off of having to be in close proximity to work. (If we can expect them as a seperate tool alone and not just another tab on the U-Tool, to cut down on universal use.)

Handheld scanners like this can also bring in some certain and underrated opportunities from their use. Especially in the case of Ship-boarding: Hijacking, piracy, blockades, military checkpoints, ship yards, and smugglers.
So far all movement and positional data in game is relative to the scanning ship. As there is no universal coordinate system. Sensors are also incredibly simple in their output: 1-3 data fields.
So I'd rather have different approach to checking someone's movement - via tracking beacons that you attach either by hand or via dedicated missile warhead. Or by manually painting them with laser designator. Then you get their position relative to your ship, and add it to your global position (that you need to first get, i.e. with ISAN or other player-made GPS)

With armament and resources I'd go even more vague. There is no logical explanation why a scanner could say what's inside a ship in a distance.
So I'd keep them to just displaying the radiation level and ship (current) mass.
Radiation would be leaked from running reactors, but also charged batteries, charged weapon capacitors, ect. So a ship with a lot of radiation for it's mass would be suspicious, but without any hard data.

There is no such thing as "base mass". You can modify your ship at will.

Material detector would be nice, but it should only show content of the crate you hit. So you need a longer scanning time or more sensors to check all the visible crates, and if someone plates them or hides valuables inside the ship you're limited to getting inside and checking by hand anyway.

Last but not least, I'd keep ship-mounted and hand-held scanners roughly the same in function. They have inherited unique traits that make enough difference:
Ship scanners can be built into bigger arrays, with multiple working at the same time, and can hook into yolol (automation). But are large, clumsy and harder to aim precisely.
Hand scanners are limited to 1 per person, but are easier to move around and aim precisely.
 
Last edited:
Joined
May 15, 2020
Messages
7
#7
I just want to clarify that 'Base Mass' of a ship is a figurative figure but i would imagine it as reading the Ship's initial total Mass as it is recorded when spawning in.
 

PopeUrban

Veteran endo
Joined
Oct 22, 2019
Messages
140
#8
1: Should be part of the basic UI. It is very difficult for a new player to stay in the safe zone and be broke if it costs them extra to know whether or not they are in the safe zone.

2: See no issue with this. Lots of interesting applications, no real balance issues.

3: Should be a basic output of the flight control IMO, as should speed. The point of the FC is to simplify thruster and piloting functions common to basically all ships.

4: Don't see an issue. More interesting variables to play with for automation.

5: I like this also, for more interesting automation options.

6: Against. Too much free information about things outside your ship removes the necessity to do hands on spying or prospecting. Removes critical player interactions from the game loop.

7: Again, should be part of the Flight Control.

8: Universal orientation while necessary for software design is a relativistic concept. We should be orienting against points in space, not universal constants. Codifying universal constants makes automating many things far too easy, removes tons of potenation sabotage/damage scenarios, and overall dilutes the function and design arms race of other more interesting navigational tools.

9: Against for basically the same reason as 8. Navigation should be a multi-vector handshake between various things that requires smart engineering, not an easy switch flip.

10: Yes. it only makes sense that one can have an easy to set up module to read the output of the easy to set up transponder

11: Hard no. This creates too much ease of automation, threatens to virtually overtake meta if used for weapons requiring all ships to mount fake/defensive systems.

12: No thank you. The function of a transponder is to announce ship position. Turning it off should allow effective hiding of ships. Visual stealth is off the table, and so output stealth and use of cover is the only option we have to sneak up on or away from one another. This should remain so.

13: No thank you. Allows too much offloading of critical computational and sensor mass. N+1 potential is too high. Automated systems should largely be required to run their own sensors and chips for balance purposes (more automation = more mass by default)

14: Interesting idea. I like this.

15: Of two minds about this. On the one hand players should have information about what is happening to them upfront for things like this. If I start taking damage I should know why if I send someone over near the part. On the other hand having such a sensor would add design and play space for intel ships. I'd say endos should be able to natively gauge such forces but ships should not without a detector. Makes space for some cool spindly armed exploration/pathfinder ships or whatever.

16: I like the idea of this as a customizable "within N range" device so there is a mass/power tradeoff for balance purposes. It will impact other parts of your design. You can run very high power to cover a massive area, or very low power at the cost of the mass of multiples for more detailed info from multiples, or you can cheaply cover just a few critical areas with only one or two at a relatively low mass and power cost.

17: I would make this part of the damage detector as the functions are very similar. "Structural integrity sensor" reading out both damage and warp capacity seems logical to me.

18: Sure. Would make checking cargo mass easier as well as thruster and power optimizations etc. Lets you cheap out on structural integrity sensors I guess but only if you are literally getting bits blown off the ship so that's OK.

19: Players should be able to be sneaky. This should by changed to RFID detector, coupled with an equipped RFID key. This would allow you to code detection of known endos (You check for specific RFID values) without preventing unknown endos or disquised saboteurs from operating in signal stealth. Also allows for fun "steal the key" gameplay if the RFIDs can be looted off dead endos.

20: Yes. Space is vast and to take any exploratory journey players first require a heading. This would provide headings. Without such a device space either has to be very densely packed or we are expecting players to fly in to potentially nothing for a potentially infinite amount of time to explore.

My sensors:

Microphone - detects endo vocalizations, small arms fire, impact sounds within a set range. Can output a 1 for each type detected.

Impact Detector - Detects impacts against the attached plate. Unable to detect very low frequency impacts like endos sneaking, but sufficient to detect heavy footsteps e.g. running/jumping as well as collisions or weapon impacts.
 

Verbatos

Veteran endo
Joined
Aug 9, 2019
Messages
199
#9
I think sensor 10 is a no-brainer, it would mean people would have to equip their ships with more components if they want to not get shot down by the first faction that spots their unmarked private ship. But it could also create interesting dynamics within play, people could create a setup that could use one of these to sweep an area to find players. Maybe if multiple are hooked up together they could form a wall between them, allowing a larger range of scanning with only a small amount more components relative to the area?
 
Top