Jump to content
Stray Fawn Community


  • Content Count

  • Joined

  • Last visited

Community Reputation

102 Excellent

About Ookami-sama

  • Rank
    A Nimbatus font, hm hm...

Recent Profile Visitors

657 profile views
  1. As additional information: this problem appears on the Sagittarius drag strip with only one thruster on each side of a drone core and a fuel tank behind, as the craft ends just a few metres North of its starting position. Adding thrusters adds some slight turning, and heavy parts behind the craft make it collide with the wall rather quickly, even with the ship perfectly balanced around its stern-prow axis. Placing a small, supplementary piece to the right of a craft's centre of mass seems to solve this (roughly). I believe I cannot prove much more useful than that, and I assume this behaviour is not intended by the developers.
  2. Planes in real life are rather big, and they do not "stop, balloonlike, whenever you stop pushing them" -- thankfully so. A ball made of foam, while small, will lose its momentum quickly. In Nimbatus, planes stall and balls speed down tracks. It might be that air resistance applies to all components of a craft however they are arranged, or that inertia is low, I do not know the details; but large ships do feel sluggish, stopping in their tracks the moment their means of propulsion shut down. That is both counter-intuitive because it seems to work another way on earth, and annoying because smaller almost always means faster, and in that situation I fail to see any much interest in larger designs.
  3. What is more useful than antimatter? Or, if the former is not available for reasons ranging from technical limitations to dull science, a fantastic cake with one layer uranium 235 and explosives, a second layer lithium, plutonium, uranium 235, then another layer like the former, with ten times the toppings. In that order, and with a big red button reading "Happy Birthday". Given these aliens' skills in rebuilding planets from the void up after I meticulously disintegrated them, I am absolutely sure they will not mind this sort of study either. For science!
  4. I had found that a NOT gate could save me the time it takes to charge jump thrusters. Said thrusters need approximately a fourth of a second to completely unload, so add a buffer to that because I rarely manage timings well and I rather let the computer. Thus: jump thruster(s) with input key "charge"; NOT gate with input key "jump", input tag "jump 2", output key "charge"; buffer gate with input key "jump", output tag "jump 2". Jump thrusters will be charging on their own, and stay loaded until you press "jump"; at which point they will kindly take the time to pull you out of a cave filled with lava, then charge up again in case you were thinking of going back. --- An old trick: distance and proximity sensors can act as buttons for half the space. Set one to "Own drone" and target something that should not move around too much.
  5. So it is that sort of person who would use a controller. I will try and refrain from commenting the kind of verbal abuse I would have just that sort of person go through if it were mine to decide. "Thanks for not taking it at heart! Much love." In a more serious tone, I do suppose that controlling one's craft can be done with only a few keys. Controller support for taking flight rather than construction sounds more enjoyable than I first imagined it. Is it yet on the "OCD (One Can Dream)" list?
  6. I have found controllers and joysticks to be most bothersome to use in anything but menus, with the utmost worst being screen-wide clusters of tightly-packed elements, like real-time strategy games. I do not believe I would even try playing Nimbatus with anything other than a mouse, or at least a device that lets me quickly point at what I want, rather than slowly dragging a cursor across the screen to reach a given position. Also, any basic circuitry requires way over ten keys, or tags. Four directions, one weapon, one magnet (two inputs) for barrel missions and such, one directional sensor (two inputs) for keeping the craft upright, and you already have a whole nine keys to map. Add a switch to make the magnet easier to use, a factory for crafting missiles (a thruster on TNT, so one input for printing and releasing, one input for missile thrust, one input for exploding), and map a total of thirteen keys. Also, one cannot use tags without the keyboard, which requires one drop the controller, enter a tag name, pick up the controller again. It is tedious. I would not make use of such function, and I have trouble figuring out what sort of person would.
  7. Original idea and post by Garheardt the Black. Now what was I writing about making designs public...
  8. For propulsion, too. Running away while laughing evilly.
  9. In the meantime, we have lasers to play baseball with. And yes, lasers are actually used to push things around, even if said things are atoms or very particular contraptions. Though this solution only works for alien creatures or objects, and lost parts of one's craft.
  10. I had this in the back of my mind for a while, but only now remembered it: some free piece of software can be improved upon -- since that is what free software is about, mostly -- and replace a former version that was spread by a former developer. They still have their software, sure, but it is not used as much any more for a precise thing that the updated/changed version does better. A drone that is improved upon still exists, and the person who made it still has it. They might not hold first place in the rankings any more, but neither does a developer after their software was upgraded by someone else. The only notable difference I can see is that a developer is (often) credited for their work in various places (e.g. encyclopedia, dictionary, wikipedia.com), while a Nimbatus player evolves among a number of individuals rather than in a system of people connected to one another. Which makes peer recognition a bit more difficult to obtain, somehow, although platforms such as Steam's "workshop" tend to sort this out.
  11. Following your advice, and experimenting further, I can say with relative confidence that the number of nodes between a drill and a battery has no influence on the order of depletion. Demonstration: clockwise depletion. Another example of clockwise, different depths for drills. Do note that battery number 4 is one node away from a drill, batteries 2 and 3 are two (through core) to four nodes away, and battery 4 is still depleted last. After having picked up and put back battery 1, hypothesis in my previous post still gives consistent results (last moved is last depleted). As for closer batteries being depleted first: neither. That is, only if I want them to, and using the rule of my previous post. There does seem, at some point, to appear some inconsistencies, in that this order suddenly becomes difficult to change. In the above example, a certain number of movements (double-clicking the drill a dozen of times, actually) made it so that I could not change the order of depletion without elaborate shenanigans. Leaving the workshop to come back seems not to change a thing, nor does restarting the game. It would seem that the position on top of the chain of small blocks is set for number 1 now, no matter what, with its children coming right after. Deleting and replacing the block chain entirely made the former number 2, on the right, absolute number 1... until I placed a newly-created battery in the exact space of the former number 1, which made it take back that place on the list permanently. I am bewildered, but there seem to be some rules, which would be, at some point in construction, ignored, overridden or its results set in stone, and that could have to do with the way the engine stores Ctrl+Z data since it seems to happen after a few (perhaps thirty on a tiny craft) placements or movements. I do not have sufficient knowledge to make any precise assumption however. I would welcome any sort of thought or additional information you have about this, Corona, faytleingod. Might I ask a developer, such as @Micha, for help on this topic? It strikes me as coherent until something breaks, and I would very much appreciate to know what does break. In the meantime, I support this feature request.
  12. A folder is, technically, a prefix to all files and folders inside it. "Documents\Important things\Chart of divinity.txt" is very much akin to a larger folder hosting, among other things, a file named "Documents - Important things - Chart of divinity.txt"; the only difference is that the folder view is less of a burden on the eye. As such, I think tags and filters would be a better solution: tag a robot with "Prototype", "Campaign" and "Factory", and it will show up when you search for either of these tags, or a combination of them. Conversely, looking for the tag "Racing" would not bring up this robot.
  13. If I may correct my previous statement: the last tank or battery to have been moved or placed in the drone workshop seems to be the last tank or battery depleted. My own experiments do not contradict this statement thus far; might I ask for an example of this problematic behaviour? As for said experiments, conducted with batteries because it is easier (replicated in private with fuel tanks, but I am bored enough that I ask you to trust me): Numbers on each picture represent the order of placement or movement. Which is to say: the battery that was last placed or moved is labelled "12"; the second-to-last battery to have been placed or moved is labelled "11"; etc. and down to number 1. Experiment 1: clockwise placement, no movement. Expected result with the above-mentioned hypothesis: order of depletion is from 1 (first to deplete) to 12 (last to deplete). Result as witnessed: consistent with hypothesis. Experiment 2: clockwise placement as for experiment 1, then moved (actually: picked up by double-clicking, then put back with click) what was number 7, making it number 12. Expected result: depletion from 1 to 12 with updated numbers. Result as witnessed: consistent with hypothesis. Experiment 3: placement as numbers show. Expected result: depletion from 1 to 5. Witnessed result: consistent with hypothesis. Experiment 4: same placement as experiment 3, then added a battery branching from battery 1, then moved battery 2. Expected result: depletion from 1 to 6, with the new battery having been placed/moved second and the branch having been moved last. Witnessed result: consistent with hypothesis. As such, and until it is proven otherwise, I do believe this matter is less of an acrobatic dance and more of a simple, numbered list. Do note that the rule is the same for distribution of power or fuel: in case of a lack of resources, devices placed/moved last will be powered last.
  14. You can include a prefix in each drone name, such as "Catch - Meifyoukan" or "Racing - Heart", and sort them by alphabetical order. Folders or tags would still be interesting, I believe.
  • Create New...