Ateready

I don't know how to do this, any help? I'm sorry that this is in unrelated, I couldn't find a place for this that fits.

Donut? Laser? They say that aliens built the pyramids, but it was us becoming aliens to the true shape of the Earth. The Egyptians knew it, the illuminati knows it, and now so do you! THE EARTH IS A PYRAMID!!!

This is a great point, in fact, this could fix some of the problems with current logic in many ways. With this kind of feature, disconnection would be the logic splitter. In fact, with this as a base for new logic, some major changes could be made to allow for better logic. The assumption on how this would work is that anything on a decoupler, factory, or not attached to the main drone effectively has a logic splitter. Hmm... getting further into the subject of better logic makes me re-think what I've said. It makes a lot of sense for logic to not transmit when disconnected. I'm thinking of changing the suggestion to this, tell me what you think: -connectors and splitters are removed, but ther functions are still imitable -logic disconnects like energy, so anything attached to a decoupler, factory, or disconnected is automatically part of a different logic group -logic can be sent to other disconnected parts of the drone via logic transmitters and receivers -receivers each have their own number to identify them and send signals to the rest of the drone their on. The drone core has a built in receiver -transmitters can select which receiver they send signals to, and can be always on, on only when a key is pressed, switched on/off and can have a separate option of sending all signals from their drone or only one of them And that's it. I believe this wouldn't be too hard to implement, it would fix the problem with how drones communicate, while still letting drones function exactly how they do. As I said, what do you think? Should it work like this? Should I change the post to this? I feel this is a valuable discussion and changing the entire post's name and would be reckless.

Okay thanks for responding! I didn't know you could remove it by just typing, but still, when you press backspace it should be removed. I'll make sure to edit my main post! Also, your idea is nice, but I suggest you create your own post, this is just about the tag starter text.

This is as simple as it sounds. Adding tags is currently counter-intuitive as the backspace key needs to be held down for a second if one doesn't know that all you need to do is type. This may not sound bad, but making this text get removed the moment someone presses backspace would make it more like search bars and would simplify the game for new users.

Yes, you are mainly correct, as of the current update, you can have the main drone body send and receive signals between the section with the logic connector. What I should have mentioned is that the sub-bodies of the main drone, separated by logic splitters, cannot communicate between parts attached to connectors attached to the splitters. This bugs me as I see no reason why the main drone works this way, while logic sub-bodies with their own sub-bodies do not. I updated the demonstration bot (dark blue for the connector body, cyan for the main drone and red for the splitter but not connector body) to include the main drone relationship and created a diagram of how I think logic bypassers should work or how connectors could be reworked. I hope this better shows what I mean. Again, correct me if I'm wrong, but logic connectors work only with the main logic body and are splitters to any sub-bodies that they are a part of, not communicating with each other even though the connector isn't supposed to break signals. In the graphs below, if there is not a blue arrow directly to one place from another, but they do indirectly go there, that means that the intermediary logic bodies receive the signal, but have to respond to it and create their own to pass it on by using if gates, for example. In fact, logic bypassers might be redundant, as they would only do what the rework does, and the rework wouldn't do any harm at all as the signals would only go to the connector body, and it would have to make a decision of whether or not to pass it on by using an if gate or something else. Just in case, here's the name for the demonstration drone as well: Demonstration_Drone_36482 logic bypassers.docx

My idea for an improvement is that signals can be sent from one logic body to another, either separated by a connector or splitter, using logic bypassers. Logic bypassers would come in two forms: Constant logic bypassers and active logic bypassers. Logic bypassers would allow the blue led to be powered on the upper part of the craft below, while the improvement to connectors would allow the button above to power the red led below. Active Logic bypassers would be turned on by a certain binding, and while active would route all logic inputs from its logic body to the selected logic body. Constant Logic bypassers would do the same but without an activation: they would always be active. Basically, this would allow a signal from the play to an active personal drone to send, but only if its active and only one way. These splitters would be a useful tool for allowing some inputs of a drone, but not others, to pass. For example, if I wanted to create many personal drones, but with more key bindings than currently available, i couldn't right now. With connectors working the way they are right now, if i wanted the controls on all drones to be accessible, I would have to put them all on splitters, due to how they use more bindings than available, then put connectors for the cameras. The problem is, however, that i can look from their perspective using the cameras, but I just can't send inputs to the rest of the craft. With a logic bypasser, however, i could place one and the craft would respond to my touch, but it wouldn't send signals to the rest of the drone. This is also useful with nitpickers like me who want to make their craft 'accident proof'. With the use of logic bypassers and better logic connections, one could make a logic craft have all the useful inputs sent in, and all the useful outputs sent out (or used on the craft) , but if somebody tried to press any of the bindings for the actual processing, they couldn't make it output something it wouldn't have otherwise. Logic bypassers would have a huge potential, and hopefully we could have them only let certain signals through (like WASD), transcending this game's impressive logic to a whole new level. Who knows, if the developers of NImbatus read and implement this, we could reach beyond the key bindings! Thanks for reading this, I hope you are interested!