Garheardt the Black

Crushing my enemies, driving their armies before me, and hearing the lamentation of their women. Awesome. (and what is best in life)

The current data on air pressure shared by the planet description is low-medium-high-very high. If air pressure is that simple, that could be achieved with four barometers connected to four timed logic blocks. Even less, if you want to get canny. A bit of data collection with an altimeter will tell you how long the timers need to set the thrusters. I can't bring myself to put "just" in front of thrust control. I've played too many reflex dependent games where consistency is the difference between victory and losing your controller in a field.

Howdy! In fire support mode, the big ship uses an altimeter and a directional sensor to maintain a stable altitude and attitude relative to the planet, while a second positional sensor tracks the position of my mouse and tells the lateral thrusters when to fire, so the ship will continuously adjust it's position to stay above the location of my mouse. The fire support weapons aren't connected to the defensive turrets. I simply leave their rotation on "cursor" so they continue to aim at my cursor from off screen. It's basic standing order is -stay above the cursor, maintain position, obliterate anything I click on. In free fly mode, the main ship is setup for WASD flight. It can do anything the fighter can do. It can also dig right through a planet at a fairly respectable pace. The only tasks it's unwieldy for are ones where indiscriminate fire is a liability or the ground is too hard to dig. For those, the fighter has more than enough capabilities to handle the job. For snake missions, if I'm feeling lazy, I can do a full throttle orbit of the planet with the fire support system activated and that usually handles it. On the turrets, my original design for an automated defense system didn't use fast spinning turrets and incorporated lasers. The question was how to detect an enemy and then use that information to get a weapon pointed at them. In real life, we typically use radar and spin them for greater coverage, so I'm spinning proximity detectors to emulate one. Proximity detectors don't gather enough information to direct a weapon that isn't already pointed at the same target, so the weapon is mounted on the radar. When the sensor detects a target, it tells the weapon to fire. The significant recoil on the weapon is mostly absorbed by transferring the majority of the force into spinning the turret faster, and the whole thing is enclosed to prevent environmental interference, making the system extremely stable. It's accurate, responsive, and stable. Thanks for the questions!

You can circumvent that with multiple barometers mounted to a detachable drone. Link each to an on-off switch that turns off the other switches when it activates. You can build as many barometers as you want to suit your taste, the more barometers, the more consistent the thrusters.

By the letter, an upright pinwheel closely resembles a rotary cannon, which is most definitely a turret, but let's go with your definition If the turrets you're familiar with are from video games, they are probably acquiring their targets artificially and wouldn't actually work in real life. If we're talking a real life modern turret, such as on a ship, those things are utilizing a whole flock of pinwheels from multiple sources. The CRAM anti artillery system is a rotary weapon with a huge aligned pinwheel sitting on it. A CRAM can mark an X-Y coordinate with it's radar for the weapon to acquire, while Nimbatus doesn't have that kind of fine control (or a Y axis). So instead, I'm using a pinwheel to mark an X coordinate and spinning my aligned weapon fast enough to make it omni-directional for instant acquisition. In real life, rotation isn't practical, but in Nimbatus, it enables the fastest, most accurate target acquisition available. Between studying radar counter strategies for Uncle Sam and the amount of time I put into developing my toy, I might be a tad sensitive about it 😅

I don't think a speedometer would be nearly as consistent. With a speedometer, the effects of momentum and gravity alone would cause your thrusters to be constantly changing their output to compensate, making low speed precision flying difficult. A barometer would simply click a setting the moment the level starts that adjusts your output. While both sensors could normalize top speed, I think a barometer could also normalize momentum.

But, but real life radar ARE spinners! If we sat down and built a radar guided weapon, the radar would spin. The spinning action of my proximity sensor is doing the same job a radar would; sweeping the target area and telling the weapon where to shoot. The only difference is that the weapon is mounted on my radar because it's more accurate with the in game physics engine. If that's not a turret, what is?

It's niche, but I could see this being very useful for consistency. If one were to do some program-fu, it would be possible to have dynamic thrusters automatically adjust their output for additional drag. If one activated self adjusting dynamic thusters like regular thrusters, so long as they don't top or bottom out, your thrusters would feel the same regardless of the resistance. If you're fine tuning an autonomous drone or performing tight maneuvers inside a planet, consistent output is important. Having this capability also opens the door for planets with dynamic pressure variances, such as what can occur in storms.

Nothing serious, I'm afraid. Although the combination of a few drawbacks unlocking a new top tier mod would tickle my fancy. Examples could be taking huge amounts of additional recoil to unlock a mod that supercharges projectile force, or reducing grenade velocity down to zero to unlock a proximity mine.

Gyaar! I thought it might be fun to create a thread for us to share our current projects with our fellow engineers. Here, we have a great deal more room to discuss our gear at length than we do in the workshop. So post your best/worst/fondest projects so the community can learn, critique, and help you improve! With that, I humbly submit my current flagship for your viewing pleasure: Features: -Automatic terrain avoidance -Full shield coverage -speed, Agility, and high stability. -8 automated defense turrets capable of dropping multiple tough enemies at full throttle when weapon fire is most inaccurate -16 long range fire support batteries -Fuel and energy reserves for extended engagements -Surprisingly effective digging -Hover mode -On board fighter bay with replenishing fighters -Automated Fighter launch sequence and bay doors. -Orbital Fire support mode X -Printed on demand "no frills" dedicated high capacity mining and recovery drone -Logic blocks remain with the docking drone for increased ship space The top photo features a hanger I've been working on, but it's looking like cpu performance may be an issue for now. I left the drone core in the ship so I'd eventually have the option to program the fighter to return and dock automatically. If I don't get around to it, I'll probably detach it into the ore box and automate the mining drone. Let me know what you think! I'm open to questions, critiques, and whatnot, such as how the turrets work. Till then!

I was kicking this around the other day and wonder'd what it would be like if damage related mods and utility mods had different slots. Lets say you get X mod slots for things like damage, attack speed, and quantity mods, then X mod slots(s) that can only slot mods that alter weapons but don't necessarily increase damage output such as recoil, accuracy, homing, and projectile duration. The reasoning: Some mods, such as projectile quantity or -80% energy cost, are far and away more powerful than things like recoil mods. With limited mod space, taking the weaker mods is rarely worthwhile. If the "sub-mods" had their exclusive slot, they'd see plenty of use.

Nevermind, figured it out!

Also, what do you use to make those sweet gif files of your stuff in motion?

Sure. I was considering starting a showcase discussion where folks can post some of their current projects for discussion and constructive criticism in a more detailed format than the workshop. Shall I post there?

It took a while, but I've worked out some automated turret designs that are not only stable, they're insanely effective. After seeing what they're capable of, I'm leery of changes that would make them easier to use.

So lets have an option to nix the boundary and free fly 😃

Hello again! I propose a version of the drone editor that combines the editing mode and the test flight mode. imagine being able adjust your precision timers without constantly jumping between modes? Imagine being able to pause your test flight to fix a mislabled thruster, then unpause and continue testing? No more having to note which part in which drone is causing problems before swapping modes. Additionally, there is the cool factor of getting to play with your new part the moment you connect it. tack on a bunch of thrusters, click a hot key, and watch it go! It didn't go? forgot to add a fuel tank? pop one on and try again without having to load a new interface! Oh, and the possible shenanigans of editing things while they're on. If anyone remembers getting their friends together and playing around with forge mode back in Halo 3, you get the idea. And you're a rock star. Thanks! Love ya!

I would personally like all of this. I do worry that this level of complexity would put off more casual drone engineers. Sadly, as far as triage goes, there may also be a lot of other quality of life tasks ahead of this nuanced kind of awesome. That said, if we are fortunate to see such detail, it may be wise to include a UI setting that hides it initially, but mentions it's existence in a tool tip similar to tags. This could allow users to ease into it without getting overwhelmed.

Fair enough. I had a photosensitive room mate who likely would have punched out if he ever saw a couple of my more laser heavy creations. My limited understanding is that seizure trigger frequencies can vary drastically, along with the color, contrast, and in some cases shape and motion. My condolences on the diagnosis. 😕

Thank you for the clarification, ManTheMister, that is what I was attempting to convey. These discussions can be as confusing as they are fascinating.

The OP referred to screen shake as a rave party. Rave parties have bright, flashy laser lights. Bright, flashy laser lights are fairly well established triggers. Nimbatus also has bright, flashy laser lights. I demonstrated a cool thing I made on Nimbatus to my mother. My mother suffers from migraines. I fired bright flashy laser lights. She /quit That was my logic train, at least 😅

Word.

This is probably the right topic to mention that fully upgraded lasers are fairly significant seizure/migraine triggers.

No worries! By my understanding of how logic works, parts perform two logic related functions: Parts periodically check the drone core for signals relevant to them. (barring a splitter) Parts add signals to the drone core as they are triggered. (again barring a splitter) ------------- So, my (convoluted) question was whether, rather than overhauling logic, if it would be more straightforward, at least short term, to create a part that prevents it's children from adding signals to the drone core. (thus creating parts that can view the signals in core stack without adding to them) Also whether your suggestion had additional benefits that I overlooked.

That would be great. It could also add a new element of depth to sumo.