Zero G flight?
pressedattack1
pressedattack2
unpressedattack1
unpressedattack2
Aperture Science: We do our science asbestos we can!
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).
[spoiler]- BEE2 Addons | (BEE2)
- Hammer Addons
Maps:
- Crushed Gel
- Gel is Not Always Helpful[/spoiler]
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. :/