Entity
-
Posts
58 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Entity
-
-
you could always upvote my wireless key/tag transceiver block
-
15 hours ago, jbox1 said:
Whatever you do. DO NOT DO THE "COLLECT BIO-BARRELS" MISSION!!!
indeed. have your delivery drones do that for you instead!
-
24 minutes ago, RAC said:
Something to try I suppose. Should work if barrels count as terrain?
which is another annoying thing. why do they count as terrain 🙄
-
Also, why are the sensor outputs' font colors not matching the sensor areas?
-
1
-
-
Yes, my OCD would prefer that.
The hole is a non-issue because you can either sweep or play with the focal point (if you have multiple offset turrets).
Yes it makes using laser fans slightly trickier with distance sensors like that but then you can just not pick the +3 beams upgrade and take the +2 instead.
-
you're welcome
Honestly though, factories and decouplers should probably cause the decoupled child(s) to become independent (they grow up so fast)
You should post a feature request for that and link this post
(it's funny)
-
Checked out your drone. it's not a bug. Rather a side effect of what the game considers debris.
When a block is destroyed, all the nodes using that block as parent (ie. all the stuff behind it) become debris (this works the same way a logic splitter does). It doesn't matter if it's physically connected.
Now, your drone...
- The main drone decouples from the core using a decoupler block, and then that decoupler block is let go by the factory. It falls into the hopper.
- This single decoupler is the parent to your drone and its sub-drone(s)
- Your sub-drones blow that up when they land in the hopper.
- Your everything is now debris because you sawed off the branch you're sitting on.
RIP.
-
Features
- 1x1 size
- One input
- Sound selector (Alarm, Bell, Horn, Piano, Snare, Bass, Trumpet, whatever else)
- Frequency slider / musical note selector.
- Volume slider
Function
- Plays the configured sound (probably not looping) when the input is active.
- Changes the color of the speaker icon to show it is active (much like the distance sensor turns green when it sees something)
- Plays sound originating from the block
Uses
you could make music, or have an audio cue when your auto turrets are engaging an enemy, or have a sound saying your factories are ready to print, etc etc..
-
2
-
Picture explains it all.
Same problem when using a fixed weapon.
-
Set my world destroyer to delete the planet.
Few minutes later, entire planet gone, only 6/10 eggs destroyed and no eggs anywhere.
-
Distance sensor set to detect "OWN DRONE" generates false positives when moving sufficiently fast in the general direction of the sensor's beam.
Needless to say this renders it completely useless.
Here's a gif showing LEDs tied to the sensor flickering on/off after gaining enough speed.
-
1
-
-
On 10/10/2018 at 8:20 PM, Lurkily said:
Isn't the distance sensor what we're talking about? I may be confused.
OP said 2x2 so either they meant 1x1, they're thinking about the wrong sensor, or are using a different scale than grid squares.
*shrug*
I do believe all square sensors where the orientation of it matters for its function should be round, regardless of their size.
-
1
-
-
- Correct spelling is Resistant.
- Coating and Plating are actually two different physical processes of adding a protective layer to something. Pick one to describe the effect, not both.
- There should be a space between Heat/Cold and Resistant at the top.
-
14 minutes ago, Markus said:
Hmm, do you mean like a "physical coupling"? In the way that train-carts are connected to each other?
Maybe we could add such a part, that you have a "coupler" part. And if you activate it, all other "couper" parts which are touching it (or are near it), simply stay connected to it in a rigid way as if it would be normally linked together. And if you release the "coupler" part, the other parts detach from that spot.
Exactly like railway couplings, yes.
Multi-point couplings sound good too.
Also throws a bone at people wanting struts I guess
-
1
-
-
In order to stop infinite energy/fuel cheese with factories, why not change how this works?
I mean, as much as I enjoy infinite energy setups, it's a bit cheesy to have the recharge of 175+ batteries crammed into 8 batteries worth of space.
Soooooo, instead of battery and supercapacitor, have these 2 block types
Reactor
(current batteries become reactors)
- same as what the battery currently does, with the same sizes, except it has no energy buffer (or a very very small one). it just generates energy, and you can run your stuff directly off of it as you can with batteries now.
- charges capacitors using the excess generated energy (the leftover recharge rate after providing power to guns/shields)
Capacitor
(current supercapacitors become capacitors)
- same as supercapacitor, except it can (re)charge.
- starts fully charged.
- charges using excess power from reactors. no cap on charge rate, excess reactor energy is simply dumped into capacitors.
- drained only when your reactors can't handle the energy demand of your systems.
- empty when printed with factory, requiring you to let it charge from the parent drone before decoupling if the sub-drone doesn't have reactors itself.
For fuel, the exact same mechanic could be implemented.
This completely stops infinite energy and fuel factory cheese without hindering the functionality of any involved blocks for most purposes (sumo still works with just capacitors, etc)
It also makes capacitors more useful instead of just the thing you use for sumo or factory cheese.
-
1
-
Why a REcoupler and not a generic coupler block?
Then you can make snake drones without making your own bulky magnet based connectors to link the segments.
-
1
-
-
+9*
I don't know how many times I untangled my drones just to replace a block.
*) still only +1 due to vote limitations. sorry.
-
2 hours ago, pieguy56 said:
I just got this weird idea, what if flame throwers used fuel instead of energy?
🤔
that... makes an awful lot of sense actually.
-
2
-
-
On 10/10/2018 at 12:34 PM, D.Mentia said:
I have concerns that oversimplifying the logic would hurt gameplay, but if you're building something so large that it's becoming unstable from the amount of logic, then yeah that becomes a bit of a problem. I think it'd be a great idea as long as it's not allowed in sumo, and if it was locked behind some research it'd still encourage new players to play with and learn the logic gates before giving them a part that replaces them all
Actually, it'd SIGNIFICANTLY spice up sumo for the advanced builders. Being able to program complex behaviour can make for super interesting strategies.
Could always make a second sumo league where the advanced logic parts are allowed.
-
4
-
-
This has some niche uses, but it's essentially 2 IF gates acting on the same input, or 1 IF gate having both a tag and key as output.
In fact, all gates technically already have 2 outputs through the use of tags and keys.
-
1 hour ago, Markus said:
Thanks for posting. I agree that we have to improve the user experience with how input fields operate (in general)
I can't say when we can work on it, but we have it on our list for things we would like to fix
The tag field behaves unintuitively too. When you have an existing tag there, e.g. "DECOUPLE2", you can press backspace and it will delete the "2". If I then press "1", it wipes the edit field and I just have "1" there instead of "DECOUPLE1". it's annoying when the input fields don't behave like standard ones in windows because you'll never get used to such quirks
-
57 minutes ago, Markus said:
Are we Turing complete? I have not enough experience or knowledge to answer that
Merely having NAND gates (or NOR, that works too) makes it Turing-complete already, because all other logic gates can be constructed from it. And when you can do that, you can build components like RAM, binary adders, etc. Using those you build an ALU, and using that you can create a processor that can execute instructions.
-
4 hours ago, Baka Red said:
One of those faulty parts might be Distance sensor (I had an ejectable armor part on my ship which would explode when distance sensor didn't detect Own Drone anymore. The problem was that even though the sensor pointed at the main part of the ship from point blank range, the TNT linked to it via NOT operation exploded immediately). The logic chain was this simple: Sensor (Own ship, DETECT), NOT (DETECT, EXPLODE), TNT (EXPLODE). (This is from memory, but I think that was how it was built). The ejectable armor part (including the sensor) was created by a factory, in case it has anything to do with anything and the logic parts were within the ejectable armor part too.
That would be the NOT gate's initial output state always being active upon starting the simulation, it has not had the chance to evaluate the sensor yet, triggering the TNT.
Initial state is a very messy problem.
-
1
-
-
- Two outputs; positive movement, negative movement
- Tolerance slider (controls "dead zone" in middle)
Function:
Sort of like a speed sensor, but only for the part of the block's movement along its long axis.
The black dot sits in the middle when the block is at rest.
When the block is moving, the dot moves to the side opposite of (or matching, maybe makes more sense) the movement vector (of the block itself) along the long axis of it.
It should not use the drone's total vector; This is important for being able to detect angular momentum with this block as well, by placing it perpendicular to the center of mass.
At zero tolerance it should detect even the slightest movement.
Not sure what total negative/positive speed range it should have but it doesn't matter too much since it's not really for detecting speed as much as figuring out your vector.
Uses:
This block would have many applications!
- hovering/anti-gravity setups
- detecting spin caused by external forces (e.g. in sumo)
- direction agnostic stabilization
Note: this is not an acceleration sensor, but it's similar; It's based on current velocity instead of ∆v
-
2
Resource Tank Empty/Full Detection
in Feature Requests
Posted