-
Posts
1,540 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Events
Posts posted by Lurkily
-
-
1 hour ago, unmog said:
Uhm, noob question coming. What is zippering and how do I do it?
11Here is a subdrone I use to courier ore I don't want to carry back myself. The ore containers were quite unstable when I tacked them on - because they're attached to my ship while I mine, they're subject to the full capabilities of my drone's maneuvering, not just the thrusters that are directly attached.
EDIT: Ignore the logic. It's a bit messy, still. I had to rebuild it, and haven't yet cleaned it up.
So what I did here is 'lace them up' like a pair of shoelaces. The left parts can't pull away without pulling on the center mass, and on the bottom, pulling on the other chain of parts. They can't 'peel away' without encountering resistance from the whole subdrone's mass.
-
Well, there is a difference between holding in place, and fully disabling a unit. Freeze can't hold a unit suspended, and the tractor beam laser wouldn't be able to disable a unit so it can't act or fire. But I don't see the usefulness of it, either, except maybe in transporting objects - something it still wouldn't be suited to.
-
Entity, I merged yours into this topic to preserve the 7 votes. Hence why the links to yours no longer work. Your post - perhaps because it's the oldest? - replaced the topic here, though. I'm not really entirely sure why - merging acts a little funny around here.
-
1
-
-
Latin is also a language I hate. EVERYTHING is dependent on form and declension. Everything. There is a proper word order, but it's a gentleman's handshake based on the habits of one popular dude's speeches. Different word orders have no influence on meaning, other than being obviously incorrect.
To be fair, I may just hate learning languages.
-
But the brain has to communicate BACK to every turret. And it has to give DIFFERENT commands to every turret. The brain can't just say 'turn left' without talking to all turrets. It has to say "Turret one, turn left." That means the brain has to contain a separate set of logic for turret one.
Even if each turret could give the logic input without giving input to other turrets, the logic still can't talk back without talking to everybody. It's not really a failing of the current system; it's just a limitation of simple logic. The circuit would have to accept input as to which turret is speaking, and be able to modify its output on that basis to give turret-specific outputs in order to change that, and we're talking about scripting, now.
-
My first suggestions on the subjects were a bit awkward. This suggestion is to have the option to use a 'chassis' with a drone core. This would be several 1x1 blocks linked to the core in a pre-determined configuration. (And perhaps with more limited options available for a configurable chassis)
Each of these parts would be connected in some stylish spaceship-shaped way to look nifty; but the connections would be far more resilient than a normal strut. They would serve as resilient and stable anchors for other parts; but the configuration would also dictate some constraints to your design. Various configurations might be suited for big ships, small ships, round ships, long ships, etc.
Chassis blocks should be a serious vulnerability. Damage to them should also transmit damage to every connected part, including other chassis parts, and their regeneration of HP should be slow; if one is exposed to damage it should be a serious liability, and god forbid your chassis catch fire.
This wouldn't offer complete rigidity; but it would offer, within certain constraints, a more stable environment for a larger build.
it would, though, being fixed to the core, beg for the ability to rotate the core.
-
20 minutes ago, unmog said:
Yea Im not sure I understood that at all. How would this help me build independant functional turrets?
It probably wouldn't. But say you wanted a world-crusher that descended smoothly, strip-mining a planet by altitude instead of just bouncing around drunkenly when it saw land - you could store a value, and every turn, add the current altimeter value to it, divide by two, and have the output overwrite that original value. An infinite decaying average.
Turrets are simple problems with simple solutions. I don't think math would help you a great deal; you might read the hinge position of a different turret, to make sure they scanned and covered different directions with little overlap, I suppose.
-
1
-
-
I think it was intended to be a knotted loop, but that's a figure-eight knot, meaning there are two loose ends hidden.

-
Looks like someone made a friend.
-
1
-
-
Agreed.
-
Micah has mentioned that he'd like to apply conditions 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.
-
Though I dearly want to know too, I agree with this. Development always takes longer than it takes, and I've worked in communities before where they soured the community by missing deadlines that they imposed themselves.
-
2
-
-
Please tell me "moon moon" is a possibility.
-
1
-
-
Initial visibility and time of posting along with a lot of chance circumstance contributes to whether a suggestion grabs alot of attention; unfortunately, such is the nature of social media. I'll merge it in later.
-
The output block, like other math blocks, would read a variable, and output a tag or key based on criteria configured in the block.
Each math block can read and output variables. They need input and output, of course.
Sensors would create the variable initially, and perhaps some logic parts could set a variable.
-
My chassis idea was awkward. I'll think on something better, and try to have a post tonight.
-
I seem to recall the devs having spoken about experiments with rigidity, and calling it boring; one reason I stepped away from ideas about rigid chassis or skeleton blocks/assemblies - it doesn't take many fully stable blocks to make a fully stable drone.
I'm not against the idea, but I'm trying to find solutions for coherence rather than rigidity, since rigid doesn't seem to be preferred. I think perhaps they want to encourage the creative solutions to coherence, rather than obsolete them.
-
There are a lot of solutions to coherence through creative construction, such as 'zippering' or 'lacing' children so that the bottom pulls on the top and vice versa, and magnets can already be used this way to help coherence.
But with rigidity solutions resurging, I thought I'd test something else.
Interconnected drones have been tried, and apparently physics became taxing very quickly.
-
I keep it synced with a second directory, myself.
-
So I like logic they way it is, but they idea of analog readings and math keeps coming up. In asides and whispers, perhaps worried that it'll be shot down as embarrassingly out of character with Nimbatus. I don't think I'd recommend it, but I have a concept on how to implement it.
This would be a second class of logic blocks - math blocks. Only an output block would cross that divide, able to output a key or tag based on whether a variable is ==, !=, > or <.
Sensors would have an option to output a variable, as well as ranged key/tag options. (Such as we use now.) Addition blocks could accept two variables and output a third, along with division, subtraction, multiplication, etc. Thus you could do things like produce decaying averages of sensor readings, or whatever else you like.
I don't think I'll recommend this, though. I think solutions to these problems largely exist in basic logic, and that introducing math obsoletes many creative solutions. Like code, I think mathematical expertise would become a cost-of-entry for complex and efficient builds.
Right now, a smart novice or an experienced idiot can both work up to very complex behavior with very simple basic tools, and I think that is critical.
-
1
-
-
Yeah, I have lost big projects with mis-clicks.
-
The parts take increased damage from impact- with less displacement, there'd be less impact mitigation, so I expect that would just happen without planning it. They'd still be mobile to seem degree, but they'd resist it more.
-
Oh. I thought you were trying to suggest a workaround in the current game, not a modification to this suggestion. Ignore everything I said.
-
Opposing forces, realistically, would really just cancel out.
Upgrade bugs
in Bugs
Posted
I think what we need is an expansion of propulsion systems that can utilize more fuel reserves, as well as other consumption, such as factories.
As for shields, I'd be okay with their current consumption, PLUS extra consumption to recharge after they go down. I think limiting their standby consumption would just encourage overlapping shields against regular bullet fire. Increased recharge would counterbalance decreased standby energy use in ONE shield, but not in overlapped or nested shields. Since only one of those nested shields would be taking damage at a time, it would diminish the energy hit you took in using multiple shields, as long as you overlapped them well.
I think there is currently enough advantage in careful nesting of shields that we don't need to further encourage it.