notsew93

Ah, but the wireless connector also performs the functions of a logic splitter. The on-off signal in this scenario does not receive its on pulse, and even if it did, the output would not propagate down past the wireless logic connector. Behold! The button and two lights are all set to the same tag.

Even better, as the parts fade in one-by-one, give each a tiny repel effect so that the factory spawning items in other items space (and the physics engine heart attack that ensues) would be less common.

Ah yes, I do have similar ore carriers. I see the point now, but I am still unsure that poofing parts out of existence is something I want in the game. To be honest, I am a bit uneasy about how the factory insta-summons parts. The sudden appearance sort of breaks my suspension of disbelief, if you will. Not to get too off the course of the thread here, but I would be happier if the factory summoned it's child parts one at a time until completion, or even phased them in from 100% transparent to 0% transparent one-by-one. This would prevent the factory from being able to "bank" a whole sub-assembly for instant summons, and could be a suitable nerf without even having to change the part conjuring rate from one a second.

I agree with your assessment of where it is useful to position the tolerance zone, and indeed when the tolerance zone is pointing towards those places it seems backwards. I would be happy with flipping the names of these regions, but I hope we realize that even though it would be better if the names were flipped, it can still seem wrong in certain situations. The round tilted sensor idea was meant to be an alternate suggestion to your custom range of degrees suggestion, for if I understand you correctly both of these suggestions solve the same problem of "But what if I want it pointed at 22.5°?", though your custom angle range suggestion provides even more flexibility than the round sensor idea. (creating two tolerance zones, for instance, if you want pink to be from 30°-60° and red from 75°-125°.)

I'm with Lurkily on this one - I'm not sure what the use case for this delete printed part feature would be. Why was it printed if you want to delete it?

But if you flip the sensor 180°, rotating CW would be instead triggering the zone labeled CCW. This is the same problem as the "Tilted Right" and "Tilted Left" labeling. Figuring out some actually unambiguous way of indicating what region it is in, like color labels or perhaps highlighting the correct wedge while the game is waiting for you to type in a tag/key would be better - CW vs. CCW doesn't really solve the problem. My personal favorite idea for getting more angle options out of the Tilted sensor is to make an alternate version of the part that is round like the fuel tank. That way you can mount it at whatever angle suits your purpose. I think we are on the same page about what should change though, we just have different idea about what it should change into.

As for how to do it, maybe they could make it so that holding alt or shift while moving/rotating leaves the rest where they be.

@Marker Mage Hell Yeah! What you've suggested are even already features of the game today, put together in a novel way.

If you turn the sensor upside down and think of the grey tolerance wedge as twelve o' clock, the mistakes start to go away. The ambiguity here is inherent in trying to assign "left" and "right" to regions of a rotationally symmetric object. I agree that the either the sensor should spawn the right way around, or that the variable lines should be color-coded to match the half-circle regions, or the region names should be swapped. Or some combination thereof.

I agree that I get the direction sensor backwards all the time. Maybe as a solution to all this confusion they could indicate what color-swatch region the output key corresponds to by putting pink and red squares by the output names. That way we can go "hrm yes, the pink half circle corresponds to this tag and key I've bound." You wouldn't even have to add color swatches, they could change the color of the yellow up arrow signal out symbols on each line to match the sensor region colors. I think that CCW and CW labels instead of left/right on these are not appropriate, because CCW and CW are directions, not positions. When you keep rotating CW at what point to do say that you are actually CCW instead? It helps if you think of the grey tolerance area as twelve o' clock, even though the sensor spawns with the grey at 6.

Hear hear!

I also think that logic shouldn't be wireless without the transmission block. Right now, I am attempting to solve a very difficult problem, which is to both have a start signal for a drone, and for there to be multiple factory copies of a drone. The way things work now, if I want to have a deployable swarm of factory created drones, I absolutely must build them on a logic splitter, otherwise each drone cross-talks with each other and, for instance, they cannot each have a gravity sensor to stay level - the multiple copies of a gravity sensor all try to talk over each other with different readings. So, a logic splitter is a must. But if I build a logic splitter into my factory created drone, it cannot detect when the factory decouple button has been pressed, an action which I would also like to simultaneously turn the now decoupled drone-baby on. But I cannot. If I put a wireless receiver on the logic-split drone, all parts down stream of the wireless connector hear and transmit to the main core, and if there are two copies of the drone, then they still cross-talk each other. Worse yet, if I still want to create an activate on/off switch on the drone that switches on when the factory decouple button is pressed, it has to be downstream of the wireless connector - but if it is downstream of the wireless logic connector, it's signals are not passed to the rest of the drone baby that is sandwiched between the wireless logic connector and the upstream logic splitter. Plus the failed latched-on signal gets transmitted from the first printed drone to the second! To get around this problem, I have resorted to a myriad of unreliable ways to kick-start my drone baby. One way was to put a heater on the main body that activates when the factory decouples, and a temp sensor in the logic-split part of the drone baby that turns it on when it gets warm. This works but is slow, and sometimes my main drone gets too warm, and newly printed drone babies would turn on too soon even with the heater off. A second way was to put some non-logic split thrusters on the baby drone, and have the drone activate when it detects a non-full fuel tank. This works, but now my drone baby will sometimes activate prematurely if my main drone accidentally uses some of the baby's fuel. A third method was to use the speed sensor, combined with jump rockets or magnets to kick the baby off to a running start, but to solve the premature activation problem I needed the main drone to be slower that I'd like. A fourth method was to use the distance sensor set to "own drone", and have a suitable ejection magnet so that the drone baby would turn on when it doesn't detect the parent anymore - the flaw with this method is at the start of a round the distance sensor will sometimes spawn undetected for what must be a single game tick, and the babies would turn on right away. A fifth method was to use the directional sensor set to drone core twisted 90 degrees. Print the drone baby and eject it above the drone, and when it drifts below the drone core it would latch the on-state. Works, but like all the methods outlined here it requires extra logic parts on the baby that become dead weight shortly after launch. The solution, I believe, is similar to what @Lurkily is trying to explain - which is when a drone is decoupled, whether from factory or plain decoupler, is that the logic should be split off also. I understand that decouplers and factories where added later in game development, and while I surely am not familiar with the game's source code, if you will let me @Micha, I think I would like to try and outline a way that this could be implemented. The desired behavior for this idea is the following: When drone parts are still physically linked to the drone core, they receive and send logic signals up and down the tree. When a connection in the tree is severed, whether from factory decoupling or decouplers or plain old damaged/destroyed parts, any parts down the tree branches from that point cannot send signals up through the broken tree area or receive signals from above. Unless, of course, the severed section of tree carries with it a wireless logic receiver component. This would allow the main drone core to send a startup command to the baby drone while the baby is still physically and logically connected to it's factory, and also allows the baby to fly free and be independent from it's future twin sibling. So, while we want it to look and feel like the logic is carried by wires through the grey joints of the craft, this is programming, and these variables and such are globally accessible by all the drone bits because this is all virtual, and there exist no physical constraints unless you choose to impose them. So how to we make subtrees of the drone cut off logic? I will say that i don't know, but I do know that somebody on your team figured out a way, because the logic splitter part exists. What I would propose, then, is to create a new class of drone component - an invisible indestructible damage-free temperature proof physics-less class of components, which may yet still occupy a node of the drone-tree graph. (I am assuming that drones are stored internally as a one-to-many linked-list tree of component objects) With this class of "virtual" components, I would make one of these new virtual create one with the same logical properties as the logic-splitter component, so that if one of these virtual logic splitters is contained along the branch of the tree components it does the logic-splitting capability. How does this help us? I would further suggest a detection event in all parts or some other event handler method looking to see if the parent parts of any component have been destroyed or disconnected via decoupler or factory. If this child component is no longer physically connected to it's parent, then create a virtual logic-splitter component and insert it as the new parent of the disconnected child, and as child of the disconnected parent. Then later, if necessary, add detection events for if the children of the virtual logic-splitter are destroyed - if they are, then remove and delete the virtual logic splitter component. (While creating a new virtual logic splitter as a new parent for the now orphaned grandchild component.) On a tangent now to expand on the virtual component notion, a virtual component could also be assigned the duty of what I'll call "Sub-root", the possession of which is what would declare drone parts trash (and friendly fire-able) or not. If the parts on a physically disconnected subtree are still "useful", then they get a Sub-root that declares them not-trash. If the physically disconnected subtree is not usefull, then it gets a trash-root, which declares all desendants as trash and friendly-fireable. "Useful", however, is tricky to define. A chunk of thrusters with no fuel is trash, but if it still has an active computer it may not be. I know that something like this would be much trickier to implement than it is to say, and it was pretty tricky to say. I do, however, believe that somehow binding propagation of the logic of a drone to whether or not the components are physically connected would greatly benefit the game. It is more intuitive to non-programmers than are global-variables-by-default, because people can see the grey component struts behind the parts and associate such connection lines as necessary for fuel hoses or electrical wires or data cords. We can still have the option of global signal sharing with the wireless logic connector - a part whose very name suggests what it is for. (And the name alone already would imply that it should be needed on decoupled parts. Without the logic splitter part, what use would the wireless part ever have in the state of the game today?) When someone like myself walks in to a game like this and can see that the factory prints new parts, I totally expect that the factory's children are not hiveminded, for two products from a real life factory do not behave that way. Plus, while broken-off thrusters are amusing when they wizz around wildly, if logic is bound to a propagation model then they would fall silent unless specifically designed to be separate. Thank you for your time, and for the lovely game.

Though of course, if logic parts were free, a drone would be made with a thousand of them just for the mass...

I am with @Lurkily on this one. As long as the three resources are tied to purchasing permanent upgrades/tech tree advancement, I cannot think of a single drone effect or ability I would ever trade them for if I still have other options. This is why I was talking about nerfing the factory in other ways than with resources. If the factory cost resources from your drone to operate, I would sooner put a thousand decouplers on my drone than trade a single tank of yellow. At least until I have no more to unlock. Then I would stack decouplers instead of factories because of the sheer inconvenience of searching half of a planet for a resource that may not even be there. This is also why i suggested Dirt as an alternative. If we are going to power anything with a non-renewable energy source, it has got to be convenient. If it weren't convenient, then the effect I would demand of such an item would be so powerful as to trivialize the game, which is also something I don't want in a new game that I care about.

Indeed. I do like the idea that they should take significant amounts of power, I am just kicking around ideas! If the goal here is to nerf factories, then perhaps we could entertain the idea of having the "Print" function grow the attached parts one at a time or slowly over time, and turning the "ready to print" indicator into a "done printing" indicator. This would make it so that you can't "bank" a new part and instant-summon them into existence. Plus if the parts "grow back" and get added back to the ship one at a time, then a particularly large print job wouldn't spaz out when it gets summoned over a stray block or meteor in the way. To prevent this from being used as an infinite regenerating health pool, it could be made so that it cannot replace any individual destroyed part without detaching the whole assembly and starting the print job over again.

I like the suggestion, but if you are in desperate need of logic space today you could put it on a decoupler and launch your big computer block into orbit. Equally valid in Sumo I would expect, since only the drone core triggers the sumo border.

Isn't explode really like quitting the mission? "Leave Planet" is already in the escape menu.

It would make sense to me if the three kinds of resource tanks had full/empty key press generation like the fuel or battery tanks. Woe is me, who was trying to make an automatic resource retrieval drones, only to find that I could not tell them when they were ready to come home!

Honestly, you could make dirt itself a fourth resource not taken back to the Nimbatus between missions, and collect it in dirt tanks using the drill. Then, factories could run off of the dirt you currently have on board!