Jump to content
Stray Fawn Community

Marker Mage

Member
  • Posts

    47
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Marker Mage

  1. Unfortunately, we seem to be in the minority of thinking that to be a good idea.
  2. I would go with the name "attractor/repulsor". Might stick "matter" or something sci-fi-ish to the beginning. Maybe split it into two separate and smaller parts.
  3. How about instead of impenetrable skin, it just regenerates? I'm thinking of some flesh terrain with a background component that's left behind when it's destroyed. Any still-existing flesh terrain will naturally spread to refill these areas. I'm thinking that just that and maybe a few appropriate buildings/enemies and maybe an acidic core that acts suspiciously similar to lava cores might be enough to sell it as a planet-sized organism while keeping it at a level of programming difficulty closer to that of lava/ice planets. Could have missions to kill the giant creature, exterminate parasites from it, or heal it by removing/destroying foreign objects and blasting areas that won't heal with bio ammunition.
  4. So I think I've got an idea that will greatly improve the functionality and number of uses for magnets: the ability to choose what they will attract/repel. Drone Parts: I've heard of some people who use magnets instead of struts, but how about letting them do that without also attracting enemies? Can finally pull yourself together without attracting unwanted attention. Enemies: Who doesn't like tossing a magnet in the middle of enemies and activating it? People that don't want to get caught up in the ball of things that want to kill them, that's who! Put this on a magnet, slap that magnet on some thrusters and a gravity directional sensor, slap that on a factory/decoupler, and you got something that can drag your enemies down to earth without pulling you down with them. Or you can slap it onto your own drone and set it to repel to keep enemies at a distance. Terrain: Sometimes, you need an anchor, and what is the best thing for an anchor to get stuck to? The ground! Focus on repulsion instead, and you can make yourself a hovercraft. Other Magnets: For those who want something very specific, how about the ability to just have the magnet work only on other magnets set to this setting that are also attracting/repelling at the same time? Debri/Bio Barrels/Other stuff you might have to collect: You got to collect something for a mission, but also got to protect it. You can't afford to have the same thing pulling it in also pull in the things you want to protect it from. Anything else a distance sensor can be set to: Just to cover all of the possibilities.
  5. I'd just ask for a rope part like in... Add a magnet at one end and you have a way to tether stuff to part of your drone. Then you can work on making it detachable/factory-printable and give it whatever it needs to anchor itself in whatever place you want.
  6. So would it be a damaging forcefield or more like a plasma globe, just sending electrical arcs at targets that get close enough? I rather like that second one. Maybe the default would have just one electrical arc that would hit the closest target within its limited range (whether it be enemy, building, or terrain) and upgrades would raise the possible number of electrical arcs to allow it to hit the second-closest target, third, and so on. Of course, a single electrical arc could hit an enemy and another enemy close to that enemy with the right upgrade.
  7. Well, if you aren't going to link one of them, then I will just take this opportunity to link my own version of this suggestion. Why not post a reply to it with the naming/tagging idea?
  8. I think something that might be of use is a sensor that just checks to see if a specified type of part is physically connected to it. Minimum Requirements: Part gives output when it is part of a chain of drone parts that goes back to core. It ceases to give output if it gets detached due to decoupling, factory part releasing, or a part in that chain being destroyed. If stuff connected to this part can receive fuel/energy from a battery/fuel tank attached to the core, then this part is giving its signal. How would this be useful? A common thing to put on a factory part is a logic splitter so that when multiples of the same thing are made, the various inputs/outputs they give do not get jumbled up. This and the all-or-nothing nature of logic splitters and logic connectors keeps the factory creation from being able to realize when it has been separated from the rest of the drone. There are workarounds to be sure, but each has some drawback. Using a distance sensor set to drone parts does not work until the section has gotten far enough away from the rest of the drone, which may become difficult it it was made on top of the drone. Just having the part behave the same when attached and unattached can have the part in question trying to drag the rest of the drone in directions that you don't intend for it to go, forcing you to either release it early or fight a fully autonomous section. Possible Improvements Let it be set to detect either the core or the closest decoupler/factory part between it and the core. This would allow the above use to be more useful for sections that separate from another section that separates from the drone core. Let the player set it to detect a connection to whatever part they want it to detect with whatever specificity. This would allow it to be used to tell when a part has been destroyed. Let it be able to detect not just parts along the path between it and the core, but any parts that are physically connected enough to share fuel/energy. This goes well with the above's possible use in automatically detecting destruction of connected parts. Let the player specify how many it has to detect to give its signal, or maybe have separate signals for if it detects less or more than the number it is set to detect. Another expansion to its possible use in realizing that a part or parts have been destroyed.
  9. Yeah, they work exactly how they do when I explained why they don't work for what I want in the section titled "The Reason".
  10. So I was reading another "have directional sensor/weapon target closest ____" suggestion when I had some ideas for options for what to do with a directional sensor set to target something that there is two or more of. Nearest Let's get the one that inspired this out of the way first. This just has the closest of the multiple targets decide which section of the directional sensor is activated. Maybe show multiple targeting dots with the nearest one being visually different from the others. Default For a default, I was thinking that we would have a visual of multiple smaller dots in the sensor for different targets. If even one of them is in the colored sections, it gives the tilted ____ output for the section. A sensor with this option set is capable of giving both outputs at the same time. Most Much like default, this option gives the multiple smaller dots visual. This option counts the number of dots in each section, including the grey tolerance section, and acts as a single-target directional sensor with its target dot in whichever section has the most target dots. Arc Instead of the familiar targeting dot (or maybe in addition to?), this option gives a targeting arc/pizza slice that tries to be as small as possible while still covering all possible targets. Maybe have it only work if it can contain them in a 180 degree or less arc (have player able to set lower limit?) if it can save some effort in programming. Other than this, this option behaves much like the default in that any section the arc overlaps gives its output. Arc Center This works like the arc option except for marking the center of the arc with a dot that activates the section it's in instead. Arc Average Much like arc center option, but with the average of the targets' positions relative to the outer points of the arc being used for targeting instead. Arc Most This behaves like the arc option, but instead of activating any section the arc touches, it limits itself to activating whichever section contains the biggest chunk of the arc. If that section happens to be the tolerance, no section is activated. In addition to these multi-targeting options I would suggest a separate option for tolerance that can be set to ignore, default, and priority. Ignore: When set to ignore, targets in tolerance section are just ignored. Nearest will go with nearest target outside of the tolerance section. Most will treat the tolerance section as though no targets were in it. Arc options will never have an end point in the tolerance section. Default: Tolerance is just treated as a third section that can still be chosen instead of left or right. Priority: If a multi-targeting option has to choose between right, left, or tolerance exclusively, then any targets in tolerance will cause it not to activate either of the two tilt outputs. Another concern would have to be whether this would just be an update to the directional sensor or if it could become a new multi-directional sensor part or something.
  11. The Idea Just have the various parts with inputs and outputs only give those inputs and outputs to parts that are physically connected to them. Have an exception for parts that come after a logic connector. Maybe have the exception also cover parts connected to the drone core. The Reason I want to be able to make a drone whose layout includes something like... core --> factory --> resource box --> flight stuff to get it to the resource collector Because I want the ability to have multiples of the factory-made part without their inputs and outputs messing each other up, it needs to be... core --> factory --> logic splitter --> resource box --> flight stuff to get it to the resource collector Because I also want it to only try to go to the resource collector when it's released, I need it to be... core --> factory (release input: A key) --> logic splitter --> resource box --> switch (input: A key/output: "fly" tag) --> flight stuff to get it to the resource collector (input: "fly" tag) However, that switch fails because of the logic splitter before it. If I instead try... core --> factory (release input: A key) --> logic splitter --> resource box --> flight stuff to get it to the resource collector (input: "fly" tag) --> logic connector --> switch (input: A key/output: "fly" tag) ...then while the switch does activate, it still fails to affect the flight stuff because outputs don't get to travel backwards through logic connectors. However, if the idea of this post is implemented, it would be possible to go with something like... core --> button ("connected" tag) --> factory --> resource box --> NOT gate (input: "connected" tag/output: "fly" tag) --> flight stuff to get it to the resource collector (input: "fly" tag) If this setup is used with this idea implemented, the NOT gate part would cease to receive the "connected" tag once the factory's release input is given, thus giving the "fly" output to activate the flight stuff. An Alternative Another idea that I've had that would get around this problem is either of a pair of parts described here: A Late Realization So I could apparently just use a distance sensor set to drone parts. Well, I've already put this much thought into this and want to see if it or the alternative I linked to get votes or not. Maybe someone else will want it implemented for a different reason. EDIT: Added wireless tranceiver post to alternative section.
  12. If we're going with propellers being more effective underwater, we could also try having them also be effective in denser atmospheres.
  13. So these faint energy beams... They remain after decoupling and just pull back the part for recoupling, not allowing recouplers to switch what they recouple to?
  14. Do you think a friendly fire upgrade that lets a weapon damage your drone parts is a possibility? It could be used to destroy excess factory part creations that are slowing the game down or have just piled up in an unappreciated location. Like if you got a harvester drone equipped with a factory part that makes resource boxes with thrusters and sensors that detach and fly to the Nimbatus to dump their contents, it might be nice to have some sort of incineration strip for them to go to afterwards. Too many times I've seen my self destruct TNT leave a single part or two behind. It could also be used with plasma and cryonic ammo types along with a damage downgrade to quickly heat or cool a drone. Just imagine if you later add more ammo types that could situationally be useful to get hit with. Also, it would allow me to make a drone with 2 decouplable/factory-made minidrones with controls set up for me and a friend to have a fight on some random planet.
  15. This sounds similar to an idea already posted. Maybe vote that one up to make the idea more visible?
  16. I had the idea while reading suggestions for upgrades to allow a weapon to not harm ore. The idea of an air-based ammo that blows away loose soil/sand/gravel while leaving ore and maybe solid rock unharmed. The idea of it doing more knockback to enemies at the cost of damage was a bit of an afterthought. Also, bio, cryonic, and plasma form this earth, ice, and fire trio that is just asking for air.
  17. I had to look up the fancy Latin/Greek/scientific word for wind for this. So I was thinking that a possible ammo type you could have could be wind/air-based. Give it knock-back at the cost of damage against enemies. On terrain though, it would have a boost to digging power against weak terrain that would be comparable to sand and gravel. Either that or it would move them around, but I'm guessing the boost to digging power would be easier to program. I'm thinking that this boost should be a set amount instead of a percentage, so it'd be possible to make weapons with a digging power of 0 that could still get rid of weak terrain, but they'd do nothing against anything stronger like solid rock or ore. It might actually be kinda fun to use weapons with this to slam enemies into stuff to damage them, repel charge attacks, repel projectiles, and clear weak terrain from around ore without worrying about damaging it.
  18. I may be calling it by the wrong term. Think of someone at an archaeological dig site who's found something, dropped his pickaxe, and takes out a brush to start removing dirt/dust/whatever from the thing he's found. Just a tool to carefully remove the stuff you don't want from around the thing that you do want, but it would be a nightmare to use it for serious digging.
  19. But would the primary factory part still count the parts attached to a printed factory part in recharge time for printing, or would it just have the printed factory part printed with an empty meter so that it'll handle the recharge time that the primary factory part skipped over? Regardless, I think maybe a "spawn with pre-printed parts" option could handle both the initial spawn in the level and the spawn when newly printed by another factory part.
  20. What about an ammo type that treats digging power as 2 points less (minimum 0) when used against ore? If you have the weapon have a low enough digging power, it can slowly destroy terrain, but leave ore unharmed. Think excavation brush over pickaxe.
  21. Physical Connection Logic Part I think we could use a part that functions like a logic splitter but with an exception for things it is physically connected to. Like, if you have it clapped onto a decoupler, it'll be like it's not even there until it gets decoupled, then it works like a logic splitter. If you have it slapped on to something that is slapped onto a decoupler, then once the thing is decoupled, it'll let through inputs to and from the thing it was slapped onto, but otherwise function as a logic splitter. Just kinda treat key events like fuel or energy.
  22. Could we get an option for factory parts that toggles whether the parts attached to them will be there when the mission starts? Some of the autonomous things that I want to print with factory blocks have thrusters on them and I would appreciate being able to just not have them there until I'm ready to print and release rather than releasing them underneath the Nimbatus or trying to fly with them still attached.
  23. I like the idea of having them have a variable recharge speed based on altitude. Maybe have its reintroduction occur alongside the introduction of a way to transfer energy between decoupled pieces so that recharge satellites could become a thing.
  24. So, I've found that weapons decoupled from a factory block do not count for the "Only 1 laser, no other weapons" requirement for the Mega Laser signal. While this is advantageous to my plans for death laser satellites, I feel that it was unintended. Please enjoy this build I used that includes an energy-free laser attached to a factory block. While it is attached to the factory block, it is MEGA. Once released from factory block, it becomes wimpy until the factory block prints another laser. Decouple to make all the lasers wimpy, and print to make them all MEGA. Also, I couldn't find where Nimbatus saves screenshots to, so I just used print screen and Microsoft Paint.
×
×
  • Create New...