- Joined
- Mar 7, 2022
- Messages
- 40
In the past, I've been posting a series of articles on the ANC Discord about how I think Starbase can be improved. However, Article #9 is so long that it's too unwieldy to post and view on Discord, as it would have to be split over 4 or more messages. I'll be coming back and posting the earlier articles on the forum as well, but Article #9 will be posted first.
Sensors in Starbase have the opportunity to provide huge changes to gameplay and to support a number of systems. However, before discussing the details of sensing, I’d like to mention that such a system should be based around options, not impossibilities. For example, if a pirate can detect a miner from hundreds of kilometers away and launch an attack without the miner having any way to detect the incoming pirate, then that is something that should be avoided. While it may not always be equal in the field, the design of the system should allow for opportunities for counterplay.
The first step of any sensor setup is determining what is being sensed and how. I propose that radiation in Starbase should be split into two forms: Infrared and Radio. This offers more opportunities for signal analysis without overcomplicating things like if a fully realistic model was adopted. Infrared radiation would be detected by passive IR sensors only, and it would be produced by heat-radiating objects. Ships in general would radiate infrared radiation, with non-maneuvering thrusters emitting most strongly as they visibly exhaust a hot stream of particles outside of the ship. Station industry would also emit strongly in the IR spectrum, as certain objects (e.g. alloy forges) would naturally be hot, and others would radiate waste heat from drawing electricity. Certain materials in asteroids would radiate in the IR spectrum, with exorium specifically noted to be radioactive and a fission fuel and therefore steadily leaking some IR radiation from radioactive decay heat. Lastly, space weather can play a role in IR emissions. We see lightning and flashes of light in the belt currently, and these could be used to generate an ambient IR emission that adds a constant noise floor to IR sensors that can vary based on location and temperature.
With the exception of thrusters, IR should a simple and direct relation to how much electricity is consumed by a ship or station part, or how much fuel is consumed by a ship or station part. This means that solar panels would produce no heat by themselves, but fuel chambers would. Nevertheless, solar panels cannot grant full stealth as there are still other components on a ship or station consuming electricity and radiating heat. The relationship between heat produced and electricity/fuel consumed should be exponential. This allows for tradeoffs between taking a hit on mass and space efficiency to use a larger amount of devices run at lower capacity for stealth, and it means that naturally high consumption devices like mining lasers and weapons will show up very strongly on IR receivers. Thrusters should also follow this exponential curve, but with a flat multiplier to heat produced (e.g. 2x) to simulate that they’re directly exhausting a very hot source outside of the ship rather than radiating from the whole structure. I ran some calculations and a Heat = Power^1.2 curve seemed suitable, but this should be play tested.
Radio emissions is where things get a little more complicated. In reality, very little is a natural radio emitter besides stars, other stellar objects, and lightning. Furthermore, exposed cross sections, material composition and arrangement, and many other factors depend on the radio reflection received by radar antennas when scanning an object. In Starbase, most of this should be simplified for both performance and ease of use reasons. Radio sensing can be split into both passive sensors and active sensors (radar). Passive sensors can only detect radio sources, which would be ship/station transmitters, ship transponders, public station transponders, and radar antennae. This means that passive radio receivers are less useful by themselves than passive IR receivers, but they can detect an enemy that’s not maintaining radio silence or enemy ships that are scanning the area to find something. Furthermore, they’re a vital half of an active radio sensing setup.
Radar antennae act as the active half of an active radio sensing setup. When paired with a passive receiver, ship and station owners can choose to emit radio waves to scan an area. Asteroids would have a radar return dependent on what’s in their core, potentially with density determining the strength of the return. Ships would have a return dependent on either their voxel volume or mass, with the proportion of exposed materials providing a modifier to this. If an entire spaceship is covered in plating of an appropriate material (possible examples include Tengium), then its radar signature is greatly reduced compared to a spaceship with no plating or plating made of materials with high radio reflectivity. Stations would have a radar return dependent on the volume of the station. Radar antennae would create a very strongly detectable signal for passive radio antennae in the path of the beam, and a weaker but still present signal for passive radio antennae located anywhere else near the transmitting ship.
Now that we know what we’re sensing, we can talk about how to sense it. Physically constructing the antennae can be relatively similar to constructing radiators. There would be a core piece attached to a hardpoint with a power connection, and then pieces can be mounted to it to enhance the antenna’s sensitivity or emitting power. Frozenbyte could also choose to restrict antenna shapes to things like cross shapes, circles, squares, or other options. Lastly, antennae must be exposed to space. This both makes logical sense, and it adds potential vulnerabilities to ships. Making antennae extensible also opens up opportunities for counterplay. A pirate in a small ship quietly scanning the area on passive IR would present only a minimal signature unless someone happened to point a radar beam right at his ship. However, because mining ships can grow to be very large (over 10 million kg), carrying tens of thousands of kg of antennae is a rather small fraction of their weight. While the pirate has the opportunity to choose his easily detectable targets in peace, when he starts closing in for the kill, the larger antennae on the mining ship give the miner the opportunity to see the pirate coming and try to prepare to either fight, run, or negotiate.
Passive antennae would have relatively simple configuration options. The sensitivity of the antenna would be determined by its physical size, and this would change as pieces get shot off or added. As for configuration options, the only one would be exposure time. A larger exposure time helps get a clearer reading on objects and help detect a very faint signature such as a far away asteroid or stealth ship that’s stationary. However, a larger exposure time would weaken returns from moving objects as they would appear to be diffuse smears to the sensor rather than a point-like object like a ship. Exposure time would have a minimum and maximum value, and the output of the device (more on this later) would change only after each exposure period is complete.
Radar antennae would be more complicated. In real life, radar antennae have a variety of frequencies and other options, but these should be simplified for the game. The field of view of the radar antenna should be configurable within a minimum and maximum value. This allows the radar beam to be shaped and adjusted to suit various circumstances where either one object needs to be scanned in great detail, or larger portions of the sky can be examined. The radar should of course have a power setting, which adjusts how much electricity the antenna consumes and how strong the radar beam. High powered beams produce very clear returns, but also advertise your position even more readily to people nearby. The antenna should also be rotatable, with this possibly being animated on the ship, to scan various portions of the sky. Lastly, the pulse frequency of the radar should be configurable. This would be very similar to the exposure time of passive sensors, but a higher pulse frequency would draw more power and generate a stronger radio signal. Combining pulse frequency with exposure time offers some possibilities for detection. A very high pulse frequency with a very low exposure time means that a complete radar set is highly effective at picking out large or moving ships, but at the cost of a very strong radio signature. A low pulse frequency and long exposure time is well suited to a miner scanning the area to detect minerals and offers a somewhat stealthier radio signature, albeit one still detectable to sensitive antennae in the area or an antenna in the path of the radar beam.
After collecting the data, it’s time to analyze and output it. The radar antenna itself will not output any data, but passive antennae will. It’s at this point where I ran into difficulty with YOLOL and sensor data. It’s very easy to suggest a “sensor display” part that projects sensor data onto either a 2D or holographic display and lets users visually interpret it. However, it’s harder to expose this to data without either requiring extensive signal processing (which current YOLOL may struggle with) or offering very specific details that defeats a lot of the ambiguity that should be present. This is what spurred my suggestion for YOLOL reform in Article 6, especially the addition of arrays. From this point forward, I’m operating under the assumption that YOLOL has been adjusted according to Article 6 and arrays are present. I’m not going to discuss a separate programming language in this article.
For a visual output, I think that a sensor display part should project the data in-world if possible and offer the possibility for endos to interact with it and integrate the data with their personal maps. This means that when within range of a sensor display module, a new overlay would be available on your map for you to view the sensor data. This lets you easily cross-reference known stations and waypoints to see if any of the sensor returns belong to something explainable, or if it represents a new opportunity or threat. It also lets you easily drop a marker on a sensor return to come back there later, which can be used for marking ore hotspots or potential enemy stations.
Visually, the sensor map would display background radiation as a dim glow, which serves the purpose of helping to hide very weak sensor returns. Depending on the sensors connected to it, a sensor map could be set to IR, Radio, or Combined mode. Combined would add the radiation returns received by both sensors onto the map, and it would be situationally useful if background radiation is high in both spectra. IR returns would be colored red, and Radio returns would be colored blue to help distinguish which sensor is detecting the signature. “Known” large objects like Titans or Moons would appear as solid and distinct objects on the map, but they would cast sensor shadows that offer opportunities for hiding a ship or station. Otherwise, how objects appear depends on the size and strength of the return. Large and well-developed stations will display as a sensor return spread out over a wider region of space than a tiny endo scooter, if the scooter is even visible at all.
In IR mode, the only information available would be the signal size, strength, and distance. All of these would have some level of uncertainty that would make them appear as various sizes of clouds rather than a 1:1 image of what the ship/station/asteroid/weather event looks like in-world. If a return is well-established then it does get narrowed down to a point shape, but remote examination of the object would not be possible beyond analyzing its signature. This means that an exorium asteroid returning with a Signal Strength of 100 at 50km away would look nearly identical to an asteroid sized ship with a Signal Strength of 100 at 50km away. Increasing the exposure time of the sensor helps to increase the signal strength of stationary objects but reduces it for moving objects. This could potentially be used to try and help filter out or include ships on the display.
In Radio mode, more information is potentially available. Natural passive radio returns are very rare besides belt lightning, so the noise floor could potentially be very low if you’re in a part of space that’s not experiencing a space lightning storm. However, the chance of picking something up is also equally low unless you are willing to perform an active scan. Unless a ship or station is using a radio transmitter device, a public transponder, or a radar antenna, it would have a small or zero passive radio signature. Therefore, radio detection can benefit from a low noise floor, but to really get any data you have to be willing to reveal your own position in turn. Radio returns would function very similarly to IR returns, but if the signal is strong enough you can potentially tell the material composition of the return. This should be carefully balanced, as it’s a dead giveaway for an incoming ship. No natural asteroids are made out of as many materials as ships after all. To balance this, the sheer number of materials can confuse the signal processor in the passive radio receiver and return a “Composition Unknown” tag for the return. At long distances and when stationary, this may not arouse too much concern as asteroids past a certain distance would return the same tag. However, if a Composition Unknown tag is heading straight for you or otherwise drifts too close to your ship, that would be cause for concern.
YOLOL can also interact with sensor output. Arrays would be critical here, as toggling through all the available returns like with the material scanner’s material selection field would be too slow in most cases, as there could be a sizeable quantity of returns. The array could return a list of signals with their heading, distance, and strength stored as subfields. Radio returns of sufficient quality could also have a composition subfield. YOLOL chips could then interact with this data to process it for various uses. Whether it’s to automatically highlight asteroids with desired ore, or to sound an alarm when a moving return gets too close, YOLOL can be used to enhance the capability of sensors, or to reduce the need to look at a sensor display while operating a ship solo. Manually examining a sensor display can be made more accurate through a number of ways as well. If there’s a Strength 100 Size 20 return hiding inside a Strength 70 Size 80 return, a sensor display may be able to highlight the two separate returns, while Frozenbyte could choose to average the two and make the output available to YOLOL. It’s dependent on whether maximal YOLOL processing is desired, or if Frozenbyte wants to emphasize manual attention to sensors.
What do these sensors enable? They enable many different features for both PvE and PvP players, which is important. Considering PvE first, they represent an enormous opportunity to enhance the asteroid mining experience. While a separate Ground Penetrating Radar component would handle examining Titan Asteroids and Moons, Passive IR and Radar would allow miners to scan the area around them and pick out asteroids with the desired ore. Passive sensors would likely not be directly helpful outside of searching for exorium, but if players know that ore hotspots are frequently camouflaged by space storms, they can scan for high background sensor returns and set course for that area. While in the storms, their passive sensors would be heavily restricted, but the tantalizing offer of a rich asteroid field may be worth the risk of a ship sneaking up on you. Radar would also be helpful for scanning asteroid fields and picking out asteroids with the desired ore nearby. The downside to scanning the area with radar is that using it makes you very visible to Passive Radio Sensors in the area.
Sensors also offer many opportunities for PvP. The most commonly discussed use is finding miners, but miners also can use sensors against pirates. Because mining ships are frequently larger than dedicated fighters, miners have enough spare thrust to carry larger sensor arrays. This fact prompts specializing pirate ships into also mounting larger sensor arrays to detect miners from ever further away, which increases their vulnerability to escorts due to the extra weight and openings in the hull, or they can spend the resources to stealth up their ships. Special baffles, which could be a variant of the regular thruster parts or an optional addition, help reduce your IR return at the cost of expense, weight, and possibly performance, while crafting your outer plating out of radar absorbent material can reduce your radio return at the cost of being weaker armor.
Mining ships as well can evolve to meet the threat of pirates with sensors. Right now, players can confidently rely on the largeness of space to hide them in almost any scenario and very few miners are armed or armored. However, if miners know that pirates have a much larger chance of finding their large thruster returns or the radar used for scanning asteroids, it prompts miners to make some changes. They too could invest in highly stealthy mining ships, although the cost may be enormous to plate an entire design in radar absorbent material, or place baffles on all the dozens of thrusters on the ship. Instead, miners may choose to place armaments on their ships to give them a fighting chance against an intercepting pirate.
Sensors also play a role in holding territory, warfare between players and companies, and sieges specifically. Claiming and holding territory is done through building stations and expanding them. Naturally, players will want to do things with their territory, and that involves building resource gathering, ship building, or other infrastructure on their stations. However, all this infrastructure increases the IR return of the station, making it ever easier to find on sensors. Enemies can survey asteroid belts, moons, and other areas looking for these returns and can then examine them closely. Right now, capital ships can launch sieges against any station within a certain radius of a navigation chip through a “magic” detection radius. This should be discarded and replaced with the necessity to perform a radar scan of the station before a siege can be launched. This scan should take at a minimum several minutes to be performed, and results in an “enhanced” or “verified” waypoint being made available on the player’s personal map. Afterwards, the player can share this waypoint with a group, company, or alliance, and then sieges can be launched by anyone with access to this enhanced/verified waypoint and a capital ship with a navigation chip encoded to within a certain radius. This extended process ensures that companies cannot launch sieges against random stations in the vicinity, but they have to undertake the risk of encoding both a navigation chip nearby and scan the station in detail. Now defenders can know that they may be at risk for a siege and could even try to destroy the scanning ship if someone is in the area.
I plan to return to the topic of sieges in the future, but the next article will be on Stations and Capital Ships. What uses do you think for sensors? Do you think that they should be changed from what I envision in this article? I would love to hear your comments.
Sensors in Starbase have the opportunity to provide huge changes to gameplay and to support a number of systems. However, before discussing the details of sensing, I’d like to mention that such a system should be based around options, not impossibilities. For example, if a pirate can detect a miner from hundreds of kilometers away and launch an attack without the miner having any way to detect the incoming pirate, then that is something that should be avoided. While it may not always be equal in the field, the design of the system should allow for opportunities for counterplay.
The first step of any sensor setup is determining what is being sensed and how. I propose that radiation in Starbase should be split into two forms: Infrared and Radio. This offers more opportunities for signal analysis without overcomplicating things like if a fully realistic model was adopted. Infrared radiation would be detected by passive IR sensors only, and it would be produced by heat-radiating objects. Ships in general would radiate infrared radiation, with non-maneuvering thrusters emitting most strongly as they visibly exhaust a hot stream of particles outside of the ship. Station industry would also emit strongly in the IR spectrum, as certain objects (e.g. alloy forges) would naturally be hot, and others would radiate waste heat from drawing electricity. Certain materials in asteroids would radiate in the IR spectrum, with exorium specifically noted to be radioactive and a fission fuel and therefore steadily leaking some IR radiation from radioactive decay heat. Lastly, space weather can play a role in IR emissions. We see lightning and flashes of light in the belt currently, and these could be used to generate an ambient IR emission that adds a constant noise floor to IR sensors that can vary based on location and temperature.
With the exception of thrusters, IR should a simple and direct relation to how much electricity is consumed by a ship or station part, or how much fuel is consumed by a ship or station part. This means that solar panels would produce no heat by themselves, but fuel chambers would. Nevertheless, solar panels cannot grant full stealth as there are still other components on a ship or station consuming electricity and radiating heat. The relationship between heat produced and electricity/fuel consumed should be exponential. This allows for tradeoffs between taking a hit on mass and space efficiency to use a larger amount of devices run at lower capacity for stealth, and it means that naturally high consumption devices like mining lasers and weapons will show up very strongly on IR receivers. Thrusters should also follow this exponential curve, but with a flat multiplier to heat produced (e.g. 2x) to simulate that they’re directly exhausting a very hot source outside of the ship rather than radiating from the whole structure. I ran some calculations and a Heat = Power^1.2 curve seemed suitable, but this should be play tested.
Radio emissions is where things get a little more complicated. In reality, very little is a natural radio emitter besides stars, other stellar objects, and lightning. Furthermore, exposed cross sections, material composition and arrangement, and many other factors depend on the radio reflection received by radar antennas when scanning an object. In Starbase, most of this should be simplified for both performance and ease of use reasons. Radio sensing can be split into both passive sensors and active sensors (radar). Passive sensors can only detect radio sources, which would be ship/station transmitters, ship transponders, public station transponders, and radar antennae. This means that passive radio receivers are less useful by themselves than passive IR receivers, but they can detect an enemy that’s not maintaining radio silence or enemy ships that are scanning the area to find something. Furthermore, they’re a vital half of an active radio sensing setup.
Radar antennae act as the active half of an active radio sensing setup. When paired with a passive receiver, ship and station owners can choose to emit radio waves to scan an area. Asteroids would have a radar return dependent on what’s in their core, potentially with density determining the strength of the return. Ships would have a return dependent on either their voxel volume or mass, with the proportion of exposed materials providing a modifier to this. If an entire spaceship is covered in plating of an appropriate material (possible examples include Tengium), then its radar signature is greatly reduced compared to a spaceship with no plating or plating made of materials with high radio reflectivity. Stations would have a radar return dependent on the volume of the station. Radar antennae would create a very strongly detectable signal for passive radio antennae in the path of the beam, and a weaker but still present signal for passive radio antennae located anywhere else near the transmitting ship.
Now that we know what we’re sensing, we can talk about how to sense it. Physically constructing the antennae can be relatively similar to constructing radiators. There would be a core piece attached to a hardpoint with a power connection, and then pieces can be mounted to it to enhance the antenna’s sensitivity or emitting power. Frozenbyte could also choose to restrict antenna shapes to things like cross shapes, circles, squares, or other options. Lastly, antennae must be exposed to space. This both makes logical sense, and it adds potential vulnerabilities to ships. Making antennae extensible also opens up opportunities for counterplay. A pirate in a small ship quietly scanning the area on passive IR would present only a minimal signature unless someone happened to point a radar beam right at his ship. However, because mining ships can grow to be very large (over 10 million kg), carrying tens of thousands of kg of antennae is a rather small fraction of their weight. While the pirate has the opportunity to choose his easily detectable targets in peace, when he starts closing in for the kill, the larger antennae on the mining ship give the miner the opportunity to see the pirate coming and try to prepare to either fight, run, or negotiate.
Passive antennae would have relatively simple configuration options. The sensitivity of the antenna would be determined by its physical size, and this would change as pieces get shot off or added. As for configuration options, the only one would be exposure time. A larger exposure time helps get a clearer reading on objects and help detect a very faint signature such as a far away asteroid or stealth ship that’s stationary. However, a larger exposure time would weaken returns from moving objects as they would appear to be diffuse smears to the sensor rather than a point-like object like a ship. Exposure time would have a minimum and maximum value, and the output of the device (more on this later) would change only after each exposure period is complete.
Radar antennae would be more complicated. In real life, radar antennae have a variety of frequencies and other options, but these should be simplified for the game. The field of view of the radar antenna should be configurable within a minimum and maximum value. This allows the radar beam to be shaped and adjusted to suit various circumstances where either one object needs to be scanned in great detail, or larger portions of the sky can be examined. The radar should of course have a power setting, which adjusts how much electricity the antenna consumes and how strong the radar beam. High powered beams produce very clear returns, but also advertise your position even more readily to people nearby. The antenna should also be rotatable, with this possibly being animated on the ship, to scan various portions of the sky. Lastly, the pulse frequency of the radar should be configurable. This would be very similar to the exposure time of passive sensors, but a higher pulse frequency would draw more power and generate a stronger radio signal. Combining pulse frequency with exposure time offers some possibilities for detection. A very high pulse frequency with a very low exposure time means that a complete radar set is highly effective at picking out large or moving ships, but at the cost of a very strong radio signature. A low pulse frequency and long exposure time is well suited to a miner scanning the area to detect minerals and offers a somewhat stealthier radio signature, albeit one still detectable to sensitive antennae in the area or an antenna in the path of the radar beam.
After collecting the data, it’s time to analyze and output it. The radar antenna itself will not output any data, but passive antennae will. It’s at this point where I ran into difficulty with YOLOL and sensor data. It’s very easy to suggest a “sensor display” part that projects sensor data onto either a 2D or holographic display and lets users visually interpret it. However, it’s harder to expose this to data without either requiring extensive signal processing (which current YOLOL may struggle with) or offering very specific details that defeats a lot of the ambiguity that should be present. This is what spurred my suggestion for YOLOL reform in Article 6, especially the addition of arrays. From this point forward, I’m operating under the assumption that YOLOL has been adjusted according to Article 6 and arrays are present. I’m not going to discuss a separate programming language in this article.
For a visual output, I think that a sensor display part should project the data in-world if possible and offer the possibility for endos to interact with it and integrate the data with their personal maps. This means that when within range of a sensor display module, a new overlay would be available on your map for you to view the sensor data. This lets you easily cross-reference known stations and waypoints to see if any of the sensor returns belong to something explainable, or if it represents a new opportunity or threat. It also lets you easily drop a marker on a sensor return to come back there later, which can be used for marking ore hotspots or potential enemy stations.
Visually, the sensor map would display background radiation as a dim glow, which serves the purpose of helping to hide very weak sensor returns. Depending on the sensors connected to it, a sensor map could be set to IR, Radio, or Combined mode. Combined would add the radiation returns received by both sensors onto the map, and it would be situationally useful if background radiation is high in both spectra. IR returns would be colored red, and Radio returns would be colored blue to help distinguish which sensor is detecting the signature. “Known” large objects like Titans or Moons would appear as solid and distinct objects on the map, but they would cast sensor shadows that offer opportunities for hiding a ship or station. Otherwise, how objects appear depends on the size and strength of the return. Large and well-developed stations will display as a sensor return spread out over a wider region of space than a tiny endo scooter, if the scooter is even visible at all.
In IR mode, the only information available would be the signal size, strength, and distance. All of these would have some level of uncertainty that would make them appear as various sizes of clouds rather than a 1:1 image of what the ship/station/asteroid/weather event looks like in-world. If a return is well-established then it does get narrowed down to a point shape, but remote examination of the object would not be possible beyond analyzing its signature. This means that an exorium asteroid returning with a Signal Strength of 100 at 50km away would look nearly identical to an asteroid sized ship with a Signal Strength of 100 at 50km away. Increasing the exposure time of the sensor helps to increase the signal strength of stationary objects but reduces it for moving objects. This could potentially be used to try and help filter out or include ships on the display.
In Radio mode, more information is potentially available. Natural passive radio returns are very rare besides belt lightning, so the noise floor could potentially be very low if you’re in a part of space that’s not experiencing a space lightning storm. However, the chance of picking something up is also equally low unless you are willing to perform an active scan. Unless a ship or station is using a radio transmitter device, a public transponder, or a radar antenna, it would have a small or zero passive radio signature. Therefore, radio detection can benefit from a low noise floor, but to really get any data you have to be willing to reveal your own position in turn. Radio returns would function very similarly to IR returns, but if the signal is strong enough you can potentially tell the material composition of the return. This should be carefully balanced, as it’s a dead giveaway for an incoming ship. No natural asteroids are made out of as many materials as ships after all. To balance this, the sheer number of materials can confuse the signal processor in the passive radio receiver and return a “Composition Unknown” tag for the return. At long distances and when stationary, this may not arouse too much concern as asteroids past a certain distance would return the same tag. However, if a Composition Unknown tag is heading straight for you or otherwise drifts too close to your ship, that would be cause for concern.
YOLOL can also interact with sensor output. Arrays would be critical here, as toggling through all the available returns like with the material scanner’s material selection field would be too slow in most cases, as there could be a sizeable quantity of returns. The array could return a list of signals with their heading, distance, and strength stored as subfields. Radio returns of sufficient quality could also have a composition subfield. YOLOL chips could then interact with this data to process it for various uses. Whether it’s to automatically highlight asteroids with desired ore, or to sound an alarm when a moving return gets too close, YOLOL can be used to enhance the capability of sensors, or to reduce the need to look at a sensor display while operating a ship solo. Manually examining a sensor display can be made more accurate through a number of ways as well. If there’s a Strength 100 Size 20 return hiding inside a Strength 70 Size 80 return, a sensor display may be able to highlight the two separate returns, while Frozenbyte could choose to average the two and make the output available to YOLOL. It’s dependent on whether maximal YOLOL processing is desired, or if Frozenbyte wants to emphasize manual attention to sensors.
What do these sensors enable? They enable many different features for both PvE and PvP players, which is important. Considering PvE first, they represent an enormous opportunity to enhance the asteroid mining experience. While a separate Ground Penetrating Radar component would handle examining Titan Asteroids and Moons, Passive IR and Radar would allow miners to scan the area around them and pick out asteroids with the desired ore. Passive sensors would likely not be directly helpful outside of searching for exorium, but if players know that ore hotspots are frequently camouflaged by space storms, they can scan for high background sensor returns and set course for that area. While in the storms, their passive sensors would be heavily restricted, but the tantalizing offer of a rich asteroid field may be worth the risk of a ship sneaking up on you. Radar would also be helpful for scanning asteroid fields and picking out asteroids with the desired ore nearby. The downside to scanning the area with radar is that using it makes you very visible to Passive Radio Sensors in the area.
Sensors also offer many opportunities for PvP. The most commonly discussed use is finding miners, but miners also can use sensors against pirates. Because mining ships are frequently larger than dedicated fighters, miners have enough spare thrust to carry larger sensor arrays. This fact prompts specializing pirate ships into also mounting larger sensor arrays to detect miners from ever further away, which increases their vulnerability to escorts due to the extra weight and openings in the hull, or they can spend the resources to stealth up their ships. Special baffles, which could be a variant of the regular thruster parts or an optional addition, help reduce your IR return at the cost of expense, weight, and possibly performance, while crafting your outer plating out of radar absorbent material can reduce your radio return at the cost of being weaker armor.
Mining ships as well can evolve to meet the threat of pirates with sensors. Right now, players can confidently rely on the largeness of space to hide them in almost any scenario and very few miners are armed or armored. However, if miners know that pirates have a much larger chance of finding their large thruster returns or the radar used for scanning asteroids, it prompts miners to make some changes. They too could invest in highly stealthy mining ships, although the cost may be enormous to plate an entire design in radar absorbent material, or place baffles on all the dozens of thrusters on the ship. Instead, miners may choose to place armaments on their ships to give them a fighting chance against an intercepting pirate.
Sensors also play a role in holding territory, warfare between players and companies, and sieges specifically. Claiming and holding territory is done through building stations and expanding them. Naturally, players will want to do things with their territory, and that involves building resource gathering, ship building, or other infrastructure on their stations. However, all this infrastructure increases the IR return of the station, making it ever easier to find on sensors. Enemies can survey asteroid belts, moons, and other areas looking for these returns and can then examine them closely. Right now, capital ships can launch sieges against any station within a certain radius of a navigation chip through a “magic” detection radius. This should be discarded and replaced with the necessity to perform a radar scan of the station before a siege can be launched. This scan should take at a minimum several minutes to be performed, and results in an “enhanced” or “verified” waypoint being made available on the player’s personal map. Afterwards, the player can share this waypoint with a group, company, or alliance, and then sieges can be launched by anyone with access to this enhanced/verified waypoint and a capital ship with a navigation chip encoded to within a certain radius. This extended process ensures that companies cannot launch sieges against random stations in the vicinity, but they have to undertake the risk of encoding both a navigation chip nearby and scan the station in detail. Now defenders can know that they may be at risk for a siege and could even try to destroy the scanning ship if someone is in the area.
I plan to return to the topic of sieges in the future, but the next article will be on Stations and Capital Ships. What uses do you think for sensors? Do you think that they should be changed from what I envision in this article? I would love to hear your comments.
