Jump to content
Stray Fawn Community

GreyCore

Member
  • Posts

    72
  • Joined

  • Last visited

Posts posted by GreyCore

  1. 9 hours ago, Lurkily said:

    The problem with very compact variables, is that sometimes you start writing and realize that two functions have the same initials; there are always ways to compress and streamline code after you're done making it functional.  I wrote a little javascript in the early, early web, when we had to worry obsessively over load times, optimizing every image and script, and I could write very explicit code, then run a script to compress it to a nub. 

    And remember, this game is meant to be accessible to novice programmers, or even non-programmers; they're exactly the market for this game.

    Hynekjhael has a valid point that would serve to improve gameplay.  Attacking his cred as a programmer doesn't serve any purpose here.

    I know nothing, becouse im way too dense, therefore whatever you say is most probably way more correct. So yeah, its not a bad idea to increase the limit of characters, it definetely wouldnt hurt anyone, and to be accurate, i was never against it.

  2. 11 hours ago, Lurkily said:

    Is that because programmers don't have these needs or challenges?  Or because a programmer would understand that it's unreasonable to ask? (Is it unreasonable?)

    I'm not a professional programmer, but I've worked with C++ in my youth, and have a shallow familiarity with a number of scripting languages - javascript, lua, etc.  I see nothing wrong with the idea that a programmer should want to be able to edit his inputs with ease, and that common sense should apply to the text fields used for it.

    I mean, i always name my variables in compact names, so i dont feel a need for this. I guess some people need that, its just that i dont. And he probably has tiny to no experience in programming.

  3. This kind of water doesnt fit this game. I have no idea how this would be implemented, since what you describe is not a feature, but a structure, whic in these small planets have no space to be put in. If water would be added, it would be a good idea to add water planets, with water that could be frozen or boiled. That i would love to see.

  4. Coolers should be removed.

    Possible upgrades:

    Efficiency, Power, Range, Integrity (+health), Heat, Heat downgrade ( transforms a heater into a cooler ), Spring stiffness, (armor) Hardness (defense against kinetic), (armor) Composition (defense agains thermal), Shape Rounder, Shape squarer, Size decreaser, Size increaser.

    I am having a hard time thinking of more... I dont know if it would be that interesting, but i would love that this idea would get deveoped upon

  5. 1 hour ago, Entity said:

    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.

     

    Thanks for writing about that. I made a mistake in a sentence, and didnt see it until now...

  6. When applying a tag, each and every time i have to erase "ENTER TAG HERE", write the tag, or choose it and then press confirm. Its annoyingly slow.

    I know that i can press delete, but that could be not necessary, therefore more conveninent.

    What if when adding a tag, the "ENTER TAG HERE" would be gone and we could write at once, or even better, choose from the list, and then there would be no confirm button, becouse confirmation would happen by closing the tag addition window?

    • Like 1
  7. Just now, Lurkily said:

    Nope, straight up heat.  If they ever got to the point where they would actually burn (get that weird magma-ey texture) they'd just go boom instead.  I mean, let's face it, if you don't have a cooler installed, the actual fire is more deadly.

    oh..... what i meant is that in 8 seconds ofcontinuous using they get to the melting point, or the lava-ish state

  8. 5 minutes ago, Lurkily said:

    I like Ecos - they basically operate on the principles of real-world ion engines; extremely low fuel use, energized thrust, but provides only as much thrust as the weight of a piece of paper. They'd be useful for all the stupid fine-thrust needs I have that, now, I have to use dynamic thrust for.  I'm not sure I like the total replacement of fuel in a number of these, though.  Fuel is a good weakness to have in design, an explosive weak point to protect.  I think I'd prefer that we keep requiring fuel for engines, even if a few can use energy as well.

    Clockwork seems a little too useful to me, and a little too easy to just logic into perfect functionality; it seems like a skill-based thrusted, but a logic-based part can make normal thrusters just plain obsolete.

    There's an saying in game design, that a decision is not a strategic decision unless it has both benefits and drawbacks; I think clockwork provides clear benefits, with drawbacks that are just too easy to make invisible.

    Overclocked - make them explode violently when they overheat.

    Ok, just gonna fix it right quick

    and overclocked thrusters dont need that as they could easily melt the entire drone if not controlled

  9. Pressurised thrusters - if all of the fuel storages are 100% - 95% the thruster gets ~25% bonus power. If there is less than 95% fuel left, power drops to 100% - ~25% when on the brink of running out of fuel. For more clearity i attached some numbers. More fuel - more power

    Hybrid thrusters - they are very fuel efficient, but uses energy. Fuel to energy alternative

    Ion thrusters - 2x2 sized thrusters that have the same amount of thrust, but uses energy instead of fuel. Large energy thrusters

    Overclocked thrusters - have 30 % more power, but use 50% more fuel and act as heaters: one thruster begins to melt in 8 seconds of continuous firing. Unreliable, but powerful thrusters

    Clockwork thrusters - Works in bursts ( they work for random periods between 0.1 and 0.6 seconds and then even if the key is pressed they turn off ). If being used while not off they quickly generate heat. But if timed perfectly they have 20 % more power.  Consumes same amount of fuel. Better timing - more power

    Tweaked thrusters - produce 20 % less thrust and take up 1x3 space, but consumes 50 % less fuel. Highly efficient

    Eco thrusters - Consumes no fuel, and consumes only 10 % of energy equivalent, produces 15% of normal thrust. Almost free but weak

    Turbines - thrusters that use energy instead of fuel, and loose power if they go above a certain altitude ( too rare atmosphere ), and can be more powerful when in dense atmosphere, or less powerful when in less dense atmosphere. Power depends of atmosphere density and altitude

    Independant thruster - a small thruster with a small fuel tank attached to it. Behaves just like one and the other, only that it has fuel storage, which is by default full, and the efficiency is between small and normal thruster. A bit weaker thruster with fuel storage. sorry, no drawing...

    And for no other reason than, becouse i could, i have drawn some examples of almost usable quality.

    Untitled.png

     

     

    thrusters.png

     

     

     

    thrusters.png

    • Like 2
  10. Just now, Lurkily said:

    I've also submitted this in the past, and would benefit from this.

    This seems like a good time to reiterate the other updates I'd like in distance sensors - an angle sweep, and the ability to separate it into segments like an altimeter.  One slider to determine if the split is from 0-100%, one tolerance, and an output for when each segment is triggered.  One sensor could be used for "Enemy spotted, outside optimum range," "Enemy in optimum range," and "Enemy too close, back the hell up."

    I think i would love that. But i will still elaborate on it: There should be an option to set the degrees on the sensor, like: 1 - current sensor ( a line ), 100 - a full circle, or basically a directionless proximity sensor

  11. 2 minutes ago, Entity said:

    that suggestion was aimed at the devs, not you.   and it would give you exactly what you want.

    Oh, Sorry mate. Now i read it properly, and see the potential.

  12. 2 minutes ago, Entity said:

    this could be solved with an invert option on every input.  (basically a free optional NOT gate on each input).

     

    This also solves tick timing issues because adding a not gate adds 1 tick of delay when you could have zero delay if it was built into the gate.

    I KNOW THERE IS A FIX. I want more powrful logic blocks with less complexity...

  13. 14 minutes ago, D.Mentia said:

    1 is an OR gate, 2 is an AND gate with NOT on one of the inputs - I don't really feel that two chips to do that is overly complex, am I missing something?

    I just want convenience

  14. There are logic gates that require only one of the buttons to be activated... That makes a lot of logic way more difficult than it should be. There should be an option to choose between two behaviours:

    1.Either one of the buttons must be pressed

    1.The first button must be pressed and the second must be not pressed

    BTW I KNOW THERE ARE WAYS TO DO THIS WITH MORE LOGIC

  15. 8 hours ago, Lurkily said:

    You can destroy any drone structure that no longer has energy or fuel attached to its structure, I believe.  If there's a functional battery left on it, it's immune.

    hm... i dont know. I think you can destroy anything that is printed in the same factory but the previous copy, becouse my batteries and fuel ussualy survives the self destruct.

  16. 8 hours ago, Lurkily said:

    This is actually something you can do with logic.  Two directional sensors, tip them 45 degrees.  If W and upright, hit the forward thrust.  If W and turned right, etc.  You'd need a lot.  Just thinking about it for a couple seconds, my solution would require (assuming four thrust groups) 2 directional sensors' undivided attention and 16 AND blocks.  There's probably a better way, though.

    Much easier to just have your drone self-orient so that it always faces the direction in which your controls make sense.  

    That is not what i meant. I want to put down a thruster, and it should be set to the right control automatically.

×
×
  • Create New...