Jump to content

Sensors


Ripper

Recommended Posts

This is MY vision of what sensors should look like.

 

Low Gain Omni Sensor:

 

antenna_omni_low_gain.gif

 

High Gain Omni Sensor:

 

antenna_omni_high_gain.gif

 

Low Gain Directional Sensor:

 

antenna_patch_coverage.gif

 

 

High Gain Directional Sensor:

 

antenna_yagi_coverage.gif

 

BEAM Sensor:

 

antenna_directional_coverag.gif

 

 

ANYTHING detected within the AREA of the sensor, is reported back to the DPU. 

 

 

Link to comment
Share on other sites

Would be pretty cool to have your ships enemy tracking and targeting implemented in lua. Brings up some question how much information would you provide to lua? Would your sensor just provide mass and a direction or do you give full information like its a ship owned by such and such?

 

Would be cool to have a transponder element that you could place on your ship so that you could choose to identify yourself (or not) and perhaps you could build ships with a low heat signature so that it reduces the detection range. You could go "silent running" so that you are less visible if pirates are about (or wait in hiding where you know someone will be :D )

 

In fact you have a whole active verses passive scanners thing going on which will be interesting. You could have a narrowly directed active scanner for checking stuff out in the distance that you trigger manually so you don't expose yourself and then a all round passive scanner looking for people who might be approaching

Link to comment
Share on other sites

Here's MY understanding of "Tabbed Targeting":

 

The servers provide XYZ positioning data for all objects.  (my guess is that means Core Units or Avatars)

The client uses that information.

The sensors would be client side.  If an object is detected within the "Area" of the sensor, it would be acted upon.

The sensor doesn't need to provide positioning, because the client already has it.

The sensor just returns "ObjectID".  (which simply means ShipID TRUE or AvatarID DETECTED)

 

The DPU then acts upon the information.  It may display it's XYZ coords. on RADAR, open a door, or activate a turret.  The actionable data is "hashed" in a manner completely defined by the player's DPU.

Link to comment
Share on other sites

Here's MY understanding of "Tabbed Targeting":

 

The servers provide XYZ positioning data for all objects.  (my guess is that means Core Units or Avatars)

The client uses that information.

The sensors would be client side.  If an object is detected within the "Area" of the sensor, it would be acted upon.

The sensor doesn't need to provide positioning, because the client already has it.

The sensor just returns "ObjectID".  (which simply means ShipID TRUE or AvatarID DETECTED)

 

The DPU then acts upon the information.  It may display it's XYZ coords. on RADAR, open a door, or activate a turret.  The actionable data is "hashed" in a manner completely defined by the player's DPU.

 

You may script yourself your sensor, and cull all wanted or unwanted sensed targets within an algorithm

 

That a quite tricky geometry + math algorithm calculation, but once its done and you understood how it works, you might get rich selling it

Link to comment
Share on other sites

There's no geometry involved for the end user OR the LUA programmer.

 

A turret only needs to know the target is within its area of influence (think of this as a hard coded turret sensor).  The Turret element has the code to actually target and fire upon the ship.

 

A RADAR display ONLY needs to know a list of "ObjectID's".  All the geometry would be performed within the hard coded RADAR element itself.  But It would also be nice to specify a color with the ObjectID to indicate friend, foe, faction, or any other player defined preference.

Link to comment
Share on other sites

There's no geometry involved for the end user OR the LUA programmer.

 

A turret only needs to know the target is within its area of influence.  The Turret element has the code to actually target and fire upon the ship.

 

A RADAR display ONLY needs to know a list of "ObjectID's".  All the geometry would be performed within the RADAR element itself.

 

 

Yes its simple, but the radar itself may sens every ID's within its range, a spheric range, and it will be your job to filter desired ID's, by comparing their coordinates with your algorithm

 

If you take off this part from the LUA then there is no use of it

 

And wrong, there is geometry in the LUA, since ID's coordinates are in 3 dimensions, X,Y and Z

So for your example you just google the expression of a cone, write it down in your filters, and collect a list of TRUE and FALSE and assume firing on the TRUE or FALSE list

Link to comment
Share on other sites

You're confusing a LOT of premade Elements provided by NovaQuark.

 

1.  A radar display is NOT a radar sensor

2.  A radar display IS a premade element provided by NovaQuark

3.  A sensor IS a premade element provided by NovaQuark

4.  A sensor "senses" objects within its field of influence

5.  The ONLY element YOU can program is the DPU.

 

I have no need to define a "cone" and detect whats within it.  There are DIFFERENT types of sensors, with DIFFERENT shapes and ranges. Per my OP.

 

So here's how it works.

Sensor provides list of ObjectIDs to DPU

DPU Filters list of ObjectIDs and specifies Friend or Foe (and any other filter defined by player)

DPU sends entire list to RADAR_Display

DPU sends FOE list to Turret

RADAR_Display Displays ALL information handed to it (and hopefully can color code)

Turret uses its OWN sensor to "see what it can see" and what's in range

Turret cross references its object list with the FOE_List

Turret Fires

Link to comment
Share on other sites

You're confusing a LOT of premade Elements provided by NovaQuark.

 

1.  A radar display is NOT a radar sensor

2.  A radar display IS a premade element provided by NovaQuark

3.  A sensor IS a premade element provided by NovaQuark

4.  A sensor "senses" objects within its field of influence

5.  The ONLY element YOU can program is the DPU.

 

I have no need to define a "cone" and detect whats within it.

 

So here's how it works.

Sensor provides list of ObjectIDs to DPU

DPU Filters list of ObjectIDs and specifies Friend of Foe (and any other filter defined by player)

DPU sends entire list to RADAR_Display

DPU sends FOE list to Turret

RADAR_Display Displays ALL information handed to it (and hopefully can color code)

Turret uses its OWN sensor to "see what it can see" and what's in range

Turret cross references its object list with the FOE_List

Turret Fires

 

 

1. I was replying to your dream of what sensors should look like:

And my answer was very clear, its not NQ that will do it, but yourself by working on it a little bit

 

2. I advice you to have a newer look at interaction between elements and dpu in the devpost about LUA

 

3. I will remember never purchasse anything that you scripted

Link to comment
Share on other sites

 

 

And my answer was very clear, its not NQ that will do it, but yourself by working on it a little bit

 

Please define "it".  Because your answers are obviously not clear.

 

Thanks, I've thoroughly read the LUA devblog.

 

A radar display displays the information provided to it.

 

Please provide an AUTHORATATIVE post that says "all sensors are spherical."

Link to comment
Share on other sites

I'd like to add.

 

YES!

 

You're right! You can use your own algorithym to "pare down" or "cripple" your sensor.  But why would you?  There may be a reason, but I can't think of it.

 

If my sensor can detect every enemy ship within a given area, why would I not provide that entire list to my weapons?

Link to comment
Share on other sites

Please define "it".  Because your answers are obviously not clear.

 

Thanks, I've thoroughly read the LUA devblog.

 

Ok, your topic is interesting, so i m not going to talk about anything else than the sensor element provided by NQ

 

I m not 100% sure of what will offer this element, but it might be very simple, and only do detection within a spheric range, and transmit a list of IDs and coordinates to your DPU that is in the middle between this sensor and an other element such as a firing barrel, and the whole thing together would make a turret.

 

In the DPU, you will be given opportunity to filter the detected list of IDs by adding some LUA code lines

It will be up to you to design that filter, and giving it a shape of cone or donut by writing down the desired expression

 

example: (very simplified filtering script)

 

{if (detected xyz) < (donut shape expression xyz)

detected xyz = TRUE ;

 

then

send message to barrel element = look at xyz;

 

then

send message to barrel element = fire;

 

else 

detected xyz = FALSE ;}

 

 

but to be honest i would suggest to use a more simple volume than a cone or a donut, but more spheric or cubic shapes

would simplify a lot its expression

 

So as conclusion, your topic is already a possibility given by LUA, which NQ wants us to improve

Thats why i said if you make it you ll be rich, because all the graphics you posted have a volumetric expression with xyz, but freaking complicated

Link to comment
Share on other sites

That idea is great, but please note that sensors are not using magic to detect, they use EM waves, and those can be absorbed and/or reflected and/or detected.

In the case of detection, pure passive scanners (like cameras basically) can be used to prevent detection, but those give quite lower resolution or ark of detection.

You can detect active scanners with active and passive scanners, because those light up in the direction they detect in.

Link to comment
Share on other sites

Jeronimo,

I completely agree.  And this is pure speculation until we here from NQ.

 

Wicpar,

 

I like where your head is at.  Let's hope we have a multitude of sensors.  If EM waves are traveling at the speed of light, how do we detect FTL ships?  :D

Link to comment
Share on other sites

The client will obviously have MORE data than we have on screen.  This way, it will show the positions of objects outside of our vision.  I would assume this would include every object up to deep space scanner radius.  The network code may support more than that, but I think it would be a waste of bandwidth to send the position of everyone.  Who cares about the bloke two star systems away?

 

But how does NQ protect that information from being exploited?

Link to comment
Share on other sites

That idea is great, but please note that sensors are not using magic to detect, they use EM waves, and those can be absorbed and/or reflected and/or detected.

In the case of detection, pure passive scanners (like cameras basically) can be used to prevent detection, but those give quite lower resolution or ark of detection.

You can detect active scanners with active and passive scanners, because those light up in the direction they detect in.

then nq will need to implement deflector, absorbator, reflector elements... that would be interesting

Link to comment
Share on other sites

The client will obviously have MORE data than we have on screen. This way, it will show the positions of objects outside of our vision. I would assume this would include every object up to deep space scanner radius. The network code may support more than that, but I think it would be a waste of bandwidth to send the position of everyone. Who cares about the bloke two star systems away?

 

But how does NQ protect that information from being exploited?

maybe just by checking all game files before game starts, to be sure the client isnt modified

Link to comment
Share on other sites

Wicpar,

 

I like where your head is at. Let's hope we have a multitude of sensors. If EM waves are traveling at the speed of light, how do we detect FTL ships? :D

Subspace magic of course ^^. But you can do without by detecting techyons, a theroetical superliminal particle. If we force warp drives to generate those it would be quite prectical, but we should think of a twist, something that you can to to hide it or play it. Best solution is the simple one: a tachion generator that can emulate a tachyon source in its vincinity to make fake big attacks or scare people etc. Cloacks should also emit tachyons so you can do really interresting psychological warfare.

Link to comment
Share on other sites

maybe just by checking all game files before game starts, to be sure the client isnt modified

Even that can be fooled. The problem is you can ever only have ontrol of heigher levels and never lower. For instance the stack looks like this: reality > hardware > kernel > os > programm > cloud

 

Here you want the cloud to be in control of the program and you cannot be 100% in control which is bad.

But: if NQ computes its physics on the cloud, then it can only send the relevany information.

Server side computing is inevitable if you want security. And it is feasible. We in 2016 right?

Link to comment
Share on other sites

The OP specifically addressed my concept of sensor "areas of influence"

 

A basic sensor would provide the "ObjectIDs" of everything in that area.

 

I DO like the idea of active and passive.

 

I also like the idea of detecting space-time curvature and tachyons.

 

I think ADVANCED sensors could provide additional data such as the object's vector. (This could be computed by the player at the DPU level too)

 

It would be nice to have different "icons" for the sensor display. Different sized dots, arrows, lines,etc.

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...