Comments (54)
This: http://en.wikipedia.org/wiki/Active_electronically_scanned_array
from arms.
I did do research before building the model. I went with a design the people would recognize as "radar" rather than a realistic-looking one.
I figure most people would not be able to identify these:
My plan was to make a model, have someone say "I can do better than that.", and then I get a better one.
The script also allows for multiple designs to be used, or blocks from other mods to work.
from arms.
Totally makes sense. "I would like to do better than that, but it'll take me a while since I have no experience with modeling" is where I'm at. But eventually I will definitely jump on this.
Thinking about this some more, you could add some nice strategic gameplay decisions by providing different types of radar blocks:
- Rotating simple parabolic dish arrays are cheap and have big range, but are easy to disable and/or jam, track slowly, can only track a single target at once, and provide a big radar signature
- Phased arrays are expensive, have less range, but provide multiple target tracking, much faster tracking, a smaller radar signature, and a surface that can take a beating and still work
- Active phased arrays are just like phased arrays but more expensive, can track more targets, even harder to jam, take less power, can act as antennae, and have a small radar signature
As for placement, have the parabolic arrays rotate (+ maybe a giant unidirectional version) and make the phased arrays unidirectional. Check for blocking blocks within a big semicircle around the blocks and give them an effectiveness based on how open to space they are.
There's some extra complexity there, but nothing Autopilot can't handle with the right systems in place I think. Happy to take a stab at this stuff after harvesting.
from arms.
I'm starting to feel like radar should be a seperate mod from autopilot. Autopilot works just fine for engaging enemy ships just by using an antenna. You would only need a radar dish if the enemy isn't broadcasting or you are out hunting for unpowered exploration ships. Sure they could go hand-in-hand when both installed but I feel like radar should get its own mod, where it can be made more complex and functional on its own level with multiple types and blocks. It isn't necessarily a part of an autopilot system ,unless you want to rename the mod to Additional Cockpit Enhancements or Autopilot + Radar or something like that. Thoughts?
from arms.
I do not really feel like Radar is a part of Autopilot, so much as Autopilot requires Radar. I cannot see E
or M
being useful at all, in multiplayer, without radar.
Space Engineers does not offer a simple way for mods to interact, they can only send messages back and forth using chat, so separating Radar would have a performance hit.
I am open to changing the name of Autopilot, but it is not something that should be done lightly.
from arms.
Was just going to say the same thing - you can't really E
or M
without radar. And radar implemented with that level of complexity would rely a lot on autopilot in its implementation.
Plus, you can always just edit the settings file to disable radar if you don't want it.
Now changing the name of Autopilot, maybe eventually that makes sense as this mod now encompasses three moderately separate functional sets. But it would be much easier to wait until functionality matures and make that decision then.
from arms.
I feel like an appropriate name would convey that this mod provides "Electronic Navigation, Communication, and Targeting Systems", but I can't think of a simple way to say that.
from arms.
Super cool awesome sauce?
from arms.
+1 make it so
from arms.
Is this still on the table, having different types of radar?
from arms.
Eventually I plan on working on it when I clear a few other things off my plate, if Rynch hasn't already accomplished before then.
from arms.
Ok, I'm currently working on updating Rynchodon's radar dish with some newer textures/construction stages, and a better collision box. After that, I wouldn't mind making some more radar models, if someone will do something with them.
from arms.
Yes, I would definitely make use of them whenever I get around to working on this, which is "definitely eventually" : ). I'd like to have 3 tiers, as mentioned above - parabolic, passive phased array, active phased array. Parabolic would look generally as is now but with the visual updates you mentioned. Passive and active phased array would be large flat circles you put on a surface that detect in an 180* arc, basically just like turrets. I was thinking a small (1x1 or 2x2) and large (maybe 8x8 or bigger?) version with different ranges, a la the images above.
from arms.
After that, I wouldn't mind making some more radar models, if someone will do something with them.
Other than simple changes to the formula, implementing different radar would take some work and I still haven't done the jump drive yet (or the ore detector, or the...).
from arms.
@Rynchodon Yeah, I'm happy to jump on this when I can, expect to in the next couple months.
from arms.
I have started on a better Radar script, so far the plan includes:
- Radar can be any type of fixed block
- Angle restrictions
- Obstruction tests
- Decoys
- Radar jamming (radar can be resistant)
- Passive detection of other radars and/or radar jammers
I considered a maximum number of targets. It would an enormous pain to code cooperation between radars. Between angle restrictions and obstruction testing, it may be necessary to build multiple radars anyway.
Is there anything that I have missed?
from arms.
Only other things I can think of:
- Maximum number of targets a block can track - would definitely be good, no need for managed cooperation between radars as long as the block tracks the closest targets. You don't need
Block A can detect 3 and Block B can detect 5 so we can detect 8
so much asBlock A can only detect a few but Block B can detect a bunch so I want that eventually
. - Radar tech levels - Affects ability to accurately judge objects at a a given range, susceptibility to jamming from a given level, and radar signature
- Jamming tech levels - Affects ability to jam radar of a given level and radar signature
- HUD markers, of course, for the N closest when you're sitting in at a control panel or cockpit.
For the tech levels, radar signature and accuracy could be hardcoded into the block easily enough, but you still want some sort of Radar level X vs Jamming level Y
dynamic that I think would be easiest to do with a levels system.
from arms.
Oh and two more things, but I don't really expect this to ever get these. It would be awesome but sounds like a ton of work:
- Radar signatures based on total surface exposure to the source of the beam. So you can build a ship with less big flat surfaces and it would have a lower radar signature.
- Material-based signatures - you can build out Radar Absorbent Materials and get a smaller signature
from arms.
I don't care for maximum number of targets but I'll add the basic support you requested.
Radar / Jamming tech levels: I don't really know what you are asking for here, the jammers can have different strengths and the radars can have different resistances. I have not decided exactly how these values would interact yet.
Radar signatures based on total surface exposure to the source of the beam. So you can build a ship with less big flat surfaces and it would have a lower radar signature.
Making the signature based on the ship's profile is doable, but I doubt many players would care when it would be so much less work to build a jammer.
from arms.
All the properties of a radar can be specified through the .sbc files; the blocks will not need to be included in Autopilot to work.
from arms.
I have not tested everything but it is all together: https://github.com/Rynchodon/Autopilot/blob/Radar/AntennaRelay/Scripts/Radar.cs
I decided to restrict radars and jammers to be beacons or antenna, I can always switch it back.
@Souper07 Are you still interested in creating (a) radar block(s)?
from arms.
First of all, looks cool! All of the below are suggestions that could be implemented down the line and I don't expect any of them immediately. : )
Obstructed()
gets all the entities from API Gateway, but it's called right after doing the same thing inActiveDetection
(thoughPassiveDetection
is able to use the establishedAllRadarAndJam
list). Perhaps we could optionally pass an existing entity list in to save it from having to do that?- PassiveDetection - would this also work on other antennae or beacons that aren't radar? Just based on some static signal strength for those blocks * their range?
- Radar/Jamming tech levels - Looking at what you've done and thinking about it, this seems unnecessary. Can probably model it into this simpler system. Only change that might be nice is for the jamming & detection to not be a static definite yes/no but rather have a particular % chance of occurring depending on the strengths involved.This would give you the cool radar "blipping" characteristic of an object moving between the range at which it's perfectly jammed / not detected to the range where it's always detected as it approaches its target. Maybe damaged radar blocks would occasionally see ghost signals in a similar manner as well.
- HUD markers would still be cool
- Materials-based signatures still would be cool, but the info would need to be aggregated at the grid level already for these update calls to not be massively time consuming right? Unless we had a entity logic component on each grid that read the properties of added blocks for a "radar absorption" attribute.
- Cross-section instead of volume detection -
- "Making the signature based on the ship's profile is doable, but I doubt many players would care when it would be so much less work to build a jammer."
- True, but what if all the jammers put off enough of a passive signal to be useless at hiding themselves, mostly useful for hiding fleet size? Or if the jammers are large and energy intensive, not appropriate to small strike fighters that might benefit from radar sneakiness?
from arms.
- Obstructed() gets all the entities from API Gateway, but it's called right after doing the same thing in ActiveDetection (though PassiveDetection is able to use the established AllRadarAndJam list). Perhaps we could optionally pass an existing entity list in to save it from having to do that?
Perhaps I should just keep a collection of all the entites, so I never actually have to use this.
- PassiveDetection - would this also work on other antennae or beacons that aren't radar? Just based on some static signal strength for those blocks * their range?
I supposed it could be expanded to include anything, I have no idea where you are going with this.
- Radar/Jamming tech levels - Looking at what you've done and thinking about it, this seems unnecessary. Can probably model it into this simpler system. Only change that might be nice is for the jamming & detection to not be a static definite yes/no but rather have a particular % chance of occurring depending on the strengths involved.This would give you the cool radar "blipping" characteristic of an object moving between the range at which it's perfectly jammed / not detected to the range where it's always detected as it approaches its target. Maybe damaged radar blocks would occasionally see ghost signals in a similar manner as well.
The position prediction would kinda defeat this, especially for objects in uniform linear motion.
- HUD markers would still be cool
I'm working on it, it's not part of radar though. I have no quite worked out the details for how a player would configure it, I guess slash commands are in order.
- Materials-based signatures still would be cool, but the info would need to be aggregated at the grid level already for these update calls to not be massively time consuming right? Unless we had a entity logic component on each grid that read the properties of added blocks for a "radar absorption" attribute.
It should be doable as long as there is a default that most blocks fall under. If only block counts are needed, CubeGridCache could suffice.
- Cross-section instead of volume detection -
- "Making the signature based on the ship's profile is doable, but I doubt many players would care when it would be so much less work to build a jammer."
- True, but what if all the jammers put off enough of a passive signal to be useless at hiding themselves, mostly useful for hiding fleet size? Or if the jammers are large and energy intensive, not appropriate to small strike fighters that might benefit from radar sneakiness?
I thought you wanted the game to run faster?
from arms.
Perhaps I should just keep a collection of all the entites, so I never actually have to use this.
Yeah I think that would make sense for this purpose. You could even maintain your own Trees for doing bounding checks and raycasts. That's what we do in GP now:
https://github.com/zrisher/SEGarden/blob/master/Math/AABBTree.cs
https://github.com/zrisher/SEGarden/blob/master/Math/AABBEntity.cs
I supposed it could be expanded to include anything, I have no idea where you are going with this.
Just the fact that radios put off electromagnetic signals that can be picked up by passive radar. Obviously not a big priority. Would just be kind of cool.
I'm working on it, it's not part of radar though. I have no quite worked out the details for how a player would configure it, I guess slash commands are in order.
I'm happy to incorporate SEGarden if you like in a PR - it's a fair amount of code, and it does run its own update manager (adapted from this one), but obviously it doesn't do much if not in use. That has a built in command model that makes these pretty easy, see:
https://github.com/zrisher/GardenPerformance/blob/master/Data/Scripts/GardenPerformance/Concealment/Commands.cs
https://github.com/zrisher/SEGarden/tree/master/Chat/Commands
I thought you wanted the game to run faster?
Yesssss you're right, it would be pretty intensive to check. I just like being the voice that mentions every possible use case. : )
from arms.
Yeah I think that would make sense for this purpose. You could even maintain your own Trees for doing bounding checks and raycasts. That's what we do in GP now:
I'll leave that level of optimization to people who know what they are doing.
Just the fact that radios put off electromagnetic signals that can be picked up by passive radar. Obviously not a big priority. Would just be kind of cool.
Radio antennas? You want to detect them beyond their broadcasting range or something?
I'm happy to incorporate SEGarden if you like in a PR - it's a fair amount of code, and it does run its own update manager (adapted from this one), but obviously it doesn't do much if not in use. That has a built in command model that makes these pretty easy, see:...
Easy like rocket science, maybe it will make more sense in the morning.
Yesssss you're right, it would be pretty intensive to check. I just like being the voice that mentions every possible use case. : )
It's probably not that bad, PathChecker does this a lot, I just like to complain. I'm definitely not happy with using volume. No idea how I could combine this with R.A.M.
from arms.
Radio antennas? You want to detect them beyond their broadcasting range or something?
Yes the idea is the passive radar would pick up the position of the signal origins beyond their normal broadcast range as because it's specifically tuned to listen across the em spectrum without being specialized for communication. But like I said not a big deal.
Easy like rocket science, maybe it will make more sense in the morning.
Lmk if you want to discuss.
from arms.
I've started working on some new models. When I first started this one I figured it could be some sort of radar jammer, but it could also be used as some sort of radar. You guys can do whatever you want with it.
from arms.
Some screens of the first finished model
from arms.
For me personally, the big white ball looks out of place. It seems like it should be armored instead of built out of a translucent material. But that's just me, I always think near-future military-ready, but all people have different views of this game.
from arms.
The white ball was inspired by the "Radar Dome" picture above. It could easily be changed to be a grey color, like the ship in the first picture.
from arms.
I have to ask, can it tell the future?
It seems like it should be armored instead of built out of a translucent material.
Wouldn't an armoured radar be counter-productive?
from arms.
Ha! No but it does grant wishes. How many radars/jammers are we talking here?
from arms.
Wouldn't an armoured radar be counter-productive?
This stuff seems pretty strong and has very low EM interference:
http://www.dsm.com/content/dam/dsm/dyneema/en_GB/Downloads/Brochures/Brochure_Radomes%20with%20Dyneema.pdf
How many radars/jammers are we talking here?
I was hoping to eventually get one low tier (single rotating dish, looks like the current radar, maybe smaller), one mid tier (looks like your new model), one standard high tier omni-directional (looks like one of the three panels visible at the top of this ship) and one gigantic high tier omni-directional (e.g. this or this).
But the way Rynch is developing this allows radar blocks to be defined in other mods. So if this list is too exhaustive for Autopilot, I could fill in the gaps in another mod.
from arms.
Ha! No but it does grant wishes.
I wish, I wish, for multiplayer fixes.
How many radars/jammers are we talking here?
As many as you want to make.
I don't know how many radars or jammers I want to include in Autopilot itself. Maybe the best option is to put all the ones you make into one or more separate mods.
from arms.
Ok, so should I still PR to autopilot or are we going to setup a seperate project for this? The wish granting orb is just needing construction stages (had to start over 😦 ) and then it is done. I've set up just a basic sbc file for it with the construction components all set to 1.
from arms.
Ok, so should I still PR to autopilot or are we going to setup a seperate project for this?
We can do a github project if you like or I can just tell you what to add to the .sbc files.
It's just a little section like:
<Description>
Radar
MaxTargets_Tracking=100
PassiveDetect_Radar=20000
SignalEnhance=1.1
</Description>
from arms.
I definitely would not mind these going straight into GardenWarfare. : ) I can commit to keeping that release up to date so people can use this feature of Autopilot. But also completely understand if it should be in an autopilot-support mod of its own.
from arms.
I definitely would not mind these going straight into GardenWarfare.
What, exactly, is your thinking behind this?
from arms.
I don't know how many radars or jammers I want to include in Autopilot itself. Maybe the best option is to put all the ones you make into one or more separate mods.
and
Ok, so should I still PR to autopilot or are we going to setup a seperate project for this?
and
We can do a github project if you like or I can just tell you what to add to the .sbc files.
suggest you were considering putting the additional implementing models into a separate mod to keep the options in autopilot simple.
My thinking is I'm planning to release that mod anyway and it will be heavily dependent on autopilot, so it's an option for above considerations.
from arms.
I definitely would not mind these going straight into GardenWarfare.
What, exactly, is your thinking behind this?
Sorry, I had GardenWarfare confused with GardenConquest, you need to stop naming things garden.
I'm trying to get @Souper07 to decide...
from arms.
I have the shared namespace for brand awareness. : ) And plus it lets me call things "Performance" and "Warfare" without having to qualify their names any further.
from arms.
"Phased Array" Radar
Still needs some detail work.
from arms.
For size comparison
from arms.
Looks awesome. Only thing I would change is maybe add some sort of protective cover over the honeycomb. And possibly make it a circular shape on top of its parallelogram mounting point. But I would be happy as-is.
Did you start with the construction stages this time? : )
What's the size of these in blocks?
from arms.
Any thoughts on the specs for the radars?
Dish radar:
- Only detects objects in front of it (half-sphere, I will probably make this smaller)
- Detects 10/5 (large radar/small radar) objects
Dome radar:
- No angle restrictions
- Detects 30/15 objects
- Detects objects 10% further away
Phased radar:
- Can't detect objects "below" it and maybe directly above
- Detects, I dunno, a lot?
- Detects objects further than dome
- Passive radar detection say... signal > 20k
- Resistant to jamming
from arms.
My suggested versions would be:
Dish radar:
- Detects 1 object (no difference between large/small)
- Large has about 3x the power of the small
- Largest range per build cost of all the radars - primary reason to build these even late tech
- Very easy to jam
- Creates a large passive EM signature
Dome radar:
- 180 degree viewing (same as a regular turret. This shouldn't be able to detect objects below it, it has a mounting point and I'm not sure how you'd reliably accomplish 360 degree rotation on a parabolic radar dish)
- Detects 1 object
- Fairly easy to jam
- Basically we treat this as the same thing as the exposed dish, but it's able to rotate on its own inside the dome, and the dome provides some protection from electromagnetic interference so it's more sensitive (more targets, slightly harder to jam). It's the parabolic dish with all the bells and whistles.
- Slightly smaller total power output than the naked dishes
Passive Phased:
- Detects up to 5 objects
- Less overall radar power than the parabolic arrays,
- Significantly smaller passive EM signature
- Moderately difficult to jam
- Can detect via EM device signatures
- Can take a beating and still work
- Second most expensive to build
- Fairly low power consumption
Active Phased (new category, can have the same model as passive phased, though we could add some cool lights or something to differentiate it)
- Detects up to 10 objects
- Most difficult to jam
- Smallest power consumption per radar power
- Very small EM signature
So basically there's two types - parabolic and phased, with two levels each. Parabolic are cheaper and have greater range. Phased have more sophisticated detection, are harder to detect themselves, and can track more targets.
from arms.
I don't know about you but I always have more than one ship. If the maximum objects is one, I'm just going to be detecting one of my ships most of the time.
Dish radar:
- Large has about 3x the power of the small
You want to boost the power of the small one? As previously discussed it is currently less than 1/5 the power.
Dome radar:
- 180 degree viewing (same as a regular turret.
??? Turrets have 360° of azimuth and 124° of elevation (despite what it says in data files). I have no idea where you got 180° from or what you mean by "viewing".
This shouldn't be able to detect objects below it,
I thought about this, I will probably add a restriction but whatever you mount the block on is going to block the radar anyway.
- Slightly smaller total power output than the naked dishes
Sorter range?
Passive Phased:
- Less overall radar power than the parabolic arrays,
Even shorter range, I don't like where this is going the next one is going to be like three feet.
- Can detect via EM device signatures
That's what I said
- Fairly low power consumption
I can't change power consumption
from arms.
I don't know about you but I always have more than one ship. If the maximum objects is one, I'm just going to be detecting one of my ships most of the time.
Shouldn't it try to show enemy ships in descending order of size before showing your own?
You want to boost the power of the small one? As previously discussed it is currently less than 1/5 the power.
Ok, that works for me!
??? Turrets have 360° of azimuth and 124° of elevation (despite what it says in data files). I have no idea where you got 180° from or what you mean by "viewing".
Was referring to elevation. 124° sounds great.
Sorter range?
Yes, by lower output I meant shorter range / detection power.
Even shorter range, I don't like where this is going the next one is going to be like three feet.
If we discuss the range as percentages of the largest one, the scale I was referring to wasn't 100-50-2-1, more like 100 - 95 - 70 - 70
That's what I said
Yeah, wasn't writing these as diffs from your suggestions, I repeated attributes to make it complete on its own without reading the original, just for the sake of future readers.
I can't change power consumption
Ahhhhh that sucks! I see <RequiredPowerInput>0.0003</RequiredPowerInput>
on the autopilot block sbc, is it just this particular type of block we can't adjust power input for?
from arms.
from arms.
You're really on fire
from arms.
Jump'n Shootman created an AWACS radar for ARMS, any thoughts on balance? The block is 5x5x1.
from arms.
I skimmed through this page https://en.wikipedia.org/wiki/Airborne_early_warning_and_control to get ideas. Maybe make it only able to detect ships but not stations. Maybe moving objects only?
from arms.
Main point of airborne radar is better detection range (vs ground-based) and mobility. Since we don't know if radar are mounted in space, in air, or on land, all the existing blocks can be mobile or static, and we don't do any sort of power adjustments based on those things, the only differentiation between this block and the others is its size and shape. Give what I see there I'd make it long range and unidirectional.
from arms.
OK, so I think I'll make it a 30 km / 12 km range directional radar. I'm also going to rebalance and increase the costs of all radar equipment.
EDIT: Decided to make it omnidirectional because rotors are evil.
from arms.
Related Issues (20)
- Radar block model isn't compiling HOT 2
- Atmospheric flight does not work as intended (compared to space)
- ARMS Demo Ore Scanner StackOverflow when it attempts to land HOT 5
- Demo world mining drone derps out & LoadARMS bug HOT 3
- scripts not working HOT 27
- Permission to republish HOT 2
- Autopilot crashes with a System.ArgumentException HOT 2
- Radar max range is same for small and large block and doesn't match value in Radar.sbc HOT 8
- "Controlling" a docked / waiting ship causes the Navigation to reset.
- Jump Drive HOT 37
- Harvesting HOT 26
- Renaming Autopilot HOT 6
- Instance Reference Error HOT 3
- Server crashes when certain players join HOT 4
- log rotation HOT 6
- guided missiles HOT 17
- Cannot place Radar block HOT 5
- weapon control HOT 6
- Hacker Block HOT 12
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 arms.