Sensors Anyone?

[SteelNorthman]

• The idea that me and Jay have been coming up with is that all ships (probably in the ship core) have transponders, which constantly broadcast Name, Pilot, Faction (when available). Now "hidden" objects for star made would be interesting. Would be like hidden in-between sectors with either asteroid fields or ship graveyards for salvagers. The graveyards would have to run off either a special folder or preselected blueprints in servers, and they get random damage down to them to make them look good. Probably will have to have their ship cores removed to prevent players from just outright using them.
  
• The "Hidden Sectors" basically have only one way to enter them, say, from one sector you can enter but from the sector of the other side you can't. If you try and enter the hidden sector from the wrong way you're basically "Teleported" to the sector across from your position and you don't enter the sector.
• The Jamming systems, would most likely be used to hide sectors/objects that are not ships like asteroids, space stations, and maybe planet bases (if they come to be). For ships you'd use the radar jammers and cloak systems, but when using "active scanning" like with probes, they'd still have a signal like that of derelict ships (destroyed ships) or asteroids.
• Now accelerator gates wouldn't be all that useful for star made's purpose, due to the varying size and masses of ships.
• I have no idea how/why it's bullet pointing these.

 

[Keptick]

Jamming could now serve to block the sensors. Perhaps the addition of jammer extender blocks would make things even better? If the jammer is slightly less powerful than the sensors then only basic information (size, faction) would be displayed, while powerful enough would simply block the scan completely. Having no jammer would give the scanning ship access to all the information you posted in the OP.

However it goes down, I support this idea!

 

[SteelNorthman]

Jamming systems for anti sensor use would make it a little more complex, there could be a few kinds of jamming computers to use.

• Passive Jamming: stationary objects only, like stations, asteroids even when moving for they don't move on power, and ships when not moving no power aka engines.
• Active Jamming: requires more power and works with ships only and can be combined with Radar Jamming and cloaking to "make you completely stealth"
• Radar Jamming: ship, stations, and asteroids only. removes object from basic (default) sensor systems, and another navigation system.

This is just what I think is a good base Jamming systems for simpler use.

 

[CoolDog3]

Yes, yes, and double yes!

 

[1adog1]

Wow this has gotten huge while I've been gone. Let me start inputting some opinions:

I've been recently think of this kind of thing too. In my opinion, sensors would be like most other systems, depending on the number of blocks in the system, it becomes more efficient and accurate, but the functions I've thought up are slightly different.

Functions:
range scales with x and z size, while accuracy scales with y. (set up like efficient power systems)
increases accuracy for turrets and AI within the range, that are apart of the same faction.
the computer block can be set to update to player/faction members if an object enters or leaves the sensor range, as well as giving simple information about object (size, mass, faction, pilot).

I would not have it send shields, power, or the what not for it is a little OP.

I agree with everything here except for the bottom, I think having it display shield capacity and percentage and power storage capacity (Should have specified) would make it more useful in combat. Love the idea of sensors slightly increasing turret accuracy, and the idea of having the same algorithms for efficiency as power generators.

Idea: Resolve the Overpowering accuracy and range with a server configurable hard limit. The AI accuracy can hit 750, but no higher, for instance. (99% accuracy at 750m). Different servers could have different limits, even keeping the ceiling at something low like 30, if they want. ("You can have sensors if you want, but the AI won't use it on this server!") Same thing for range. Range increase 1m per block (maybe server configurable) with a maximum range increase of 200m. Maybe put a parabolic curve on the increase formula for diminishing returns as more sensor blocks are added.

Maybe have range be a function of sensor dimension, not just count, so people would build giant sensor "dishes" instead of sensor "cubes".

Maybe limit the number of elements on a target ship that can be described as a function of distance, ECM variables (jamming and cloaking cubes), and sensor blocks.
So for example, a ship that's 2500 blocks away will simply be described as a ship with dimensions. Maybe make the dimensions have a random chance of being a few blocks off, so that a distance reading is unreliable. A ship that's 250 blocks away would have information like it's dimensions, docking status, shield status, mass, faction, etc. Things that are not visible or likely to be advertised should not be shown. For instance, while faction is likely advertised with a transponder signal (and inversely a pirate faction is advertised with a LACK of transponder signal) I don't think we should see a ship's energy generation count or shield regeneration count.

Although giving distance based tolerances and limits to when things show up would be complicated, it wouldn't be impossible, and I definitely think it would make things that much more interesting. We've tried to resolve the issue with making things besides cubes highly efficient before, but cubes remain the most efficient shape one can make in game for any device. +1 to variable turret accuracy.

I like how EVE-Online does it.
There should be many more hidden objects that you can discover. At least in populated sectors.

I especially like the idea of accelerator gates which aid navigation, but there should be a reason why you are unable to line up your ship with the object and just fly straight ahead.

All ships should have easy access to jammers which hide their most significant signal sources, but "active scanning" should require you to turn it off.

There could be more different signal types with different jamming costs and different distances/difficulty to detect.
But I would like an easy default setup and some ways to modify it rather than a complex system all-over.

I love the idea of unmanned sensor probes similar to having long range sensors on stations. Different types of signals (Frequencies Maybe) and the ability to Jam them would be awesome!

-Cheers! :D

 

[NeonSturm]

Now I've got a good idea with logic, sensors and jammers:

CoM (Centre of Mass) is the core, centre of boundary box or average of your core position and the boundary box centre as long as no proper implementation exists.

1. Calculate the average position of Jam-block (avg) for: jammed_CoM = CoM - avg_relativeTo_CoM(avg - CoM) * allowed_CoM_displacement (example: 2x or 5x ship size)
2. Optional : Jamming has diminishing returns based on the two smallest axis 70% effect, and second smallest 30% effect, discouraging cubes.

3a. visible_CoM == jammed_CoM is true while you have just enough sensors to detect the enemy ship
3b. but while not jammed and 100% sensor strength, visible_CoM == CoM

accuracy = sensor_strength (0..1) * (1- jamming_efficiency (0..1) )
visible_CoM = CoM * accuracy + jammed_CoM * (1- accuracy)​

You want to hit the ship in it's centre, as there you most likely hit it. Displacing the visible centre may let you fire aside the ship or at parts with fewer hit-able surface.

If peoples can now select not a ship, but a signal source and some logic block passes/receives relative distances, angles and movement to math elements made of logic blocks, peoples can use these to calculate the (ShipCentre or ShipCore to visible_CoM offset), have a greater/lower than last-position detection and adjust weapon angles.
This would even give 8 bit ( based on1/256 of weapon range) computers a reason to exist on ships :D

If above is too complex, peoples could use logic to decide

1. how much closer the AI ship should move (reliable targeting, keep itself out of range)
   
2. when AI turrets should start to fire

if we get logic<->game interfaces that are sufficient to transfer this size of information

 

[SteelNorthman]

Being a programmer i can simplify those equations to look and sound easier to understand for those less scientific and physics oriented.... no offense to you who can't understand that system above...

vector MC; //mass center;
float M; //Mass;
vector S; //scale (x,y,z)
vector JMC; //jammed mass center;
float JS; //jamming strength;
vector J_Off ; //jam block offset from MC;
float R; //range;
float AF; //accuracy falloff. removes the idea of "range" instead having an accuracy falloff so that at a curtain range it has 0 accuracy;
float SS; //sensor strength;
Scan(MC, JS,J_off,AF,SS,M,S,R){
if(JS != 0){ // != is not equal;
JMC = (J_Off * S) * M * (-1 * (JS + (AF/R * SS)); //the off set of the jammer to the scale, times mass, times the inverse of JS added by the sensors;
} else {
MC = S * M * (-1 * (AF/R* SS)); //the scale times the mass times the inverse of sensor;
}
}

what it does is as the jammer is stronger the larger the core appears to AI and the such giving them a less accurate image of the target core. while the weaker the jammer is and the stronger the sensors are the smaller (more pinpoint) the target core appears to AI.
there more mass a ship has to it's scale the harder it is to find the core, it's like trying to use an x-ray with lead in-between it and what you're trying to see through, the sensors are meant to eliminate the "density" of the target making it easier to see the core.

Sorry about the way I wrote it... that's how you write code.

 

[NeonSturm]

@SteelNorthman
Do you see the smiley above your edit textbox? 3 times to the right is an insert-quote/spoiler/code feature.

With the new Core-HP system (based on how many and/or which type of ship blocks) you don't want to waste dps on your core while leaving other systems at full health and capable of damaging you.
You will want to cripple the enemy first to have enough time for the core.
( If I understood the proposals of mods/devs right )

You want to hit the ship in it's centre, as there you most likely hit it. Displacing the visible centre may let you fire aside the ship or at parts with fewer hit-able surface.

AI will target this visible centre. AI will not fire if this centre is 200 metre further and thus out of your range even though the ship itself is inside (and it's weapon outputs)

 

[SteelNorthman]

That is true, but as your previous post said by signals not but he core, I was just making the note for others to understand better. I get the idea of visible center and the what not, but sensor, both IRL and scifi, work by "eliminating density" of the targeted ship/object to find signal sources and to pinpoint their locations. A good game example of this is sensor probes from EVE-Online, even when you find something you must them narrow the scan grid around it to "truly" find it's location.

 

[NeonSturm]

That is true, but as your previous post said by signals not but he core, I was just making the note for others to understand better. I get the idea of visible center and the what not, but sensor, both IRL and scifi, work by "eliminating density" of the targeted ship/object to find signal sources and to pinpoint their locations. A good game example of this is sensor probes from EVE-Online, even when you find something you must them narrow the scan grid around it to "truly" find it's location.

That is true for objects which don't move and rotate randomly relative to you
Rotation + movement + relative offset from centre of rotation => you have to decipher the algorithm (here already known) and adjust min-max possible values for used variables (increasing accuracy) to get the current position.

If I understand it correctly with "eliminating density" == statistical analysis of average(position, rotation) with use of stuff like Gaussian normal distribution it is great for knowing where something was, but bad for where something will be.

In reality planes don't create an image 100m to their top-rear-left, but scramble the received information, but if you have magnetic lenses which bend light, it would be a different story (on planets air would hinder you from using that power-efficiently, but in vacuum there is no air and it might be possible in future)

 

[SteelNorthman]

There is a very simple system for getting where something will be,

vector TarPos; //position of target in 3d space;
vector TarVel; //velocity of target relative to the 3d space;
vector LeadPos; //the estimated coordinate position of target;
LeadPos = TarPos + TarVel;

and done... I also know how to get the lead for turrets tracking a target as well using similar methods.
then you just add the lead to the targeted bounding box for AI tracking.

 

[NeonSturm]

vector TarPos; //position of target in 3d space;
vector TarVel; //velocity of target relative to the 3d space;
+vector TarAcc; //acceleration of target relative to the 3d space;
vector LeadPos; //the estimated coordinate position of target;
LeadPos = TarPos + (TarVel + TarAcc + TarVel)/2;

---

vector TarPos; //position of target in 3d space;
vector TarVel; //velocity of target relative to the 3d space;
vector TarAcc; //acceleration of target relative to the 3d space;
+vector TarRot; //rotation of target relative to the 3d space;
vector LeadPos; //the estimated coordinate position of target;
//this is what we have.

 

[SteelNorthman]

Technically acceleration isn't needed due to the facts that the more calls within a function the slower it becomes,
LeadPos = TarPos + VelPos; is sufficient for what is needed for the AI to track a target.
The need for acceleration would only really be useful for homing missiles, but saying they preset missiles to have 2x the max velocity that is set for a server its not needed.

 

[NeonSturm]

Somewhat true.

I hope we can some time get logic with less than 0.5 delay but some soft-cap on max logic steps per tick (to avoid lag). If you use more than you have, it just skips the next automated step until it regenerated (automated: delays, not automated: user activations, maybe a per-block limit for area triggers too).

 

[1adog1]

So if I'm understanding this right, you guys think that the navigation and turrets should target the geological center of a ship instead of it's core? If that's what you are saying this would technically eliminate the possibility of Core-Drilling, which we've needed to do for a VERY long time.

 

[FunnyBunny14]

They should be working on a hp system to make sure core drilling isn't a thing anymore.

 

[NeonSturm]

So if I'm understanding this right, you guys think that the navigation and turrets should target the geological center of a ship instead of it's core? If that's what you are saying this would technically eliminate the possibility of Core-Drilling, which we've needed to do for a VERY long time.

It would not eliminate the possibility of core-drilling if you know the core position.

It would just increase the value of overall fighting knowledge and experience with the target you are fighting as long as ships still rotate around the core.

And this alone can still allow core-drilling with a jammed ship and 3x3 beam-slave punch-effect cannon ambush if you know the ship design.

 

[1adog1]

It would not eliminate the possibility of core-drilling if you know the core position.

It would just increase the value of overall fighting knowledge and experience with the target you are fighting as long as ships still rotate around the core.

And this alone can still allow core-drilling with a jammed ship and 3x3 beam-slave punch-effect cannon ambush if you know the ship design.

yes but as you just said it would require knowledge of the ships design, since 99% of ships on servers are custom built by their owners there's only a tiny chance of someone knowing the ship enough to find its core. Also the ship would rotate around its geological center instead of its core if this was implemented.