Jump to content
Stray Fawn Community
  • 10

Events do not propagate without connection


Lurkily

Post

I'd like to see events cease to propagate without a connection.  Right now, it is very hard to determine when a sub drone is detached, and should try to move.  (Not everything should be immediately decoupled. )

We have a wireless transmitter, and losing a signal from a decoupling is valuable information. 

  • Like 1
Link to comment
Share on other sites

Recommended Posts

  • 0

How would a sub-core be different from a sub-drone fully parented to a TNT block?  It would be self-destructible.  How would it solve this logic problem without logic being localized?  Right now, every part can receive every signal.  This doesn't seem to be an alternative to local logic, it seems to rely upon it.

Link to comment
Share on other sites

  • 0

Maybe the mini-core is a requirement on sub-drones. If a piece is not connected to a core, then it is debris. And it fits with lore. It might get annoying if you want to build small drones, and when it got implemented everyone would have to modify their current drones, but I think that it would be a good addition long-term.

not too sure about this part, but thought that i’de mention it: maybe there are different sizes of mini-core, and each can support a different number of parts 1x1 might hold up to 20, maybe 2x2 could hold 60, and 3x3 is 100?

Link to comment
Share on other sites

  • 0

So every beacon, every missile would require a core?  I couldn't detach ore containers over the hopper and let them empty, of have a thruster propel a component away prior to self-desstructing it, without also putting a drone core on it?

And if logic is already local, what do they earn us?  A self-destruct system can already be fulfilled through other means, and so can further localization of logic.

Link to comment
Share on other sites

  • 0

Ah, no, this sub-core idea was meant to be presented as an alternative to the idea of all-logic-gets-cut-when-parts-are-cut idea. Another way of looking at it without all the flowery trappings I gave it is that this mini-core would serve as a logic splitter component, that only splits the logic when it itself becomes physically split. 

Yet another alternative would be a version of the current logic splitter components that can be activated/deactivated with a key/tag binding. 

Link to comment
Share on other sites

  • 0

So logic would be global, as now, except when there's a subcore present, which will segregate logic, but only under the condition that it has no direct connection to the main core.

It just seems a lot harder to explain to a player, and it doesn't seem to have a marked advantage over simply localizing logic.  That's easy to explain; "logic needs to be connected."

Link to comment
Share on other sites

  • 0

So I made a mock up to demonstrate the current logic:
The Arrows/Lines show the different connections/networks.
Each color is a separated network.
The Letters are keys pressed.

Nimbatus_Networking.thumb.png.75d6d7cab8ec5c814eefc4c4038de440.png

And yes the big red arrow shows a wireless connection that shouldn't be there.
I agree that this is a confusing behavior.

I would prefer if we had a "wireless transmitter" and a "wireless receiver" that would allow us a fine control over what is connected to what.

There are several design choices here:

  • A emitter -> receiver connection this would be a on way connection of one or multiple inputs send to receiver, basically a button that is pressed "remotely".
    This is the most simplest and straight forward form.
  • A bidirectional connection, basically all things with the same network name are connected as if they where one construct.
    Almost how the receiver works at the moment the only difference he would also be a sender for logic.
  • A remote control that switches completely and acts as virtual drone core with the ability to take over controls also a "return control" function.
    This would also needs two blocks the pseudo core and the trigger block to take control of it.
    This also makes it far simpler to distinguish what is debris and what not.
    The pseudo core could also have a "next" function that gives the control to the next pseudo core with the same name.

Each has it's own advantages and disadvantages, your pick.

Link to comment
Share on other sites

  • 0
8 minutes ago, MrFaul said:

That is exactly point one I made...

 Which is why I thought you'd like to lend your voice and/ or vote there, along with anybody else reading this.  I didn't link you there because I thought you were wrong. 

I do think allowing signals not generated wirelessly to cross to a wireless parts parents is a good option 4 though. It's the one I favor.  I think it carries the potential to provide a simple logic solution to most wireless problems. 

Link to comment
Share on other sites

  • 0

I personally think having non wireless signals cross wireless parts is enough. By activating an if gate, you get that result; a select signal passes to the split segment, and the signal generated by the IF gate can convert it to a local signal the whole split section can see.

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