[New build - EXPERIMENTAL] 20w47a: New Player Locomotion Modes

[tsunamayo]

The player locomotion has been streamlined. Now a simple Jetpack toggle key is used to switch mode.

New Features and Changes:

• Locomotion Tab is removed.
• Jetpack keybind added, F by default.
• In a gravity field player can switch Jetpack On and Off.
• In a gravity field Jetpack on will align the player to the gravity field.
• In a zone without gravity the jetpack will be automatically activated.
• In a zone without gravity the player can control its roll with the Q and E keys. (6dof mode)
• New tutorial starting zone to accomodate the change (Zone 1 removed)

Community Suggestion:

3219 6dof pivot around head.

Bugfixes:

3223 Lag after a few warps.

[tsunamayo]

Build is up! There was a lot of refactoring in this build, so please dont hesitate to report anything fishy! Thanks all!

[ZachZent]

A much better movement system. Much easier to use. One question, two suggestion, and one comment

Q: When in the grav field, pressing J turns on anti-grav mode and not jetpack like in the update notes. Is this intentional or is it supposed to be like the jetpack from the old locomotion system?

Thinking about it, having the anti-grav inside of a grav field works well if you need to build and don't want to break the grav gen. Perhaps in creative mode the player can go from walk to jetpack to 6dof/anti-grav inside a grav field while in survival you are stuck with just walk and jetpack.

---

S: Is it possible to have the player align to gravity and "chair alignment" when the player sits down on a seat go a little quicker? It starts off at a good speed, but the last few degrees takes an awkward amount of time. It is the same with going in a grav field. A smooth quick sit down and gravity readjustment may be a better option imo, though not sure what everyone else thinks.

---

S: Now that the movement system is more finalized (relatively), would it be possible to implement the R key rotate only on one axis and the T key switch the axis? The keybind is already there, the feature just needs to be added. That way if you go one rotation too far, you don't have to go around the entire circuit.

---

C: I hate bringing this up again but since this update is about movement and gravity becoming more important, is there a technical reason why gravity can't be set to the ship's bounding box, or some other entity detection in the F3 menu. Now with gravity becoming more necessary, I'm finding that grav-gen setup is even more annoying then ever before. For example, this carrier's hangar me and DaOyster are making is 83m wide at its widest point and about 25m high. The plan is going to have the hangar section be around 200m long (this is just one section we will be copying). That would require ~160 separate gravity blocks to cover the hangar completely. Who knows how much more for the rest of the ship that isn't hangars. Every single one needing to be placed and configured exactly as to not intersect with the next one and risk double gravity. And there will be good amount of the gravity field that is accessed outside of the ship. I can't even imagine how many grav-gens would be needed to perfectly cover the interior of the ship without the gravity bleeding to the outside.

Increasing the distance of the field, which is something you mentioned before, wouldn't really solve the problem, just reduce the number of grav-gens needed. Which is probably not as reduced as one would think if you want to minimize gravity bleed though. Something tells me future NPCs would be working well with scattered gravity fields, potential gaps, intersects, and if a player has spots where gravity goes a different direction. Either way, literal hours of tedious work that I'd, and I assume many others some with much larger ships, would rather spend actually building the ship.

[Garrett-C]

@ZachZent I have a question about the following point:

"S: Now that the movement system is more finalized (relatively), would it be possible to implement the R key rotate only on one axis and the T key switch the axis? The keybind is already there, the feature just needs to be added. That way if you go one rotation too far, you don't have to go around the entire circuit."

I don't quite understand what you are asking for here.

Are you suggesting that it should be r to rotate a block right and t should rotate it left?

Are you suggesting that it should be r to rotate a block right and then pressing t swaps the direction to left?

Are you suggesting that it should be r to rotate(in a fixed direction) and t swaps the face that it is rotating on?

[ZachZent]

R rotates the block to the right on lets say the X axis. T will switch the rotation to the Y axis. And vis versa. This is at least how I assume what the default bind intended to be. So #3

[Garrett-C]

Interesting to me it feels like it currently just alters the direction of rotation currently, which to me does feel like a better system.

I feel like swapping the axis would just result in you having to cycle the full way through even more. If you have a way to go back and forward then you don’t have the issue of missing an orientation and having to fully recycle.

[ZachZent]

Perhaps it would have been better as a question rather than suggestion. Before this update, I stuck with used Q and E for rotate as I never used 6dof. Now that I have to (which is not a bad thing) I switched to using R to rotate. I found that going over means that I can't go backwards (Q) but rather have to click 7 more times. Worst even is if you are building and constantly switching between two axis, you would have to press R another 7 times to place even one block before going changing then going around again.

Adding in the already existing bind would reduce it to only 3 clicks to go around only using T to switch between each axis you rotate. Not the best solution, but better than 7.

Old system: rotate left, rotate right (axis switch in sequence) Current system: rotate right (axis switch in sequence) Proposed solution: rotate right (only on one axis), switch axis "Best" solution: rotate left, rotate right (only on one axis), switch axis

[Garrett-C]

Oh did the rotate system actually change then, I haven’t seen him mention it. I use Q and E myself because I have the 6DOF keys as buttons on my mouse.

I would agree that the best system is having the 3 key binds.

Then I would order the rest best to worst as: Left and right. One direction and axis. One direction and no axis? (If that’s how it seems to work at the moment)

So what does T actually do currently?

[ZachZent]

Nothing, which was partly the point of the suggestion/question. Is it supposed to work like proposed solution, a forgotten bind that is no longer relevant, something new that is to be added but hasn't been fully implemented yet, or something else.

[Garrett-C]

Yeah that sounds unintentional. The bind should either do something or be removed honestly.

[tsunamayo]

Hi, sorry this is actually Experimental build and not default. thx

[tsunamayo]

So my target is: So T will switch the axis. There is 6 possible axis, the first one is the normal. Then R rotate right, and SHIFT-R rotate left. Thanks

[Garrett-C]

So my target is: So T will switch the axis. There is 6 possible axis, the first one is the normal. Then R rotate right, and SHIFT-R rotate left. Thanks

It will be rebindable though right? So if someone say wants to use r for right and l for left they could do so?

[tsunamayo]

Yes they will be rebindable. I still need to work on binding SHIFT+KEY though. @ZachZent thanks indeed I will tweak the rotation alignment formula and move away from the slerp. I will also give you that global grav generator! The old jetpack is gone, I just call the anti-grav jetpack now. Yes it is confusing, but not for new player.

[tsunamayo]

@ZachZent rotation alignment tweaked for 20w48a.