Jump to content
Stray Fawn Community

A dev question about logic


Lurkily

Recommended Posts

Discussion about logic has sometimes been confused by not understanding logic - some suggestions are feasible or silly based on certain criteria. 

The question is, how does logic propagate? Does it propagate?  Or does a part just query for all connected signals?  Or are segments of the hierarchy, separated by splitters and wireless parts, assigned to 'signal regions' determining what signals to respect, or not? 

This is mostly a curiosity, but I feel it could help avoid some logic suggestions from getting derailed by ill informed ideas of feasibility.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

The drone brain,  logic splitters and connectors have a "hub" which contains a list of active signals.
The splitters and drone brain have a seperate hub, but the connectors just foward queries to the drone brain.
Each dronepart has a reference to it's parent hub, which is found by traversing the hierarchy upwards starting from the dronepart itself.

This reference is then used to ask if a signal is active or not.

  • Like 2
Link to comment
Share on other sites

 

19 minutes ago, Micha said:

The splitters and drone brain have a seperate hub, but the connectors just foward queries to the drone brain.

So to make a wireless part not act like a splitter, you would just need to have a splitter part also collect the active signals from the children of a wireless part, if any, and list them in its hub?

Then wireless signals would only be accessible by children of the wireless part, but those children could generate signals that could cross the wireless part, and a wireless keypress could activate control in a split -off drone, such as sending a 'cease bombing' signal to a bomber fleet. 

  • Like 1
Link to comment
Share on other sites

A wireless part that does not split but gets the signals from the dronebrain would have to combine the signals from it's parent hub (which might be a splitter or another wireless part) and the drone brain which has information about the manually pressed keys.

Or am I not seeing something?

 

  • Like 1
Link to comment
Share on other sites

I'd like to see the parents of a connector (or the other children of those parents)  to be able to see signals from the connector's children - but not signals from the brain. If parts only query upward for a signal, it sounds like the splitter upstream of a connector would have to provide the active signals generated by children of the connector. 

  • Like 1
Link to comment
Share on other sites

God that whole paragraph is a confusing mess.  I'm not at home, or I'd provide pictures.

Say you split a drone off to avoid crosstalk with duplicates. I'd like to have a wireless part with a switch as its child, controlling the drone's activity. 

Right now, it sounds like most parts query the splitter, who doesn't know what the connector's children are doing. 

  • Like 1
Link to comment
Share on other sites

image.png

Here's one I used for a feature request elsewhere.  Every button and every LED is set to 'x'. 

The lower left LED doesn't light up because it's asking the splitter what's active, and the splitter doesn't give a fig about the button beyond the connector, right?  If splitters contained not just the signals from their segment, but also the signals beyond any child connector, then that lower left LED would light up.  Since the LED queries upward, the connector wouldn't be able to deliver the information to the LED, unless I misunderstand.

Now imagine that button is a switch, instead.  I could activate it with a keyboard command.  The splitter would still remain functional, hiding the keyboard commands I issued, but the drone would respond to the state of the switch normally.  I could selectively send some commands, but not others, past the splitter.

Normally you have to split-off factory-built drones, otherwise they crosstalk.  You can split SOME things, like weapons control into a wireless section of the drone.  But if you need that weapon control to respond to logic on board the drone, perhaps linked to maneuvering, then you have some problems on your hands.

  • Like 2
Link to comment
Share on other sites

It seems to me that this could be fixed by having the splitters communicate with pieces that are children of connectors, without communicating with the connector (make the connector act like a basic block [no signals] instead of the end of a line when the splitter is checking for/sending signals downstream of itself), and parts downstream of a connector would communicate with both the splitter and the connector.

If Having a part communicate with two hubs is not reasonable, then having the connector hub acts the core hub plus the parent splitter hub, and have the splitter hub sync with the non-core part of the connector hub, so that signals from both sides of the connector could crosstalk.

With either of those systems, if there was [button(A) —> splitter —> LED(A), LED(B) —> splitter —> LED(A), LED(B), button(C) —> connector —> LED(A), LED(C), button (B)], then the first/second/third LEDs would be off, and the fourth/fifth/sixth LEDs would be on.

  • Like 1
Link to comment
Share on other sites

Well, the connector doesn't generate a signal of its own - it doesn't even have a list of active signals of its own.  As I understand, if an item queries the connector, it just gets a response from the drone brain, instead. 

A splitter should just be able to see all signals beyond a connector, add those to its list of active signals, and that's the end of the splitter's job.  It doesn't have to exclude the connector, because there's not a real signal being generated there. (I think?  I think the signals listed by the hubs are different.  Maybe.) 

As for things beyond the connector reading parents of the connector, you're right; @Micha said it, too, but I was focused on signals going from the wireless segment to the split part, not signals from the split part going to the wireless segment.  From the picture above, if the button were attached to the lower-left LED instead, it would need to light up the lower-right LED - the connector can duplicate a parent splitter's signals to accomplish that.

  • Like 1
Link to comment
Share on other sites

29 minutes ago, Lurkily said:

Well, the connector doesn't generate a signal of its own - it doesn't even have a list of active signals of its own.  As I understand, if an item queries the connector, it just gets a response from the drone brain, instead

A splitter should just be able to see all signals beyond a connector, add those to its list of active signals, and that's the end of the splitter's job.  It doesn't have to exclude the connector, because there's not a real signal being generated there. (I think?  I think the signals listed by the hubs are different.  Maybe.) 

That would be option 1 in my above suggestion. Parts that are the children of a connector would have to interact with both the splitter hub AND the core/connector hub, and right now parts only interact with 1 hub.

Link to comment
Share on other sites

I don't think they need to query two hubs; the hubs just need to interact with each other differently.  The splitter reads signals that are children of a connector, and a connector mirrors signals hosted by the splitter.

Link to comment
Share on other sites

Connectors and splitters are already queried by their children - I suspect I'm not understanding your meaning. 

In short, I want non wireless signals to be able to cross a connector. I think a signal connector blocking signals is what's not intuitive, though I'm willing to listen if people disagree. 

Link to comment
Share on other sites

No worries! By my understanding of how logic works, parts perform two logic related functions:

 

Parts periodically check the drone core for signals relevant to them. (barring a splitter)

Parts add signals to the drone core as they are triggered. (again barring a splitter)

-------------

So, my (convoluted) question was whether, rather than overhauling logic, if it would be more straightforward, at least short term, to create a part that prevents it's children from adding signals to the drone core. (thus creating parts that can view the signals in core stack without adding to them) Also whether your suggestion had additional benefits that I overlooked.

  • Like 1
Link to comment
Share on other sites

Isn't that what a splitter already does?  Parts behind a splitter do not have their signals added to the core, and instead are collected in the splitter's hub.

I'm not sure how that would help the parent of a wireless part receive a signal from its children.

Link to comment
Share on other sites

17 minutes ago, Lurkily said:

Isn't that what a splitter already does?  Parts behind a splitter do not have their signals added to the core, and instead are collected in the splitter's hub.

I'm not sure how that would help the parent of a wireless part receive a signal from its children.

What I understand garheardt was saying was that there should be a 1-directional logic splitter, letting parts read signals from the core, but not send them to the core. That way there could be sub-drones that could be sent signals, but couldn’t cross talk. I think that having a wireless receiver (described above), a wireless transmitter (the opposite), and a 2-way version (equivalent to current wireless connector), in addition to the “events do not propagate without connection”, would solve most of the problems that make us want the joiners to not be splitters (not saying I’m against that as well, but I don’t think that it would be necessary with 1-directional wireless).

  • Like 1
Link to comment
Share on other sites

I see how that would help . . . but I've got a few issues.

Firstly, you still has a connector that acts to disconnect signals, and I don't think that's the way most people expect the connector to behave.

Secondly, it's a very technical breakdown of wireless activity with subtle and confusing differences between the parts.

Lastly, if we had single-key transmitters and receivers, I would actually argue for giving them an 'all signals' setting, and having all hubs fully mirror any non-splitter child hub so that wireless parts don't split any signals, not even wireless signals.  If you can be selective with the signals you send, you don't need to be selective about which signals can cross.

Link to comment
Share on other sites

8 minutes ago, Lurkily said:

single-key transmitters and receivers, I would actually argue for giving them an 'all signals' setting, and having all hubs fully mirror any non-splitter child hub so that wireless parts don't split any signals, not even wireless signals.

1

Actually . . . I think this might be a better solution.  Receivers wouldn't impede anything.  Splitters would be the only part to block signals, as their name implies, and wireless function would be consistent in every respect, and selectivity in the commands sent is built-in.  You wouldn't need a separate part at all, just modify the connector into a transmitter/receiver pair instead.

 

Link to comment
Share on other sites

I wasn’t referring to transmitters/receivers that only sent 1 key (which might also work). I was referring to ones that sent but didn’t receive, or ones that received but didn’t send. They don’t have to disconnect signals, I just don’t think it would be strictly necessary that they didn’t.

Link to comment
Share on other sites

2 minutes ago, ManTheMister said:

I was not aware of those. We’re they in an older version of the game before the steam release?

I'm specifically referring to Entity's feature request, when I mention single-key transceivers.

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...