Jump to content
Stray Fawn Community

All my thoughts on sensors/logic, in a single coherent picture.


Lurkily

Recommended Posts

I've posted a lot of suggestions to make our creations more dynamic, responsive, to intelligently respond and adapt to a player's intentions. I wanted to put up a post about what they look like in a coherent picture. 

First, the basics. I think logic should be local. That is to say, parts should require a connection to see a signal. Even the lack of such a connection is information that can be of great value to an engineer, activating a missile's flight or indicating to the brain that something critical is destroyed, and I think wireless logic with wireless connectors present is a meaningless 'gimme' that circumvents a logistical problem that could be quite rewarding to overcome via design. 

Speaking of connectors; I think wireless connectors should go to a pair of units, transmitter and receiver, each with the option for a whitelist or blacklist of signals that are permitted or forbidden. Receivers should act like a simple button, relaying signals that pass their whitelist/blacklist. Connectors currently block signals, but with control over the direction signals travel and the type of signals traveling, I don't think that separation is necessary.  

Sensors. I would like sensors to have ranges that can be added. A directional sensor might have one range and one tolerance, or five ranges and no tolerances, and it shouldn't have to be filled sideways to adjust the tolerance. Instead, add and adjust ranges as you see fit, and anything you don't set is a tolerance. 

Self awareness is a big thing. Trackers will help a lot, if sensors can seek a specific tracker, not the nearest or average center. Things like a GPS setting for the directional sensor (your current rotation around the planet, with Nimbatus being 0/360) would also help. 

Awareness in general will also help. My complex creations often stumble on simple things like not being able to position themselves well, hooking on terrain that slips through sensor fans, unexpected input leaving hinges in unexpected positions, etc. 

The previous adjustable ranges will help. I think permitting detector sensors to have even a narrow angle, so they're a fan instead of a line, would help with sensor criteria 'dodging' sensors. More criteria for sensors to operate on will also help. 

Altitude should be a general purpose distance sensor, with units that aren't changed by planet size. Instead, when used for altitude, they should have the option to have a specific starting value. (Altitude of the core, surface, hopper, Nimbatus level, and whatever in between marks are appropriate. ) It should be able to measure distance to any sensor criteria that makes sense. 

Dynamic sensor control.  Sensors can be as powerful as a keyboard in controlling complex behaviors. I'd like to see the ability to adjust the range of a sensor dynamically, the same way dynamic thrusters can be adjusted.  That way, fine dynamic control can be achieved without math parts, without dozens of ranges, without tons of logic. 

Processors. Think of them as a box that can contain a few logic parts. My opinion is that every 1x1 footprint of a processor should contain a 2x2 footprint of sensors or logic. This means you could use them to put very compact directional sensors on a hinge, or put a whole raft of complex logic in a larger processor. 

The reason is twofold. Obviously, it makes streamlined construction easier. But it also reduces part count for logic. Sumo is far too dependent on brute force - smart drones are weaker drones. I'd like to see that mitigated to reward intelligent design and intelligent done behavior more in asynchronous multiplayer. By limiting the available size of professors, or by damaging the parts it contains when the processor is damaged, you also aren't totally eliminating the threat posed by logic damage. 

 

In the end, this will provide wired logic as a challenge, with a simple transmission system to overcome it that is intuitive, and treats all signals the same, while still providing exacting control. It will provide dynamic, precise behaviors without requiring math. It grants a player more awareness to tune complex behaviors by as they cruise around, as well as granting awareness of your own drone's behavior via trackers. It rewards intelligent design in sumo and any part restricted game mode, without limiting the vulnerability of logic. 

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

It's just my two cents, but here you go

On 12/12/2018 at 11:26 AM, Lurkily said:

First, the basics. I think logic should be local. That is to say, parts should require a connection to see a signal. Even the lack of such a connection is information that can be of great value to an engineer, activating a missile's flight or indicating to the brain that something critical is destroyed, and I think wireless logic with wireless connectors present is a meaningless 'gimme' that circumvents a logistical problem that could be quite rewarding to overcome via design. 

I'm not on board. If you've ever debugged real world physical circuits and logic gates before, you know that missing connections and spaghetti of wires does not help. Regarding detection of critical destruction, I've found drone-detecting sensors to be useful for this.

On 12/12/2018 at 11:26 AM, Lurkily said:

Speaking of connectors; I think wireless connectors should go to a pair of units, transmitter and receiver, each with the option for a whitelist or blacklist of signals that are permitted or forbidden. Receivers should act like a simple button, relaying signals that pass their whitelist/blacklist. Connectors currently block signals, but with control over the direction signals travel and the type of signals traveling, I don't think that separation is necessary.  

I'm in favor of whitelist and blacklist signals. This would allow better more fine control over state/signal propagation, but without all the spaghetti mess of manually wiring stuff. In other words, pervasive signal propagation should be the default, but restricting what signals can propagate should be an option.

I don't know if receiver/transmitter pairs are necessary though. I think whitelist on logic splitters and blacklist on logic connectors would suffice.

On 12/12/2018 at 11:26 AM, Lurkily said:

Sensors. I would like sensors to have ranges that can be added. A directional sensor might have one range and one tolerance, or five ranges and no tolerances, and it shouldn't have to be filled sideways to adjust the tolerance. Instead, add and adjust ranges as you see fit, and anything you don't set is a tolerance. 

This is difficult to understand. Are you saying, for example, you would like to configure directional sensors so they can detect thirds, fourths, fifths, or any other arbitrary split of radial ranges? I think I could see use in this. Actually I know I could. I'm on board in principle.

Also I think people don't understand what tolerance is. I think the graphic is very very misleading. The tolerance isn't a dead section of the circle, it is the amount of slack the directional sense has.

On 12/12/2018 at 11:26 AM, Lurkily said:

Self awareness is a big thing. Trackers will help a lot, if sensors can seek a specific tracker, not the nearest or average center. Things like a GPS setting for the directional sensor (your current rotation around the planet, with Nimbatus being 0/360) would also help. 

Position trackers are recently released and can be turned on and off by signals

On 12/12/2018 at 11:26 AM, Lurkily said:

Awareness in general will also help. My complex creations often stumble on simple things like not being able to position themselves well, hooking on terrain that slips through sensor fans, unexpected input leaving hinges in unexpected positions, etc. 

The previous adjustable ranges will help. I think permitting detector sensors to have even a narrow angle, so they're a fan instead of a line, would help with sensor criteria 'dodging' sensors. More criteria for sensors to operate on will also help. 

Proximity sensors are now released

On 12/12/2018 at 11:26 AM, Lurkily said:

Altitude should be a general purpose distance sensor, with units that aren't changed by planet size. Instead, when used for altitude, they should have the option to have a specific starting value. (Altitude of the core, surface, hopper, Nimbatus level, and whatever in between marks are appropriate. ) It should be able to measure distance to any sensor criteria that makes sense. 

Dynamic sensor control.  Sensors can be as powerful as a keyboard in controlling complex behaviors. I'd like to see the ability to adjust the range of a sensor dynamically, the same way dynamic thrusters can be adjusted.  That way, fine dynamic control can be achieved without math parts, without dozens of ranges, without tons of logic. 

To me it sounds complex, but good if the complexity is tolerable

On 12/12/2018 at 11:26 AM, Lurkily said:

Processors. Think of them as a box that can contain a few logic parts. My opinion is that every 1x1 footprint of a processor should contain a 2x2 footprint of sensors or logic. This means you could use them to put very compact directional sensors on a hinge, or put a whole raft of complex logic in a larger processor. 

The reason is twofold. Obviously, it makes streamlined construction easier. But it also reduces part count for logic. Sumo is far too dependent on brute force - smart drones are weaker drones. I'd like to see that mitigated to reward intelligent design and intelligent done behavior more in asynchronous multiplayer. By limiting the available size of professors, or by damaging the parts it contains when the processor is damaged, you also aren't totally eliminating the threat posed by logic damage. 

So if I understand correctly, you want to discount complex logic?

I share the goal. There are lots of different ways to solve that goal though. In the following thread, I mention two new gates that if introduced would allow for all possible "2 inputs and 1 output" logic to each get their own gate.

Another possible idea is a 2x2 tile that accepts 4 inputs, produces 1 output, and is basically a configurable 4 input truth table. This would extremely help condense complex logic. The configuration UI might be difficult to design though.

  • Like 1
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...