-
Posts
1,540 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Events
Everything posted by Lurkily
-
There was talk about a glue block or grapple block of some sort that this also might be useful for. I'm a firm believer though, that the magnet is so situational, and of such limited usefulness, that it should be a 'gravity' block instead and just stick to anything. EDIT: As for stabilizing magnets, lower their radius until they're almost entirely inside your ship.
-
Every parent says that, but nobody believes them.
-
Drone core upgrade ability, more specific component slots
Lurkily replied to MrFaul's post in Feature Requests
It's not that I'm opposed to the mechanic; I'm opposed to the arbitrary and artificial presentation. Having weapon slots when you're permitted a free build from scratch is basically naked and undisguised 'this is how you play our game'. Let's provide an organic way to deny them the resources to support three weapons - mounts, or make them buy each weapon individually, or whatever. I feel like just a number on the build screen saying you've filled 2/3 weapon slots without a really good explanation isn't the way to pursue that progression. -
Changing the current logic i/o method to a visual style.
Lurkily replied to MrFaul's post in Feature Requests
To be fair, 'complete revamp' were your own words. It's easy to see how people might think you're asking for a more fundamental rebuild than that. Separating logic from inputs and outputs - which seems like the foundation of their concept at the moment - might be harder than rewriting them from scratch. It might be possible to code in some auto-assignment of UID's for each input/output that's invisible to the player, and just use what we have now with a different system for assignment, but there's also the risk that the result might get messy. There are a number of suggestions for visualizing input and output connections already up; what if the input-output system remained as-is, but in the visualization of them, the player could drag and drop to copy a block's output to another block's input? Does that touch the core of what you're looking for here? -
Creates a laser? Reads a numerical value? Clicking logic elements in game? (Just the idea of trying is painful, given the camera movement linked to mouse movement.) I'm not 100% sure you're posting for the right game. I mean, there's stuff we can use here, but some of them seem fully inapplicable, and a great deal of them seem to be tuned for a different environment than Nimbatus provides.
-
Thanks. I'll find that and anything similar and try to pull them together. Just FYI, I'm trying to merge each topic into the one with the most votes. If you voted on a topic I merged, but didn't vote on the original, consider re-adding your vote.
-
The man's not a moderator, nobody's obligated to do any extra work in being helpful. I had intended to start merging tracker topics, and forgot to, in fact. Let me do this now. EDIT: Interestingly, only two topics on beacons, though a couple more for things like laser targeting and lock-ons; directional sensor criteria.
-
I know I've commented on this already, but doesn't it seem arbitrary and artificial to provide an unrestricted environment to build from scratch, and then say 'but not the way you want to'? I'm not against progression mechanics, but let's try to make it organic. Make people purchase or find a 'mount' item that weapons need to be fitted into, or make people find/buy each individual weapon, so they have to actually get two lasers before they can mount two lasers. I suppose lore could address this somewhat, and we have no campaign or backstory yet; perhaps you're constricted by regulation build parameters until you get promoted. But I think it's really important, in a game that's trying to enable wild creativity, for the restrictions they enforce not to seem arbitrary.
-
I actually already do this with heaters. I have a bomber that just bombs the region with a heater/solar/sensor stack. It does litter the terrain with heaters, though.
-
Things You shouldn't suggest
Lurkily replied to Alpino_WILL_STEAL_ oats!'s topic in Discussion & Feedback
Multiple suggestions often end up dividing people's voting, though. Hence why I'd prefer to merge things early. So, yes, message me, or if you like, suggest in a feature thread that a topic should be merged with others. Provide links if you like, but even just saying there's something to merge it with would help direct our efforts. It's really hard to know what concepts I should look for duplicates of, until you actually go and search for topics on exactly that idea. -
The core has some significance, though. The drone can't operate without this one piece that doesn't do anything not done by logic pieces. (Actuate devices, receive signals wirelessly) That gives me a thought. If custom cores and core mods become a thing, perhaps you'd be required to repurchase those if you lose a core, and only the default core is free? It would provide an incentive to return that's lore-friendly, a penalty that is really just an inconvenience, and ensure that it's not a barrier to later gameplay.
-
Things You shouldn't suggest
Lurkily replied to Alpino_WILL_STEAL_ oats!'s topic in Discussion & Feedback
Feel free to send me a link if you see a repeat, I'll do some mergey stuff. -
Word of advice. Use thrusters to hold the feet down. Rotate hinges in opposite directions, and you can keep a leg pointing down, even as you rotate a joint to move it up and down. With the new logic available, you can get much more complex movements than were available when I last tried. Have fun!
-
Drone core upgrade ability, more specific component slots
Lurkily replied to MrFaul's post in Feature Requests
It's not that I think every game has to be for everybody; I think Nimbatus, specifically, is about enabling engineering madness, instead of making a player earn their way into unconventional design. I may be entirely wrong about that, it's just the feeling I've gathered in the last year of handling it. I'm not too concerned about the grindfest personally. I don't think the devs would go grindy, and costs can always be balanced for a better result. -
Changing the current logic i/o method to a visual style.
Lurkily replied to MrFaul's post in Feature Requests
Sorry; when you described it as a 'complete revamp' I thought you were talking about a complete rewrite, and you seemed to be saying you'd favor doing away with the input/output system we have entirely, which would mean an entire rewrite of logic, and the editor UI, (UI being generally painful to mess with,) along with the creation of a new system. I didn't think accomplishing your goals required all that. On a re-read, it looks like you might be talking about just re-writing the way the player uses the UI to assign those inputs, and how it represents them. Sorry if I was confused. Honestly, I personally don't like big foundational overhauls in early access; foundational things are usually best more-or-less settled in closed alpha/beta. But that's only my opinion, and I'm aware it isn't universal. -
Huh. Conveyor belt . . . . . . magnetic? I once made a repulsor magnet relay to serve that purpose. It was timing-dependent, though, so it couldn't be manufactured segment by segment. while preserving the timing. How's yours work? I'm more interested in this than the flat world, honestly. Edit: Actually, maybe you could, if you could place the next piece carefully enough that it put a hinge inside some blacks meant to trap that hinge, rather than having them connected by struts.
-
A quantity of planets full of HOLES! (Probably a good idea not to take me too seriously at the moment . . . or any moment, really.)
-
My perfectly spherical planet is better than yours.
-
I'm just imagining a planet where the resources bleed when you harvest them. My mind works in strange ways sometimes.
-
Resupply missions with limited or vulnerable win conditions
Lurkily replied to Lurkily's post in Feature Requests
I would have it seek out a suitable location so that, in case of problems, the player doesn't have to wait a long time for mission requirements to come available. My assumption is that 'suitable' is a relatively level terrain edge; but for the purposes of maintaining an achievable win-condition, I think most people wouldn't mind if they were laid in open space. That, and permitting them to hatch microsnakes if you didn't hunt them down would be cool - and under these circumstances, would no longer ruin win conditions. -
That bug is really just for borderline cases; one TNT wouldn't destroy a thruster even without that bug, and the solution to add more TNT than a weapon needs doesn't seem ideal to me. Do you parent the thruster to a destroyed part? At least then the thruster is debris, destroyable by weapon fire. I usually parent things to a decoupler or LED next to TNT. Fragile stuff, to make sure things aren't active parts after destruction, contributing to lag. I think the heater is a good solution, actually, given that it spreads to nearby parts and is almost certain to destroy it all. EDIT: I checked, and both decouplers and LED's have 1000 HP - which stymies me, because the few times I need them to endure, they are always the first things to blow. In any case, find a delicate thing. Distance sensor, maybe. Though you should be able to parent directly to the TNT, with recent updates fixing some cleanup issues, I think.
-
It's not really an 'on' switch. It's a signal that signifies that the drone has been initiated, and which goes off only once. I used it a while ago, on a drone from an older version. You can probably do this with a few logic parts. Let me think. Button: Core Active XOR: Core Active/Interrupt, Game on Switch: Game on, Interrupt So a signal signifies that the core is alive. An XOR activates our 'game on' signal, because only ONE of two signals is activated. (Core Active) A switch activates the "interrupt" signal with that input, and with BOTH active, the XOR stops our one-time-signal that the mission has started.
-
Drone core upgrade ability, more specific component slots
Lurkily replied to MrFaul's post in Feature Requests
Part of the problem with anticipating a most common type of gameplay is that it usually fails to anticipate others. My impression of Nimbatus (and I may be wrong) is that they're trying to provide, within the constraints of challenge/reward and progress/reward growth balances, the freedom to indulge the inner mad scientist. I guess I feel like imposing build restrictions that are clearly and obviously "We as devs think you will have fun playing this way" injures what Nimbatus is trying to be. -
Drone core upgrade ability, more specific component slots
Lurkily replied to MrFaul's post in Feature Requests
On the other hand . . . a more organic limit would be realistic. Something like having to find or buy parts, and having to buy three large thrusters before you can have three equipped would make a lot of sense - part unlocks are something i fully expect in time, and unlocking a VOLUME of each part would make more sense to me. -
Drone core upgrade ability, more specific component slots
Lurkily replied to MrFaul's post in Feature Requests
No, I understand you. I would just like the restrictions on what a player can build to be less arbitrary and artificial. In many games this makes sense; but where you are building from nothing, it's arbitrary and restrictive, and the player's going to question it when it stops them from doing what they want to do. I'd much rather a player come in and say "I can only build this big, but look at this, I can do anything I want with this big. Is there a limit to how big it can go?" than to ask "I can only build this big, and I can't specialize because of the part-type limits. Will the upgrade system ever permit me to build freely?"