Ripper Posted September 15, 2016 Share Posted September 15, 2016 NovaQuark has not provided details on how sensors work. Everything mentioned in this thread is speculative.Here's my IDEA, and reason for the thread. Allow for "sensor dimming" by adjusting input power to the sensor. This reduces the size of the "Area of Influence".In the previous sensors thread, I suggested the following:===== Sensor Elements =====Sensor Elements do NOT have to be omnidirectional. Hemispheres, cones, cubes, and beams are possible.Sensor Elements ARE different than Display ElementsSensor Elements detect all core units or avatars within a defined 3D "Area of Influence"Sensor Elements ONLY need to return the "ObjectID" from the core unit or the player's Avatar.Advanced Sensor Elements can return more information than the ObjectID, depending upon how NQ codes them.===== Display Elements =====Display Elements (radar display) will only need to know the ObjectIDDisplay Elements will be hard coded by NQ, to display the XYZ position of known ObjectIDsAdvanced Display Elements may take additional attributes such as "Friend or Foe" designationAdvanced Display Elements may take additional "Color" attributesAdvanced Display Elements may have the ability to provide different icons "on screen"===== The DPU =====The DPU can be used for filtering ObjectIDs provided by the sensor to the DisplayThe DPU can be programmed by the player to filter however they like.===== Flow of Data to the Display =====Information is passed from the Sensor --> to the DPU --> to the Display===== Weapon Elements =====Weapon Elements have their own hard coded sensorWeapon Elements attack ALL ObjectIDs passed to them by a DPU===== Flow of Data for Weapons =====Information is passed from a DPU --> to a Weapon ElementThe DPU obtains that list of ObjectIDs however the player decides, including from a sensor. Neosphaler and Underhand Aerial 2 Link to comment Share on other sites More sharing options...
DaSchiz Posted September 15, 2016 Share Posted September 15, 2016 However sensors are done I already have the best countermeasure ... Wicpar, Kuritho, Lord_Void and 1 other 4 Link to comment Share on other sites More sharing options...
MrFaul Posted September 17, 2016 Share Posted September 17, 2016 Man I love that movie xD Link to comment Share on other sites More sharing options...
Anaximander Posted September 17, 2016 Share Posted September 17, 2016 Sensors 2 : Sensor Harder Link to comment Share on other sites More sharing options...
StoneLegionYT Posted September 17, 2016 Share Posted September 17, 2016 I love things like Scanners, Radar's, Sensors, Probes, etc. I know we can fire off Prove I don't know much info about them besides being able to warp to them? It be cool though if you own a moon or live in a system or hell out of a system randomly somewhere in the darkness that you can setup some sort of decent sensor net that can alert your entire organization if events. Link to comment Share on other sites More sharing options...
Ripper Posted September 19, 2016 Author Share Posted September 19, 2016 Here's another idea about sensors: COMMUNICATIONS We know that Core Units will be used for Identification, and the RDMS system. This means a sensor should be able to detect the core unit and provide basic feedback from the construct. (who currently has rights to the construct, and also the possibility of assigning rights to the construct, plus a variety of other aspects of identification) Construct to Construct communication can be COMPLETELY fascilitated via sensors and core units. The core unit just needs to have some extra "custom fields" that are scannable by a sensor. The core unit fields could be modified by LUA, and the sensor data could be retrieved by LUA. From there, the rest of the communications should be doable with a player's script. Link to comment Share on other sites More sharing options...
Anaximander Posted September 19, 2016 Share Posted September 19, 2016 Well, we should be getting a telemetric sensor to deduce our distances from a star, so explorers do know how long they have before reaching said star and hopefully, if the first law of motion graces us, we get some satisfying piloting calculations so our navigators can feel loved on how good they are at braking the ship's velocity Link to comment Share on other sites More sharing options...
Lord_Void Posted September 20, 2016 Share Posted September 20, 2016 It would be interesting if sensors not only had an area of influence but also had a strength attribute that affected it's ability to operate at certain ranges. So for instance at a very long range you would only be able to tell there was a ship, but not any specific attributes about. As the ship got closer into range or the sensors are in some way manipulated (perhaps the scan area is decreased in order to increase scan strength) more attributes would become scan-able. Various skills could affect different aspects of scanning: skill at pinpointing ship's location, owner, elements (what kind of equipment it has), crew size, cargo hold, etc. This could make being a dedicated scout/scanner a valuable career path. it could also make it a bit more fun and challenging rather than a simple point and scan. Link to comment Share on other sites More sharing options...
Ripper Posted September 20, 2016 Author Share Posted September 20, 2016 Yeah, I agree. Consider the sensor to open a door. You wouldn't want the range to extend beyond the part of the hallway. Being able to adjust it's range is needed. Link to comment Share on other sites More sharing options...
Cornflakes Posted September 21, 2016 Share Posted September 21, 2016 Here i outlined some basic ways to define actual detection. NovaQuark has not provided details on how sensors work. Everything mentioned in this thread is speculative.Here's my IDEA, and reason for the thread. Allow for "sensor dimming" by adjusting input power to the sensor. This reduces the size of the "Area of Influence".In the previous sensors thread, I suggested the following:===== Sensor Elements =====Sensor Elements do NOT have to be omnidirectional. Hemispheres, cones, cubes, and beams are possible.Sensor Elements ARE different than Display ElementsSensor Elements detect all core units or avatars within a defined 3D "Area of Influence"Sensor Elements ONLY need to return the "ObjectID" from the core unit or the player's Avatar.Advanced Sensor Elements can return more information than the ObjectID, depending upon how NQ codes them.===== Display Elements =====Display Elements (radar display) will only need to know the ObjectIDDisplay Elements will be hard coded by NQ, to display the XYZ position of known ObjectIDsAdvanced Display Elements may take additional attributes such as "Friend or Foe" designationAdvanced Display Elements may take additional "Color" attributesAdvanced Display Elements may have the ability to provide different icons "on screen"===== The DPU =====The DPU can be used for filtering ObjectIDs provided by the sensor to the DisplayThe DPU can be programmed by the player to filter however they like.===== Flow of Data to the Display =====Information is passed from the Sensor --> to the DPU --> to the Display===== Weapon Elements =====Weapon Elements have their own hard coded sensorWeapon Elements attack ALL ObjectIDs passed to them by a DPU===== Flow of Data for Weapons =====Information is passed from a DPU --> to a Weapon ElementThe DPU obtains that list of ObjectIDs however the player decides, including from a sensor. i like the idea of just needing the object ID to identify a located target in the computer system, but it also seems slightly limited in what the player can do with software to locate/identify/track targets. maybe replace it with a more generic "point/vector" primitive to which characteristics can be added by the player? the primitive would contain an origin, a direction and optionally a distance. so its denoting "somewhere in that direction" or "exactly there". those primitives can be handed over to other systems (like turrets) and the game engine handles all necessary coordinate transformations. (cause thats a pain) the primitives would be reusable for other purposes other than detection as well, for example for general navigation and communication of directions. (hell, the direction vector could directly be utilised for target designation by the player "the first ship that intersects with my pointing vector", a raycast) so, now to actual gameplay and not programming details. a passive sensor cant determine the distance to an object on its own. it either needs a reference emission strength (it receives x watts/m² object radiates y watts so the distance has to be r away x=y/r²) or a second passive measurement which has to be some distance away to cross the vectors and to determine the distance that way. active sensors provide their own reference emissions and thus can pinpoint targets on their own, but they are very visible over great distances (the square of their detecion range assuming identical ships) again the vector math should be done by the game engine the vector headings shouldnt be perfectly precise but have some imprecision in their heading. so one sensor might have an angular resolution of 0.5° which gives good enough data at short ranges but isnt suitable for long range fire and another sensor might have an angular resolution of 0.025° which is suited for much longer range pinpointing but the sensor also has balance defined drawbacks. this would enable confusion plays with multiple ships flying close to each other. appearing like a bigger target or a different target than whats searched for. player programming skill should come from choosing which vectors to analyse more closely and which vectors to "cross" to determine pinpoint coordinates. the rate at which vectors can be compared could be game mechanics limited ( x comparisons/second per DPU) so that good programmers would have an edge in terms of target detection by smart choice of the vectors to analyse and cross for coordinates. so one could run target identification by brute force and a large amount of DPUs or by smart checking and using the resources they have optimally. with a way to have DPUs communicate even across constructs (linky) would encourage having specialised sensor and processing ships, which weave their com nets through the fleet and supply the less sensor focused ships with targetting data. so for large battles dedicated C4 ships would be highly useful to keep all the targetting data organised, precise and distributed to the combat ships. this also opens the gates for player made countermeasures. have an emitter randomly switch on and off to confuse the distance assesments of active sensors. throw out flares to confuse passive sensors. randomly toggle emitters distributed over the surface of you ship to obfuscate your position and velocity vector. edit: after posting i noticed a small gap in my explanations: sensors on their own dont provide pinpoint coordinates, the player has to process data in DPU's to get pinpoint data. the sensors directly only provide directions and emission strengths Velenka 1 Link to comment Share on other sites More sharing options...
Ripper Posted September 21, 2016 Author Share Posted September 21, 2016 A basic sensor could detect only the ObjectID within the "Area of Influence". An omnidirectional sensor would essentially say an object is near you. A directional sensor, could respond that an object was detected off your starboard side. Sensor 1.0 - ObjectID Sensor 2.0 - ObjectID, XYZCoordinates Sensor 3.0 - ObjectID, XYZCoordinates, Distance etc... I DO very much like your emission strength, and counter measures. Link to comment Share on other sites More sharing options...
Cornflakes Posted September 21, 2016 Share Posted September 21, 2016 A basic sensor could detect only the ObjectID within the "Area of Influence". An omnidirectional sensor would essentially say an object is near you. A directional sensor, could respond that an object was detected off your starboard side. Sensor 1.0 - ObjectID Sensor 2.0 - ObjectID, XYZCoordinates Sensor 3.0 - ObjectID, XYZCoordinates, Distance etc... I DO very much like your emission strength, and counter measures. i think a sensor should /never/ just provide the ObjectID. determining an object ID is the job of the computer behind the sensor. a sensor should provide "theres a signal", and the player has to figure out the rest with DPU magic. the sensor doesnt know /what/ it is in first iteration. it could be a single generator generating heat and nothing else, it could be a ship with a generator, it could be a group of ships close together. the "object" the sensor detects is only some generic radiation, the DPU has to make sense of that itself. if you add some ID to that signature its fine, thats your thing. but the sensor just tells you that theres /something/. Link to comment Share on other sites More sharing options...
Kuritho Posted September 21, 2016 Share Posted September 21, 2016 A basic sensor could detect only the ObjectID within the "Area of Influence". An omnidirectional sensor would essentially say an object is near you. A directional sensor, could respond that an object was detected off your starboard side. Sensor 1.0 - ObjectID Sensor 2.0 - ObjectID, XYZCoordinates Sensor 3.0 - ObjectID, XYZCoordinates, Distance etc... I DO very much like your emission strength, and counter measures. Another cool thing would probably allow sensors to detect gases, liquids, and/or unauthorized material (like a testFor Narcotics). Maybe even allow it to detect colors, so your ships won't be detected or something. Link to comment Share on other sites More sharing options...
Ripper Posted September 21, 2016 Author Share Posted September 21, 2016 i think a sensor should /never/ just provide the ObjectID. I think you're confusing ObjectID with "Object ID" ObjectID is NovaQuarks unique identifier of each "core unit". It would look something like: ObjectID=asdf8af87648496234 The "Object ID" is something like: Avatar="Ripper" or Ship="Ripper's Awesome Ship Of Massive Destruction" The ObjectID will be utilized by mesh elements and those players that want to reference it in the DPU If two Objects are within sensor range, you would need a method to distinguish between "blip 1" and "blip 2" That's why the ObjectID would need to be returned. You're not getting any "intelligence" information. You're just getting the assigned unique identifier. Less friendly fire accidents that way. You're not firing at both "blips". Link to comment Share on other sites More sharing options...
Cornflakes Posted September 21, 2016 Share Posted September 21, 2016 If two Objects are within sensor range, you would need a method to distinguish between "blip 1" and "blip 2" That's why the ObjectID would need to be returned. You're not getting any "intelligence" information. You're just getting the assigned unique identifier. thats the intention you shouldnt be able to tell two identical blips apart without extra data. or even if the blip in question is anything at all (think sensor confusing environment conditions). with better and better sensor data you should have an easier time telling what it is, but not magically gain unique identifiers. cause how can your sensor say that the thing its detecting is core unit fb5cdeff883c2 and not fb5cdeff883d2 ? all your system knows is "blip 1" (with emission signature 1) and "blip 2" (with emission signature 2) or however you name them in your code and what other data your system gains through other game ways. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now