Eldrad

@Lurkily the reason for isolating internal logic is to make it possible to modularize your logic. I.e. take some common task and group it together into a "function" then call that function with a set of inputs and read the results through a set of outputs. In particular this allows you to reuse the same function multiple times in the same over all design without having to actually place all the blocks multiple times (and without their signals getting crossed). For example (see Bumper Car for exactly this logic) you might want to have a function which has the inputs of "wall in front", "wall behind", "enemy in front" and the outputs of "fire forward thrusters", "fire backwards thrusters", which fires thrusters to go away from the wall unless there's walls in both or neither direction in which case it goes towards the enemy. This logic is exactly the same for up/down as it is for right/left and ideally it should just be a matter of assigning the inputs and outputs not renaming all the internal logic. Over all I strongly agree with this. Except don't limit it to only 4 layers of nesting. Put a limit based on total number of pieces of logic for things like sumo and just check for loops in the dependency graph (if there are any warn the user and don't execute the logic).

Definitely want this with the winch. Without it's very similar to weak springs.

You'd still see a flood of mindless pushers as you do in the current tourney. The issue is that the tournament puts you against drones who have beat 1-10 opponents. For a very small population that'll approximate a spread of quality, but with a large population (as the game appears to have since being early-access on Steam) all of those will likely be pretty close to average/common. Mindless pushers aren't good. They're just easy to make and therefore the first thing people try and frequently the only thing.

It costs 3 blocks (decoupler, fuel tank, and thruster) to do but is generally worth it in my opinion if you have logic and already win tournaments most of the time. It removes a loss condition of random damage/explosions taking out an important piece of logic. Download Jack from the steam workshop to test how you do against damage. You can generally get away with tying it to a signal which starts out on that isn't on 100% of the time (i.e. don't bother adding a button). But if you really want it to keep heading as far away from the ring as it can you can set all of your fuel tank's empty and full signals to the same thing and get the effects of a button without spending the block.

The issues of wanting to handle mixtures of local logic with non local information should be handled more generally and not rely on physical connections.

It's not just all the parts that produce an initial signal. There could also an arbitrary number of logic blocks attached to those sensors (e.g. a large number of batteries ANDed together). Ideally the initial state would be the steady state if one exists or any state within a loop at least if the loop isn't enormous).

This sounds like the issue of when the battery is printed it starts giving the signal that it is full, however the login circuits all look at the previous time step (before the battery was printed) when there is no full signal. I believe the next patch has a fix for this, but is it possible your logic is doing something unexpected when the battery is printed but all your sensors are still not receiving the full signal?

This has a significant added advantage of allowing us to write more modular code (particularly if these blocks can be nested within each other). Ideally a single block could be written in one place then referenced by multiple drones. And if updated would be updated for all drones.

I believe that would eliminate the problem.

With far fewer sensors you should be able to do it in a single (very slow) circumnavigation by going up and down between min and max altitudes.

Fly in a pattern that will take you near all the viable hopper locations and stop the pattern when your containers are empty. It's slow but would work.

There appear to be significant differences in the evaluation of sumo matches on different hardware (beyond just uniform randomness). I suspect it's due to different numbers of times (and the spacing between) logic/sensors/collisions are evaluated in a match. The result is different drones perform better or worse depending on the hardware of the observer. There are a couple different ways to address this but they're likely all pretty significant development time. On the other hand I'm concerned the PvP won't sustain interest without everyone being able to observe similar outcomes from the same drone fights. Supposedly the Bumpercar 6 vs CyberpunkBeyblade is a reasonable example of these results (which one wins a higher % of the time shifts between lower end and higher end hardware). I haven't tested it myself.

An and-gate and the toggle switches are a pretty straight forward transistor which will get you modern computers which are turning complete as long as you're willing to fudge on the issue of your read/write tape not actually being infinite (but limited by how much RAM/disk the system has or in this case how many logic blocks you dedicated to storage). If you use factories you could have a horizontal line of blocks (1) or empty space (0) a read head of a distance sensor and a write head which either destroyed the block or printed a new one. Then you'd get a literal Turing Machine inside the game (though it's still be running on physical hardware with finite limits). And actually making the heads move with repeatable precision and would be hard.

You don't need to hit delete. If you start typing it will replace the existing text. That being said there is certainly a lot of room for UX improvements.

Poor UX isn't a good source of extending game play. These systems are sufficiently complex. In fact they are Turing Complete, making them as complicated as the computers there running on. If so inclined one could make a drone which itself was an implementation of Nimbatus (it would be really hard and the result would be at best incredibly slow if it didn't just out right break, but theoretically possible). My point is making it easier to work with the editor won't reduce the number of hours you could spend making interesting things, it will just make you able to make more interesting things per hour.