So while I'm investigating this as a possible solution to another problem I'm having, I was unable to find anything on it through the forums and thought I'd ask.

Is there any way to give the player flying controls to let them move around a simulated zero-g environment? Or to get something like Observer controls, but as a player?

Thanks very much for any help!

The only way I could think of is either using a perfectly clear, fogless, and ripple-less water texture through the entire map, or you could turn on noclip and then put trigger_catapults inside the walls, launching you back into the map at a very low speed.

You may be able to create a giant trigger_gravity around the chamber with the gravity set to the lowest you can, and then put a bunch of trigger_pushs around the player, each turning on and off with a game_ui. You'll also have to somehow move those triggers with the player, so maybe a logic_measuremovement to do that. Honestly, I have barely any clues on how to use those entities, so hopefully another user will know what I'm trying to say and say it in an understandable way. :/

A trigger_gravity, to my knowledge, allows you to invert gravity if you're in the trigger, but making it have zero gravity is impossible with that trigger.

(double post mistake)

Arachnaphob wrote:
You may be able to create a giant trigger_gravity around the chamber with the gravity set to the lowest you can, and then put a bunch of trigger_pushs around the player, each turning on and off with a game_ui. You'll also have to somehow move those triggers with the player, so maybe a logic_measuremovement to do that. Honestly, I have barely any clues on how to use those entities, so hopefully another user will know what I'm trying to say and say it in an understandable way. :/

This is actually working pretty well so far! (Though rather than the trigger_gravity, I used a phys_thruster pointed up to directly offset gravity) I managed to create a func_physbox, then use a set of phys_thrusters controlled by a game_ui to get it to move around. Forward, back, strafe, all work perfectly... but I'm getting stuck on the looking.

I have thrusters that can turn it in all directions properly, but how to I fire them? How do I get it to turn with the player's mouse input? I tried using all of the different Axis commands from the game_ui as a SetValueCompare input into a logic_compare, but that didn't seem to work. Any thoughts?

EDIT: I've now seen multiple tutorials that do this via the XAxis and YAxis inputs from the game_ui into compares just like I have, but mine aren't working at all, and I can't seem to figure out why. It's quite frustrating.

Use a point_viewcontrol, that'll let you lock the player in a position while allowing them to look around.

TeamSpen210 wrote:
Use a point_viewcontrol, that'll let you lock the player in a position while allowing them to look around.

I'm not sure I understand... the point_viewcontrol is for locking the player's view, correct? So they wouldn't be able to look around, because their view would be locked to the point_viewcontrol camera. Does it need to be set up in a certain way?

EDIT: After attempting it, I think that mapped the XAxis and YAxis inputs from the game_ui to my WASD keyboard controls, meaning I can't strafe... I thought the Axis inputs were from the mouse? :\ Is there a way I can get my game_ui movement controls on WASD, and the Axis inputs from the mouse at the same time?

Sorry, I meant a point_viewproxy. It's similar, but lets you look around. It's used in the tube ride scene and the hotel room in singleplayer.

TeamSpen210 wrote:
Sorry, I meant a point_viewproxy. It's similar, but lets you look around. It's used in the tube ride scene and the hotel room in singleplayer.

I actually tried a point_viewproxy too, in case you did. However, I got essentially the same result - WASD was now giving Axis input and controlling my look, and my mouse did nothing. Is there something in the setup that I'm just missing? It doesn't seem like the way that actor should work.

EDIT: Okay, I didn't have the info_target for the Proxy Entity set up properly. So now I can look around. Unfortunately, I still can't figure out how to make that looking control my thrusters. XAxis and YAxis are still only responding to my WASD controls. So how do I get mouse input to actually fire off these thrusters?

pressedattack1
pressedattack2
unpressedattack1
unpressedattack2

You should be able to either parent to the "eyes" attachment on the "!player" or use a logic_measure_movement (try both) to make something basically float in front of the player. If that's a phys_thruster, it'll probably push you around correctly. Test it first with a prop_dynamic beans can or something else small and visible. (You'll want to place it where the player spawns in, and do the SetParentAttachmentMaintainOffset from a trigger - that actually triggers slightly earlier compared to logic_autos).

Logic_measure_movement will get you more accurate eye-following than the attachment, and it will work consistently no matter what model is used.

I think I understand... thank you guys so much!

One more question, if I may - right now, the phys_thrusters don't actually affect the player, which is requiring me to do a lot of janky stuff that I'd much rather just simplify, and I think it's making my life more complicated than it needs to be. So how do you get these physics forces to act on the player properly? Right now, I'm listing !player in the Attached Object field, because I don't see an option to set that through a trigger after the level starts...

You can put the player in a physbox "cage", I suppose, then attach thrusters to that.

Many, many thanks again to everyone for all the help! I've got the system mostly set up, but I'm having trouble incorporating the pieces.

I'm moving a func_physbox (Hoverbox) around as a proxy for the player. It has phys_thrusters attached to it that fire via a game_ui, and are set to Ignore Mass and Orient Locally. Additionally, I have a func_brush (test_base), set to Never Solid, with its axis in the center of the Hoverbox. Finally, I'm using a logic_measure_movement with the following settings:

Entity to Measure: test_base
Measure Reference: test_base, but set to !player OnMapSpawn by a logic_auto
Entity to Move: Hoverbox
Movement Reference: test_base
Movement Scale: 100
Measurement Type: Eye Position

This causes the Hoverbox to turn in place an follow my mouse look when the map spawns, like I want it to. However, as soon as I move (fire the thrusters), it snaps back to its original position (even though the thrusters are set to Orient Locally), disables the look movement from the logic_measure_movement completely, and very slowly drifts back to its starting location (where the test_base is). Once it gets there, I can mouse look with it again.

My problems are twofold:

1) How do I get my entire thruster assembly to affect the Hoverbox according to the Hoverbox's current facing? (ie, not reset back to its starting position like it's doing now)

2) How do I keep the mouse look controls from my logic_measure_movement while I'm pushing the Hoverbox around with thrusters?

Some notes: I can't parent the Hoverbox to anything, or the thrusters won't be able to move it. If I parent the test_base to the Hoverbox, nothing moves at all (I also tried a phys_constraint with similar results).

Update: So, I think the problem may be related to a Warning on the logic_measure_movement page on the developer wiki, in which it says "Does not properly update collision physics on the object being moved". I think this means that the visible model is turning with my mouse look, but the collision box is staying where it was, meaning that the thrusters are acting on the collision box that hasn't moved. Is there any way around this?

Also, this doesn't explain why it's slowly drifting back to the test_base. :/