Events do not propagate without connection

[Lurkily]

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. 

[ManTheMister]

I’m not sure exacly what you mean. Do you want some way to detect wether a sub-drone is still connected to the main drone? Please elaborate.

[Lurkily]

Treat events like energy or fuel.  If you detach a drone from the core, it should require a wireless connection to receive key or tag events without a connection.  

Instead, now I must use logic splitters so that sub drones don't interfere with one another if I print two, and they have no easy way to know when they're decoupled. 

[ManTheMister]

I agree that there should be some way to tell if a drone is decoupled other than using distance sensors, but I do not think that logic should work like fuel/energy.

[Lurkily]

Can I ask why, though? It seems like intuitive behavior to me, and anything it breaks can be fixed by throwing a wireless connector in. In the meantime, it makes more criteria available by which to control a drone's behavior, without having to add parts or features. 

Do you have a specific objection? 

[ManTheMister]

I feel that it’s more intuitive (to me at least) that logic is all connected. And with my sub-drones. I usually only have 1 in existence at a time, and they have a button on them that lets my main drone know that they are in existence, and that button deactivated manual controls on my main drone. Both drones only have the same controls, but only 1 is active at a time. Either way, some people won’t be happy. Some drones do need to be connected to the main drone, while other ones don’t. You happen to use more that don’t while I happen to use more that do.

[Lurkily]

Why should it be obvious that Logic is broadcast, though?  Fuel and energy trains you in the opposite concept, and the wireless connector strongly implies that logic isn't wireless by default.

When I began with sub- drones, I re-worked logic three times before realizing that subdrone one was pushing subdrone two's buttons. 

It does make things a little easier for a novice, but most novices aren't creating complex logic-driven deployable subdrones, and it takes away some cues that advanced users may have a use for. 

[ManTheMister]

When I play games, I think about how the code works. Each tag/key is a variable that is on/off (in my mind when I started playing. That’s not how it actually works).

[FreakyWaves]

38 minutes ago, Lurkily said:

Why should it be obvious that Logic is broadcast, though?  Fuel and energy trains you in the opposite concept, and the wireless connector strongly implies that logic isn't wireless by default.

When I began with sub- drones, I re-worked logic three times before realizing that subdrone one was pushing subdrone two's buttons. 

It does make things a little easier for a novice, but most novices aren't creating complex logic-driven deployable subdrones, and it takes away some cues that advanced users may have a use for. 

Just put a prefix on your tags

I.E.: D1GL >>> Drone1GoLeft 

O R G A N I Z E 

[ManTheMister]

3 minutes ago, FreakyWaves said:

Just put a prefix on your tags

I.E.: D1GL >>> Drone1GoLeft 

O R G A N I Z E 

That doesn’t work when printing with factory blocks. All drones printed with the same factory block have the same tags

[FreakyWaves]

yeah I tought about that but instead of having a table system  don't see how it could be a thing

[Lurkily]

35 minutes ago, FreakyWaves said:

yeah I tought about that but instead of having a table system  don't see how it could be a thing

Now, you have to use a logic splitter to keep drones separate. If disconnection disconnected logic signals, losing a signal from the other side of the disconnection would provide feedback that you were disconnected. 

Logic is wireless now, though.  I feel it's not intuitive, and that broken connections are useful information that can provide a drone with additional self awareness. 

[FreakyWaves]

1 minute ago, Lurkily said:

Now, you have to use a logic splitter to keep drones separate. If disconnection disconnected logic signals, losing a signal from the other side of the disconnection would provide feedback that you were disconnected. 

Logic is wireless now, though.  I feel it's not intuitive, and that broken connections are useful information that can provide a drone with additional self awareness. 

BLUE PILL 

OR

RED PILL

CHOOSE WISELY ...

[Lurkily]

I'm trying to get a straight answer on why wireless is preferable.  The two schemes are equal in most regards, in my opinion -- except that non wireless logic enables connection status to be used in logic. 

Self - awareness is one of the biggest requirements for intelligent drone behavior. With these schemes mostly being equal, the increased self awareness is a very big point, in my opinion. 

[Micha]

Wireless is preferrable if you dont want to automate your drone, but want manually decoupable and flyable mini drones. It just works without the need of a transmitter part.

But I see the point. It was not really an active decision by us. It was just how the game evolved. Logic came first and decouplers where added later. ( First they shared energy and fuel too)

I'm not sure which solution is the best honestly

[Lurkily]

I think the two schemes are largely equivalent until you get to the information offered by the connection and disconnection of signals.

I've seen connection sensor ideas; in connection with the tracker you mentioned elsewhere, if you can point a connection sensor to a specific tracker, that would provide the same capability.  This seems a little more organic in the mechanics, though.

[Entity]

I kinda want local logic stuff too.

Would make certain things much easier to implement

[Crossing]

Make it so that parts can't receive or send commands without a wireless connector, basically like fuel and energy are now

 

[ManTheMister]

See lurkily’s “Logic events do not propogate without connection” (or something like that) suggestion.

[notsew93]

I also think that logic shouldn't be wireless without the transmission block. Right now, I am attempting to solve a very difficult problem, which is to both have a start signal for a drone, and for there to be multiple factory copies of a drone. 

The way things work now, if I want to have a deployable swarm of factory created drones, I absolutely must build them on a logic splitter, otherwise each drone cross-talks with each other and, for instance, they cannot each have a gravity sensor to stay level - the multiple copies of a gravity sensor all try to talk over each other with different readings. So, a logic splitter is a must. But if I build a logic splitter into my factory created drone, it cannot detect when the factory decouple button has been pressed, an action which I would also like to simultaneously turn the now decoupled drone-baby on. 

But I cannot. If I put a wireless receiver on the logic-split drone, all parts down stream of the wireless connector hear and transmit to the main core, and if there are two copies of the drone, then they still cross-talk each other. Worse yet, if I still want to create an activate on/off switch on the drone that switches on when the factory decouple button is pressed, it has to be downstream of the wireless connector - but if it is downstream of the wireless logic connector, it's signals are not passed to the rest of the drone baby that is sandwiched between the wireless logic connector and the upstream logic splitter. Plus the failed latched-on signal gets transmitted from the first printed drone to the second!

To get around this problem, I have resorted to a myriad of unreliable ways to kick-start my drone baby. One way was to put a heater on the main body that activates when the factory decouples, and a temp sensor in the logic-split part of the drone baby that turns it on when it gets warm. This works but is slow, and sometimes my main drone gets too warm, and newly printed drone babies would turn on too soon even with the heater off. 

A second way was to put some non-logic split thrusters on the baby drone, and have the drone activate when it detects a non-full fuel tank. This works, but now my drone baby will sometimes activate prematurely if my main drone accidentally uses some of the baby's fuel. 

A third method was to use the speed sensor, combined with jump rockets or magnets to kick the baby off to a running start, but to solve the premature activation problem I needed the main drone to be slower that I'd like. 

A fourth method was to use the distance sensor set to "own drone", and have a suitable ejection magnet so that the drone baby would turn on when it doesn't detect the parent anymore - the flaw with this method is at the start of a round the distance sensor will sometimes spawn undetected for what must be a single game tick, and the babies would turn on right away. 

A fifth method was to use the directional sensor set to drone core twisted 90 degrees. Print the drone baby and eject it above the drone, and when it drifts below the drone core it would latch the on-state. Works, but like all the methods outlined here it requires extra logic parts on the baby that become dead weight shortly after launch. 

The solution, I believe, is similar to what @Lurkily is trying to explain - which is when a drone is decoupled, whether from factory or plain decoupler, is that the logic should be split off also. 

 

I understand that decouplers and factories where added later in game development, and while I surely am not familiar with the game's source code, if you will let me @Micha, I think I would like to try and outline a way that this could be implemented. 

The desired behavior for this idea is the following: When drone parts are still physically linked to the drone core, they receive and send logic signals up and down the tree. When a connection in the tree is severed, whether from factory decoupling or decouplers or plain old damaged/destroyed parts, any parts down the tree branches from that point cannot send signals up through the broken tree area or receive signals from above. Unless, of course, the severed section of tree carries with it a wireless logic receiver component. This would allow the main drone core to send a startup command to the baby drone while the baby is still physically and logically connected to it's factory, and also allows the baby to fly free and be independent from it's future twin sibling. 

So, while we want it to look and feel like the logic is carried by wires through the grey joints of the craft, this is programming, and these variables and such are globally accessible by all the drone bits because this is all virtual, and there exist no physical constraints unless you choose to impose them. So how to we make subtrees of the drone cut off logic? I will say that i don't know, but I do know that somebody on your team figured out a way, because the logic splitter part exists. 

What I would propose, then, is to create a new class of drone component - an invisible indestructible damage-free temperature proof physics-less class of components, which may yet still occupy a node of the drone-tree graph. (I am assuming that drones are stored internally as a one-to-many linked-list tree of component objects) With this class of "virtual" components, I would make one of these new virtual  create one with the same logical properties as the logic-splitter component, so that if one of these virtual logic splitters is contained along the branch of the tree components it does the logic-splitting capability. 

How does this help us? I would further suggest a detection event in all parts or some other event handler method looking to see if the parent parts of any component have been destroyed or disconnected via decoupler or factory. If this child component is no longer physically connected to it's parent, then create a virtual logic-splitter component and insert it as the new parent of the disconnected child, and as child of the disconnected parent. Then later, if necessary, add detection events for if the children of the virtual logic-splitter are destroyed - if they are, then remove and delete the virtual logic splitter component. (While creating a new virtual logic splitter as a new parent for the now orphaned grandchild component.)

On a tangent now to expand on the virtual component notion, a virtual component could also be assigned the duty of what I'll call "Sub-root", the possession of which is what would declare drone parts trash (and friendly fire-able) or not. If the parts on a physically disconnected subtree are still "useful", then they get a Sub-root that declares them not-trash. If the physically disconnected subtree is not usefull, then it gets a trash-root, which declares all desendants as trash and friendly-fireable. "Useful", however, is tricky to define. A chunk of thrusters with no fuel is trash, but if it still has an active computer it may not be. 

 

I know that something like this would be much trickier to implement than it is to say, and it was pretty tricky to say. I do, however, believe that somehow binding propagation of the logic of a drone to whether or not the components are physically connected would greatly benefit the game. It is more intuitive to non-programmers than are global-variables-by-default, because people can see the grey component struts behind the parts and associate such connection lines as necessary for fuel hoses or electrical wires or data cords. We can still have the option of global signal sharing with the wireless logic connector - a part whose very name suggests what it is for. (And the name alone already would imply that it should be needed on decoupled parts. Without the logic splitter part, what use would the wireless part ever have in the state of the game today?) When someone like myself walks in to a game like this and can see that the factory prints new parts, I totally expect that the factory's children are not hiveminded, for two products from a real life factory do not behave that way. Plus, while broken-off thrusters are amusing when they wizz around wildly, if logic is bound to a propagation model then they would fall silent unless specifically designed to be separate. 

Thank you for your time, and for the lovely game. 

 

 

[Lurkily]

You can put an on/off switch downstream of a splitter, then a wireless connecter, which transmits only to its children, I believe.  (I haven't actually used this yet.)

The flaw in this is that if you choose to deactivate or reactivate any of them, you can only de/reactivate ALL of them.

Mine have a small thrust away at all times, and only activate away from the main drone, or at a certain altitude.  

[notsew93]

Ah, but the wireless connector also performs the functions of a logic splitter. The on-off signal in this scenario does not receive its on pulse, and even if it did, the output would not propagate down past the wireless logic connector. 

Behold! The button and two lights are all set to the same tag. 

[unmog]

28 minutes ago, notsew93 said:

Ah, but the wireless connector also performs the functions of a logic splitter. The on-off signal in this scenario does not receive its on pulse, and even if it did, the output would not propagate down past the wireless logic connector. 

Behold! The button and two lights are all set to the same tag. 

Huh? This seems useful to me but... Im not sure I clearly understand whats going on or why. >.> These two blocks have caused nothing but headaches for me tho so when I thought I understood how they worked and tried to use them in a way everything just crashed and burned.

[notsew93]

Right. I very much agree that these block are not intuitive or obvious, and my long-winded babbling above is only trying to find a way to make it better. 

[Lurkily]

7 hours ago, notsew93 said:

Ah, but the wireless connector also performs the functions of a logic splitter. The on-off signal in this scenario does not receive its on pulse, and even if it did, the output would not propagate down past the wireless logic connector. 

Behold! The button and two lights are all set to the same tag. 

Wait . . . what? . . . huh . . . that is weird.

[notsew93]

I have a different idea for the logic problem: create a new drone part, called something like "Sub-Core" or "Mini-Core".

This new sub-core would be an octagon in the same color scheme and patterning as the main drone core, but be the size of one of the large fuel tanks. The intent here is for it to serve as the basis of a second drone, and it's physical appearance and name would suggest as such to the player. It has the following properties:

1. The mini-core is both a drone core and a drone component.  This means that it possesses a self-destruct feature like the main core, and can be attached to other parts of the drone like any other component. (specifically, you'd want this part as a child part to a decoupler or factory.) Because it also counts as a core, it is self-validating in terms of being turned to destructible junk - if any parent parts of the child core are destroyed, the mini-core and it's children are are not turned to destructible chaff so long as the mini-core (and main core) still lives. But since it has the self-destruct feature, you can still clean it up easily enough.

2. Because this is a mini-core, it is "diminished in features" as compared to the main core - as in, it's poor radio cannot receive keyboard or mouse clicks directly from the Nimbatus, only the main core can do that. This means that while the mini-core is still physically attached to the main drone, it can use the main logic network, but when it becomes disconnected from the main drone it instead behaves how the current logic splitter does. The only key it can receive from the main drone is the self-destruct. 

By attaching this new idea of physical-detachment-means-logical-detachment to a specific part, we can keep how logic works in existing drones (since people seem to like that global wirelessness), and since this part looks like a drone core and has some of the same features as a drone core, it helps the player understand what it is supposed to do and be for. As a bonus, if the mini-core itself has a decoupler child, it can still wirelessly control that part. And who wouldn't want their drone that can have drones have drones of the drone's drones.