func_shaking

[Springheel]

Has anyone ever used this entity? The description says:

Shaking object. Starts shaking at map start by default. Triggering entity turns it on and off.

 

 

Does this entity make an actual model shake? Or does it make the whole screen shake like some loud noises do?

 

I'm wondering if it could be used to simulate a really unstable floor by shaking the player's view as they walk.

[motorsep]

Is this http://idtechforums.fuzzylogicinc.com/index.php?topic=365.msg3819;topicseen#msg3819 related to your question?

 

If so, no, it's not possible to make floating ship out of the box. However, with minor game code tweaks, you could do it. Basically you need for an entity that is being bound to the root entity via bind to copy its origin and angles. Then you can make animated (as func_animated) model of the ship and a collisions hull for it. Collision hull would be func_mover and you can bind it to the func_animated. Player's code works with func_mover (collisions) and func_mover will "float" with animation of func_animated.

[Springheel]

This isn't necessarily related to a ship. It's about making the player feel like they're shaking or bobbing by moving only the camera, not any geometry.

[motorsep]

Still not possible. The way camera shakes currently is by playing sound shader with shake key (https://www.iddevnet.com/doom3/sounds.php). You could try making sound with sine waveform, and cranking down its volume in the sound shader, and using looping/shaking keys, but I am not quite sure if such hack will work or produce shaking of the cam.

[Destined]

Try to have a look at the map "Thomas Porter 3: Glenham Tower". If I remember correctly, there is a shaky cam, when the player reaches the top of the tower. Maybe you can ask Sotha, how he did this.

[SteveL]

func_shaking makes an entity wobble, either a model or an fs created in DR. I don't think it could make the camera bob during normal play.

 

It'd be possible to script moving the player (and therefore the eye camera) around, but it probably won't work if the player has to move around normally at the same time. The wobble script would probably get the player stuck in the surrounding geometry.

[motorsep]

Or you could mess around with view cvars via script to make view move

[Springheel]

Collision hull would be func_mover and you can bind it to the func_animated.

 

 

Would the same principle work if you bound a func_mover to a func_pendulum or func_bobbing?

[motorsep]

 

Would the same principle work if you bound a func_mover to a func_pendulum or func_bobbing?

 

Yes, if you modify binding functionality. Currently the way binding works is that bound object will only change location, but not rotation.

[SteveL]

 

Yes, if you modify binding functionality. Currently the way binding works is that bound object will only change location, but not rotation.

Are you sure about that? Keys bound to AI rotate correctly as the AI moves, for example.

[Springheel]

I did a quick test binding a simple func_mover to a model that was bound to a func_bobbing entity, and the results are promising. The player moved correctly with it, and movables did too--at least until you stacked two movables on top of each other--then the bobbing was interrupted. That was to be expected, though, since the same thing happens to elevators and doors.

[motorsep]

Are you sure about that? Keys bound to AI rotate correctly as the AI moves, for example.

 

Maybe you guys already had it fixed in TDM. I recall we didn't have it working right and had to fix it in the Storm Engine. Or maybe it worked fine with entity>bone, but didn't work with entity>entity binding. I don't recall by now.

Edited January 30, 2016 by motorsep

[Springheel]

Doors attached to a func_bobbing seem to work properly, but oddly their sounds are extremely muted--so muted you can't hear anything but the loudest noises.