Sanaret

Additional note: If in the future factories are made to always consume resources, then the old (current) behavior could be enabled with a god mode cheat like in Beseige

Don't VTOL thrusters already fulfill this? Or do you mean you want a general remote force actuator, like an omnidirectional tractor beam, and the fact it uses 'force' has nothing to do with 'gravity'?

I've needed this recently!

Speaking of which, it would be cool if planets had oceans. I'm surprised I never heard this idea before

I imagine it has long waited in the back of many our minds, when will our machines get to combat one another for dominance over a planet? When can we use our hard earned weapons against other players? Will Factories ever NOT be broken in a PVP environment? Here I propose a constraint that might make Factories viable in PVP. We have to put a leash on it. Obviously in any PVP battle, drone size and block count limits should apply. So what happens when factories effectively circumvent the block count limit? We have to add a leash on factories (when in PVP at least). Factories need to pay for their creations with some kind of resource, but not just time. What if factories built stuff out of the actual resources we harvest in the game??? Imagine every single block in the game has a recipe, in red/yellow/blue materials. In full combat PVP with factories, you have to include resource tanks on your drone. These resource tanks contain the material that the Factories use (Stetium, Rogium, Marium). Resource tanks may not be attached on a branch off of a factory. You cannot factory create resource tanks in these kinds of PVP matches. Now here are some ideas on how to leverage this core idea in different possible ways: In easy mode autonomous or synchronous PVP: At the beginning of each match, all resource tanks are filled for free. You don't get to keep the resources after the match ends though. In hard mode synchronous and manual live PVP: Resource tanks regenerate! They draw upon your resource balance available in game! This creates hardcore end-game content and a reason to harvest resources in PVE even after unlocking all the tech tree nodes! In ultra-hard mode autonomous or synchronous PVP: Resource tanks are not filled automatically at the beginning of the match. When the match starts, your drone has to go into the world and harvest resources from the ground itself before it can use a factory! You also get to keep any resources you harvested and have leftover if you win the match!

It's just my two cents, but here you go I'm not on board. If you've ever debugged real world physical circuits and logic gates before, you know that missing connections and spaghetti of wires does not help. Regarding detection of critical destruction, I've found drone-detecting sensors to be useful for this. I'm in favor of whitelist and blacklist signals. This would allow better more fine control over state/signal propagation, but without all the spaghetti mess of manually wiring stuff. In other words, pervasive signal propagation should be the default, but restricting what signals can propagate should be an option. I don't know if receiver/transmitter pairs are necessary though. I think whitelist on logic splitters and blacklist on logic connectors would suffice. This is difficult to understand. Are you saying, for example, you would like to configure directional sensors so they can detect thirds, fourths, fifths, or any other arbitrary split of radial ranges? I think I could see use in this. Actually I know I could. I'm on board in principle. Also I think people don't understand what tolerance is. I think the graphic is very very misleading. The tolerance isn't a dead section of the circle, it is the amount of slack the directional sense has. Position trackers are recently released and can be turned on and off by signals Proximity sensors are now released To me it sounds complex, but good if the complexity is tolerable So if I understand correctly, you want to discount complex logic? I share the goal. There are lots of different ways to solve that goal though. In the following thread, I mention two new gates that if introduced would allow for all possible "2 inputs and 1 output" logic to each get their own gate. Another possible idea is a 2x2 tile that accepts 4 inputs, produces 1 output, and is basically a configurable 4 input truth table. This would extremely help condense complex logic. The configuration UI might be difficult to design though.

Similar to how the directional sensor and altimeter have two possible states and two possible outputs, it would be convenient if distance sensors, proximity sensors, speed sensors, and temperature sensors all came with their negatives states as built in configurable outputs. This would spare us a "not gate" quite frequently.

One major difficulty with this is the fact it heavily implies connecting parts in a non-tree structure. e.g. connecting two disparate branches of parts instead always branching out from parts. This would probably require significant rework of the underlying code. However, such an underlying capability would be useful for loads of more things than just pistons. Overall I'm very in favor. I wouldn't get my expectations too high too soon though

I would like a logic splitter that can have the splitting functionality turned on and off according to a signal. Right now there is a lot of suffering with conflicting logic on factory spawned creations. I would like to have an element created by the factory send a signal back to the factory, but for that signal to be disconnected after the factory-produced machine decouples from the factory itself. An alternate solution would be to add a "Split logic on decouple" checkbox to the factory

To expand on Advanced Logic Gates: 2 Inputs: Nonimplication https://en.wikipedia.org/wiki/Material_nonimplication https://en.wikipedia.org/wiki/Converse_nonimplication. The above links are the same thing, but with inputs flipped (since inputs are not commutable in this operation). "A but not B" "A and not B" 2 Inputs: Conditional/Implication https://en.wikipedia.org/wiki/Material_conditional https://en.wikipedia.org/wiki/Converse_implication The above links are the same thing, but with the inputs flipped (since the inputs are not commutable in this operation) "A if B" "not B without A If we added the above gates, then we would only need a single gate for every possible 2 input truth table. This is the core material motivation in my eyes I run into the need for these operations all the time, but I'm stuck using two gates, usually in the "A and not B" format Here is a picture depicting the behavior of the new gates on the right: https://imgur.com/a/pnFdl04

Here are some more thoughts I'll add then: The reason that VTOL is overwhelmingly the best at Catch isn't because it automatically aims, but because it can change directions almost instantly You can tell this if you try to make a drone that goes extremely fast in one direction and tries to turn towards the target instead of using VTOLs. Full drone turning can't compete with the instant direction adaptation of VTOLs I personally don't think VTOL is overpowered and needs to be nerfed or anything. Just to be extra clear. Rather than saying "we should nerf VTOL because it does this map too well" I would say "We should create new maps where VTOL isn't automatically the best solution" The idea you mention of the map changing over time is awesome. Especially if with barriers. How to create a map that is VTOL-nerfed is basically to reduce the number of waypoints that can be reached by following a straight line. That is the simplest way to boil down the issue Thanks for your ears! or your eyes, as it were

Pretext: Right now we have 2 damaging hazard types in racing (and catch) Walls. You can think of this as damage proportional to your perpendicular velocity component. Or "damage by speed". Shock areas. As far as I can tell this is "damage over time". There is a problem with the "damage over time" approach though. There is a counterplay to damage over time areas by going over them extremely fast, rather than trying to avoid them at all. In "Catch" it seems like there is more incentive for redundancy and raw speed than careful navigation. There is nothing wrong with a challenge in redundancy and speed, but there isn't a challenge truly dedicated to careful navigation in that regard yet. In the racing maps, leaderboard-grade speeds fly over shock-areas so fast that they are totally inconsequential, making the Phoenix and Tournament maps practically as featured as Hydrus but with with less difficult turns. Example of shock areas made totally inconsequential by speed: https://youtu.be/MCeprgLvRqg?t=284 Feature Suggestion: New race/catch hazard area: Spikes/blade area. This type of area does "damage over distance", in contrast with "damage over time". The more distance you go through it, the more damage you take, up to very high damage. If you come to a standstill inside it, there is no damage over time. (But it will still take damage to navigate out once you get moving again.) The damage is low enough that escaping laterally (in races) should be feasible, but the damage should be high enough that pressing forward recklessly will be very punishing. With only "damage over time" hazards, solving the map can be reduced to solving only one variable: speed. With "damage over distance" hazards, the challenge again becomes to solve two variables, speed and hazard perception/reaction. New race/catch hazard area: Barrier. This is "damage by speed", just like walls, except...... cutting into the roadway itself, making an impassable lane. It could be done in any way, but I imagine this like any other hazard: Center lane, Left Lane, Right Lane This is again to prevent race maps from being reduced to solving raw speed alone. Think about what makes the Hydrus Highway more difficult to solve than the Sagittarius Drag Strip. It's the very tight turns that are very very difficult to control at high speeds. Roadblocks may have the same damage mechanism as raw walls, but the drone design challenge to avoid roadblocks is very different from the challenge to avoid walls. This again makes the maps a challenge in solving hazard perception/reaction, not just speed and simple waypoint following. This already exists in the Catch tournament! Which is good! You can see that drones get caught on it very often, and even smash one another into it. This enriches the arena very much. Maybe there could be even more catch maps, including one with more barriers? (Do not modify any existing maps, for obvious reasons. The above new area types would be good for new maps though. Particularly I would personally imagine these as higher difficulty hazards than what exists right now. Belonging to future, higher difficulty maps.)