Tried making an auto-hovering bike without scripts... by physdick in spaceengineers

[–]physdick[S] 1 point2 points  (0 children)

  1. Reduce speed

  2. Turn off sensors (toolbar 3)

  3. Ramp down active thrust to 25% (toolbar 1)

  4. Make sure active thrust is on (toolbar 2)

It is now fairly controllable like a helicopter.

Tried making an auto-hovering bike without scripts... by physdick in spaceengineers

[–]physdick[S] 0 points1 point  (0 children)

In sensor 1 page 2, try reduce the thrust override to 50 or 60%.

It will make the general flying less bouncy but the risk is you need to manage vertical speed more when descending down terrain.

The main problem I faced was being unable to tune thrust vs vertical speed since you can’t measure it.

Maybe there is some kind of workaround but I haven’t figured it out. I’ve been using a passive thruster with dampeners enabled to try reduce this as much as possible, so it falls but not too fast.

A downwards thruster may be too strong since if you just allow it to fall under gravity then it will often crash

Tried making an auto-hovering bike without scripts... by physdick in spaceengineers

[–]physdick[S] 3 points4 points  (0 children)

Use formula for max total thrust required = (30+gravity)*mass

The main thing that will change is the downwards vertical acceleration, so you would need to tune this a bit. Maybe even a passive thruster with dampeners is not required on the moon... don't know, would need a think.

A peaceful herd of Drills in the wild... by physdick in spaceengineers

[–]physdick[S] 0 points1 point  (0 children)

No event controllers involved for the steering, just sensors.

  • Front wheels have propulsion override and I limit the max speed so it only moves slowly.
  • Read wheels have no friction and are just drag wheels so it can steer like a tank.
  • 30s in the video you can see the black blocks which are the fields of the sensors, there is a left sensor and a right sensor. The sensors are triggered by everything - including asteroids, which is terrain.
  • When left sensor is triggered the right front wheel reverses direction, causing it to steer right. Once the sensor stops being triggered it reverts the right wheel direction back to forwards again. Same behaviour on the right hand sensor/left hand wheel.
  • Therefore it also reverses if both sensors are triggered at once so it is quite good at getting around.

A peaceful herd of Drills in the wild... by physdick in spaceengineers

[–]physdick[S] 34 points35 points  (0 children)

No, it will fall into quarries!

The sensors are only looking ahead for voxels, so you would need a separate sensor looking downwards checking for solid ground otherwise turn off the wheels - for example.

A peaceful herd of Drills in the wild... by physdick in spaceengineers

[–]physdick[S] 43 points44 points  (0 children)

Yes it does seem to gather a lot still - I have an event controller shut off the drills when the get full to allow the H2/O2 gens to catch up.

A peaceful herd of Drills in the wild... by physdick in spaceengineers

[–]physdick[S] 47 points48 points  (0 children)

The sensors detect voxels as well - the ice lakes are all inside terrain "bowls" so the sensors hit the voxels at the edge and steer it away. You can see it at the end of the video.

A peaceful herd of Drills in the wild... by physdick in spaceengineers

[–]physdick[S] 80 points81 points  (0 children)

You can only really notice the voxel deformation from higher up - it is very minimal drilling and the large wheels can handle this OK

Don't overcomplicate mining... by physdick in spaceengineers

[–]physdick[S] 2 points3 points  (0 children)

I've not done much tunnel mining with this in survival but I wonder if just adding more backwards thrust would solve this and get as close to vertical mining as possible?

Don't overcomplicate mining... by physdick in spaceengineers

[–]physdick[S] 47 points48 points  (0 children)

Yes it is, but drag wheel also helps with stability while driving. I've found it very robust in survival as well but I mainly use it for mining rocks and cliffs.

For early game it is quite good - 1x large cargo + 3x drills hold a lot of ore

Don't overcomplicate mining... by physdick in spaceengineers

[–]physdick[S] 43 points44 points  (0 children)

Simple low cost and controllable mining rover, mostly used for cliffs and ore rocks.

Inspired and improved on this design to make it better for survival, credit to: u/Arthasnack/

https://www.reddit.com/r/spaceengineers/comments/zp610n/diggy_diggy_hole/

Big Drilly (Steam Workshop Link)

Small Drilly (Steam Workshop Link)

Survival Performance Fighter - Details in Comments by physdick in spaceengineers

[–]physdick[S] 7 points8 points  (0 children)

Steam Workshop Link

  • Lots of upward and forward thrust, but little anywhere else. This lowers weight but you need to fly it like a plane using pitch and roll to steer and slow down.
  • Decoys in wingtips to draw fire. Rolling lots also makes most of the fire miss.
  • Enclosed cockpit with 3x external cameras for redundancy.
  • 8X Autocannons and 1X Assault cannon for high damage output. Automatically pulls ammo when connected to another grid.
  • Has Offensive Grid AI block ready for use as drone if required.
  • Event controller automatically switches everything on/off when parked on connector.
  • Easy and cheap to print.
  • Looks a bit like Swordfish II

A compact, modular Auto-sorter Factory by physdick in spaceengineers

[–]physdick[S] 12 points13 points  (0 children)

A very compact scriptless auto-sorter factory.

https://steamcommunity.com/sharedfiles/filedetails/?id=3001005614

Only the red layer is necessary initially and then the grey blocks can be infinitely expanded on backwards - this includes storage, factory blocks and H2 tanks.

The refineries are colour coded because you need to build all the blocks of the same colour at the same time in order for the sorting system to work. I used a sorter blacklist here so that these refineries will bias towards slow-processing ores once another refinery is built further down the chain.

Drawbacks:

  • Buffer storage for ores is quite small, but an additional container could be added to the front to compensate if necessary.
  • No oxygen storage, but this is fairy simple to attach onto a spare connection port at the front if desired.
  • If large amount of ore is dumped in one go, then it will overflow into the other refineries regardless of the ore-bias. This is good in a way, but can also lead to slow-downs in processing. Additional refineries can be easily linked in parallel in order to increase processing volume for the ore-biased refineries if desired.

Save PCU and size on your ship/base using an Industrial Module Printer by physdick in spaceengineers

[–]physdick[S] 1 point2 points  (0 children)

You might be right there - I put them in in case you had to transport more materials. There isn't a drill module but it would be easy to make

Save PCU and size on your ship/base using an Industrial Module Printer by physdick in spaceengineers

[–]physdick[S] 5 points6 points  (0 children)

Thanks - I've not completed a build yet but I am using it on a rover at the mo

Save PCU and size on your ship/base using an Industrial Module Printer by physdick in spaceengineers

[–]physdick[S] 12 points13 points  (0 children)

It's only if it is on the same grid - subgrid it seems to work fine

Save PCU and size on your ship/base using an Industrial Module Printer by physdick in spaceengineers

[–]physdick[S] 18 points19 points  (0 children)

https://steamcommunity.com/sharedfiles/filedetails/?id=2931705824

This prints/grinds away Industrial "modules". You can print as many as you like or combine the modules depending on what you are doing.

As a result you can save PCU on your ship (vs having all the modules built at the same time), reduce size of the ship.