Directional sensor criteria merged thread

[Lurkily]

I'll keep the thread with the most votes on it.  These are threads asking for additional detection sensor criteria.

My biggest want is a way to sense the deposit bin.  

After that, my wish list for criteria goes:

Drone self (EDIT:Already implemented)

Drone part (any drone part regardless of connection)

Nimbatus (Because, who knows, one day I might want to.)

Enemy unit

Snake

Enemy structure

Ore

Terrain

Collectible

[limez]

Also, distance sensors should be able to detect them!

[Micha]

Good idea.

[STM]

An essential part to create auto-miners, upvoted!

[PhantomDerp]

Read the title

[EdTheRabbit]

Have an option on the directional sensor that point to the closest resource node - you could automate miners to find and collect resources - of course if anything's in the way, that's the drone designer's problem!

[androshalforc]

On 7/3/2018 at 8:22 PM, limez said:

Also, distance sensors should be able to detect them!

came here just to say this. wanted to slap a resource collector and sensor on my drone and no setting for resources just terrain

[Markus]

This will definitely come! I hope we can include it as soon as possible. Thank you for posting and upvoting! This helps to sort our feature-list considerably  

[stuChris]

simply what the title states, this would allow for (simpler) autonomous turreted-drones, auto-ramming drones, guided missiles, and much more...

[notsew93]

Release the hounds! 

Hounds being a small swarm of guided sawblade rockets, that is. 

I like this idea, but if we feel it is too powerful we could have it be heat-seeking, and be confused by lava, for example. That sort of limitation could be fun.

 

[Lurkily]

I feel like the sensor capability demonstrated in general should be able to grab a target effectively, but maybe not intelligently.  For instance, 'nearest enemy' is not very intelligent targeting, and a swarm would be wasted on a single target.  A minimum range might be established, so that a weapon wouldn't circle the world looking for its prey.

I'm not sure sensor inaccuracy is the way to go.  With a number of competitive arenas being autonomous, and there being autonomous-only missions planned for the future, I feel like a designer should be able to trust sensors.  I don't think sensors or logic should ever lie.  They should have limitations, sure, for instance your enemy-seeking TNT missile might go after a firefly instead of a hive or a hammerhead, but I don't think it should confuse fire or magma for enemy activity.

[unmog]

2 hours ago, notsew93 said:

I like this idea, but if we feel it is too powerful we could have it be heat-seeking

Heat seeking? god no that upgrade suuuuucks~ :p

[notsew93]

And right you both are. Particularly about the sensor never lying, that is definitely a good principle I'd like to keep. Oh how the mind can be subject to whimsy

[Lurkily]

8 hours ago, unmog said:

Heat seeking? god no that upgrade suuuuucks~ 😛

I don't think he's talking about the upgrade.  This is a sensor setting, remember.  I think what he means is that the sensor will target hot things as well as enemies.  How well your targeting works is up to the thrusters on the missile or the design of your turret.

[stuChris]

i was more thinking the feature would be great for automated turrets. currently you would have to use several distance sensors, and it makes each turret extremely unstable, pretty much no matter what. with this, that would be much easier, not to mention more accurate. as for missiles, i think it would still work, as long as the first, maybe second missile killed the target. perhaps a difference between "enemies" and "stationary enemies" would help that.

[Garheardt the Black]

It took a while, but I've worked out some automated turret designs that are not only stable, they're insanely effective. After seeing what they're capable of, I'm leery of changes that would make them easier to use. 

[Lurkily]

Can you share a couple?  My experience is that putting a turret requires clearance from the drone's body, which requires long struts, and also requires multiple sensors on a hinge, which is an inherently stable part, prone to shaking itself to pieces under torque.  And shake in the hinge results in instability in the sensors, which risks more flicker in sensor conditions, and more shake in the torque applied - a cyclic problem.  

The solution of course, is to slow down the turret, which works directly against the goal of a useful turret - I haven't been able to make something that's stable, accurate, and responsive - it's always "pick two."

[Garheardt the Black]

Sure. I was considering starting a showcase discussion where folks can post some of their current projects for discussion and constructive criticism in a more detailed format than the workshop. Shall I post there?

[Garheardt the Black]

Also, what do you use to make those sweet gif files of your stuff in motion?

[Garheardt the Black]

Nevermind, figured it out!

[Lurkily]

Not sure I'd put spinners and turrets in the same category, myself.  In any case, I personally didn't want them for turrets, which are currently more trouble than they're worth.  Eventually, autonomous mission completion will be a condition of some missions, and for things like that, and for missiles, nearest-enemy would come in handy. 

 

[Garheardt the Black]

But, but real life radar ARE spinners! If we sat down and built a radar guided weapon, the radar would spin. The spinning action of my proximity sensor is doing the same job a radar would; sweeping the target area and telling the weapon where to shoot. The only difference is that the weapon is mounted on my radar because it's more accurate with the in game physics engine. If that's not a turret, what is?

[Lurkily]

Most turrets I'm familiar with aren't mounted on pinwheels, but as I said, turrets weren't my main concern.  

[Garheardt the Black]

By the letter, an upright pinwheel closely resembles a rotary cannon, which is most definitely a turret, but let's go with your definition  

If the turrets you're familiar with are from video games, they are probably acquiring their targets artificially and wouldn't actually work in real life. If we're talking a real life modern turret, such as on a ship, those things are utilizing a whole flock of pinwheels from multiple sources. The CRAM anti artillery system is a rotary weapon with a huge aligned pinwheel sitting on it. A CRAM can mark an X-Y coordinate with it's radar for the weapon to acquire, while Nimbatus doesn't have that kind of fine control (or a Y axis). So instead, I'm using a pinwheel to mark an X coordinate and spinning my aligned weapon fast enough to make it omni-directional for instant acquisition. In real life, rotation isn't practical, but in Nimbatus, it enables the fastest, most accurate target acquisition available. 

Between studying radar counter strategies for Uncle Sam and the amount of time I put into developing my toy, I might be a tad sensitive about it 😅

[Lurkily]

I would dispute that a fixed gatling gun is always a turret, but we are getting way off topic. Turrets of a tank style, or in the style of a ship's weaponry can be effective, but can't really be strong, responsive, AND stable. 

And turrets don't really scratch the surface of where this is useful. 

Edited November 19, 2018 by Lurkily

[Дяденька]

Quote

Enemies - allow to detect DirectioanlSensor enemies in few patterns: Closest, Further, With maximum HP, With minimum HP.
Resources - same as above but excluding HP with three Key outputs per ore type.

It will allow to make awesome fully automated stations (motherships) with a swarm of a small destructive drones 😄

Additional to merging.
For altitude meter - when you impliment detection for ores it would be cool to see if we would be able to understand where the drone is by altitude. Example as a possible parameters for Altimeter: almost like for DirectionalSensor - mode list (Sumo Enemy, Cursor, etc) Planet, Cargo, Core.
When I talk about it I think it may be good ide to allow linking between GameObjects by reference to allow use their functional. Like in GMod with WireMod modification.