Flying manatee flies through telephone wires?

Mr Neutron

Newbie
Joined
Sep 3, 2003
Messages
484
Reaction score
0
This may be old, but in the coastline vid, the flying manatee seems to skim the telephone pole wires without getting caught or affecting the poles. This made me wonder: can Source handle a complex chain reaction of telephone polls taking each other down domino-style?

Along those lines, I'm seriously puzzled about implementing physics in multiplayer. For everyone's world to remain consistant with each others', wouldn't all player movements at all times have to be sent to each client, and wouldn't the physics calculations anywhere in the map always have to be performed client side? Or does the server keep track of the physics and send object transposition to the clients after the fact? Is it a combination of these two such that the client calculates physics in its area but then gets updates about the objects in other areas when it enters them?

Some people seem to have adopted a priori the belief that Source physics works just like the real world e.g. 'I'm going to construct a particle accelerator mod and conduct physics experiments!' Suirley there's some complexity limit.
 
valve has said that in multiplayer that not everything is going to be serverside.

for example, small items or something will be client side, while big items will be server side.
 
Regarding the gunship question, I'm sure it could be done, but probably wouldn't be done under most circumstances for performance reasons. Try e-mailing a Valve staffer and see if they can shed any more light... I think it's an interesting question.
 
Mac said:
valve has said that in multiplayer that not everything is going to be serverside.

for example, small items or something will be client side, while big items will be server side.


Thats true but is in no way connected to what the thread starter is describing.

As with all E3 presentations there are bugs, this one is hardly very important but knowing valve it will get fixed.

Searching through the forums shows quite a lot of bugs in the demos...

from lighting to shadows to NPC's to clipping to sound....

its just that HL2 fans are especialy paranoid and seek out every scrap of info in any official material.

:cheers:
 
This may be old, but in the coastline vid, the flying manatee seems to skim the telephone pole wires without getting caught or affecting the poles. This made me wonder: can Source handle a complex chain reaction of telephone polls taking each other down domino-style?
Im fairly certain it very well could because when creating a chain/rope/wire you assign it values (elasticity, slack etc) and attatch it to two objects, so in theory if something heavy like a telephone pole (you would edit its weight to make sure it was heavy enough) fell, it would either A: fall and hang a foot above the ground because its support (the pole it is attatched to) is stronger than its own weight or B: fall and the momentum causes the next to fall, and the next and the next.

Along those lines, I'm seriously puzzled about implementing physics in multiplayer. For everyone's world to remain consistant with each others', wouldn't all player movements at all times have to be sent to each client, and wouldn't the physics calculations anywhere in the map always have to be performed client side? Or does the server keep track of the physics and send object transposition to the clients after the fact? Is it a combination of these two such that the client calculates physics in its area but then gets updates about the objects in other areas when it enters them?
so far we are all clueless on MP, however Gabe has stated that physics will be in full force and that they are handled differently as follows:
to cut down on congestion Client side predictions are things like if a rocket knocks some cans/rocks/bodies/objects around that dont effect anything.
like say sammy's missile blows a ton of cans my way, but none hit me and none cause me damage. that is client side. (consider client side predictions to be nothing more than eye/game candy.. they dont make or break rules in the game)

server side predictions are things like, picking up a barrel and launching it at a player, it hits that player (this will be broadcasted as it affects gameplay)
also an object like a matress blocking a hole in the floor, would be considered server side.
anything that does affect the way the game is played.

Some people seem to have adopted a priori the belief that Source physics works just like the real world e.g. 'I'm going to construct a particle accelerator mod and conduct physics experiments!' Suirley there's some complexity limit.
of course there is, especially if you take it to such a detailed level, but you can trust me.. the physics work exactly how you expect, there is no game out there that can touch what Valve have done with the Havok engine.. you can see that Physics is a big draw, and one of the things they focused on primarily and it all works how you would expect.

Edit: bah damn you fast typers, so much for first post bleh!
 
Dougy said:
Thats true but is in no way connected to what the thread starter is describing.

As with all E3 presentations there are bugs, this one is hardly very important but knowing valve it will get fixed.

Searching through the forums shows quite a lot of bugs in the demos...

from lighting to shadows to NPC's to clipping to sound....

its just that HL2 fans are especialy paranoid and seek out every scrap of info in any official material.

:cheers:

he asked about multiplayer. read his post again. thanks. :cheers:
 
Of course physics interactions irrelevant to the game are calculated clientside. And of course everything game-vital needs to be handled server side lest cheats creap in. But do you really need to know what's happening on the other side of the map as it happens? No. So it would be more efficient if the new positions of objects are transmitted to you as you enter their proximity, not as they get moved. My question is, do you think this scheme is feasable?
 
Mr Neutron said:
Of course physics interactions irrelevant to the game are calculated clientside. And of course everything game-vital needs to be handled server side lest cheats creap in. But do you really need to know what's happening on the other side of the map as it happens? No. So it would be more efficient if the new positions of objects are transmitted to you as you enter their proximity, not as they get moved. My question is, do you think this scheme is feasable?

I dont see why not, it would make more sense to only calculate what is happening in your immediate area, especially in huge maps.. however we will have to wait and see how Hl2 handles netcode and physics in general upon release... since really all we can do at this time is speculate.

regardless your idea does indeed sound feasable, and one would think it to be the most prudent way to handle physics heavy situations.
perhaps you should send an e-mail to Rick Ellis about this?
 
About not being updated on things you can't see or hear... this is what PVS (potentially visible set) is used for, to calculate what things you can or can't see, and therefore don't need to know about.

I'd imagine that HL2 follows on with the same basic principles as the HL1 netcode of using client-side interpolation and prediction, along with lag compensation. Physics is calculated on both the server and the client to keep things smooth, with the server-side positions of things being imposed on clients as often as bandwidth allows in order that the client-side prediction and the server-side actuallity don't fall out of sync. And small objects and effects never have to trouble the server at all and can be totally simulated client-side only. I actually like the sound of this, it may be possible to throw round loads of pretty non-gameplay-effecting entities without lag.
 
if u kill some one and the way their body falls : arm bends to a 90 degree angle and it flies 3 feet 2 inches it would cause a lagg if all the details on everyones computer was the same so those kinda things will be client side
 
i have a bit of a question then.

Say im in a room with a rocket launcher and a hell of a lot of cans with my buddy duffman. i shoot the cans and they go everwhere. Since the cans are nonimportant, the physics for them is calculated client side. What does duffman see? Do they go different directions on his screen than mine becuase the physics calculations for him were slightly different?
 
Triggerhappy41 said:
i have a bit of a question then.

Say im in a room with a rocket launcher and a hell of a lot of cans with my buddy duffman. i shoot the cans and they go everwhere. Since the cans are nonimportant, the physics for them is calculated client side. What does duffman see? Do they go different directions on his screen than mine becuase the physics calculations for him were slightly different?

exactly, it isnt important for him to see the EXACT same thing as you, since those are non-essential to gameplay.. instead he will have a similar effect on his end, but not the same (not that either of you would know it)
 
But if there was something like a table or a barrel in the room, which are larger objects that can affect gameplay, the server would calculate the physics, so you'd see the object move in exactly the same way.
 
actucally I thought i saw a comment that if you do something to disturbe and object the server sends out the info to other comps and it does the computations, and if anyone alters the path that it will also be sent to other comps, which will then calculate again.
 
If beer cans can block fire, then they're not non-trivial.

I don't know what you mean by interpolation, which generally refers to a post process: you can't fill in between A and B if you don't know what B is because it hasn't happened yet. Do you mean prediction? Prediction might work, though in very complex situations, it could introduce big jumps even on non-laggy broadband connections. In some games like BF, players have momentum, so on-line games have a jerkiness even on the best servers because the server is second-guessing what the player thought he was doing. In general, I'm concerned that physics increases netload by orders of magnitude. The bandwidth solution, I think, is for events local to the player (capable of affecting him immediatly--whether visually, audibly, or game-wise) to be calculated on both client and server with the server correcting events as they happen; for non-local events, the world would be updated for the client when that part of the world becomes local to it. Remember: divergence is introduced by lag, and lag is always present to some degree. So I think the more separate objects (each with its own transformation data), the higher the potential bandwidth usage when things get knocked around. The problem with this scheme is that it means the server does physics calcs for every game-relevant object. Isn't server cpu load already a problem with newer games? I'm thinking of BF, which itself has (less sophisticated) physics.
 
If an object needs to be calculated server side, the only properties needed to be sent to each one of the players are: position, direction, velocity. maybe even axis values but i doubt about this one.
The server doesnt need to gather this information too many times, I'd guess once a couple of seconds, then update it to the players again.
If maps are built good enough, I do not see any reason for massive lags happen and ruin multiplayer games, especially when connections get faster and faster...
Correct me if I'm wrong
 
connections seem to be getting slower and slower around these parts. (australia)
 
Despite what everyone has said so far...

No one understands exactly how it will work. If youve messed around with some phsyics programs, then you know you dont have a problem until your processor starts calculating hundreds of objects at the same time.

So the domino effect should work with ease, figuring that since the telephone poles are so heavy, that by the time the 5th or 6th poll is falling, the 1st poll has already stopped. So youd get no more then 5 calculations at a time which can be done with ease.

Now if you wanted to make your telephone poles out of ruber, you might run into a problem.

But Valve will figure it all out, and what they dont get right in the release version, they'll easily update it.
 
Back
Top