## terminal velocity part 1

Portals slow you down! Go figure.

A more in depth analysis:

Portals automatically drop your velocity to about 7.8 u/s (or 1000 game units/s) as you go through them, which is why your terminal velocity drops when you go through portals more often. Every time you hit a portal, your speed drops to 7.8 u/s. If you have less distance to fall after your speed drops, your speed has less time to increase. In the longer drops, you have more time to pick up speed, meaning your terminal velocity, as measured in this experiment, will be higher.

This video is meant to describe a way to quickly and easily run experiments in a classroom. Without knowing that portals affect your velocity ahead of time, this experiment would give students a strong indication that something weird is going on and the relationship between portals and velocity is worth investigating.

sv_cheats 1 (must be done first but only has to be done once)
host_timescale 0.001 (slows time to 1/1000 speed)
host_timescale 1 (brings time back to normal)

## 4 thoughts on “terminal velocity part 1”

1. Ehsan Kia says:

Out of curiosity, how do you start/stop the timer? Because if you’re doing it on the spot, there will be an uncertainty of roughly 200ms, which corresponds to 0.83u/s or 2m/s, and your error bars will be overlapping. Maybe getting a couple more loops in there would’nt have been bad ðŸ˜‰

Great analysis though. I just went in hammer created a huge pit and did a couple experiments. To get from 0 to 3500u/s (terminal velocity), it took me 10200u and 5.83s. From this, I also tried getting back to gravity with both g = v/t and g = v^2/(2*d) and they both got me to roughly 600! ðŸ™‚

Feels good!

• cameronwp says:

The timer on the screen is more or less there for the fun of it. I did the actual timing with a real life stopwatch. I came to those times after doing five or six trials at each height and taking the average. But you’ve got a good point about the error bars. This is an experiment worth doing in a more precise manner.

I’m glad to hear the game is internally consistent when it comes to terminal velocity and acceleration. Do you know if terminal velocity is handled differently for entities? If you don’t beat me to it, I’ll probably do some experiments tonight to find out.

• Ehsan Kia says:

Well first off, falling side by side, it’s obvious that the player falls much faster.
Again, side by side, cube falls faster than ball.

Can’t quite explain why though. sv_massreport says cube=40kg, sphere=75kg and player=85kg. Also logically sphere is supposed to be more aerodynamic.

Couple experiments later:

– The portal 1000 velocity cap also applies to entities
– Cubes terminal velocity is ~2000, where as the sphere’s is ~1700
– The other 4 cubes which are all of mass 40kg follow the same physics laws
http://i.imgur.com/2ZWFo.jpg (Here they are after a 32000 unit fall)

I’m gonna try to get more entities of varying weights and see if I can find the underlying formulas for this.

• cameronwp says:

It’s curious that spheres are slower than cubes. It sounds like a nuance of the game engine.

I’m curious to see what you find about the way other entities fall. I’m hoping there’s some type of relationship between mass, shape and terminal velocity.

I’ve got a really neat experiment coming up for tomorrow’s video. After that, I’d like to figure out a way to quantitatively answer how your acceleration changes as you approach terminal velocity. Do you think it’d be easiest to just use a mix of a really long fall with host_timescale and cl_showpos? Know of any quirks with cl_showpos and the way it reports velocity?