Jump to content
Stray Fawn Community

Entity

Member
  • Posts

    58
  • Joined

  • Last visited

Posts posted by Entity

  1. 1 minute ago, unmog said:

    Hmm... I never even thought of that. Uhm, you have a file I can look at to study how it works?

    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)

  2. Just now, unmog said:

    Wait, whats this about an infinite energy generator? o.O mind sharing? Ive no idea what your talking about, is there a way to wirelessly transmit energy maybe?

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

  3. 5 minutes ago, unmog said:

    If Shields didnt have a "max hp" and instead, just ran off energy, then you wouldnt need to overlap shields. Anytime any of the shields took a hit, it'd instead drain your energy. Thus the shields you have wouldnt go down until you ran out of energy, but theyd all go down together.

    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.

     

  4. 1 hour ago, unmog said:

    Sorry Im new, but also active! I didnt see yours before, only read the newer posts on the forum, theres a lot of posts and cant be expected to read them all right? Or maybe Im lazy~

    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 :P

  5. 9 minutes ago, Lurkily said:

    Micah has mentioned that he'd like to apply condition to the outputs of sensors.  What that means to me is that instead of having a 'tilted left' and 'tilted right' output, you would be able to configure 'Tilt between 5-85', 'tilt between 95-175', 'tilt between 185-265', and 'tilt between 275-355'.  That would fulfill even your most complex example there at the end.

    I may misinterpret his meaning, but I think that would be ideal for nearly any purpose. 

    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)

     

  6. image.png.3a3874d361a4228d8aab8d386f64f2f2.png

    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:
      image.png.549cb0ed3c558141347a9b77ff4391e1.png
    • Tolerance slider (0-90 degrees) to control deadzone between each quadrant:
      image.png.703700868dde034512acebcbd75d2840.png

     

    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.

     

    • Thanks 1
  7. 1 hour ago, ManTheMister said:

    Evidentially, the battery still gives power as well as logic outputs, seeing as the lasers work.

    (unless the lasers have both efficiency upgrades equipped, but, correct me if I’m wrong, weapons still need energy, they just don’t use any [which may also be a bug])

    zero energy weapons.

  8. 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.

    Nimbatus_GIF_201810302304185499.gif.bfc55ac073e04baf21e6b3ddc6922f1b.gif

     

     

  9. 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?

  10. 3 hours ago, Micha said:

    Are both TnT on the same button or does only 1 explode and then trigger the other explosion?

    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 :P

  11. (Credit to Wumpie on discord)

    Multiple TNT blocks no longer seem to destroy parts that have that exact multiple of 500 hp.

    • 1 TNT destroys 500 hp blocks as expected
    • 2 TNT does NOT destroy 1000 hp blocks
    • 4 TNT does NOT destroy 2000 hp blocks
    • etc

     

    Repro: make a drone like this, detonate the TNT, the button survives even though it has 1000 hp and the TNT should be doing 2x500 damage.

    image.png.aa136aea254e4b7c6ead4f41538f5c45.png

  12. Honestly they should be explosive decouplers (ie. they destroy themselves.  not leave a stump).

     

    As they currently are, even their graphic is misleading. They look like they would detach leaving half of the decoupler on each of the separated parts.

  13. 2 minutes ago, Ookami-sama said:

    I usually only use a NOT gate when I want to achieve such thing, so I am curious as to what would make this undesirable. What are these issues you are dealing with?

    A not gate adds a 1 tick delay and that makes the event arrive too late (it must happen before another fires, so I'd have to add an IF gate to delay that by 1 tick too)

     

    Besides it should take almost no effort at all to implement this.   and there's no reason not to implement it.  Low effort feature, saves having to use extra gates, etc.

    • Like 1
  14. he wants to be able to bind wheel up/down to stuff so you can have some kind of mutex logic cycle through options (for things like activating a specific factory in an array of them using the same spawn space)

     

    I like the idea if it weren't for the fact that they just made camera zoom be controlled by mousewheel so that'd be weird.

     

  15. The new camera zoom with mousewheel is great, but ...

     

    Could you please make it remember the zoom level so I don't have to zoom out every time I launch?  Doesn't even have to persist, just remember it during the play session.

    • Like 1
  16. 12 hours ago, jbox1 said:

    plus, you wouldn’t even be able to tell the drone to go foward without any logic parts!

    uh. sure you can. just have 2 fuel tanks with all outputs set to the same key and use that key for your thrusters 😛

×
×
  • Create New...