Roblin

@ababaBABABABABBA how would one make a signal filter, as described in the OP from the existing logic parts? to clarify: the goal is to have 3 seperate parts, 2 of which are exact duplicates of each other (both produced from the same factory part) where the duplicates are not communicating with each other but are communicating with the 3rd part. how would one make that with existing logic parts? @Konchog After reading that wiki page I am confused as to how a delay gate does anything like this. the desired behaviour from a signal filter that I describe in the OP is not "Filters out signals shorter than the time switch" which is what a delay gate does according to the wiki you sent. the desired behaviour is "child parts ignore/are unaffected by some but not all signals coming from parent parts (or other branches from parent parts)" the important thing is to allow some communication between what is essentially 2 systems seperated by a logic splitter. delay gates does nothing of the sort.

As is, the programmer can simulate any input that any other captain can perform, with the exception of the mouse cursor, this causes some clunky behavior. in particular, this is especially important for combat, which is very strange for the programmer. Combat is essentially trivial, because every problem related to combat can be solved with 'moar guns' and any energy problems that arise can be solved with 'moar energy' However, because guns aiming is strictly 'fixed' that means that aiming the guns are complicated. frequently it is far easier to rotate the entire space drone to aim towards the target than it is to rotate some sort of connected turret comprised of several guns. (having a rotating turret with only 1 gun is not worth it space-efficiency wise) so the go-to solution becomes 'fire in every direction' which makes for some very boring gameplay. this can be solved by allowing the guns to actually aim similar to how other captains can: by rotating in place to aim at some simulated cursor. this would likely make people use fewer guns on programmer creations simply because there would be more fun ways of solving the problem: make the guns you do have actually aim at the enemy the way other captains can.

The programmer cannot control their drone at all, so there is no reason to have the camera follow it. Right now if you, as the programmer, want to be able to see how different parts of your drone is doing (if for example you have detached subdrones) you would need a system of cameras that rotate being activated or have a rather sophisticated setup that makes drones sense their surrounding to determine whether the player is interested in watching it at that time, and hopefully 2 drones dont decide they want your attention at the same time because then you would be watching the midpoint betwen them, often seeing nothing at all. why not just let the programmer move the camera freely since they can't control anything anyway? maybe have the camera follow the drone core/camera controllers by default but the programmer can detach their camera by the press of a button to make it free to control.

@garr890354839 true, one can use the keys + the tags to make OR gates with effectively more inputs, but for purposes of more structured programming, I would strongly discourage anyone from programming with keys. the single-letter notation makes the names very ambigous and it is far easier to avoid bugs by using tags with descriptive names like ROTATE_RIGHT or FIRE. even when making a drone that is partially controlled by the player and supplementally controlled by logic I would encourage people to have IF gates that translate keystrokes into tags for programming the internal machinery.

Idea: more (preferably arbitrarily many) input rows for AND/OR/NOR/NAND gates purpose: simplify programming currently if you want to make a signal that means ROTATE_RIGHT AND RESOURCE_FOUND AND ENEMY_NEARBY AND STUCK_UNDER_TERRAIN you would need to first make an AND gate that combines ROTATE_RIGHT and RESOURCE_FOUND into ROTATE_RIGHT AND RESOURCE FOUND and then use another AND gate to combine ROTATE_RIGHT AND RESOURCE_FOUND and ENEMY_NEARBY into ROTATE_RIGHT AND RESOURCE_FOUND AND ENEMY_NEARBY and then use another AND gate tat combines ROTATE_RIGHT AND RESOURCE_FOUND AND ENEMY_NEARBY and STUCK_UNDER_TERRAIN into ROTATE_RIGHT AND RESOURCE_FOUND AND ENEMY_NEARBY AND STUCK_UNDER_TERRAIN. why not just let us use 1 AND gate to take all 4 inputs? it's unlikely to affect the balance of the game since the partial AND statements are often useful in ones drone, but I see little reason why the logic gates are limited to taking so few inputs when their various functions can be so easily extended to allow arbitrarily many inputs. possible implementations: AND gate: take any number of inputs, gives output if all inputs are recieved. OR gate: take any number of inputs, gives output if any inputs are recieved. NOR gate: take any number of inputs, gives output if no inputs are recieved. NAND gate: take any number of inputs, gives output as long as any input is not recieved.

Idea: let players input multiple inputs or outputs for the same activation/logic gate/sensor Purpose: Simplify programming to not require as many OR-gates. for example, if you have a drone with 4 thrusters, symmetrically placed with 2 facing forward and 2 facing backwards, and you want 2 diagonally opposite ones to activate when you want to rotate and both of the back ones to activate when you want to move forward, this currently requires having OR-gates that combine 'rotation' and 'moving forward' signals and send the combined signal to the back thrusters. this could be greatly simplified by simply having the back thrusters activate on both 'forward' signals and its respective 'rotate' signal. This functionality can already be achieved by OR-gates, but in large systems with several states this necessitates very large numbers of logic blocks, making the whole system unnecessarily prone to mistakes, furthermore, this functionality would not make OR-gates obsolete since there are many situations when you would want to set up more complicated intermediary logic statements that would not directly activate anything

Idea: something should allow some but not all signals (keypresses and tags) to propogate through them. Purpose: lets say you have a factory part that creates individually autonomous drones (from here called the "Drone Swarm"), to do this you would currently need to use a logic splitter to prevent the steering-sensors of one swarm-drone to interfere with the steering of another, identical swarm-drone. however, the same logic splitter would also prevent all signals from some other, regulatory drone (from here called the "mothership"), which makes it impossible to have the mothership dynamically change what the swarm targets. for example, you might want to have the swarm able to target 4 different things, enemies, resources, mission objectives or the mouse cursor and have the mothership send signals to change what the swarm is doing, this is currently impossible without extremely cumbersome workarounds like using a remote logic connector connected to some moving part which reads the signal command and activates some sensor inside the logic splitter. also, this would make it simple for a swarm-drone to be made aware of whether it has been disconnected from the mothership, something which currently needs to be inferred through the use of sensors, which can produce false positives or false negatives through turbulence. also, without this functionality it is equally cumbersome to send data from swarm drones back to the mothership, for example, perhaps you want to have an exploratory drone swarm which searches for the mission objective and, when it finds it, wants all other swarm drones to gather to it. this is currently impossible. the only current way of having a drone swarm capable of cooperatively performing more than one task is to have each drone programmed to independently judge the situation using nothing but its own sensors or making multiple different kinds of drones, each specialised for its own task but unable to communcate that said task is completed, meaning every kind of drone must be continously produced at all times even if most of them are not needed for the current project. Possible Implementation Methods: 1. let there be a logic part which acts as a logic splitter (or redesign logic splitters to have this functionality) except you can name some number of signals which are propogated normally, possibly with a blacklist/whitelist option letting the player choose whether the listed signals are the only ones allowed through or the only ones blocked. 2. have a specialised IF-gate which: if it recieves the input signal then it sends the output signal through a parent remote logic connector into, presumably, a logic splitter network. this way one can use the remote logic connector in combination with these specialised IF-gates to propogate signals from the mothership into a logic splitter. drawback: this implementation doesn't allow swarm drones to send data back to the mothership.