Comments (18)
Ooh! Good point. I do think we need to have a simple mode (which is the current mode) and the advanced mode, which pretty much does all of the above.
This also enables a bit more 'silent hunter' type of play, where you try to be as invisible as possible (flying slower, disabling certain systems, etc).
I also think that adding stuff like probes is an excellent way of doing more with sensors.
from emptyepsilon.
Ooooh. Very interesting ideas. Need to work out the details, but I like improving the science task, which is a bit dull right now (just as weapons, but we have ideas for that already). Most important detail is on how to go from "sensors say x" to, "ok, this is a destroyer from race Y at position Z"
Note, on the last play session we had, it was very funny that I identified ships from the visuals before the science station managed to scan them.
from emptyepsilon.
Most important detail is on how to go from "sensors say x" to, "ok, this is a destroyer from race Y at position Z"
Easy. Targets are identified when sensor measurements go over a threshold. The threshold depends on background noise and sensor sensitivity.
In real-life radar, you listen for microwaves coming in, but most of the stuff is just background noise. If you're lucky and a target is emmitting microwaves like crazy, you'll see it over the background noise. Usually you'll throw microwaves around, and if a target reflects them well enough, you'll see the reflection over the background noise.
I think all sensor bands (gravimetric, µwave, visible, x-ray, psi) can operate under the same principle, something simple like:
signature = target_radiance + sensor_power * target_reflectivity;
if ( signature / distance^2 - background_noise > sensor_threshold) {
// target_detected
}
I think that sensors should have a couple of defined thresholds - for displaying a blip, tracking it and identifying a target. That keeps them simple enough.
The hardcore way of doing this would be to going full nerdy into decibels and emulating the statistical analysis for establishing confidence values of detection, but I think that'd only overcomplicate things.
And for gravimetric sensors, radiance would be equal to the momentum (remember to add rotational momentum, so black holes show up easily). Grav sensors are only passive, and the own ship's momentum counts toward the background noise. Or maybe grav sensors can be active if the ship can do a "warp ping" or something.
A nice thing to do would be to mask a sensor signature by its nearby sensor signatures. Usually, when a radar blip is big enough, you can't know if there's one ship or two ships together (doing a docking maneuver or whatever). I mean, who wouldn't like to hide a ship next to a black hole?
Anyway, enough daydreaming. Please add a concept of sensor bands (grav, µwave, visible, xray, psi) and reflectivity/radiance attributes to every spaceObject. I guess sensor logic is a separate matter :-)
from emptyepsilon.
I could add the concept to the spaceObject, but without a clear vision who we're going to use it, adding different "sensor signature values" to objects will make it hard to fill those values.
from emptyepsilon.
Well, in almost all games (and it's reasonably realistic) its standard to use 'signiature size'. You could set a signiature size for different means of scanning (Radar, heat, etc). Certain parameters give a basic signiature size and actions can increase / decrease it (Speed, power usage, heat, damage, cloaking, having an active scanner).
Once you have this, it's a simple matter of having a sensor that a object with signature size A, looking at a target at range R. The scanner has a strength rating of S and there is a background noise of B.
This gives a whole bunch of data back and the science officer can increase / decrease the threshold. In most cases you'd want to put it well above the noise ratio, but different situations might create more / less background noise, forcing the science guy to change it.
Putting more power in the sensor is now always an option, which will increase the strength rating with a certain amount. Getting closer is always a good option, as is trying to force your enemy to increase his / her signiature (Probes? Rays? Shooting at random so it -must- move?)
On the other hand, you might drop objects that fake being a ship by projecting very large signiature, but not on all bands. This might fool your oponent, but not for a long time, as cycling your sensor suite will show that it doesn't pop up in every spectrum (but then again, at longer ranges it might work well enough, which is pretty cool emergent behaviour!).
from emptyepsilon.
In my mind, I imagine a Science console in which you can cycle through the sensor bands.
Instead of a clean image of the environment, the Sci officer would see a noisy background with some brighter splodges, trails and artifacts (see, for example, http://www.radartutorial.eu/18.explanations/pic/noise1.print.jpg ). This way, a trained Sci officer could detect (or suspect) the position of a target before the target is automatically acquired by the sensor threshold.
Ideally, the different sensor bands would have different artifacts. e.g. the gravimetric sensor would have a threshold control for filtering out the effects of black holes; EMPs would disrupt the µwave and x-ray bands by adding a ton of noise during a few seconds; nebulae block the visible band; AI-controlled vessels are invisible to psi-detecting alien races, etc etc.
from emptyepsilon.
Like I said, I like these ideas. But first, I want to change 2 other things. First, I'm looking into missile weapons and targeting:
http://bridgesim.net/discussion/111/ee-fire-zhe-missiles#Item_1
Next, I want to do some AI work. The ship AI could really use some more work. Where different ships follow different tactics. Especially when I change the missile weapons.
from emptyepsilon.
You're gonna hate me for saying this, but in real life, missiles don't lock onto a "target", they lock onto a sensor fingerprint because of an onboard sensor suite for the µwave or infrared band.... ;-)
(Too much time playing flight sims to know the difference between chaff and flare countermeasures)
from emptyepsilon.
Not going to hate you for that. Actually, in Silent Hunter, you have torpedoes that lock to different signatures. For example, the sound torpedoes are very good at striking the props of a moving ship, as they create a lot of turbulence in the water. While heat seekers have a bigger chance of striking engines, as they home in on the engine signature.
Those torpedoes in Silent Hunter do need "enough" input to home in, so you need to get them close enough before they start homing. Which might not be a bad idea for EE eventually.
from emptyepsilon.
From the sound of it, the locking in Silent hunter and real life missles is more like a hill climbing algorithm, which usually moves towards the highest concentration of something. This is also why flares work, as they provide another heat source to ' latch on', but as it falls down it moves the missile towards a local maxima where it will not escape from.
from emptyepsilon.
Well, target acquisition is a bit more complex. If you have an infrared camera, you might think "steer towards the brightest pixel in the image", but you can throw pattern matching, computer vision and machine learning to the mix and turn that into "steer towards the area in which the pixels look most similar to this reference image".
e.g. instead of steering to the brightest pixel you can steer towards a bunch of black pixels which have white pixels at both sides: http://docs.opencv.org/doc/tutorials/objdetect/cascade_classifier/cascade_classifier.html#cascade-classifier
Also, you can expose a computer to a crapload of cat images, so it will identify if a picture looks like a cat (or which part of a picture looks most like a cat) http://www.digitalstrategyconsulting.com/intelligence/2012/06/google_brain_simulator_uses_16.php
So when Sci "scans" a target, what's really happening is that the ship's computer is applying machine learning and technobabble technobabble technobabble to the sensor input, and builds a sensor signature of what makes that target unique. Then you load that signature into the torpedo, so it can steer toward whatever resembles the target most closely.
So I kinda expect futuristic torpedoes to have FoF and individual targeting capabilities :-) (even if the individual targeting occurs close to the target because of cheap/compact sensors or whatever, which sounds like a nice idea)
from emptyepsilon.
Yeah, computer vision is my thing right now, but that is rather complex to get right. Especially if you can simulate the behaviour with much simpler algorithms. Especially because the signiatures can change (eg; If a ship does not has its engines powered, missile gets signiature, ship powers engines, signiature changes). You can compensate for that, but that is rather tricky.
Auto locking a nearest target (missile gets within x range of a target, it homes toward it) and forcing you to think somewhat before spamming missiles is probably a good idea. We're going to test it tonight, so lets see how it pans out.
from emptyepsilon.
Especially if you can simulate the behaviour with much simpler algorithms. Especially because the signatures can change. You can compensate for that, but that is rather tricky.
It's a game. It doesn't have to be perfect ;-)
For the sake of simplicity, I'd rather assume signatures don't change, or signature changes are automatically tracked and updated.
from emptyepsilon.
But in that case flares don't work. In the case of a hill climber, the emergent behaviour would automatically let the missile target the flares.
from emptyepsilon.
I guess a flare (or any countermeasure) would put so much noise in the sensor readings that the missile would not be able to detect a pattern and just fly straight.
from emptyepsilon.
But then it could still hit the ship (by simply flying straight). Another effect is that adding noise would also hide the ship from scanners, whereas very 'bright' signiatures would show up, but won't hide the ship from sensors.
from emptyepsilon.
FWIW, it looks like abd590e added gravitational, electrical, and biological signatures to spaceObject
s via RawRadarSIgnatureInfo
. Only the radar bands on the edge of the Science radar use those values at the moment.
from emptyepsilon.
Working on a visualization of radar grav/elec/bio signals in a branch off my fork: oznogon@78d0f75.
Circles scaled to the object's radius and colored for each band, and numeric values visible next to the ship that's toggled by a button. More of a proof-of-concept as I'm not happy with the implementation.
Similar to #726, it's meant to give science another way to guess at what a ship's doing by observing it without necessarily scanning it. For instance, here's the same ship when it was still at warp, with an elevated grav reading.
I'd love to have this work more like a heatmap of recent signal activity, maybe piggybacking on the ghost dots object, so science can do fiction-y things like track where a ship warped based on the trail of grav disturbances, predict where a ship is jumping to/from, or hide radar traces of objects with weak signals to enable things like running silent and cloaking devices.
from emptyepsilon.
Related Issues (20)
- [Ship categories] Freighters and Ktlitan ships should get their own category. HOT 3
- [GM interface improvements] GM input dialogue and Add ship filtering HOT 3
- [gm/ObjectCreationView] Add icons to ship lists HOT 1
- [gm/ObjectCreationView] Allow filtering/sorting ship lists HOT 2
- [AI] CpuShips with 0 max_impulse_speed can set infinite impulse_request values HOT 3
- [GuiAdvancedScrollText] Large number of entries degrades render performance HOT 1
- [GuiScrollbar] Draggable bar size has no lower bound HOT 2
- [GuiScrollbar] Scrollbar bottom range can be positioned below bottom arrow, where user can't scroll HOT 1
- [GuiScrollbar] Arrow scroll amount can be too small HOT 1
- Warp Jammer is invisible in 3D views HOT 1
- [ShipsLogControl] Log might not update if first entry text is the same as the latest
- [Planet] Collision radius isn't updated with object radius
- [scriptdocs] Path references are incorrect
- [docs] Document resource pack creation and usage
- Alpine-linux compiling HOT 9
- Package EmptyEpsilon via Flatpack and publish on Flathub HOT 9
- After building from source running fails due to no config HOT 5
- Pressing delete while at the end of a text entry box crashes the game HOT 2
- [tweak] Docking services toggles are confusing if ship doesn't have any DockClasses HOT 2
- Enhancement Request - Missile Tube Status getter HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from emptyepsilon.