Jump to content
Stray Fawn Community

Entity

Member
  • Posts

    58
  • Joined

  • Last visited

Reputation

31 Excellent

Retained

  • โค๏ธ๐Ÿงก๐Ÿ’›๐Ÿ’š๐Ÿ’™๐Ÿ’œ

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. As I suggested on discord before... Don't ban them. Just make them only work on your own drone. They are still useful for being able to see what decoupled stuff is doing.
  2. Entity

    Upgrade bugs

    Infinity Generator II.drn Here's a basic version demonstrating the concept. I have one that only uses supercapacitors too but there's slight issues with it that are awaiting game bugfixes. (also this is getting way off-topic)
  3. Entity

    Upgrade bugs

    It's just decoupling and printing capacitors and/or batteries with a factory when they're empty.
  4. Entity

    Upgrade bugs

    This would totally justify the excessive infinite energy generators I've been working on. It'd also make me completely immune to damage and turn shields into the single most OP thing right after said infinite energy generator.
  5. Heh don't worry man. I was just a bit surprised about the number of votes on this when I didn't even get a response on my thread
  6. If it was implemented like that, yes, it would pretty much implement this sensor in a more flexible manner. as long as it gets 4+ configurable conditions and also lets you specify negative angles (like tilt between -40 to +40 for an upward arc)
  7. Features: 4 outputs (one for each quadrant) Target selector (Gravity, Enemy Core, etc, exactly the same ones as Directional Sensor) Angle slider (0-359 degrees) to control the orientation of the quadrants relative to the sensor, so you can offset it e.g. 45 degrees like this: Tolerance slider (0-90 degrees) to control deadzone between each quadrant: Functionality: Nearly identical to current Directional Sensor, except it has 4 sensor zones instead of two Why? It really simplifies making drones that follow the cursor while staying upright. It also makes it so you do not have to use -two- sensors to cover cases where your drone is facing away from the interested direction when you need to invert behavior based on that, or do something else (this would be rather useful in sumo) Example: Right now you have to use 3 regular Directional Sensors to do make a drone that follows the cursor while staying upright (gravity + one for left/right + one for up/down). if you want to also have diagonal movement you need 2 ADDITIONAL sensors to create the cursor detection required for that (not to mention needing to place sensors diagonally which makes building awkward. why are these things a square anyway) With the proposed sensor you would only need 2 sensors (one gravity, one 4way cursor), or 3 (one gravity, two 4way cursor) for 8 directions.
  8. I didn't get the game until it got released on steam, so no that is not it
  9. really? I posted a more detailed feature request ages ago and this post somehow gets 7 votes?
  10. I edited it out. It's not relevant to the problem.
  11. Separated debris from your drone still maintains state signals, such as EMPTY or FULL on capacitors. Only destroying the block removes the active states. Note: this is not about normally decoupled stuff using decouplers or factory. See following setup: The TNT severs the capacitor, turning it into debris. The LED, which is ON when it sees FULL from the capacitor, only turns off after destroying the capacitor. Edit: YES THE LASERS IN THE GIF ARE -100% ENERGY. sheesh.
  12. It's not that the buttons are initialized after the logic gates, it's that the NOT gate has not had a chance to evaluate its input yet, so on the first state evaluation tick it is active, to disable on the next tick. Initial state is hard. On a related sidenote: The inconsistent behaviour between test flight and launch is still there, @Micha, I thought you were adding the initial logic gate delay to test flight too?
  13. both detonated on same input. I know blocks repair themselves, but when detonated at the same time it should be destroying the block. Maybe the delay-on-detonation-if-hit-by-other-explosion is overriding the detonation input? Even if it happens on the same tick? if so, that's not the right way to handle simultaneous events
×
×
  • Create New...