Konchog

Hi yes - this is a bug not a feature!! I too want this bug to be fixed 😉 It’s been reported as a bug.

So, currently the VTOL rotates within the block, and doesn't turn the block at all, just the direction of thrust. I would really love to see the VTOL have an option (even an input) to lock the block, so that the block rotates with the engine too.

It's not so hard to build an auto turret... here.. turrets.drn

I actually have mixed feelings about this. It would definitely be good to have some number-based work (eg. decrements / foreach are a pain) - and the ability to access switches/variables as inputs, rather than build-time settings would be sweet - but I really like the 'scratch' style of using logic parts. However, I think we do need logic container parts - (along with component libraries) - and then we can work on our own cool logic modules without having to breakout into code. I code for work 40+ hours a week. I would then want an IDE, and a RT debugger and an oscilloscope.. Would just begin to be a different game... There's some awesome physics engines out for that sort of stuff.

I put this as a feature request.

The wiki is improving a lot. But yes, adding a tag binding tutorial would clear a lot of confusion - and it’s pretty hard to use keybindings ever again..

No rules - just fight to the death...

Top of my list

Being able to group and classify drones (and drone libraries) would be awesome.

I don't think I want to see a priority switch for this - but just being able to use linkage would really help - either the closer to the core, or the closer to the appropriate engine, so that there's a clear rule which can be used.

Much that I don't mind having '0000s of tritium, the economy doesn't really work with programmer captain, because lots of what you normally pay for comes free. I'm not suggesting that parts should cost - it would kill development - but maybe reduce the amount of tritium to be mined?

Well, just being able to see the primary linkage tree would be really useful, Micha. We can already select multiple parts by choosing a parent/ancestor node. Maybe with a simple arrow overlay view, is all is really necessary.

This has been suggested by Micha too.. It's got to be the most important feature I can think of.

You get my vote for this - though just keeping the timer with what it was when I was last in would do the trick for me.

So with VTOL and directional sensor, the TILT/Steer is a straight heading to (or away) from the target. However, and especially with planets, terrain, (and racetracks) - this is far from being the optimal course. This becomes especially relevant when trying to get to an objective the other side of the planet. In the real world, digging through the centre of the planet is about the least efficient way of getting from Switzerland to New Zealand. So, in Nimbatus, the ability to switch between 'course' and 'heading' would be really useful. Course involves avoiding climbing out of gravity holes, tunnelling through terrain, etc. Otherwise, we have to build large drones just do deal with the course logic.

If you add arms to your mother drone, you can drop off your sub-drones so that they don't go straight into the container. If you are in Programmer mode, you will want to drop Resource Tanks into the container before doing anything else.

great minds...

Even if it comes at a cost (explosive value, low HP, etc), being able to contain larger logic components in a bag, or module would be super-cool, especially with more complex drone systems. It could have three regions (inputs, outputs, and internal), then it would be easier also to hide internal messaging (ie, have local variables) within the part, but keep external facing inputs and outputs available too...

This can be done using two proximity sensors. It's a bit of a faff - about 7 parts, but not impossible. turrets.drn

This is exactly what the Delay Gate does. https://nimbatus.fandom.com/wiki/Delay_Gate

This is probably the second-most important additional feature I can think of (whereas most of what I want is just tweaks). Being able to see what tag/key bindings are actually set to in the drone builder, and even better being able to see the activation network in the Testflight area would cut out a huge amount of debugging grind, which just isn't really very fun. The first-most important is what Micha has mentioned before - about being able to import/export subsystems - so one can develop a library of drone subsystems.

Both for weaponry and as a target in VTOL, 'Cursor' appears as a valid option when it is not. This gets to be really confusing.

Gravity / Cursor / Drone Core will disable secondary targets, but you cannot see that when choosing targets on VTOL thruster. The secondary target should be disabled if the primary is any of those.

An input that switches targets on the VTOL thruster would be really useful.

Some things can be seen but not targeted. It's confusing! It doesn't help, when there's a direction sensor which can only sense targetable things! Maybe this is a bug rather than a feature. It's not just confusing - it would be useful, for instance when making an autonomous mining drone, to be able to target resources.