Jump to content
Stray Fawn Community

Cool Nimbatus GIFs


Philo

Recommended Posts

Yes, I think the attracting magnets really help keeping it from wobbling. I'm happy with the timing of the landing engines and landing legs, but of course the timing is not always perfect under higher or lower gravity.

 

[Edit] Falcon Heavy will work.

 

ForsakenKaleidoscopicDikkops-size_restricted.gif

 

 

Link to comment
Share on other sites

Nimbatus1

Nimbatus2

 

I actually didn't like the lasers. I had found some that were labelled '+150% range after time' or something  (+ less energy cost, increased damage and damage to terrain.. basically everything good) and thought they'd be better than some of the other things I had. So far nothing has beat pure plasma rocket shotguns + mouse-seeking bio rockets shotguns. The gifs are pretty big so I'm just going to URL them. Anyone know how to make a hyperlink open in a new tab?

Link to comment
Share on other sites

I wish I had those upgraded lasers your describe.

 

The gifs are pretty big so I'm just going to URL them. Anyone know how to make a hyperlink open in a new tab?

This should be in your browser settings. They open in a new tab for me.

 

Link to comment
Share on other sites

Oh yeah so they do open in a new window, neat.

 

Honestly the lasers range though makes them much worse than rockets... rockets can be destroying what's in front of you as well as a large swath of land far away from you, and you can just outrange anything with enough solar panels + rockets. I was doing tests to see how fast I could destroy planets, and I haven't come across anything that beats rockets yet. In fact I kinda want to dig through the files to find that specific launcher... I got it really early on in the game and it's the most powerful thing that generated - I want to see the full stats of it. Anyone know how to go about doing that? Hm I'll look into it tomorrow anyways.

 

Bonus gifs of my old craft:

OldShip1

OldShip2

OldShip3

Lasership1

Lasership showing low reach lasering

Link to comment
Share on other sites

Lasers are great, for the right thing.  A short-beam laser is great for clearing terrain. (wider beam misses fewer specks.)  A long-beam laser with a push upgrade and maybe a range upgrade can keep exploders at bay, and their range is so long I can't see the end of them.  Exploders can damage you through shields and are hard to handle autonomously, so they're my drone's nemesis.

 

Towers aren't great on terrain because they all waste effort focusing on the terrain under your cursor.  Fixed banks of lasers will serve that better.  I have a number of surface-roamers whose task it is to destroy all planetary mass.  The best solution I've found for it is a bank of downward-facing lasers.  Long beam, range upgrade, digging. (If I had a dual beam/digging/long range epic, if only.)

 

As always-on weapons, they're not as damaging to enemies as some other things, and I find myself okay with that.

Link to comment
Share on other sites

I've made a jellyfish that kinda behaves like a jellyfish when it flies or hits a wall.

 

DiscreteDisgustingArrowworm-size_restricted.gifSlowSpicyCoelacanth-size_restricted.gif

CircularMagnificentJavalina-size_restricted.gifImmaterialRareBasenji-size_restricted.gif

HelplessHardtofindCollie-size_restricted.gif

 

And a video here that shows a little more: https://gfycat.com/gifs/detail/NimbleUnfoldedGyrfalcon (the video feels good when played at 2× speed on gfycat)

 

Of course it's not very efficient to clear planets (although it is not useless either). Building the logic parts was a nightmare, it doesn't seem like much, but I think all the keys of my keyboard are bound except Tab, there were so many exceptions I had to deal with to make the tentacles spread and behave correctly.

  • Like 2
Link to comment
Share on other sites

I've made a jellyfish that kinda behaves like a jellyfish when it flies or hits a wall.

I like it.  Try turning off that gravity sensor, and see if those . . . outriggers?  Will tip it over and climb the wall.  See if using hinges instead of thrusters for their attitude control works.  As long as they return to downward-facing when not under thrust, and the hinge doesn't stress the hinge so much that the whole thing explodes the moment you use it, it might just work out.

 

How much logic do you need?  It looks like you could manage with less than twenty keys and less than ten blocks, but I'm only basing that on what I see. 

 

I've used up to two keys and two blocks each for WASD before. That's 8/8.  Weapons.  Shields need a key and maybe a block for the toggle.  Magnets might need two keys, the toggle for repel, and if not repel, then attract, twelve keys, eleven blocks.  I assume the detectors keep it aloft if it's near terrain?  These can directly link to upward thrusters though, so they shouldn't need extra keys or blocks.  Each sensor on the pod needs keys, but they can be a direct link, and you can use disconnect blocks on each of those to duplicate the key selections without them triggering each other.  Assuming you didn't, that's three sensors directly triggering thrusters - six more keys for a total of 18 keys, 11 blocks.

 

I find keeping a notepad of my logic helps a lot.  My thrust looks like:

Thrust forward, left side: Numpad 4

Thrust forward, right side: Numpad 5

Thrust back, left side: Numpad 1

Thrust back, right side: Numpad 2

W: n4/n5

A: n1/n5

S: n1/n2

D: n4/n2

Link to comment
Share on other sites

You can get some pretty interesting results using dynamic thrusters. I've created a drone that essentially increases thrust until it is equal to gravity, at which point it maintains power. The effect is your ship is hovering in place despite the effect of gravity. There is a second set of thrusters as well if you want to move up or down, and these do not affect the dynamic thrusters. If you watch the background grid in the gif below, you'll notice that the ship starts out falling but stops completely.

 

vA2tf2Z.gif

 

I've saved the base logic system, which I'll attach below in case anyone wants it. Sadly, it tends to have slightly more upward thrust than gravity has downward pull, but this effect is less noticeable as the drone gains mass. When the base logic system alone flies, it will have a noticeable upwards movement, but when the drone in the gif above is flying, you can't detect any upward force because of how massive the ship is.

**To activate the logic system for the dynamic thrusters, you have to press Alpha4(4, located above E and R)**

HorizontalLockBase.nimbatusdrone

  • Like 1
Link to comment
Share on other sites

I've made a jellyfish that kinda behaves like a jellyfish when it flies or hits a wall.

I like it.  Try turning off that gravity sensor, and see if those . . . outriggers?  Will tip it over and climb the wall.  See if using hinges instead of thrusters for their attitude control works.  As long as they return to downward-facing when not under thrust, and the hinge doesn't stress the hinge so much that the whole thing explodes the moment you use it, it might just work out.

 

How much logic do you need?  It looks like you could manage with less than twenty keys and less than ten blocks, but I'm only basing that on what I see. 

 

I've used up to two keys and two blocks each for WASD before. That's 8/8.  Weapons.  Shields need a key and maybe a block for the toggle.  Magnets might need two keys, the toggle for repel, and if not repel, then attract, twelve keys, eleven blocks.  I assume the detectors keep it aloft if it's near terrain?  These can directly link to upward thrusters though, so they shouldn't need extra keys or blocks.  Each sensor on the pod needs keys, but they can be a direct link, and you can use disconnect blocks on each of those to duplicate the key selections without them triggering each other.  Assuming you didn't, that's three sensors directly triggering thrusters - six more keys for a total of 18 keys, 11 blocks.

 

I find keeping a notepad of my logic helps a lot.  My thrust looks like:

Thrust forward, left side: Numpad 4

Thrust forward, right side: Numpad 5

Thrust back, left side: Numpad 1

Thrust back, right side: Numpad 2

W: n4/n5

A: n1/n5

S: n1/n2

D: n4/n2

Thanks for the kind comment!

 

There is probably room for optimizing it, but I don't think it could be simplified this much while keeping the same flexibility. For instance, I did not want the sensors on the tentacles to have any effect on the main body when the tentacles are retracted, otherwise it would trigger the tentacle engines and impede movement for no reason, so I couldn't use a direct binding between sensors (3 per tentacles) and said engines, yet I wanted the lower engines to ignite in concert with the main body when retracted so that they can contribute to the thrust of the whole drone... But not when extended, because tentacles have to stay extended regardless of the drone movements. You'll notice also that the main body is keeping level when tentacles are extended, but can be moved freely in the "travel" form with retracted arms. All these little exceptions really add a lot of complexity to logics when you only have AND/OR/XOR gates. :<

 

I also wanted tentacles to extend evenly and react to obstructing terrain in two different ways: first, if the terrain is not too difficult, then the tentacles stop overextending laterally to avoid bumping into it, and instead they slowly go upwards to try passing over the terrain barrier before extending again behind it and continuing progression if successful. But if the terrain is too difficult, then the tentacles have some kind of reflex movement, quickly retracting under the body and not extending back again until the obstacle is passed (this needs jump drives, and therefore an impulse logic). This keeps tentacles from jumping all the time as it would be annoying and could get messy with the spring or bump into other parts, but still make them have this "natural" behavior that I wanted, only when necessary. All this had to be lateralized, so I could not use the same sensors, keybindings and logics for both sides. This behavior should make climbing walls unnecessary if the proximity sensors are set to appropriate distances: the jellyfish will just pass over terrain irregularities, and so will the tentacles, while keeping the overall extended form. Climbing walls would be for another drone I build previously that hovers at low altitude. This one can retract the tentacles and fly easily if really necessary.

 

Also, I needed the gravity sensors because all the movements I've configured on the tentacles made them wobble too much with just a free hinge, it was not good. It would be OK if they were more passive, but I really wanted them to be more than just weapons hanging on springs. The engines are necessary to maintain them horizontal but it's not a big loss because all those thrusters have secondary uses, be it extending the springs vertically and horizontally, reacting to obstacles (I cannot retract tentacles without bumping into the body if they are not overextended thanks to downwards thrust in the first place), or supplementing the overall thrust when retracted.

 

I wanted some automation as well, which is not all shown in the video, but adds some logic parts. Again you're right that it can probably be simplified here and there, but it would be a lot of work to review all the sensors, overhaul everything, and test again. I feel way to lazy for that now. :D

 

It still needs some adjustments though, the drone is far from perfect. With the absence of zooming feature in game, the current settings for the proximity sensors are very frustrating because you can't see the ground when hovering. I need to lower the altitude a little, but keep tentacles far enough from the body not to alter the overall shape too much. Very rough terrain can be difficult too, but this could be worked around with shorter tentacles and longer distances on their proximity sensors; it just does not look really good so I prefer the current setting even if suboptimal.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

That's an interesting way to form a circle . . .  the pulsation mystifies me.  That's some janky physics.  Nice.

 

I'll have to see what I can do about treadlike things with captive springs - I suspect they'll slip between other blocks under tension, though.

Link to comment
Share on other sites

Anyone know how to find the game data I lost? Not sure what happened between last night and tonight, but I only have the items that I made last night. Could that be caused by having two instances of the game open by mistake? I opened two and used the first one that opened until I realized it opened twice. Then I closed the other instance and carried on...

Link to comment
Share on other sites

Exit to the main menu before closing the game out; I think that's the only time it saves at this alpha stage.

 

I worked on pistons a bit, too, but for a different use; I wanted to make it as part of a walker.  Limited success.  Changes to the impulse block are supposed to be considered, which will make sequencing and thus complex behavior like walkers easier.

 

The closest I got to a tread was a giant ring, using the drone brain and some mass blocks as an internal weight to roll the entire craft, interlacing some blocks so that an unconnected segment held together.  You might try something with springs captured in angle blocks, but your tread will be very heavy and I think any tread will be prone to stretching and slipping off its drive gear.  Also, treads can be broken, so chains of parts may not be the most robust build for them.

 

I think i'd prefer to have 'tread blocks' that, like motorized hinges, have controls to rotate forward and backwards, and are linked as a group.  Draw a line stretched between all tread blocks in this group that provide a CW or CCW force.  Dealer's choice as to how much work the devs want to put in making sure the treat can't be penetrated - I'd be happy putting some mass blocks (give us some lightweight mass blocks?) behind the tread to make sure stuff doesn't pass through, but if it can resist terrain and enemies passing through it, that'd be nice, too.

 

 

  • Like 1
Link to comment
Share on other sites

  • 2 months later...
  • 1 month later...
On 12/6/2017 at 7:32 PM, Lurkily said:

Remember I mentioned I was going to play with vectored thrust?

 

This is small and unstable (probably in part because of low mass,) but it works, it freaking works.  Thruster rotation looks herky-jerky because I use the impulse logic to slow down rotation so I don't get constant sway with the gravity sensors.  0.2s delay, 0.1s rotation.  Less responsive leveling out, but it works better.

 

Now I just have to figure out how to make it work without gravity sensors, so that it can navigate walls and ceilings.

 

The drone is attached.  Hit tab to engage automatic roaming.  Be aware if it comes up against a cliff, if can and will go into an uncontrollable spin.

 

Guns face backwards because it's fast, and I want it outrunning the explosive units when they detonate.

 

https://i.imgur.com/Qu40xrQ.gif

Qu40xrQ.gif

Example.nimbatusdrone

You still have this drone to share? or could you tell me some of how you made it? This is my favorite drone out of this thread.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
On 4/22/2018 at 4:22 PM, Momiro said:

You still have this drone to share? or could you tell me some of how you made it? This is my favorite drone out of this thread.

Sorry!  I fell out of the forum for a while.

I don't still have it, as the old saves don't work.  I can tell you how I made it, though.

 

I put thrusters and an orientation sensor on a hinge.  I used an impulse giver and some AND logic so that the hinge's rotation turned half as fast - that's why it's hurky jerky, the hinge is on-off-on-off in half-second increments.  The sensor is downward-facing when the craft is level.  If it gets close to the ground, it turns the thrusters counter-clockwise at full speed - this boosts that part of the craft upwards.  Then the thrusters level off more slowly.

The logic required is that the impulse giver gives an output of (for example) A, the orientation sensor gives an output of either B and C on the left sensor.  If B AND the impulse are active, turn the left hinge one way - if C AND the impulse are active, turn it the other.  If the Directional sensor is tripped, activate the hinge directly.  Same setup for the right thruster.  If I recall, they are independent in this example.

 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...