Garheardt the Black

Yarr! I thought it could help to make a thread where we share our observations about the new parts I'll detail more as I get my feet wet, but here are some of my initial thoughts so far: VTOL thrusters: -Good: My new favorite part. Drones will be faster, more responsive, smaller, and smarter. -Bad: Doubly so for sumo spinners. Proximity sensors: -Good: Huge potential. Fully automated spin-free are now turrets within reach. Terrain avoidance is easier. Better formations. Smarter drones. -Bad: The lack of range is prohibitive. Afterburners -Good: High speed shenanigans. Could be weaponized with future tweaks to collision damage -Bad: Jump thrusters can mitigate the minimum speed requirement pretty easily, making that feature seem kind of pointless. -Possibly bad: spinners can spin REALLY fast now. That's as far as I've gotten so far. Thanks for the new toys!

The enabler lies with the propulsion. When the head pulls on the body, the body distorts because of the interaction of mass and force. So long as a directional force can use less energy to alter a part's orientation than it would use to alter the position, then that applied force will always alter a part's orientation first. If the body was mass-less, it would be impossible for a force to alter it's shape. So I concluded that the greater the difference between the mass of a fluid object and the force applied to it, the more the object will distend and I fooled around with a bunch of different thrust settings. It failed completely. But. I noticed that while pulling on a curved semi-fluid object reduces the curve, pushing it causes the curve to increase. Apply a pull to the top of the curve and a push at the bottom and you get a collapse at the top and a ballooning at the bottom. So. I thought if I could apply a simultaneous push and pull throughout the entire structure of the curve equally, the curve wouldn't collapse. I tested this by building a drone with segments that each contain identical amounts of thrust, causing the collective mass to resist a constant amount of pull and push. Hopefully, so long as the forces remain equal, when the craft turned the curve would be unable to collapse. Evidently, it worked. Further proof of evidence is the way the curve still collapsed near the tail; there was no longer enough push behind the curve to maintain it. I might be able to stabilize it some by adding more thrust at the very end, but in order for my conclusion to be correct, the curve near the last segment must collapse. I bear little hope the design will prove useful for anything practical, but it's really cool to watch. SCIENCE!!!!

Meanwhile.....

I agree. I shy away from ideas that would reduce creative thinking, such as suggestions to make stable structures significantly easier to build. I've enjoyed learning quite a bit about modern engineering by teaching myself how to methodically plan drone structures from the bones on up. I like the sensor changes, because I think they'll actually increase people's creativity by giving them more tools to create with rather than easy solutions to problems that have already been solved.

Nice! I built something similar a while back that used spinning clones that tracked my mouse cursor. They moved like a school of fish because of the interaction between their constantly adjusted minimum spacing and the need to all travel to the same point. The practical problem was the huge number of sensors it took to prevent them all from flying into whatever you looked at. These sensor changes will make them much more viable. While you're editing the proximity sensor, would it be possible to give each sensor criteria it's own detection event? Something similar to how batteries can send both an "empty" or a "full" signal event. That would allow a drone to respond to different stimulus differently with a single sensor. Great work guys!

If you post an idea in a game's official suggestions forum and no one votes for it, the data points to a single conclusion; what was suggested was not well received. The rest of your data is speculative and diluting the only hard figure you have. That said, sorry for getting way off topic.

I've found the vote count on suggestions to be fairly compelling

I agree with Lurkily. I tend to build large, complex, long drones and they're all quite stable. It takes planning and practice, but I find it's part of the fun.

Good points. A redundant switch could work to override signals. Or a AND or NOR gate with a switch. The drawback being having to program 70 more logic blocks. Alternatively, I could rig the armor logic blocks to dynamite, blow them up, then reprint them after the fire is out. 😆 Update: I found a quicker work-around. I'm using a large series of NOT gates already, so I added a uniform input command to each one. Now they're basically NEITHER gates. This way, I could input a single variable to toggle on and off with a switch rather than having to simulate every unique button signal. Being able to toggle is fairly useful in collisions as well, since whatever you hit has a tendency to destroy the first reprint if it's still in the way. With the automated repair off, it prevents wasted prints and their associated cooldowns.

I did some testing. The armor is spaced far enough from the inner hull that it won't catch it on fire, but once it's lit, the armor will continue to burn indefinitely. It's rather amusing to watch.

So far, the armor has been fairly good at preventing fire from crossing into the internals, but that hasn't been heavily tested. My best guess on how fire works is that a heat value transferred to any given part will then begin to dilute that value among other parts nearby. If that's the case, the fact that the armor continuously respawns helps to soak heat before it can jump to the main body. The distance between layers also seems to help. I'll mess around a bit and see if I can get a decent example gif out of it. Thanks for the question; I have more testing!

Cool, thanks for the info!

Ladies and gentlemen! I give you regenerative armor! This bad boy was designed to laugh in the face of anything short of a mamma snake, and boy does it. After taking enough damage, the outer hull will automatically repair itself. It can do this quickly enough to render it effectively impervious to weapon fire and it can withstand a hit from a hammerhead with no lasting damage to the ship. It can do this by taking advantage of light parts with high HP values, and converting the loss of signal from a button in the armor into a build order on a corresponding factory. While effective, it takes a ton of programming. The featured blasters are modified with sticky bullets, increased force, and multiple projectiles. This effect repels enemies and causes them to spin uncontrollably, negating things like a hammerhead's hard front end and preventing them from attacking. That's what I've been up to lately!

Is your day job interpreter? Your day job needs to be interpreter. Thanks again! -Edit: to elaborate, though; if there was an armor overlay that soaked damage in place of the internals, a shield that blocked actual damage would likely need to act on or before that overlay in order to apply damage to the shields before the armor.

Also, CometShine, I'm seriously jealous of your artistic ability. Can I ask what tools you're using?

I like it. I'm also for having armor on a cosmetic layer. Heat resistant armor could continue to have less HP than standard armor, so the trade off wouldn't be free heat resistance, you're losing overall armor for it. I wouldn't mind seeing shields act on this layer as well, as they could act to soak damage rather than destroying projectiles without actually protecting from the effects of a blast.

Hello! As it stands, the tinniest of grains of sand can wreck a fast moving drone, or hook the inside of a larger one where it's weapons may not be able to free it. I suggest a change where terrain suffers collision damage, allowing larger drones to push through such nuisances at the cost of a part or two instead of possible catastrophe. If structures like hives could take collision damage as well, that would open up some interesting new design concepts also. Thanks! Love ya!

In the hopes of preventing this fate from befalling anyone else, I hunted around for the location of the Nimbatus save file location. No promises, but backing it up occasionally could mitigate the amount of data you lose. Provided your save locations are the default, the folder location should be as follows: C:\Users\(user)\AppData\LocalLow\Nimbatus\Nimbatus (user) is whatever your local user name is. AppData is a hidden file, so you'll have to enable the viewing of hidden items in the view tab. Hope that helps!

Hello and welcome! Possible complications with this kind of device: -Reducing air resistance increases overall speed regardless of the ambient pressure. That makes this a speed multiplier that could always be worth using, mitigating the point of the original use. -Any part increasing pressure would be subjected to it, causing instability unless it's ship wide, at which point the enemies around you are slower, but so are you, so it's a bit of a wash. -Reducing the air pressure to send enemies flying would likely result in you getting sent flying instead. A striking drone part will speed up the moment before it hits you with an arm, and even if you manage to strike back, all you struck was a moving part. With your reduced friction, you'll head straight for the ring. -Anything that can increase air pressure in sumo will make center hogs even more dominant than they already are. So far, I think drones do fairly well in high air resistance maps if they're built with an emphasis on high thrust. Sadly, I think a part like this could be very hard to balance.

You could always go oldschool and have parts beging to blink at a rate dependent on their percentage of missing health.

Heh.

Good idea. Lets see.... -gun propulsion is a thing -Tractor beam propulsion is a thing -put -80%, -20% on a weapon and you don't need to attach it to a battery to fire. -The above fact makes printing piles of guns and either using them with huge recoil like a school of fish, or bombing enemies with them rather amusing -For sake of being said because it originally surprised me; currently, logic blocks don't need to be attached to anything in order to communicate with anything else -Anyone not using tags; doing so changes the whole game. -Factories are the most powerful offensive option in the game -Factories are the most powerful defensive option in the game -Enemy structures CANNOT be destroyed by collision damage and have infinite mass. -fire/heat resistant parts aren't resistant, they're IMMUNE to the corresponding effect.

It's cool. What throws me off is how some letters look bold to me, and others don't. That and I wonder if the letters have too much space between them as compared to our current font. I can't identify individual words quickly enough to read smoothly. I particularly like the "X". It reminds me of space invaders.

Aye! It's already uploaded

You can split off a factory that produces the drones to prevent crosstalk already. A one-way splitter added to the current architecture wouldn't require any connectors at all and would still enable communication. Also, we can't assume that most folks will be using factories for all of their drones. Just be being active here, we're identifying as a (somewhat obsessive) minority. *I see a lot of benefits to a range of these ideas, but you asked for a devil's advocate, and what devil wouldn't comply? 😁 Edit- mighta miss spoke on the cross talk bit. brb! Edit 2- yup, have to put the splitter farther down. My mistake Edit 3- mostly circumvented by using multiple factories though.