notsew93

Alternatively to the center of play area for gravity sensor in no-grav maps, it could point to the Nimbatus. Heck, I'd like a Nimbatus setting anyways.

Speed and temperature sensors only have one boolean output for if you have exceeded the limit. It would be nice if they had two outputs, one for higher than the limit and one for lower than the limit, with an adjustable grey no-output area in the middle. This would make them so that they fall in line with the directional sensor and the altitude sensor, which both already behave this way.

My favorite suggestion by far is the "Parts are built one at a time down the tree". Have them phase in one per second, provide each with a small repel magnet effect to that existing obstacles are pushed away, not spawned on top of, and have the whole lot of them totally inoperable and fragile until the factory finishes the whole print job. This also makes it so that factories cannot "bank" a replacement sub-assembly because the factory red juice can't start refilling until the previous print job is disconnected. This doesn't stop an infinite horde, and I don't want it to. This would greatly slow their speed though. As a further nerf, I would like to see the factory be powered by some source, rather than being free. I would have it take quite a bit of power and/or fuel, and I would have it so that printed fuel and power modules start empty. (And don't start filling until the print job is done, perhaps even requiring that they be full in order to consider the print job complete) This last addition would make it mush harder/slower to print factories that print factories that print factories, as each would require (~2-3 power/fuel blocks) in order to start working - slowing down the child build time, and increasing the amount of time it would take for a child to start reproducing in it's own right. Together, these all nerf the factory while keeping it's function and role in the game the same as it is now, which I kinda like.

As written, I think the suggestion of deflective lasers is too strong. Put 8 on a motorized joint, and as it spins you would effectively become immune to the corp enemies. Plus, if you slap the two energy reduction upgrades on this too, then you have a energy-free shield that blocks all blasters and never drops out to recover. It just sounds like free permanent immunity to one of the most prevalent enemies.

I would like to see being able to actually backspace a few character, then type in a suffix. As it is right now, when you start typing it clears the bar unless you were typing from scratch, even if visibly you had just deleted two characters. (It only does this when freshly editing a tag. What a pain.)

So, you want tighter spread on a multi-laser... how would this be different from the damage upgrades?

But on the other other hand, the game is about making drones. A variance between planets, environments, and missions would be essential to prevent the game from being boring. For instance, I had a drone that could do every mission quite handily until they came out with the "light fires to retrieve artifact" jungle mission. I see you point about props vs. thrusters being the same, maybe tedious, and having right/worngness attached to them, but what other variety would you propose instead? The game needs to have differences on the planets to avoid repetition, so we are encouraged to keep making new better drones. Alright, so if what we want is to try and make the choice more strategic, then how about making these different in a few other ways: Size of props could vary width-wise, not lengthwise like thrusters as @Dui Mauris Football said; Maybe it could be made so that in addition to air resistance varying from planet to planet, it could also vary with altitude - this way there is almost always the trade-off "strategic" factor; Perhaps when they develop the ice planets there could be liquid water underneath an ice crust that you'd have to dive through, and props would work in water but thrusters would not; There could be an asteroid field mission where props don't work at all and thrusters would do great; there could also be a fuel usage difference, where props are really fuel efficient, but thrusters are easier or work in more situations. Are any of these differences starting to sound strategic yet? I agree that props and thrusters should have more to set them apart than just low air planets vs. high air planets, but I disagree with the notion that all drones should work everywhere and you never have to make new ones. Its a drone constructor game - the Nimbatus should fly around mission to mission, planet to planet, and the staff (player) on board makes new drones to meet new challenges.

I am trying to do some precision work on a Sumo Bot, and I keep eyeballing where the directional sensor regions are located. I have a use case where I am trying to line up two directional sensors to more granularly chase and track the enemy sumo core. To help with alignment, I am currently holding a ruler up to my computer monitor - in that vein, I had an idea to help make this alignment happen in game. If there were toggleable tracing lines that extended from the directional sensor, matching where the three detection regions are currently set, I could better guess if the sensor region falls on one side or the other of a block on the opposite end of my drone. It is possible that this could be implemented solely in the graphics, and not as any kind of physical part extension like in the distance sensor. It could even be done when the part itself is selected - when part are selected currently, the construction environment turns the part differing shades of green. For a directional sensor, an additional graphic could be overlaid on the green selection effect, perhaps in the form of transparently extending a faint version of the region wedges to the edge of the screen, or adding a divided filled circle like how the magnet shows it's effective radius when selected. As a couple of bonus suggestions, a round version of the directional sensor would be useful for creating regions at an odd angle like I am attempting, a key/tag binding for the tolerance zone would very much cut out a lot of logic gates, and some sort of hotkey (ctrl?) you could hold down when rotating parts so that the part rotates without rotating all it's children would be neat. What do we think?

If I had to hazard a guess, I'd say that logic variables are global as a remnant of when everything was global, including fuel/energy. Later, they would have added the logic splitter feature by splitting of a branch of the tree model of the drone, by saying "all logic is global, except for logic parts which are descendants of this splitter block - they get their own section, inside of which is locally global." Then, when the added they logic connector part, they added a feature to the logic splitter, which now says "you know that cordoned off local global logic section downstream of this wireless connector? Yeah, actually that's the same region as the drone core global logic area now." So if this is how they implemented it, no logic connections are calculated at drone flight-time, (except factories, which would increment a region defining prefix for each new splitter or connector) and no signals are *actually* "propagated" part-to-part. Every logic part is assigned a logic region number based on the tree subdivisions created by the splitter/connector parts, and every part within a region label communicates using local global variables. In the case of the wireless connector, instead of incrementing a new region label they just assign the "region 0" of the core. Inside a region, physical connection/decoupling does not matter and in fact is not even detected by the game from a logic tracking standpoint. This is speculation of course, but this explanation fits all facts I know of. Because I suspect that the logic is done in this way, any change to the logic that would "just change the propagation rules" would require a front-back re-write, because logic is not "propagated" in the first place. I'm not saying it shouldn't be changed, I guess I'm just trying to say that some changes that seem small may not actually be. Even some of the changes that I suggested would be big changes if this is correct.

If things were to be changed as Lurkily Suggests, then I would finally be able to activate a factory printed drone on-demand, while also having the drone be split and not cross-talk with its brothers. As things are now, it really is an all-or-nothing deal with transmitting signals. Unfortunately, I fear that this change could require up to a total rewrite of the logic propagation - at present, there are no examples that I know of that pass certain signals selectively based on where they are sourced from. Plus, if the wireless transmitter passes signals from the core up and down, but only returns signals from below, then suddenly it is asymmetric. How would a player figure out such a strange property without essentially a paragraph-sized tooltip? Other solutions to this problem could include the logic splitter being toggleable with a key, assigning a whitelisting-type behavior to the wireless connection part, or making logic cut off when parts are disconnected like how fuel and energy are dynamically shared/cut off. Don't get me wrong, I like the idea, and firmly believe that a lack of answer to this problem is holding the game back. Is there a even better solution though, that fixes this problem cleanly, intuitively, and without feeling like it is a quirky band-aid to an underlying propagation model problem?

I see your point, and it's a good one.

The game is about building what you want, so I would hope for a part where you can press a button to make it freely extend until ti hits a cable length limit, with another button that pulls it back in at a slower rate. That way, if we want it to rocket out, or stick, or insert purpose here, then it would be up to use to attach those parts. We'd need an additional harpoon part though, or an addition to the spike that makes it really stick. Then, if you put this cable part on a decoupler, you could detach it, or on a factory you could detach it and make a new one! I also got to thinking, they could add propellers or jet engines. Make them a sort of part that gets better with increasing air resistance, instead of the thruster which gets worse. And if they implement an asteroid-area vaccum level, the the props could no go at all. Try and make us change up our drones, yes?

Normally when you are editing tags, it presents a list of tags that you have used recently or currently exist on your drone. When editing my drone in a sumo arena, I was surprised to find a lot of tags that I had never typed in, but made sense for a sumo game. My guess as to what happened is that since I was fighting another users drone, when it had done the match the game must have added the tags that the other drones were using to the tag autofill list. This is a far cry from a world-breaking catastrophe, but I imagine that this is unintended behavior. It's only a guess, but there you have it. Thank you

I like the idea of an aura-damage lightning coil. Upgrades could include target jumping chain lightning. I was actually trying to find a good solution to that sort of thing today - I have a very large drone, with a hanger on one end that spawns ore carries. The drone is large enough to where the hangar end of it is not on-screen, so I wanted to create an automated defense of the area. I tried enemy sensor bristles, and even laser pinwheels, but without the directional sensor being able to point at enemies I could not really make a auto-motor-spin turret. I ended up creating a lot of rocket launchers because they have a wide angle of dispersion, and with enough of them blind firing became a viable "damage field". I later put a camera on the far end of the drone, so I could actually see stuff, but still, that is my example of why I would want an aura or Tesla coil weapon. To balance the fact that you don't have to aim it, such a device could be made to require a lot of power when active, plus additional energy per lightning bolt fired, and it could be short range like the lasers.

Indeed, for trying to get a wireless logic connector through to a drone that was logic split while also preventing crosstalk is something I have tried and failed to do. The best we can do right now is to put half your drone as logic split/full autonomous, and half as logic connected with crosstalk to duplicate drones, and then hope you never have a use case where those two halves of your subdrone need to talk to each other. The use case where you have an external startup signal to "power on" you drone so it starts flying is such a use case.