Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
For future reference: turns out it *was* the linux build. Source doesn't
seem to like gcc 4.2.4 - built fine, but with a few vphysics quirks as
said below. I rebuilt with gcc 4.1.2 and the 90° snap issue was gone.
Makes me fear though what other kind of bugs are due to the gcc version,
and what gcc version finally is the way to go, if there is any :)
On 20/02/2011 16:04, Maarten De Meyer wrote:
No no, I'm fairly sure it's not me :D I beyond-compare'd anything
between prop_physics and the engine, no relevant changes on my side. I
still think it'll turn out to be an issue with the linux build - eg
gcc version can be a factor too, although we're on 4.2.4 so we should
be good. If I end up not finding it at all I'll compile a clean OB mod
on my linux machine or something and work from there, but hope that
won't be necessary.
On 20/02/2011 15:39, Tobias Kammersgaard wrote:
Sounds like you need to check previous revisions of your code to be
honest.
- ScarT
On 20 February 2011 14:18, Maarten De Meyer <mailto:maar...@off-limits.be>> wrote:
Found out another piece of interesting information. When we drop
weapons, we give them the direction of the player to make the
drop look realistic. This has always worked decently. On our
linux server, the dropped weapons - also physics objects ofcourse
- always have orientation 0 0 0, irrespective of the player
orientation.
On 19/02/2011 15:01, Tom Edwards wrote:
Without knowing how the debug code works it's hard to say what
that means. But it's still definitely a networking problem
rather than something that's happening on the server. What
happens when a predicted player walks around the affected
object, hugging it tightly?
*From:* Maarten De Meyer
<mailto:maar...@off-limits.be>
*To:* hlcoders@list.valvesoftware.com
<mailto:hlcoders@list.valvesoftware.com>
*Sent:* Saturday, 19 February, 2011 11:14:39
*Subject:* Re: [hlcoders] Physics props 90° angle snap issue -
(linux?)
vcollide_wireframe moves together with the mesh I'm afraid.
On 19/02/2011 11:52, Tom Edwards wrote:
If you look closely, the collision model doesn't change. It's
only the visual, client-side mesh that's out of place. Try
using vcollide_wireframe to see what's really going on.||
*From:* Jonathan Murphy
<mailto:nuclearfri...@gmail.com>
*To:* Discussion of Half-Life Programming
<mailto:hlcoders@list.valvesoftware.com>
*Sent:* Saturday, 19 February, 2011 10:41:28
*Subject:* Re: [hlcoders] Physics props 90° angle snap issue -
(linux?)
In my experience it is unlikely to be a Linux specific issue,
and more of a prediction issue. Try introducing fake lag on a
listen server (net_fakelag 200) and seeing if the issue is
reproducable. That should make it much easier to debug.
On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer
mailto:maar...@off-limits.be>> wrote:
Yes, they are.
From: Jonathan Murphy
Sent: zaterdag 19 februari 2011 11:02
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Physics props 90° angle snap issue
- (linux?)
Would be a interesting clue to know if all players are
seeing exactly the same thing?
On Sat, Feb 19, 2011 at 7:42 PM, Joel R.
mailto:joelru...@gmail.com>> wrote:
Have you tested it on a windows dedicated server?
Listenservers don't act entirely the same as dedicated
servers. It appears like the angle of the physics
object is updating a bad networked angle value.
On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer
mailto:maar...@off-limits.be>>
wrote:
As great as Noir Desir's song is, obviously it's
not what I wanted to show :D
Here's the real vid with the issue:
*http://www.youtube.com/watch?v=QhmrP6eSAek*
sorry for that.
On 19/02/2011 9:15, Maarten De Meyer wrote:
Hi list,
we're facing an issue I don't immediately know
where to start to debug. Basically, in all of our
maps, some physics props have an issue where the
orientation of their model snaps at 90° angles
instantaneously. This is not only with props, but
also eg with our vehicles, so I'm looking
suspicously at vphysics :). In addition, this only
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
No no, I'm fairly sure it's not me :D I beyond-compare'd anything
between prop_physics and the engine, no relevant changes on my side. I
still think it'll turn out to be an issue with the linux build - eg gcc
version can be a factor too, although we're on 4.2.4 so we should be
good. If I end up not finding it at all I'll compile a clean OB mod on
my linux machine or something and work from there, but hope that won't
be necessary.
On 20/02/2011 15:39, Tobias Kammersgaard wrote:
Sounds like you need to check previous revisions of your code to be
honest.
- ScarT
On 20 February 2011 14:18, Maarten De Meyer <mailto:maar...@off-limits.be>> wrote:
Found out another piece of interesting information. When we drop
weapons, we give them the direction of the player to make the drop
look realistic. This has always worked decently. On our linux
server, the dropped weapons - also physics objects ofcourse -
always have orientation 0 0 0, irrespective of the player
orientation.
On 19/02/2011 15:01, Tom Edwards wrote:
Without knowing how the debug code works it's hard to say what
that means. But it's still definitely a networking problem rather
than something that's happening on the server. What happens when
a predicted player walks around the affected object, hugging it
tightly?
*From:* Maarten De Meyer
<mailto:maar...@off-limits.be>
*To:* hlcoders@list.valvesoftware.com
<mailto:hlcoders@list.valvesoftware.com>
*Sent:* Saturday, 19 February, 2011 11:14:39
*Subject:* Re: [hlcoders] Physics props 90° angle snap issue -
(linux?)
vcollide_wireframe moves together with the mesh I'm afraid.
On 19/02/2011 11:52, Tom Edwards wrote:
If you look closely, the collision model doesn't change. It's
only the visual, client-side mesh that's out of place. Try using
vcollide_wireframe to see what's really going on.||
*From:* Jonathan Murphy
<mailto:nuclearfri...@gmail.com>
*To:* Discussion of Half-Life Programming
<mailto:hlcoders@list.valvesoftware.com>
*Sent:* Saturday, 19 February, 2011 10:41:28
*Subject:* Re: [hlcoders] Physics props 90° angle snap issue -
(linux?)
In my experience it is unlikely to be a Linux specific issue,
and more of a prediction issue. Try introducing fake lag on a
listen server (net_fakelag 200) and seeing if the issue is
reproducable. That should make it much easier to debug.
On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer
mailto:maar...@off-limits.be>> wrote:
Yes, they are.
From: Jonathan Murphy
Sent: zaterdag 19 februari 2011 11:02
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Physics props 90° angle snap issue -
(linux?)
Would be a interesting clue to know if all players are
seeing exactly the same thing?
On Sat, Feb 19, 2011 at 7:42 PM, Joel R.
mailto:joelru...@gmail.com>> wrote:
Have you tested it on a windows dedicated server?
Listenservers don't act entirely the same as dedicated
servers. It appears like the angle of the physics
object is updating a bad networked angle value.
On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer
mailto:maar...@off-limits.be>>
wrote:
As great as Noir Desir's song is, obviously it's not
what I wanted to show :D
Here's the real vid with the issue:
*http://www.youtube.com/watch?v=QhmrP6eSAek*
sorry for that.
On 19/02/2011 9:15, Maarten De Meyer wrote:
Hi list,
we're facing an issue I don't immediately know
where to start to debug. Basically, in all of our
maps, some physics props have an issue where the
orientation of their model snaps at 90° angles
instantaneously. This is not only with props, but
also eg with our vehicles, so I'm looking
suspicously at vphysics :). In addition, this only
seems to happen on our linux server. Not 100% sure,
since it does not happen consistently on all props,
but we've tried reproducing it a lot on a windows
listenserver without success, and on our linux
dedicated server it happens frequently. Here's a
video of the issue:
*http://ww
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
Sounds like you need to check previous revisions of your code to be honest. - ScarT On 20 February 2011 14:18, Maarten De Meyer wrote: > Found out another piece of interesting information. When we drop weapons, > we give them the direction of the player to make the drop look realistic. > This has always worked decently. On our linux server, the dropped weapons - > also physics objects ofcourse - always have orientation 0 0 0, irrespective > of the player orientation. > > > On 19/02/2011 15:01, Tom Edwards wrote: > > Without knowing how the debug code works it's hard to say what that > means. But it's still definitely a networking problem rather than something > that's happening on the server. What happens when a predicted player walks > around the affected object, hugging it tightly? > > -- > *From:* Maarten De Meyer > *To:* hlcoders@list.valvesoftware.com > *Sent:* Saturday, 19 February, 2011 11:14:39 > *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) > > vcollide_wireframe moves together with the mesh I'm afraid. > > On 19/02/2011 11:52, Tom Edwards wrote: > > If you look closely, the collision model doesn't change. It's only the > visual, client-side mesh that's out of place. Try using vcollide_wireframe > to see what's really going on. > > -- > *From:* Jonathan Murphy > *To:* Discussion of Half-Life Programming > > *Sent:* Saturday, 19 February, 2011 10:41:28 > *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) > > In my experience it is unlikely to be a Linux specific issue, and more of a > prediction issue. Try introducing fake lag on a listen server (net_fakelag > 200) and seeing if the issue is reproducable. That should make it much > easier to debug. > > On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer > wrote: > >> Yes, they are. >> -- >> From: Jonathan Murphy >> Sent: zaterdag 19 februari 2011 11:02 >> To: Discussion of Half-Life Programming >> Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) >> >> >> Would be a interesting clue to know if all players are seeing exactly the >> same thing? >> >> On Sat, Feb 19, 2011 at 7:42 PM, Joel R. wrote: >> >>> Have you tested it on a windows dedicated server? Listenservers don't >>> act entirely the same as dedicated servers. It appears like the angle of >>> the physics object is updating a bad networked angle value. >>> >>> >>> On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer >> > wrote: >>> >>>> As great as Noir Desir's song is, obviously it's not what I wanted to >>>> show :D >>>> Here's the real vid with the issue: >>>> >>>> *http://www.youtube.com/watch?v=QhmrP6eSAek* >>>> >>>> sorry for that. >>>> >>>> >>>> On 19/02/2011 9:15, Maarten De Meyer wrote: >>>> >>>> Hi list, >>>> >>>> we're facing an issue I don't immediately know where to start to debug. >>>> Basically, in all of our maps, some physics props have an issue where the >>>> orientation of their model snaps at 90° angles instantaneously. This is not >>>> only with props, but also eg with our vehicles, so I'm looking suspicously >>>> at vphysics :). In addition, this only seems to happen on our linux server. >>>> Not 100% sure, since it does not happen consistently on all props, but >>>> we've >>>> tried reproducing it a lot on a windows listenserver without success, and >>>> on >>>> our linux dedicated server it happens frequently. Here's a video of the >>>> issue: >>>> >>>> *http://www.youtube.com/watch?v=NrgcRvBJYBE* >>>> >>>> At one point we had a vehicle that stood still with a driver in it, and >>>> it did a 'snap' at nearly fixed intervals of several seconds. Player got >>>> out, it went away, player stepped in, it was back ( another reason for me >>>> to >>>> look at vphysics with the evil eye ). >>>> >>>> I'm hoping someone has hit this issue before, or can at least point me >>>> in the right direction, or, a method for debugging this. Since I'm not sure >>>> if it's related to vphysics linux internals, the linux build >>>> machine/settings, networking tolerances, ... I'm not sure where to
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
Found out another piece of interesting information. When we drop weapons, we give them the direction of the player to make the drop look realistic. This has always worked decently. On our linux server, the dropped weapons - also physics objects ofcourse - always have orientation 0 0 0, irrespective of the player orientation. On 19/02/2011 15:01, Tom Edwards wrote: Without knowing how the debug code works it's hard to say what that means. But it's still definitely a networking problem rather than something that's happening on the server. What happens when a predicted player walks around the affected object, hugging it tightly? *From:* Maarten De Meyer *To:* hlcoders@list.valvesoftware.com *Sent:* Saturday, 19 February, 2011 11:14:39 *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) vcollide_wireframe moves together with the mesh I'm afraid. On 19/02/2011 11:52, Tom Edwards wrote: If you look closely, the collision model doesn't change. It's only the visual, client-side mesh that's out of place. Try using vcollide_wireframe to see what's really going on.|| *From:* Jonathan Murphy *To:* Discussion of Half-Life Programming *Sent:* Saturday, 19 February, 2011 10:41:28 *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer mailto:maar...@off-limits.be>> wrote: Yes, they are. From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. mailto:joelru...@gmail.com>> wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer mailto:maar...@off-limits.be>> wrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
Without knowing how the debug code works it's hard to say what that means. But it's still definitely a networking problem rather than something that's happening on the server. What happens when a predicted player walks around the affected object, hugging it tightly? From: Maarten De Meyer To: hlcoders@list.valvesoftware.com Sent: Saturday, 19 February, 2011 11:14:39 Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) vcollide_wireframe moves together with the mesh I'm afraid. On 19/02/2011 11:52, Tom Edwards wrote: If you look closely, the collision model doesn't change. It's only the visual, client-side mesh that's out of place. Try using vcollide_wireframe to see what's really going on. > > > From: Jonathan Murphy >To: Discussion of Half-Life Programming >Sent: Saturday, 19 February, 2011 10:41:28 >Subject: Re: [hlcoders] Physics props 90° angle snap issue - >(linux?) > >In my experience it is unlikely to be a Linux specific issue, and >more of a prediction issue. Try introducing fake lag on a listen >server (net_fakelag 200) and seeing if the issue is reproducable. >That should make it much easier to debug. > > >On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer > wrote: > >Yes, they are. From: Jonathan Murphy >>Sent: zaterdag 19 februari 2011 11:02 >>To: Discussion of Half-Life Programming >>Subject: Re: [hlcoders] Physics props 90° angle snap >>issue - >>(linux?) >> >> >> >>Would be a interesting clue to know if all players are >>seeing exactly the same thing? >> >> >>On Sat, Feb 19, 2011 at 7:42 PM, Joel R. >> wrote: >> >>Have you tested it on a windows dedicated server? >>Listenservers don't act entirely the same as >>dedicated >>servers. It appears like the angle of the physics >>object is updating a bad networked angle value. >> >>> >>> >>> >>>On Sat, Feb 19, 2011 at 2:22 AM, Maarten De >>>Meyer wrote: >>> >>>As great as Noir Desir's song is, >>>obviously >>>it's not what I wanted to show :D >>>>Here's the real vid with the issue: >>>> >>>>http://www.youtube.com/watch?v=QhmrP6eSAek >>>> >>>>sorry for that. >>>> >>>> >>>>On 19/02/2011 9:15, Maarten De >>>>Meyer >>>>wrote: >>>> >>>>Hi list, >>>>> >>>>>we're facing an issue I don't >>>>>immediately know where to start >>>>>to >>>>>debug. Basically, in all of our >>>>>maps, >>>>>some physics props have an issue >>>>>where >>>>>the orientation of their model >>>>> >>>>>snaps at 90° angles >>>>>instantaneously. >>>>>This is not only with props, but >>>>>also >>>>>eg with our vehicles, so I'm >>>>> >>>>>looking suspicously at vphysics >>>>>:). In >>>>>addition, this only seems to >>>>>happen on >>>>>our linux server. Not 100% sure, >>>>> >>>>>since it does not happen >>>>>consistently >>>>>on all props, but we've tried >>>>>reproducing it a lot on a >>>>>windows
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
Well, I just tried playing with cl_predict 0, and it still happens, so I guess it's not prediction then. On 19/02/2011 12:33, Tobias Kammersgaard wrote: I'd say its related to the prediction. You say it doesn't happy with all props? Have you tried checking the difference between props that does it, and props that don't? - ScarT On 19 February 2011 12:17, Jonathan Murphy <mailto:nuclearfri...@gmail.com>> wrote: How unusual.. I'm starting to feel for you. Hopefully someone can come on here and shine some real light on the problem. :( On Sat, Feb 19, 2011 at 10:15 PM, Maarten De Meyer mailto:maar...@off-limits.be>> wrote: That was my first try, but I can't reproduce it with net_fakelag. On 19/02/2011 11:41, Jonathan Murphy wrote: In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer mailto:maar...@off-limits.be>> wrote: Yes, they are. From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. mailto:joelru...@gmail.com>> wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer mailto:maar...@off-limits.be>> wrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listin
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
I'd say its related to the prediction. You say it doesn't happy with all props? Have you tried checking the difference between props that does it, and props that don't? - ScarT On 19 February 2011 12:17, Jonathan Murphy wrote: > How unusual.. I'm starting to feel for you. Hopefully someone can come on > here and shine some real light on the problem. :( > > > On Sat, Feb 19, 2011 at 10:15 PM, Maarten De Meyer > wrote: > >> That was my first try, but I can't reproduce it with net_fakelag. >> >> >> On 19/02/2011 11:41, Jonathan Murphy wrote: >> >> In my experience it is unlikely to be a Linux specific issue, and more of >> a prediction issue. Try introducing fake lag on a listen server (net_fakelag >> 200) and seeing if the issue is reproducable. That should make it much >> easier to debug. >> >> On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer >> wrote: >> >>> Yes, they are. >>> ------ >>> From: Jonathan Murphy >>> Sent: zaterdag 19 februari 2011 11:02 >>> To: Discussion of Half-Life Programming >>> Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) >>> >>> >>> Would be a interesting clue to know if all players are seeing exactly the >>> same thing? >>> >>> On Sat, Feb 19, 2011 at 7:42 PM, Joel R. wrote: >>> >>>> Have you tested it on a windows dedicated server? Listenservers don't >>>> act entirely the same as dedicated servers. It appears like the angle of >>>> the physics object is updating a bad networked angle value. >>>> >>>> >>>> On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer < >>>> maar...@off-limits.be> wrote: >>>> >>>>> As great as Noir Desir's song is, obviously it's not what I wanted to >>>>> show :D >>>>> Here's the real vid with the issue: >>>>> >>>>> *http://www.youtube.com/watch?v=QhmrP6eSAek* >>>>> >>>>> sorry for that. >>>>> >>>>> >>>>> On 19/02/2011 9:15, Maarten De Meyer wrote: >>>>> >>>>> Hi list, >>>>> >>>>> we're facing an issue I don't immediately know where to start to debug. >>>>> Basically, in all of our maps, some physics props have an issue where the >>>>> orientation of their model snaps at 90° angles instantaneously. This is >>>>> not >>>>> only with props, but also eg with our vehicles, so I'm looking suspicously >>>>> at vphysics :). In addition, this only seems to happen on our linux >>>>> server. >>>>> Not 100% sure, since it does not happen consistently on all props, but >>>>> we've >>>>> tried reproducing it a lot on a windows listenserver without success, and >>>>> on >>>>> our linux dedicated server it happens frequently. Here's a video of the >>>>> issue: >>>>> >>>>> *http://www.youtube.com/watch?v=NrgcRvBJYBE* >>>>> >>>>> At one point we had a vehicle that stood still with a driver in it, and >>>>> it did a 'snap' at nearly fixed intervals of several seconds. Player got >>>>> out, it went away, player stepped in, it was back ( another reason for me >>>>> to >>>>> look at vphysics with the evil eye ). >>>>> >>>>> I'm hoping someone has hit this issue before, or can at least point me >>>>> in the right direction, or, a method for debugging this. Since I'm not >>>>> sure >>>>> if it's related to vphysics linux internals, the linux build >>>>> machine/settings, networking tolerances, ... I'm not sure where to start >>>>> looking. >>>>> >>>>> Thanks for any feedback ( or sympathy :D ), >>>>> >>>>> Maarten >>>>> >>>>> >>>>> ___ >>>>> To unsubscribe, edit your list preferences, or view the list archives, >>>>> please visit:http://list.valvesoftware.com/mailman/listinfo/hlcoders >>>>> >>>>> >>>>> >>>>> ___ >>>>> To unsubscribe, edit your list preferences, or view the list archives, >>>>> p
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
How unusual.. I'm starting to feel for you. Hopefully someone can come on here and shine some real light on the problem. :( On Sat, Feb 19, 2011 at 10:15 PM, Maarten De Meyer wrote: > That was my first try, but I can't reproduce it with net_fakelag. > > > On 19/02/2011 11:41, Jonathan Murphy wrote: > > In my experience it is unlikely to be a Linux specific issue, and more of a > prediction issue. Try introducing fake lag on a listen server (net_fakelag > 200) and seeing if the issue is reproducable. That should make it much > easier to debug. > > On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer > wrote: > >> Yes, they are. >> -- >> From: Jonathan Murphy >> Sent: zaterdag 19 februari 2011 11:02 >> To: Discussion of Half-Life Programming >> Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) >> >> >> Would be a interesting clue to know if all players are seeing exactly the >> same thing? >> >> On Sat, Feb 19, 2011 at 7:42 PM, Joel R. wrote: >> >>> Have you tested it on a windows dedicated server? Listenservers don't >>> act entirely the same as dedicated servers. It appears like the angle of >>> the physics object is updating a bad networked angle value. >>> >>> >>> On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer >> > wrote: >>> >>>> As great as Noir Desir's song is, obviously it's not what I wanted to >>>> show :D >>>> Here's the real vid with the issue: >>>> >>>> *http://www.youtube.com/watch?v=QhmrP6eSAek* >>>> >>>> sorry for that. >>>> >>>> >>>> On 19/02/2011 9:15, Maarten De Meyer wrote: >>>> >>>> Hi list, >>>> >>>> we're facing an issue I don't immediately know where to start to debug. >>>> Basically, in all of our maps, some physics props have an issue where the >>>> orientation of their model snaps at 90° angles instantaneously. This is not >>>> only with props, but also eg with our vehicles, so I'm looking suspicously >>>> at vphysics :). In addition, this only seems to happen on our linux server. >>>> Not 100% sure, since it does not happen consistently on all props, but >>>> we've >>>> tried reproducing it a lot on a windows listenserver without success, and >>>> on >>>> our linux dedicated server it happens frequently. Here's a video of the >>>> issue: >>>> >>>> *http://www.youtube.com/watch?v=NrgcRvBJYBE* >>>> >>>> At one point we had a vehicle that stood still with a driver in it, and >>>> it did a 'snap' at nearly fixed intervals of several seconds. Player got >>>> out, it went away, player stepped in, it was back ( another reason for me >>>> to >>>> look at vphysics with the evil eye ). >>>> >>>> I'm hoping someone has hit this issue before, or can at least point me >>>> in the right direction, or, a method for debugging this. Since I'm not sure >>>> if it's related to vphysics linux internals, the linux build >>>> machine/settings, networking tolerances, ... I'm not sure where to start >>>> looking. >>>> >>>> Thanks for any feedback ( or sympathy :D ), >>>> >>>> Maarten >>>> >>>> >>>> ___ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit:http://list.valvesoftware.com/mailman/listinfo/hlcoders >>>> >>>> >>>> >>>> ___ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>>> >>>> >>>> >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >>> >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit:http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
That was my first try, but I can't reproduce it with net_fakelag. On 19/02/2011 11:41, Jonathan Murphy wrote: In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer mailto:maar...@off-limits.be>> wrote: Yes, they are. From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. mailto:joelru...@gmail.com>> wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer mailto:maar...@off-limits.be>> wrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
vcollide_wireframe moves together with the mesh I'm afraid. On 19/02/2011 11:52, Tom Edwards wrote: If you look closely, the collision model doesn't change. It's only the visual, client-side mesh that's out of place. Try using vcollide_wireframe to see what's really going on.|| *From:* Jonathan Murphy *To:* Discussion of Half-Life Programming *Sent:* Saturday, 19 February, 2011 10:41:28 *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer mailto:maar...@off-limits.be>> wrote: Yes, they are. From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. mailto:joelru...@gmail.com>> wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer mailto:maar...@off-limits.be>> wrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
If you look closely, the collision model doesn't change. It's only the visual, client-side mesh that's out of place. Try using vcollide_wireframe to see what's really going on. From: Jonathan Murphy To: Discussion of Half-Life Programming Sent: Saturday, 19 February, 2011 10:41:28 Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer wrote: Yes, they are. From: Jonathan Murphy >Sent: zaterdag 19 februari 2011 11:02 >To: Discussion of Half-Life Programming >Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) > > >Would be a interesting clue to know if all players are seeing exactly the same >thing? > > >On Sat, Feb 19, 2011 at 7:42 PM, Joel R. wrote: > >Have you tested it on a windows dedicated server? Listenservers don't act >entirely the same as dedicated servers. It appears like the angle of the >physics object is updating a bad networked angle value. > >> >> >> >>On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer >wrote: >> >>As great as Noir Desir's song is, obviously it's not what I wanted to show :D >>>Here's the real vid with the issue: >>> >>>http://www.youtube.com/watch?v=QhmrP6eSAek >>> >>>sorry for that. >>> >>> >>>On 19/02/2011 9:15, Maarten De Meyer wrote: >>>Hi list, >>>> >>>>we're facing an issue I don't immediately know where to start to debug. >>>>Basically, in all of our maps, some physics props have an issue where the >>>>orientation of their model snaps at 90° angles instantaneously. This is not >>>>only >>>>with props, but also eg with our vehicles, so I'm looking suspicously at >>>>vphysics :). In addition, this only seems to happen on our linux server. >>>>Not >>>>100% sure, since it does not happen consistently on all props, but we've >>>>tried >>>>reproducing it a lot on a windows listenserver without success, and on our >>>>linux >>>>dedicated server it happens frequently. Here's a video of the issue: >>>> >>>>http://www.youtube.com/watch?v=NrgcRvBJYBE >>>> >>>>At one point we had a vehicle that stood still with a driver in it, and it >>>>did a >>>>'snap' at nearly fixed intervals of several seconds. Player got out, it >>>>went >>>>away, player stepped in, it was back ( another reason for me to look at >>>>vphysics >>>>with the evil eye ). >>>> >>>>I'm hoping someone has hit this issue before, or can at least point me in >>>>the >>>>right direction, or, a method for debugging this. Since I'm not sure if >>>>it's >>>>related to vphysics linux internals, the linux build machine/settings, >>>>networking tolerances, ... I'm not sure where to start looking. >>>> >>>>Thanks for any feedback ( or sympathy :D ), >>>> >>>>Maarten >>>> >>>> ___ To unsubscribe, edit your >>>> list >>>>preferences, or view the list archives, please visit: >>>>http://list.valvesoftware.com/mailman/listinfo/hlcoders >>>> >> >>>___ >>>To unsubscribe, edit your list preferences, or view the list archives, >>>please >>>visit: >>>http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >>> >> >>___ >>To unsubscribe, edit your list preferences, or view the list archives, please >>visit: >>http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > >___ >To unsubscribe, edit your list preferences, or view the list archives, please >visit: >http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer wrote: > Yes, they are. > -- > From: Jonathan Murphy > Sent: zaterdag 19 februari 2011 11:02 > To: Discussion of Half-Life Programming > Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) > > > Would be a interesting clue to know if all players are seeing exactly the > same thing? > > On Sat, Feb 19, 2011 at 7:42 PM, Joel R. wrote: > >> Have you tested it on a windows dedicated server? Listenservers don't act >> entirely the same as dedicated servers. It appears like the angle of the >> physics object is updating a bad networked angle value. >> >> >> On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer >> wrote: >> >>> As great as Noir Desir's song is, obviously it's not what I wanted to >>> show :D >>> Here's the real vid with the issue: >>> >>> *http://www.youtube.com/watch?v=QhmrP6eSAek* >>> >>> sorry for that. >>> >>> >>> On 19/02/2011 9:15, Maarten De Meyer wrote: >>> >>> Hi list, >>> >>> we're facing an issue I don't immediately know where to start to debug. >>> Basically, in all of our maps, some physics props have an issue where the >>> orientation of their model snaps at 90° angles instantaneously. This is not >>> only with props, but also eg with our vehicles, so I'm looking suspicously >>> at vphysics :). In addition, this only seems to happen on our linux server. >>> Not 100% sure, since it does not happen consistently on all props, but we've >>> tried reproducing it a lot on a windows listenserver without success, and on >>> our linux dedicated server it happens frequently. Here's a video of the >>> issue: >>> >>> *http://www.youtube.com/watch?v=NrgcRvBJYBE* >>> >>> At one point we had a vehicle that stood still with a driver in it, and >>> it did a 'snap' at nearly fixed intervals of several seconds. Player got >>> out, it went away, player stepped in, it was back ( another reason for me to >>> look at vphysics with the evil eye ). >>> >>> I'm hoping someone has hit this issue before, or can at least point me in >>> the right direction, or, a method for debugging this. Since I'm not sure if >>> it's related to vphysics linux internals, the linux build machine/settings, >>> networking tolerances, ... I'm not sure where to start looking. >>> >>> Thanks for any feedback ( or sympathy :D ), >>> >>> Maarten >>> >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit:http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >>> >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. wrote: > Have you tested it on a windows dedicated server? Listenservers don't act > entirely the same as dedicated servers. It appears like the angle of the > physics object is updating a bad networked angle value. > > > On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer > wrote: > >> As great as Noir Desir's song is, obviously it's not what I wanted to >> show :D >> Here's the real vid with the issue: >> >> *http://www.youtube.com/watch?v=QhmrP6eSAek* >> >> sorry for that. >> >> >> On 19/02/2011 9:15, Maarten De Meyer wrote: >> >> Hi list, >> >> we're facing an issue I don't immediately know where to start to debug. >> Basically, in all of our maps, some physics props have an issue where the >> orientation of their model snaps at 90° angles instantaneously. This is not >> only with props, but also eg with our vehicles, so I'm looking suspicously >> at vphysics :). In addition, this only seems to happen on our linux server. >> Not 100% sure, since it does not happen consistently on all props, but we've >> tried reproducing it a lot on a windows listenserver without success, and on >> our linux dedicated server it happens frequently. Here's a video of the >> issue: >> >> *http://www.youtube.com/watch?v=NrgcRvBJYBE* >> >> At one point we had a vehicle that stood still with a driver in it, and it >> did a 'snap' at nearly fixed intervals of several seconds. Player got out, >> it went away, player stepped in, it was back ( another reason for me to look >> at vphysics with the evil eye ). >> >> I'm hoping someone has hit this issue before, or can at least point me in >> the right direction, or, a method for debugging this. Since I'm not sure if >> it's related to vphysics linux internals, the linux build machine/settings, >> networking tolerances, ... I'm not sure where to start looking. >> >> Thanks for any feedback ( or sympathy :D ), >> >> Maarten >> >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit:http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer wrote: > As great as Noir Desir's song is, obviously it's not what I wanted to show > :D > Here's the real vid with the issue: > > *http://www.youtube.com/watch?v=QhmrP6eSAek* > > sorry for that. > > > On 19/02/2011 9:15, Maarten De Meyer wrote: > > Hi list, > > we're facing an issue I don't immediately know where to start to debug. > Basically, in all of our maps, some physics props have an issue where the > orientation of their model snaps at 90° angles instantaneously. This is not > only with props, but also eg with our vehicles, so I'm looking suspicously > at vphysics :). In addition, this only seems to happen on our linux server. > Not 100% sure, since it does not happen consistently on all props, but we've > tried reproducing it a lot on a windows listenserver without success, and on > our linux dedicated server it happens frequently. Here's a video of the > issue: > > *http://www.youtube.com/watch?v=NrgcRvBJYBE* > > At one point we had a vehicle that stood still with a driver in it, and it > did a 'snap' at nearly fixed intervals of several seconds. Player got out, > it went away, player stepped in, it was back ( another reason for me to look > at vphysics with the evil eye ). > > I'm hoping someone has hit this issue before, or can at least point me in > the right direction, or, a method for debugging this. Since I'm not sure if > it's related to vphysics linux internals, the linux build machine/settings, > networking tolerances, ... I'm not sure where to start looking. > > Thanks for any feedback ( or sympathy :D ), > > Maarten > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit:http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics props 90° angle snap issue - (linux?)
Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics Problem
The real answer to this problem is: A) It doesn't matter what you do with the solid flags, - unless - B) you give an object a shove to move It's right there in the comments on the solid flag. Go figure. :P --- On Fri, 2/20/09, Grash wrote: From: Grash Subject: Re: [hlcoders] Physics Problem To: "Discussion of Half-Life Programming" Date: Friday, February 20, 2009, 4:47 PM Yea, the func_breakable is doing what we're looking for. Thanks... --- On Fri, 2/20/09, Ryan Sheffer wrote: From: Ryan Sheffer Subject: Re: [hlcoders] Physics Problem To: "Discussion of Half-Life Programming" Date: Friday, February 20, 2009, 4:29 PM When the object is disabled it isn't forcing a physics update on physics props touching it. You just need to force a physics update on those props on disable. I am pretty sure the code to do this can be found in the func_breakable as I believe when those break the physics objects update accordingly. Cheers. On Fri, Feb 20, 2009 at 1:16 PM, Grash wrote: > Here's the setup: I have a prop_physics on top of a func_brush. > When the brush is disabled, either through code or though script (via a > trigger), the physics object does not drop to the ground. > > When I slightly push the prop_physics with another prop, it can get into a > position where it will swing in the air from a corner on the model. > > When I pick up the object and throw it through the disabled brush, it moves > through it as intended. > > The player moves through the brush in the correct manner (Colliding when > enabled and moving through when disabled) in all cases. This includes when > the player or NPC (Combine Solider) stands on top of the brush and falls > through it correctly when it is disabled. > > What am I missing here in the code? > > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ~Ryan ( skidz ) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics Problem
Yea, the func_breakable is doing what we're looking for. Thanks... --- On Fri, 2/20/09, Ryan Sheffer wrote: From: Ryan Sheffer Subject: Re: [hlcoders] Physics Problem To: "Discussion of Half-Life Programming" Date: Friday, February 20, 2009, 4:29 PM When the object is disabled it isn't forcing a physics update on physics props touching it. You just need to force a physics update on those props on disable. I am pretty sure the code to do this can be found in the func_breakable as I believe when those break the physics objects update accordingly. Cheers. On Fri, Feb 20, 2009 at 1:16 PM, Grash wrote: > Here's the setup: I have a prop_physics on top of a func_brush. > When the brush is disabled, either through code or though script (via a > trigger), the physics object does not drop to the ground. > > When I slightly push the prop_physics with another prop, it can get into a > position where it will swing in the air from a corner on the model. > > When I pick up the object and throw it through the disabled brush, it moves > through it as intended. > > The player moves through the brush in the correct manner (Colliding when > enabled and moving through when disabled) in all cases. This includes when > the player or NPC (Combine Solider) stands on top of the brush and falls > through it correctly when it is disabled. > > What am I missing here in the code? > > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ~Ryan ( skidz ) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics Problem
When the object is disabled it isn't forcing a physics update on physics props touching it. You just need to force a physics update on those props on disable. I am pretty sure the code to do this can be found in the func_breakable as I believe when those break the physics objects update accordingly. Cheers. On Fri, Feb 20, 2009 at 1:16 PM, Grash wrote: > Here's the setup: I have a prop_physics on top of a func_brush. > When the brush is disabled, either through code or though script (via a > trigger), the physics object does not drop to the ground. > > When I slightly push the prop_physics with another prop, it can get into a > position where it will swing in the air from a corner on the model. > > When I pick up the object and throw it through the disabled brush, it moves > through it as intended. > > The player moves through the brush in the correct manner (Colliding when > enabled and moving through when disabled) in all cases. This includes when > the player or NPC (Combine Solider) stands on top of the brush and falls > through it correctly when it is disabled. > > What am I missing here in the code? > > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ~Ryan ( skidz ) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics Problem
Now, I haven't messed with the physics system, but it sounds like the prop is unaware things have changed. Props in Source that haven't moved for a while, aren't physically simulated, for performance reasons. I would find a way to broadcast an event that tells nearby props that they need to be simulated. (Or hackier: Simply find all nearby props and move them a little or something.) - Sortie. - Original Message - From: "Grash" To: "Discussion of Half-Life Programming" Sent: Friday, February 20, 2009 10:16 PM Subject: [hlcoders] Physics Problem Here's the setup: I have a prop_physics on top of a func_brush. When the brush is disabled, either through code or though script (via a trigger), the physics object does not drop to the ground. When I slightly push the prop_physics with another prop, it can get into a position where it will swing in the air from a corner on the model. When I pick up the object and throw it through the disabled brush, it moves through it as intended. The player moves through the brush in the correct manner (Colliding when enabled and moving through when disabled) in all cases. This includes when the player or NPC (Combine Solider) stands on top of the brush and falls through it correctly when it is disabled. What am I missing here in the code? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics Problem
Here's the setup: I have a prop_physics on top of a func_brush. When the brush is disabled, either through code or though script (via a trigger), the physics object does not drop to the ground. When I slightly push the prop_physics with another prop, it can get into a position where it will swing in the air from a corner on the model. When I pick up the object and throw it through the disabled brush, it moves through it as intended. The player moves through the brush in the correct manner (Colliding when enabled and moving through when disabled) in all cases. This includes when the player or NPC (Combine Solider) stands on top of the brush and falls through it correctly when it is disabled. What am I missing here in the code? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] physics shadow?
The physics shadows are basically a physics object that follows an entity that doesn't move with vphysics, ie: an npc, or the player, and provides collision with physics objects, and has callbacks to notify the entity it's following that it just collided with something else that is vphysics (or another shadow) -Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Chang Sent: October-02-08 11:59 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] physics shadow? Can someone explain this one to me? In VPhysicsShadowUpdate() I just took all the traces ie util_traceline, util_traceentity, etc and changed the MASK_PLAYERSOLID to use PhysicsSolidMaskForEntity() except I used some ifdefs so I remember that the code was modified by our mod when it comes time to merge new code that affected this file for instance. Chris What is PhysicsShadow? For some reason I imagine shadows doing physical collision tests and that sort of stuff, which makes no sense. Can someone put this into some context please? Thanks ~M ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] physics shadow?
Can someone explain this one to me? In VPhysicsShadowUpdate() I just took all the traces ie util_traceline, util_traceentity, etc and changed the MASK_PLAYERSOLID to use PhysicsSolidMaskForEntity() except I used some ifdefs so I remember that the code was modified by our mod when it comes time to merge new code that affected this file for instance. Chris What is PhysicsShadow? For some reason I imagine shadows doing physical collision tests and that sort of stuff, which makes no sense. Can someone put this into some context please? Thanks ~M ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics crash related (urgent).
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Thank you Mulchman and rest of people except the drunk one :P
Yes I think all my physic objects are vphysics. BTW, I copied a method from SDK
meant for gibs to create my hats, maybe should I use a different approach for
multiplayer? That function is used for single player APC so maybe this isn't
correct at all.
CPhysicsProp *pHat = assert_cast(CreateEntityByName(
"prop_physics" ));
I wish there was more info about physics in Source, if someone can point me to
a related document I'd be very grateful. I couldn't see any relevant in Valve's
wiki.
So well, I added the DAMAGE_NO flag to every physic object in my mod, for the
moment our server stopped crashing except one time. That's a very rare crash
which happens when server is loading a new map, just when is supposed to start
loading. It happens after the same map but rarely. This is the call stack:
server.dll!CBaseEntity::TakeDamage(const CTakeDamageInfo & inputInfo=) Line
1204 + 0xd bytes C++
> server.dll!CBaseEntity::PhysicsDispatchThink(void (void)*
> thinkFunc=0x) Line 1068 C++
PhysicsDispatchThink is supposed to run when there are ropes in the map?
// Purpose: Called when it's time for a physically moved objects (plats, doors,
etc) to run it's game code.
---
All of our buildable objects - detpack, dispenser, sg - run the code below
when they explode. The detpack is a "real" physics object (as in it uses
VPhysicsInitNormal()) and I'm assuming your hat you describe is vphysics as
well.
void CFFBuildableObject::Explode( void )
{
VPROF_BUDGET( "CFFBuildableObject::Explode",
VPROF_BUDGETGROUP_FF_BUILDABLE );
// MUST DO THIS or CreateExplosion crashes HL2
m_takedamage = DAMAGE_NO;
// Remove bounding box (other models follow this pattern...)
SetSolid( SOLID_NONE );
// Do the explosion
DoExplosion();
// Notify player to tell them they can build
// again and remove current owner
m_hOwner = NULL;
// Remove entity from game
UTIL_Remove( this );
}
And that's it. There's also a method for 'quietly' removing a buildable
object (like when dismantling) but it's the same code minus the
DoExplosion() call.
Anyway, we've never experienced/received minidumps from people w/ weird
physics related errors so perhaps you need some other steps in addition to
using UTIL_Remove().
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics crash related (urgent).
well ive drunk a fair amount and im still able to type properly although
without any punctuation whatsoever...
Merry Christmas everyone, have a good one, get drunk (well, dont), have
fun, do not shoot santa!
Ondřej Hošek wrote:
Posting under the Influence (PUI) will lead to a revocation of your
license to post. Please do not try typing when your blood contains more
than 0.2% of alcohol.
Actually, I'm impressed you were able to press two keys simultaneously
when typing the exclamation mark, and don't get me started on the nonce
word "sadues".
Meery Christams and a hapy NEw yAer!
~~ Ondra
On 25.12.07 0:35 Uhr, Josh Marshall wrote:
--
[ Picked text/plain from multipart/alternative ]
its christams sadues stop emialing and tget with ti, man!
On Dec 24, 2007 7:10 PM, Mulchman <[EMAIL PROTECTED]> wrote:
All of our buildable objects - detpack, dispenser, sg - run the code
below
when they explode. The detpack is a "real" physics object (as in it
uses
VPhysicsInitNormal()) and I'm assuming your hat you describe is
vphysics
as
well.
void CFFBuildableObject::Explode( void )
{
VPROF_BUDGET( "CFFBuildableObject::Explode",
VPROF_BUDGETGROUP_FF_BUILDABLE );
// MUST DO THIS or CreateExplosion crashes HL2
m_takedamage = DAMAGE_NO;
// Remove bounding box (other models follow this pattern...)
SetSolid( SOLID_NONE );
// Do the explosion
DoExplosion();
// Notify player to tell them they can build
// again and remove current owner
m_hOwner = NULL;
// Remove entity from game
UTIL_Remove( this );
}
And that's it. There's also a method for 'quietly' removing a buildable
object (like when dismantling) but it's the same code minus the
DoExplosion() call.
Anyway, we've never experienced/received minidumps from people w/ weird
physics related errors so perhaps you need some other steps in
addition to
using UTIL_Remove().
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of A.Oliver
Sent: Monday, December 24, 2007 08:09
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Physics crash related (urgent).
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Our recently released modification (Fistful of Frags) is suffering some
stability issues. Hope someone can bring some light to these serious
servers
crashes. I posted another similar issue in this list, and as I said
before,
I never modified any part of the physics code. Now I'm starting to
understand what's going on, seems like a physic entity was removed, but
server is still trying to use it so finds a null pointer and
crashes. Is
that rigth?
These issues were noticed only during maximum stress, once the mod was
released. They may happen rarely or not, depends the way physics are
stressed I guess.
I'm using UTIL_Remove in several parts of the game, example: a
cowboy hat
is
created (falls to ground), and after some seconds is deleted. There are
other items deleted in a similar way. Should I use other method
different
from UTIL_Remove?
And a last question. Can server performance ( low FPS) make these
issues
worse? Because they tend to happen more in our own server, which
sometimes
is even below 10 FPS.
Hope this helps, these are 3 different call stacks we are seeing
repitedly.
If you need any other info plz let me know.
server.dll!AllocTouchLink() Line 361 + 0x41 bytes C++
server.dll!CBaseEntity::PhysicsMarkEntityAsTouched(CBaseEntity *
other=0x0d21e300) Line 850 + 0x5 bytes C++
server.dll!CBaseEntity::PhysicsMarkEntitiesAsTouchingEventDriven
(CBaseEntity
* other=0x, CGameTrace & trace={...}) Line 908 C++
server.dll!CCollisionEvent::DispatchStartTouch(CBaseEntity *
pEntity0=0x0d21e300, CBaseEntity * pEntity1=0x0fdf0dd8, const Vector &
point={...}, const Vector & normal={...}) Line 1567 + 0x8c bytes C++
server.dll!CCollisionEvent::UpdateTouchEvents() Line 1590 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1262 + 0xa
bytes
C++
server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
server.dll!InvokePerFrameMethod(void (void)* f=0x22198170, const
char *
timed=0x2217be3f) Line 431 C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line
1001 +
0x14 bytes C++
-
server.dll!CCollisionEvent::UpdateDamageEvents() Line 1624 + 0x8
bytes
C++
server.dll!CCollisionEvent::PostSimulationFrame() Line 1499 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1206 C++
server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
server.dll!InvokePerFrameMethod(void (void)* f=0x22198170, const
char *
timed=0x2217be3f) Line 431 C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line
1001 +
0x14 bytes C++
-
server.dll!CBaseEntity::TakeDamage(const CTakeDamageInfo &
inputInf
Re: [hlcoders] Physics crash related (urgent).
Posting under the Influence (PUI) will lead to a revocation of your
license to post. Please do not try typing when your blood contains more
than 0.2% of alcohol.
Actually, I'm impressed you were able to press two keys simultaneously
when typing the exclamation mark, and don't get me started on the nonce
word "sadues".
Meery Christams and a hapy NEw yAer!
~~ Ondra
On 25.12.07 0:35 Uhr, Josh Marshall wrote:
--
[ Picked text/plain from multipart/alternative ]
its christams sadues stop emialing and tget with ti, man!
On Dec 24, 2007 7:10 PM, Mulchman <[EMAIL PROTECTED]> wrote:
All of our buildable objects - detpack, dispenser, sg - run the code below
when they explode. The detpack is a "real" physics object (as in it uses
VPhysicsInitNormal()) and I'm assuming your hat you describe is vphysics
as
well.
void CFFBuildableObject::Explode( void )
{
VPROF_BUDGET( "CFFBuildableObject::Explode",
VPROF_BUDGETGROUP_FF_BUILDABLE );
// MUST DO THIS or CreateExplosion crashes HL2
m_takedamage = DAMAGE_NO;
// Remove bounding box (other models follow this pattern...)
SetSolid( SOLID_NONE );
// Do the explosion
DoExplosion();
// Notify player to tell them they can build
// again and remove current owner
m_hOwner = NULL;
// Remove entity from game
UTIL_Remove( this );
}
And that's it. There's also a method for 'quietly' removing a buildable
object (like when dismantling) but it's the same code minus the
DoExplosion() call.
Anyway, we've never experienced/received minidumps from people w/ weird
physics related errors so perhaps you need some other steps in addition to
using UTIL_Remove().
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of A.Oliver
Sent: Monday, December 24, 2007 08:09
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Physics crash related (urgent).
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Our recently released modification (Fistful of Frags) is suffering some
stability issues. Hope someone can bring some light to these serious
servers
crashes. I posted another similar issue in this list, and as I said
before,
I never modified any part of the physics code. Now I'm starting to
understand what's going on, seems like a physic entity was removed, but
server is still trying to use it so finds a null pointer and crashes. Is
that rigth?
These issues were noticed only during maximum stress, once the mod was
released. They may happen rarely or not, depends the way physics are
stressed I guess.
I'm using UTIL_Remove in several parts of the game, example: a cowboy hat
is
created (falls to ground), and after some seconds is deleted. There are
other items deleted in a similar way. Should I use other method different
from UTIL_Remove?
And a last question. Can server performance ( low FPS) make these issues
worse? Because they tend to happen more in our own server, which sometimes
is even below 10 FPS.
Hope this helps, these are 3 different call stacks we are seeing
repitedly.
If you need any other info plz let me know.
server.dll!AllocTouchLink() Line 361 + 0x41 bytes C++
server.dll!CBaseEntity::PhysicsMarkEntityAsTouched(CBaseEntity *
other=0x0d21e300) Line 850 + 0x5 bytes C++
server.dll!CBaseEntity::PhysicsMarkEntitiesAsTouchingEventDriven
(CBaseEntity
* other=0x, CGameTrace & trace={...}) Line 908 C++
server.dll!CCollisionEvent::DispatchStartTouch(CBaseEntity *
pEntity0=0x0d21e300, CBaseEntity * pEntity1=0x0fdf0dd8, const Vector &
point={...}, const Vector & normal={...}) Line 1567 + 0x8c bytes C++
server.dll!CCollisionEvent::UpdateTouchEvents() Line 1590 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1262 + 0xa bytes
C++
server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
server.dll!InvokePerFrameMethod(void (void)* f=0x22198170, const char *
timed=0x2217be3f) Line 431 C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 1001 +
0x14 bytes C++
-
server.dll!CCollisionEvent::UpdateDamageEvents() Line 1624 + 0x8 bytes
C++
server.dll!CCollisionEvent::PostSimulationFrame() Line 1499 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1206 C++
server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
server.dll!InvokePerFrameMethod(void (void)* f=0x22198170, const char *
timed=0x2217be3f) Line 431 C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 1001 +
0x14 bytes C++
-
server.dll!CBaseEntity::TakeDamage(const CTakeDamageInfo &
inputInfo={...}) Line 1204 + 0xd bytes C++
server.dll!CCollisionEvent::UpdateDamageEvents() Line 1642 C++
server.dll!CCollisionEvent::PostSimulationFrame() Line 1499 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1206 C++
s
Re: [hlcoders] Physics crash related (urgent).
--
[ Picked text/plain from multipart/alternative ]
its christams sadues stop emialing and tget with ti, man!
On Dec 24, 2007 7:10 PM, Mulchman <[EMAIL PROTECTED]> wrote:
> All of our buildable objects - detpack, dispenser, sg - run the code below
> when they explode. The detpack is a "real" physics object (as in it uses
> VPhysicsInitNormal()) and I'm assuming your hat you describe is vphysics
> as
> well.
>
> void CFFBuildableObject::Explode( void )
> {
>VPROF_BUDGET( "CFFBuildableObject::Explode",
> VPROF_BUDGETGROUP_FF_BUILDABLE );
>
>// MUST DO THIS or CreateExplosion crashes HL2
>m_takedamage = DAMAGE_NO;
>
>// Remove bounding box (other models follow this pattern...)
>SetSolid( SOLID_NONE );
>
>// Do the explosion
>DoExplosion();
>
>// Notify player to tell them they can build
>// again and remove current owner
>m_hOwner = NULL;
>
>// Remove entity from game
>UTIL_Remove( this );
> }
>
> And that's it. There's also a method for 'quietly' removing a buildable
> object (like when dismantling) but it's the same code minus the
> DoExplosion() call.
>
> Anyway, we've never experienced/received minidumps from people w/ weird
> physics related errors so perhaps you need some other steps in addition to
> using UTIL_Remove().
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of A.Oliver
> Sent: Monday, December 24, 2007 08:09
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] Physics crash related (urgent).
>
> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Our recently released modification (Fistful of Frags) is suffering some
> stability issues. Hope someone can bring some light to these serious
> servers
> crashes. I posted another similar issue in this list, and as I said
> before,
> I never modified any part of the physics code. Now I'm starting to
> understand what's going on, seems like a physic entity was removed, but
> server is still trying to use it so finds a null pointer and crashes. Is
> that rigth?
>
> These issues were noticed only during maximum stress, once the mod was
> released. They may happen rarely or not, depends the way physics are
> stressed I guess.
>
> I'm using UTIL_Remove in several parts of the game, example: a cowboy hat
> is
> created (falls to ground), and after some seconds is deleted. There are
> other items deleted in a similar way. Should I use other method different
> from UTIL_Remove?
>
> And a last question. Can server performance ( low FPS) make these issues
> worse? Because they tend to happen more in our own server, which sometimes
> is even below 10 FPS.
>
> Hope this helps, these are 3 different call stacks we are seeing
> repitedly.
> If you need any other info plz let me know.
>
>
> > server.dll!AllocTouchLink() Line 361 + 0x41 bytes C++
> server.dll!CBaseEntity::PhysicsMarkEntityAsTouched(CBaseEntity *
> other=0x0d21e300) Line 850 + 0x5 bytes C++
>
> server.dll!CBaseEntity::PhysicsMarkEntitiesAsTouchingEventDriven
> (CBaseEntity
> * other=0x, CGameTrace & trace={...}) Line 908 C++
> server.dll!CCollisionEvent::DispatchStartTouch(CBaseEntity *
> pEntity0=0x0d21e300, CBaseEntity * pEntity1=0x0fdf0dd8, const Vector &
> point={...}, const Vector & normal={...}) Line 1567 + 0x8c bytes C++
> server.dll!CCollisionEvent::UpdateTouchEvents() Line 1590 C++
> server.dll!PhysFrame(float deltaTime=0.01500) Line 1262 + 0xa bytes
> C++
> server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
> server.dll!InvokePerFrameMethod(void (void)* f=0x22198170, const char *
> timed=0x2217be3f) Line 431 C++
> server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 1001 +
> 0x14 bytes C++
>
> -
>
> > server.dll!CCollisionEvent::UpdateDamageEvents() Line 1624 + 0x8 bytes
> C++
> server.dll!CCollisionEvent::PostSimulationFrame() Line 1499 C++
> server.dll!PhysFrame(float deltaTime=0.01500) Line 1206 C++
> server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
> server.dll!InvokePerFrameMethod(void (void)* f=0x22198170, const char *
> timed=0x2217be3f) Line 431 C++
> server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 1001 +
> 0x14 bytes C++
>
>
> -
>
> server.dll!CBaseEntity::TakeDamage(const CTakeDamageInfo &
> inputInfo={...}) Line 1204 + 0xd bytes C++
> server.dll!CCollisionEvent::UpdateDa
[hlcoders] Physics crash related (urgent).
All of our buildable objects - detpack, dispenser, sg - run the code below
when they explode. The detpack is a "real" physics object (as in it uses
VPhysicsInitNormal()) and I'm assuming your hat you describe is vphysics as
well.
void CFFBuildableObject::Explode( void )
{
VPROF_BUDGET( "CFFBuildableObject::Explode",
VPROF_BUDGETGROUP_FF_BUILDABLE );
// MUST DO THIS or CreateExplosion crashes HL2
m_takedamage = DAMAGE_NO;
// Remove bounding box (other models follow this pattern...)
SetSolid( SOLID_NONE );
// Do the explosion
DoExplosion();
// Notify player to tell them they can build
// again and remove current owner
m_hOwner = NULL;
// Remove entity from game
UTIL_Remove( this );
}
And that's it. There's also a method for 'quietly' removing a buildable
object (like when dismantling) but it's the same code minus the
DoExplosion() call.
Anyway, we've never experienced/received minidumps from people w/ weird
physics related errors so perhaps you need some other steps in addition to
using UTIL_Remove().
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of A.Oliver
Sent: Monday, December 24, 2007 08:09
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Physics crash related (urgent).
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Our recently released modification (Fistful of Frags) is suffering some
stability issues. Hope someone can bring some light to these serious servers
crashes. I posted another similar issue in this list, and as I said before,
I never modified any part of the physics code. Now I'm starting to
understand what's going on, seems like a physic entity was removed, but
server is still trying to use it so finds a null pointer and crashes. Is
that rigth?
These issues were noticed only during maximum stress, once the mod was
released. They may happen rarely or not, depends the way physics are
stressed I guess.
I'm using UTIL_Remove in several parts of the game, example: a cowboy hat is
created (falls to ground), and after some seconds is deleted. There are
other items deleted in a similar way. Should I use other method different
from UTIL_Remove?
And a last question. Can server performance ( low FPS) make these issues
worse? Because they tend to happen more in our own server, which sometimes
is even below 10 FPS.
Hope this helps, these are 3 different call stacks we are seeing repitedly.
If you need any other info plz let me know.
> server.dll!AllocTouchLink() Line 361 + 0x41 bytes C++
server.dll!CBaseEntity::PhysicsMarkEntityAsTouched(CBaseEntity *
other=0x0d21e300) Line 850 + 0x5 bytes C++
server.dll!CBaseEntity::PhysicsMarkEntitiesAsTouchingEventDriven(CBaseEntity
* other=0x, CGameTrace & trace={...}) Line 908 C++
server.dll!CCollisionEvent::DispatchStartTouch(CBaseEntity *
pEntity0=0x0d21e300, CBaseEntity * pEntity1=0x0fdf0dd8, const Vector &
point={...}, const Vector & normal={...}) Line 1567 + 0x8c bytes C++
server.dll!CCollisionEvent::UpdateTouchEvents() Line 1590 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1262 + 0xa bytes
C++
server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
server.dll!InvokePerFrameMethod(void (void)* f=0x22198170, const char *
timed=0x2217be3f) Line 431 C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 1001 +
0x14 bytes C++
-
> server.dll!CCollisionEvent::UpdateDamageEvents() Line 1624 + 0x8 bytes
C++
server.dll!CCollisionEvent::PostSimulationFrame() Line 1499 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1206 C++
server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
server.dll!InvokePerFrameMethod(void (void)* f=0x22198170, const char *
timed=0x2217be3f) Line 431 C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 1001 +
0x14 bytes C++
-
server.dll!CBaseEntity::TakeDamage(const CTakeDamageInfo &
inputInfo={...}) Line 1204 + 0xd bytes C++
server.dll!CCollisionEvent::UpdateDamageEvents() Line 1642 C++
server.dll!CCollisionEvent::PostSimulationFrame() Line 1499 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1206 C++
> server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
server.dll!InvokePerFrameMethod(void (void)* f=0x22198420, const char *
timed=0x2217bddf) Line 431 C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 1001 +
0x14 bytes C++
--
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Physics crash related (urgent).
Are you deleting the entities inside a callback form vphysics? e.g.
VPhysicsCollision? That can cause crashes. There should be code that
prevents that - i.e. UTIL_Remove() should actually add the object to a
list by calling PhysCallbackRemove() but I don't have the SDK code in
front of me so I can't check.
Jay
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of A.Oliver
> Sent: Monday, December 24, 2007 8:09 AM
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] Physics crash related (urgent).
>
> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ] Our recently
> released modification (Fistful of Frags) is suffering some
> stability issues. Hope someone can bring some light to these
> serious servers crashes. I posted another similar issue in
> this list, and as I said before, I never modified any part of
> the physics code. Now I'm starting to understand what's going
> on, seems like a physic entity was removed, but server is
> still trying to use it so finds a null pointer and crashes.
> Is that rigth?
>
> These issues were noticed only during maximum stress, once
> the mod was released. They may happen rarely or not, depends
> the way physics are stressed I guess.
>
> I'm using UTIL_Remove in several parts of the game, example:
> a cowboy hat is created (falls to ground), and after some
> seconds is deleted. There are other items deleted in a
> similar way. Should I use other method different from UTIL_Remove?
>
> And a last question. Can server performance ( low FPS) make
> these issues worse? Because they tend to happen more in our
> own server, which sometimes is even below 10 FPS.
>
> Hope this helps, these are 3 different call stacks we are
> seeing repitedly. If you need any other info plz let me know.
>
>
> > server.dll!AllocTouchLink() Line 361 + 0x41 bytes C++
>
> server.dll!CBaseEntity::PhysicsMarkEntityAsTouched(CBaseEntity
> * other=0x0d21e300) Line 850 + 0x5 bytes C++
>
> server.dll!CBaseEntity::PhysicsMarkEntitiesAsTouchingEventDriv
> en(CBaseEntity * other=0x, CGameTrace & trace={...})
> Line 908 C++
> server.dll!CCollisionEvent::DispatchStartTouch(CBaseEntity
> * pEntity0=0x0d21e300, CBaseEntity * pEntity1=0x0fdf0dd8,
> const Vector & point={...}, const Vector & normal={...})
> Line 1567 + 0x8c bytes C++
> server.dll!CCollisionEvent::UpdateTouchEvents() Line 1590 C++
> server.dll!PhysFrame(float deltaTime=0.01500) Line
> 1262 + 0xa bytes C++
> server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
> server.dll!InvokePerFrameMethod(void (void)* f=0x22198170,
> const char * timed=0x2217be3f) Line 431 C++
> server.dll!CServerGameDLL::GameFrame(bool simulating=true)
> Line 1001 + 0x14 bytes C++
>
> -
>
> > server.dll!CCollisionEvent::UpdateDamageEvents() Line 1624 + 0x8
> > bytes C++
> server.dll!CCollisionEvent::PostSimulationFrame() Line 1499 C++
> server.dll!PhysFrame(float deltaTime=0.01500) Line 1206 C++
> server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
> server.dll!InvokePerFrameMethod(void (void)* f=0x22198170,
> const char * timed=0x2217be3f) Line 431 C++
> server.dll!CServerGameDLL::GameFrame(bool simulating=true)
> Line 1001 + 0x14 bytes C++
>
>
> -
>
> server.dll!CBaseEntity::TakeDamage(const CTakeDamageInfo &
> inputInfo={...}) Line 1204 + 0xd bytes C++
> server.dll!CCollisionEvent::UpdateDamageEvents() Line 1642 C++
> server.dll!CCollisionEvent::PostSimulationFrame() Line 1499 C++
> server.dll!PhysFrame(float deltaTime=0.01500) Line 1206 C++
> > server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
> server.dll!InvokePerFrameMethod(void (void)* f=0x22198420,
> const char * timed=0x2217bddf) Line 431 C++
> server.dll!CServerGameDLL::GameFrame(bool simulating=true)
> Line 1001 + 0x14 bytes C++
> --
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics crash related (urgent).
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Our recently released modification (Fistful of Frags) is suffering some
stability issues. Hope someone can bring some light to these serious servers
crashes. I posted another similar issue in this list, and as I said before, I
never modified any part of the physics code. Now I'm starting to understand
what's going on, seems like a physic entity was removed, but server is still
trying to use it so finds a null pointer and crashes. Is that rigth?
These issues were noticed only during maximum stress, once the mod was
released. They may happen rarely or not, depends the way physics are stressed I
guess.
I'm using UTIL_Remove in several parts of the game, example: a cowboy hat is
created (falls to ground), and after some seconds is deleted. There are other
items deleted in a similar way. Should I use other method different from
UTIL_Remove?
And a last question. Can server performance ( low FPS) make these issues worse?
Because they tend to happen more in our own server, which sometimes is even
below 10 FPS.
Hope this helps, these are 3 different call stacks we are seeing repitedly. If
you need any other info plz let me know.
> server.dll!AllocTouchLink() Line 361 + 0x41 bytes C++
server.dll!CBaseEntity::PhysicsMarkEntityAsTouched(CBaseEntity *
other=0x0d21e300) Line 850 + 0x5 bytes C++
server.dll!CBaseEntity::PhysicsMarkEntitiesAsTouchingEventDriven(CBaseEntity
* other=0x, CGameTrace & trace={...}) Line 908 C++
server.dll!CCollisionEvent::DispatchStartTouch(CBaseEntity *
pEntity0=0x0d21e300, CBaseEntity * pEntity1=0x0fdf0dd8, const Vector &
point={...}, const Vector & normal={...}) Line 1567 + 0x8c bytes C++
server.dll!CCollisionEvent::UpdateTouchEvents() Line 1590 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1262 + 0xa bytes C++
server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
server.dll!InvokePerFrameMethod(void (void)* f=0x22198170, const char *
timed=0x2217be3f) Line 431 C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 1001 + 0x14
bytes C++
-
> server.dll!CCollisionEvent::UpdateDamageEvents() Line 1624 + 0x8 bytes C++
server.dll!CCollisionEvent::PostSimulationFrame() Line 1499 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1206 C++
server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
server.dll!InvokePerFrameMethod(void (void)* f=0x22198170, const char *
timed=0x2217be3f) Line 431 C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 1001 + 0x14
bytes C++
-
server.dll!CBaseEntity::TakeDamage(const CTakeDamageInfo & inputInfo={...})
Line 1204 + 0xd bytes C++
server.dll!CCollisionEvent::UpdateDamageEvents() Line 1642 C++
server.dll!CCollisionEvent::PostSimulationFrame() Line 1499 C++
server.dll!PhysFrame(float deltaTime=0.01500) Line 1206 C++
> server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 271 C++
server.dll!InvokePerFrameMethod(void (void)* f=0x22198420, const char *
timed=0x2217bddf) Line 431 C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 1001 + 0x14
bytes C++
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics on live npcs?!
Done.
http://developer.valvesoftware.com/wiki/%24jigglebone
Ryan Sheffer wrote:
Just create a stub for it and throw the cleanup flag on top. Someone
is bound to see it and clean up the article.
On Nov 10, 2007 9:15 PM, Jake Breen <[EMAIL PROTECTED]> wrote:
Never mind about creating that article, can't describe how they work :x
Jake Breen wrote:
I'll try and start an article about it...also
Proof of concept - Hair
http://youtube.com/watch?v=4cc6N8mWPRg
OvermindDL1 wrote:
Could someone somewhat knowledgable in this area make sure it gets
posted to the valve dev wiki?
On 11/10/07, Tony omega Sergi <[EMAIL PROTECTED]> wrote:
Ah, that's pretty cool.
I didn't rotate the model around really fast so i didn't see it at
all ;(
On Nov 10, 2007 9:54 PM, Jake Breen <[EMAIL PROTECTED]>
wrote:
Lovely, just lovely!! Thanks Jay!
Jay Stelly wrote:
Yeah - we call that "jiggle bones" - there's a little simulator
you can
configure in your qc with the orange box engine. It's something
one of
the Turtle Rock guys developed for CS:S or L4D. You can see the
simulation in hlmv. I don't know if there is a doc for them yet, but
here's the qc from the antlion worker for example:
//
// jiggle bones for antlion worker
//
$jigglebone "Antlion.AntR_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 8
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 10
length 5
angle_constraint 20
}
}
$jigglebone "Antlion.AntL_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 7
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 15
length 5
angle_constraint 20
}
}
$jigglebone "Antlion.glasswingR_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 6
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 5
length 30
angle_constraint 37
}
}
$jigglebone "Antlion.glasswingL_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 5
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 5
length 30
angle_constraint 40
}
}
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kori
Sent: Saturday, November 10, 2007 5:44 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physics on live npcs?!
Holy, I never noticed that before. I'd like to know how its
done as well.
- Original Message -
From: "Jake Breen" <[EMAIL PROTECTED]>
To:
Sent: Saturday, November 10, 2007 8:05 PM
Subject: Re: [hlcoders] Physics on live npcs?!
http://youtube.com/watch?v=o9OpKjq8Uos
made a short video showing the live physics. You can see
they bounce
around with the movement of the camera.
Tony "omega" Sergi wrote:
you must have different models than i do.
On Nov 10, 2007 6:50 PM, Jake Breen
<[EMAIL PROTECTED]>
wrote:
Chell's hair, and the antlion workers wings both move
along with the
camera, and in animations, are not from the actual animation.
Tony "omega" Sergi wrote:
how do you figure they have live physics?
at least, chells hair for example. her hair doesn't even move
seperately from the head, there is only the one bone that the
ponytail is attached to.. and.
as for the antlion workers..they just have a bone follower thing
like the strider legs for the ragdolls.
the wings just move in an animation.
On Nov 10, 2007 5:54 PM, Jake Breen
<[EMAIL PROTECTED]>
wrote:
Decompiled it and cannot find any line with the bone ponytail
besides the hitbox info..
Tobias Kammersgaard wrote:
--
[ Picked text/plain from multipart/alternative ] Tried
decompiling the model :-)?
/ProZak
On 10/11/2007, Jake Breen
<[EMAIL PROTECTED]> wrote:
I just noticed The Antlion Worker's wings and such,
and Chell's
hair have live physics. I was wondering how do you do
this? Or
if anyone outside of Valve knows..
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit
Re: [hlcoders] Physics on live npcs?!
Just create a stub for it and throw the cleanup flag on top. Someone
is bound to see it and clean up the article.
On Nov 10, 2007 9:15 PM, Jake Breen <[EMAIL PROTECTED]> wrote:
> Never mind about creating that article, can't describe how they work :x
>
>
> Jake Breen wrote:
> > I'll try and start an article about it...also
> >
> > Proof of concept - Hair
> > http://youtube.com/watch?v=4cc6N8mWPRg
> >
> > OvermindDL1 wrote:
> >> Could someone somewhat knowledgable in this area make sure it gets
> >> posted to the valve dev wiki?
> >>
> >> On 11/10/07, Tony omega Sergi <[EMAIL PROTECTED]> wrote:
> >>
> >>> Ah, that's pretty cool.
> >>>
> >>> I didn't rotate the model around really fast so i didn't see it at
> >>> all ;(
> >>>
> >>>
> >>> On Nov 10, 2007 9:54 PM, Jake Breen <[EMAIL PROTECTED]>
> >>> wrote:
> >>>
> >>>> Lovely, just lovely!! Thanks Jay!
> >>>>
> >>>>
> >>>> Jay Stelly wrote:
> >>>>
> >>>>> Yeah - we call that "jiggle bones" - there's a little simulator
> >>>>> you can
> >>>>> configure in your qc with the orange box engine. It's something
> >>>>> one of
> >>>>> the Turtle Rock guys developed for CS:S or L4D. You can see the
> >>>>> simulation in hlmv. I don't know if there is a doc for them yet, but
> >>>>> here's the qc from the antlion worker for example:
> >>>>>
> >>>>> //
> >>>>> // jiggle bones for antlion worker
> >>>>> //
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> $jigglebone "Antlion.AntR_bone" {
> >>>>> is_flexible {
> >>>>> yaw_stiffness 700
> >>>>> yaw_damping 8
> >>>>> //yaw_constraint 30 -30
> >>>>> pitch_stiffness 700
> >>>>> pitch_damping 8
> >>>>> //pitch_constraint 30 -30
> >>>>> tip_mass 10
> >>>>> length 5
> >>>>> angle_constraint 20
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> $jigglebone "Antlion.AntL_bone" {
> >>>>> is_flexible {
> >>>>> yaw_stiffness 700
> >>>>> yaw_damping 7
> >>>>> //yaw_constraint 30 -30
> >>>>> pitch_stiffness 700
> >>>>> pitch_damping 8
> >>>>> //pitch_constraint 30 -30
> >>>>> tip_mass 15
> >>>>> length 5
> >>>>> angle_constraint 20
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> $jigglebone "Antlion.glasswingR_bone" {
> >>>>> is_flexible {
> >>>>> yaw_stiffness 700
> >>>>> yaw_damping 6
> >>>>> //yaw_constraint 30 -30
> >>>>> pitch_stiffness 700
> >>>>> pitch_damping 8
> >>>>> //pitch_constraint 30 -30
> >>>>> tip_mass 5
> >>>>> length 30
> >>>>> angle_constraint 37
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> $jigglebone "Antlion.glasswingL_bone" {
> >>>>> is_flexible {
> >>>>> yaw_stiffness 700
> >>>>> yaw_damping 5
> >>>>> //yaw_constraint 30 -30
> >>>>> pitch_stiffness 700
> >>>>> pitch_damping 8
> >>>>> //pitch_constraint 30 -30
> >>>>> tip_mass 5
> >>>>> length 30
> >>>>> angle_constraint 40
> >>>>> }
> >>>>> }
> >>>>>
> >>>>>
> >>>>> Jay
> >>>>>
> >
Re: [hlcoders] Physics on live npcs?!
Never mind about creating that article, can't describe how they work :x
Jake Breen wrote:
I'll try and start an article about it...also
Proof of concept - Hair
http://youtube.com/watch?v=4cc6N8mWPRg
OvermindDL1 wrote:
Could someone somewhat knowledgable in this area make sure it gets
posted to the valve dev wiki?
On 11/10/07, Tony omega Sergi <[EMAIL PROTECTED]> wrote:
Ah, that's pretty cool.
I didn't rotate the model around really fast so i didn't see it at
all ;(
On Nov 10, 2007 9:54 PM, Jake Breen <[EMAIL PROTECTED]>
wrote:
Lovely, just lovely!! Thanks Jay!
Jay Stelly wrote:
Yeah - we call that "jiggle bones" - there's a little simulator
you can
configure in your qc with the orange box engine. It's something
one of
the Turtle Rock guys developed for CS:S or L4D. You can see the
simulation in hlmv. I don't know if there is a doc for them yet, but
here's the qc from the antlion worker for example:
//
// jiggle bones for antlion worker
//
$jigglebone "Antlion.AntR_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 8
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 10
length 5
angle_constraint 20
}
}
$jigglebone "Antlion.AntL_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 7
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 15
length 5
angle_constraint 20
}
}
$jigglebone "Antlion.glasswingR_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 6
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 5
length 30
angle_constraint 37
}
}
$jigglebone "Antlion.glasswingL_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 5
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 5
length 30
angle_constraint 40
}
}
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kori
Sent: Saturday, November 10, 2007 5:44 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physics on live npcs?!
Holy, I never noticed that before. I'd like to know how its
done as well.
- Original Message -----
From: "Jake Breen" <[EMAIL PROTECTED]>
To:
Sent: Saturday, November 10, 2007 8:05 PM
Subject: Re: [hlcoders] Physics on live npcs?!
http://youtube.com/watch?v=o9OpKjq8Uos
made a short video showing the live physics. You can see
they bounce
around with the movement of the camera.
Tony "omega" Sergi wrote:
you must have different models than i do.
On Nov 10, 2007 6:50 PM, Jake Breen
<[EMAIL PROTECTED]>
wrote:
Chell's hair, and the antlion workers wings both move
along with the
camera, and in animations, are not from the actual animation.
Tony "omega" Sergi wrote:
how do you figure they have live physics?
at least, chells hair for example. her hair doesn't even move
seperately from the head, there is only the one bone that the
ponytail is attached to.. and.
as for the antlion workers..they just have a bone follower thing
like the strider legs for the ragdolls.
the wings just move in an animation.
On Nov 10, 2007 5:54 PM, Jake Breen
<[EMAIL PROTECTED]>
wrote:
Decompiled it and cannot find any line with the bone ponytail
besides the hitbox info..
Tobias Kammersgaard wrote:
--
[ Picked text/plain from multipart/alternative ] Tried
decompiling the model :-)?
/ProZak
On 10/11/2007, Jake Breen
<[EMAIL PROTECTED]> wrote:
I just noticed The Antlion Worker's wings and such,
and Chell's
hair have live physics. I was wondering how do you do
this? Or
if anyone outside of Valve knows..
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
-omega
__
Re: [hlcoders] Physics on live npcs?!
I'll try and start an article about it...also
Proof of concept - Hair
http://youtube.com/watch?v=4cc6N8mWPRg
OvermindDL1 wrote:
Could someone somewhat knowledgable in this area make sure it gets
posted to the valve dev wiki?
On 11/10/07, Tony omega Sergi <[EMAIL PROTECTED]> wrote:
Ah, that's pretty cool.
I didn't rotate the model around really fast so i didn't see it at all ;(
On Nov 10, 2007 9:54 PM, Jake Breen <[EMAIL PROTECTED]> wrote:
Lovely, just lovely!! Thanks Jay!
Jay Stelly wrote:
Yeah - we call that "jiggle bones" - there's a little simulator you can
configure in your qc with the orange box engine. It's something one of
the Turtle Rock guys developed for CS:S or L4D. You can see the
simulation in hlmv. I don't know if there is a doc for them yet, but
here's the qc from the antlion worker for example:
//
// jiggle bones for antlion worker
//
$jigglebone "Antlion.AntR_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 8
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 10
length 5
angle_constraint 20
}
}
$jigglebone "Antlion.AntL_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 7
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 15
length 5
angle_constraint 20
}
}
$jigglebone "Antlion.glasswingR_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 6
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 5
length 30
angle_constraint 37
}
}
$jigglebone "Antlion.glasswingL_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 5
//yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
//pitch_constraint 30 -30
tip_mass 5
length 30
angle_constraint 40
}
}
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kori
Sent: Saturday, November 10, 2007 5:44 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physics on live npcs?!
Holy, I never noticed that before. I'd like to know how its
done as well.
- Original Message -
From: "Jake Breen" <[EMAIL PROTECTED]>
To:
Sent: Saturday, November 10, 2007 8:05 PM
Subject: Re: [hlcoders] Physics on live npcs?!
http://youtube.com/watch?v=o9OpKjq8Uos
made a short video showing the live physics. You can see
they bounce
around with the movement of the camera.
Tony "omega" Sergi wrote:
you must have different models than i do.
On Nov 10, 2007 6:50 PM, Jake Breen <[EMAIL PROTECTED]>
wrote:
Chell's hair, and the antlion workers wings both move
along with the
camera, and in animations, are not from the actual animation.
Tony "omega" Sergi wrote:
how do you figure they have live physics?
at least, chells hair for example. her hair doesn't even move
seperately from the head, there is only the one bone that the
ponytail is attached to.. and.
as for the antlion workers..they just have a bone follower thing
like the strider legs for the ragdolls.
the wings just move in an animation.
On Nov 10, 2007 5:54 PM, Jake Breen
<[EMAIL PROTECTED]>
wrote:
Decompiled it and cannot find any line with the bone ponytail
besides the hitbox info..
Tobias Kammersgaard wrote:
--
[ Picked text/plain from multipart/alternative ] Tried
decompiling the model :-)?
/ProZak
On 10/11/2007, Jake Breen
<[EMAIL PROTECTED]> wrote:
I just noticed The Antlion Worker's wings and such,
and Chell's
hair have live physics. I was wondering how do you do
this? Or
if anyone outside of Valve knows..
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
-omega
___
To unsubscribe, edit your list preferences, or view the list
archives,
Re: [hlcoders] Physics on live npcs?!
Could someone somewhat knowledgable in this area make sure it gets
posted to the valve dev wiki?
On 11/10/07, Tony omega Sergi <[EMAIL PROTECTED]> wrote:
> Ah, that's pretty cool.
>
> I didn't rotate the model around really fast so i didn't see it at all ;(
>
>
> On Nov 10, 2007 9:54 PM, Jake Breen <[EMAIL PROTECTED]> wrote:
> > Lovely, just lovely!! Thanks Jay!
> >
> >
> > Jay Stelly wrote:
> > > Yeah - we call that "jiggle bones" - there's a little simulator you can
> > > configure in your qc with the orange box engine. It's something one of
> > > the Turtle Rock guys developed for CS:S or L4D. You can see the
> > > simulation in hlmv. I don't know if there is a doc for them yet, but
> > > here's the qc from the antlion worker for example:
> > >
> > > //
> > > // jiggle bones for antlion worker
> > > //
> > >
> > >
> > >
> > >
> > > $jigglebone "Antlion.AntR_bone" {
> > > is_flexible {
> > > yaw_stiffness 700
> > > yaw_damping 8
> > > //yaw_constraint 30 -30
> > > pitch_stiffness 700
> > > pitch_damping 8
> > > //pitch_constraint 30 -30
> > > tip_mass 10
> > > length 5
> > > angle_constraint 20
> > > }
> > > }
> > >
> > > $jigglebone "Antlion.AntL_bone" {
> > > is_flexible {
> > > yaw_stiffness 700
> > > yaw_damping 7
> > > //yaw_constraint 30 -30
> > > pitch_stiffness 700
> > > pitch_damping 8
> > > //pitch_constraint 30 -30
> > > tip_mass 15
> > > length 5
> > > angle_constraint 20
> > > }
> > > }
> > >
> > > $jigglebone "Antlion.glasswingR_bone" {
> > > is_flexible {
> > > yaw_stiffness 700
> > > yaw_damping 6
> > > //yaw_constraint 30 -30
> > > pitch_stiffness 700
> > > pitch_damping 8
> > > //pitch_constraint 30 -30
> > > tip_mass 5
> > > length 30
> > > angle_constraint 37
> > > }
> > > }
> > >
> > > $jigglebone "Antlion.glasswingL_bone" {
> > > is_flexible {
> > > yaw_stiffness 700
> > > yaw_damping 5
> > > //yaw_constraint 30 -30
> > > pitch_stiffness 700
> > > pitch_damping 8
> > > //pitch_constraint 30 -30
> > > tip_mass 5
> > > length 30
> > > angle_constraint 40
> > > }
> > > }
> > >
> > >
> > > Jay
> > >
> > >
> > >
> > >> -Original Message-
> > >> From: [EMAIL PROTECTED]
> > >> [mailto:[EMAIL PROTECTED] On Behalf Of Kori
> > >> Sent: Saturday, November 10, 2007 5:44 PM
> > >> To: hlcoders@list.valvesoftware.com
> > >> Subject: Re: [hlcoders] Physics on live npcs?!
> > >>
> > >> Holy, I never noticed that before. I'd like to know how its
> > >> done as well.
> > >> - Original Message -
> > >> From: "Jake Breen" <[EMAIL PROTECTED]>
> > >> To:
> > >> Sent: Saturday, November 10, 2007 8:05 PM
> > >> Subject: Re: [hlcoders] Physics on live npcs?!
> > >>
> > >>
> > >>
> > >>> http://youtube.com/watch?v=o9OpKjq8Uos
> > >>> made a short video showing the live physics. You can see
> > >>>
> > >> they bounce
> > >>
> > >>> around with the movement of the camera.
> > >>>
> > >>> Tony "omega" Sergi wrote:
> > >>>
> > >>>> you must have different models than i do.
> > >>>>
> > >>>>
> > >>>> On Nov 10, 2007 6:50 PM, Jake Breen <[EMAIL PROTECTED]>
> > >>>> wrote:
> > >>>>
> > >>>>
> > >>>>> Chell's hair, and the antlion workers wings both move
> >
Re: [hlcoders] Physics on live npcs?!
Ah, that's pretty cool.
I didn't rotate the model around really fast so i didn't see it at all ;(
On Nov 10, 2007 9:54 PM, Jake Breen <[EMAIL PROTECTED]> wrote:
> Lovely, just lovely!! Thanks Jay!
>
>
> Jay Stelly wrote:
> > Yeah - we call that "jiggle bones" - there's a little simulator you can
> > configure in your qc with the orange box engine. It's something one of
> > the Turtle Rock guys developed for CS:S or L4D. You can see the
> > simulation in hlmv. I don't know if there is a doc for them yet, but
> > here's the qc from the antlion worker for example:
> >
> > //
> > // jiggle bones for antlion worker
> > //
> >
> >
> >
> >
> > $jigglebone "Antlion.AntR_bone" {
> > is_flexible {
> > yaw_stiffness 700
> > yaw_damping 8
> > //yaw_constraint 30 -30
> > pitch_stiffness 700
> > pitch_damping 8
> > //pitch_constraint 30 -30
> > tip_mass 10
> > length 5
> > angle_constraint 20
> > }
> > }
> >
> > $jigglebone "Antlion.AntL_bone" {
> > is_flexible {
> > yaw_stiffness 700
> > yaw_damping 7
> > //yaw_constraint 30 -30
> > pitch_stiffness 700
> > pitch_damping 8
> > //pitch_constraint 30 -30
> > tip_mass 15
> > length 5
> > angle_constraint 20
> > }
> > }
> >
> > $jigglebone "Antlion.glasswingR_bone" {
> > is_flexible {
> > yaw_stiffness 700
> > yaw_damping 6
> > //yaw_constraint 30 -30
> > pitch_stiffness 700
> > pitch_damping 8
> > //pitch_constraint 30 -30
> > tip_mass 5
> > length 30
> > angle_constraint 37
> > }
> > }
> >
> > $jigglebone "Antlion.glasswingL_bone" {
> > is_flexible {
> > yaw_stiffness 700
> > yaw_damping 5
> > //yaw_constraint 30 -30
> > pitch_stiffness 700
> > pitch_damping 8
> > //pitch_constraint 30 -30
> > tip_mass 5
> > length 30
> > angle_constraint 40
> > }
> > }
> >
> >
> > Jay
> >
> >
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Kori
> >> Sent: Saturday, November 10, 2007 5:44 PM
> >> To: hlcoders@list.valvesoftware.com
> >> Subject: Re: [hlcoders] Physics on live npcs?!
> >>
> >> Holy, I never noticed that before. I'd like to know how its
> >> done as well.
> >> - Original Message -
> >> From: "Jake Breen" <[EMAIL PROTECTED]>
> >> To:
> >> Sent: Saturday, November 10, 2007 8:05 PM
> >> Subject: Re: [hlcoders] Physics on live npcs?!
> >>
> >>
> >>
> >>> http://youtube.com/watch?v=o9OpKjq8Uos
> >>> made a short video showing the live physics. You can see
> >>>
> >> they bounce
> >>
> >>> around with the movement of the camera.
> >>>
> >>> Tony "omega" Sergi wrote:
> >>>
> >>>> you must have different models than i do.
> >>>>
> >>>>
> >>>> On Nov 10, 2007 6:50 PM, Jake Breen <[EMAIL PROTECTED]>
> >>>> wrote:
> >>>>
> >>>>
> >>>>> Chell's hair, and the antlion workers wings both move
> >>>>>
> >> along with the
> >>
> >>>>> camera, and in animations, are not from the actual animation.
> >>>>>
> >>>>>
> >>>>> Tony "omega" Sergi wrote:
> >>>>>
> >>>>>
> >>>>>> how do you figure they have live physics?
> >>>>>> at least, chells hair for example. her hair doesn't even move
> >>>>>> seperately from the head, there is only the one bone that the
> >>>>>> ponytail is attached to.. and.
> >>>>>> as for the antlion workers..they just have a bone foll
Re: [hlcoders] Physics on live npcs?!
Lovely, just lovely!! Thanks Jay!
Jay Stelly wrote:
Yeah - we call that "jiggle bones" - there's a little simulator you can
configure in your qc with the orange box engine. It's something one of
the Turtle Rock guys developed for CS:S or L4D. You can see the
simulation in hlmv. I don't know if there is a doc for them yet, but
here's the qc from the antlion worker for example:
//
// jiggle bones for antlion worker
//
$jigglebone "Antlion.AntR_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 8
// yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
// pitch_constraint 30 -30
tip_mass 10
length 5
angle_constraint 20
}
}
$jigglebone "Antlion.AntL_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 7
// yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
// pitch_constraint 30 -30
tip_mass 15
length 5
angle_constraint 20
}
}
$jigglebone "Antlion.glasswingR_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 6
// yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
// pitch_constraint 30 -30
tip_mass 5
length 30
angle_constraint 37
}
}
$jigglebone "Antlion.glasswingL_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 5
// yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
// pitch_constraint 30 -30
tip_mass 5
length 30
angle_constraint 40
}
}
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kori
Sent: Saturday, November 10, 2007 5:44 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physics on live npcs?!
Holy, I never noticed that before. I'd like to know how its
done as well.
- Original Message -
From: "Jake Breen" <[EMAIL PROTECTED]>
To:
Sent: Saturday, November 10, 2007 8:05 PM
Subject: Re: [hlcoders] Physics on live npcs?!
http://youtube.com/watch?v=o9OpKjq8Uos
made a short video showing the live physics. You can see
they bounce
around with the movement of the camera.
Tony "omega" Sergi wrote:
you must have different models than i do.
On Nov 10, 2007 6:50 PM, Jake Breen <[EMAIL PROTECTED]>
wrote:
Chell's hair, and the antlion workers wings both move
along with the
camera, and in animations, are not from the actual animation.
Tony "omega" Sergi wrote:
how do you figure they have live physics?
at least, chells hair for example. her hair doesn't even move
seperately from the head, there is only the one bone that the
ponytail is attached to.. and.
as for the antlion workers..they just have a bone follower thing
like the strider legs for the ragdolls.
the wings just move in an animation.
On Nov 10, 2007 5:54 PM, Jake Breen
<[EMAIL PROTECTED]>
wrote:
Decompiled it and cannot find any line with the bone ponytail
besides the hitbox info..
Tobias Kammersgaard wrote:
--
[ Picked text/plain from multipart/alternative ] Tried
decompiling the model :-)?
/ProZak
On 10/11/2007, Jake Breen
<[EMAIL PROTECTED]> wrote:
I just noticed The Antlion Worker's wings and such,
and Chell's
hair have live physics. I was wondering how do you do
this? Or
if anyone outside of Valve knows..
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
-omega
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
-omega
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http:/
RE: [hlcoders] Physics on live npcs?!
Yeah - we call that "jiggle bones" - there's a little simulator you can
configure in your qc with the orange box engine. It's something one of
the Turtle Rock guys developed for CS:S or L4D. You can see the
simulation in hlmv. I don't know if there is a doc for them yet, but
here's the qc from the antlion worker for example:
//
// jiggle bones for antlion worker
//
$jigglebone "Antlion.AntR_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 8
// yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
// pitch_constraint 30 -30
tip_mass 10
length 5
angle_constraint 20
}
}
$jigglebone "Antlion.AntL_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 7
// yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
// pitch_constraint 30 -30
tip_mass 15
length 5
angle_constraint 20
}
}
$jigglebone "Antlion.glasswingR_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 6
// yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
// pitch_constraint 30 -30
tip_mass 5
length 30
angle_constraint 37
}
}
$jigglebone "Antlion.glasswingL_bone" {
is_flexible {
yaw_stiffness 700
yaw_damping 5
// yaw_constraint 30 -30
pitch_stiffness 700
pitch_damping 8
// pitch_constraint 30 -30
tip_mass 5
length 30
angle_constraint 40
}
}
Jay
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kori
> Sent: Saturday, November 10, 2007 5:44 PM
> To: hlcoders@list.valvesoftware.com
> Subject: Re: [hlcoders] Physics on live npcs?!
>
> Holy, I never noticed that before. I'd like to know how its
> done as well.
> - Original Message -
> From: "Jake Breen" <[EMAIL PROTECTED]>
> To:
> Sent: Saturday, November 10, 2007 8:05 PM
> Subject: Re: [hlcoders] Physics on live npcs?!
>
>
> > http://youtube.com/watch?v=o9OpKjq8Uos
> > made a short video showing the live physics. You can see
> they bounce
> > around with the movement of the camera.
> >
> > Tony "omega" Sergi wrote:
> >> you must have different models than i do.
> >>
> >>
> >> On Nov 10, 2007 6:50 PM, Jake Breen <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> Chell's hair, and the antlion workers wings both move
> along with the
> >>> camera, and in animations, are not from the actual animation.
> >>>
> >>>
> >>> Tony "omega" Sergi wrote:
> >>>
> >>>> how do you figure they have live physics?
> >>>> at least, chells hair for example. her hair doesn't even move
> >>>> seperately from the head, there is only the one bone that the
> >>>> ponytail is attached to.. and.
> >>>> as for the antlion workers..they just have a bone follower thing
> >>>> like the strider legs for the ragdolls.
> >>>> the wings just move in an animation.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Nov 10, 2007 5:54 PM, Jake Breen
> <[EMAIL PROTECTED]>
> >>>> wrote:
> >>>>
> >>>>
> >>>>> Decompiled it and cannot find any line with the bone ponytail
> >>>>> besides the hitbox info..
> >>>>>
> >>>>>
> >>>>> Tobias Kammersgaard wrote:
> >>>>>
> >>>>>
> >>>>>> --
> >>>>>> [ Picked text/plain from multipart/alternative ] Tried
> >>>>>> decompiling the model :-)?
> >>>>>>
> >>>>>> /ProZak
> >>>>>>
> >>>>>>
> >>>>>> On 10/11/2007, Jake Breen
> <[EMAIL PROTECTED]> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> I just noticed The Antlion Worker's wings and such,
> and Chell's
> >>>>>>> hair have live physics. I was wondering how do you do
> this? Or
> >>>>>>> if
Re: [hlcoders] Physics on live npcs?!
The decompiler is not setup for this model version. The fact that it even works at all is great. Chris - Original Message - From: "Jake Breen" <[EMAIL PROTECTED]> To: Sent: Saturday, November 10, 2007 5:54 PM Subject: Re: [hlcoders] Physics on live npcs?! Decompiled it and cannot find any line with the bone ponytail besides the hitbox info.. Tobias Kammersgaard wrote: -- [ Picked text/plain from multipart/alternative ] Tried decompiling the model :-)? /ProZak On 10/11/2007, Jake Breen <[EMAIL PROTECTED]> wrote: I just noticed The Antlion Worker's wings and such, and Chell's hair have live physics. I was wondering how do you do this? Or if anyone outside of Valve knows.. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics on live npcs?!
Holy, I never noticed that before. I'd like to know how its done as well. - Original Message - From: "Jake Breen" <[EMAIL PROTECTED]> To: Sent: Saturday, November 10, 2007 8:05 PM Subject: Re: [hlcoders] Physics on live npcs?! http://youtube.com/watch?v=o9OpKjq8Uos made a short video showing the live physics. You can see they bounce around with the movement of the camera. Tony "omega" Sergi wrote: you must have different models than i do. On Nov 10, 2007 6:50 PM, Jake Breen <[EMAIL PROTECTED]> wrote: Chell's hair, and the antlion workers wings both move along with the camera, and in animations, are not from the actual animation. Tony "omega" Sergi wrote: how do you figure they have live physics? at least, chells hair for example. her hair doesn't even move seperately from the head, there is only the one bone that the ponytail is attached to.. and. as for the antlion workers..they just have a bone follower thing like the strider legs for the ragdolls. the wings just move in an animation. On Nov 10, 2007 5:54 PM, Jake Breen <[EMAIL PROTECTED]> wrote: Decompiled it and cannot find any line with the bone ponytail besides the hitbox info.. Tobias Kammersgaard wrote: -- [ Picked text/plain from multipart/alternative ] Tried decompiling the model :-)? /ProZak On 10/11/2007, Jake Breen <[EMAIL PROTECTED]> wrote: I just noticed The Antlion Worker's wings and such, and Chell's hair have live physics. I was wondering how do you do this? Or if anyone outside of Valve knows.. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- -omega ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- -omega ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics on live npcs?!
Yeah I noticed the same thing and had a thousand ideas.. I wouldn't mind knowing the QC set-up fo this. - Jed On 11/11/2007, Jake Breen <[EMAIL PROTECTED]> wrote: > http://youtube.com/watch?v=o9OpKjq8Uos > made a short video showing the live physics. You can see they bounce > around with the movement of the camera. > > Tony "omega" Sergi wrote: > > you must have different models than i do. > > > > > > On Nov 10, 2007 6:50 PM, Jake Breen <[EMAIL PROTECTED]> wrote: > > > >> Chell's hair, and the antlion workers wings both move along with the > >> camera, and in animations, are not from the actual animation. > >> > >> > >> Tony "omega" Sergi wrote: > >> > >>> how do you figure they have live physics? > >>> at least, chells hair for example. her hair doesn't even move > >>> seperately from the head, there is only the one bone that the ponytail > >>> is attached to.. and. > >>> as for the antlion workers..they just have a bone follower thing like > >>> the strider legs for the ragdolls. > >>> the wings just move in an animation. > >>> > >>> > >>> > >>> > >>> On Nov 10, 2007 5:54 PM, Jake Breen <[EMAIL PROTECTED]> wrote: > >>> > >>> > Decompiled it and cannot find any line with the bone ponytail besides > the hitbox info.. > > > Tobias Kammersgaard wrote: > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Tried decompiling the model :-)? > > > > /ProZak > > > > > > On 10/11/2007, Jake Breen <[EMAIL PROTECTED]> wrote: > > > > > > > >> I just noticed The Antlion Worker's wings and such, and Chell's hair > >> have live physics. I was wondering how do you do this? Or if anyone > >> outside of Valve knows.. > >> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list archives, > >> please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > >> > >> > >> > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > >>> > >>> -- > >>> -omega > >>> > >>> ___ > >>> To unsubscribe, edit your list preferences, or view the list archives, > >>> please visit: > >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >>> > >>> > >>> > >>> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list archives, > >> please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > >> > > > > > > > > -- > > -omega > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics on live npcs?!
http://youtube.com/watch?v=o9OpKjq8Uos made a short video showing the live physics. You can see they bounce around with the movement of the camera. Tony "omega" Sergi wrote: you must have different models than i do. On Nov 10, 2007 6:50 PM, Jake Breen <[EMAIL PROTECTED]> wrote: Chell's hair, and the antlion workers wings both move along with the camera, and in animations, are not from the actual animation. Tony "omega" Sergi wrote: how do you figure they have live physics? at least, chells hair for example. her hair doesn't even move seperately from the head, there is only the one bone that the ponytail is attached to.. and. as for the antlion workers..they just have a bone follower thing like the strider legs for the ragdolls. the wings just move in an animation. On Nov 10, 2007 5:54 PM, Jake Breen <[EMAIL PROTECTED]> wrote: Decompiled it and cannot find any line with the bone ponytail besides the hitbox info.. Tobias Kammersgaard wrote: -- [ Picked text/plain from multipart/alternative ] Tried decompiling the model :-)? /ProZak On 10/11/2007, Jake Breen <[EMAIL PROTECTED]> wrote: I just noticed The Antlion Worker's wings and such, and Chell's hair have live physics. I was wondering how do you do this? Or if anyone outside of Valve knows.. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- -omega ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- -omega ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics on live npcs?!
you must have different models than i do. On Nov 10, 2007 6:50 PM, Jake Breen <[EMAIL PROTECTED]> wrote: > Chell's hair, and the antlion workers wings both move along with the > camera, and in animations, are not from the actual animation. > > > Tony "omega" Sergi wrote: > > how do you figure they have live physics? > > at least, chells hair for example. her hair doesn't even move > > seperately from the head, there is only the one bone that the ponytail > > is attached to.. and. > > as for the antlion workers..they just have a bone follower thing like > > the strider legs for the ragdolls. > > the wings just move in an animation. > > > > > > > > > > On Nov 10, 2007 5:54 PM, Jake Breen <[EMAIL PROTECTED]> wrote: > > > >> Decompiled it and cannot find any line with the bone ponytail besides > >> the hitbox info.. > >> > >> > >> Tobias Kammersgaard wrote: > >> > >>> -- > >>> [ Picked text/plain from multipart/alternative ] > >>> Tried decompiling the model :-)? > >>> > >>> /ProZak > >>> > >>> > >>> On 10/11/2007, Jake Breen <[EMAIL PROTECTED]> wrote: > >>> > >>> > I just noticed The Antlion Worker's wings and such, and Chell's hair > have live physics. I was wondering how do you do this? Or if anyone > outside of Valve knows.. > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > >>> -- > >>> > >>> ___ > >>> To unsubscribe, edit your list preferences, or view the list archives, > >>> please visit: > >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >>> > >>> > >>> > >>> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list archives, > >> please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > >> > > > > > > > > -- > > -omega > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- -omega ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics on live npcs?!
Chell's hair, and the antlion workers wings both move along with the camera, and in animations, are not from the actual animation. Tony "omega" Sergi wrote: how do you figure they have live physics? at least, chells hair for example. her hair doesn't even move seperately from the head, there is only the one bone that the ponytail is attached to.. and. as for the antlion workers..they just have a bone follower thing like the strider legs for the ragdolls. the wings just move in an animation. On Nov 10, 2007 5:54 PM, Jake Breen <[EMAIL PROTECTED]> wrote: Decompiled it and cannot find any line with the bone ponytail besides the hitbox info.. Tobias Kammersgaard wrote: -- [ Picked text/plain from multipart/alternative ] Tried decompiling the model :-)? /ProZak On 10/11/2007, Jake Breen <[EMAIL PROTECTED]> wrote: I just noticed The Antlion Worker's wings and such, and Chell's hair have live physics. I was wondering how do you do this? Or if anyone outside of Valve knows.. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- -omega ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics on live npcs?!
how do you figure they have live physics? at least, chells hair for example. her hair doesn't even move seperately from the head, there is only the one bone that the ponytail is attached to.. and. as for the antlion workers..they just have a bone follower thing like the strider legs for the ragdolls. the wings just move in an animation. On Nov 10, 2007 5:54 PM, Jake Breen <[EMAIL PROTECTED]> wrote: > Decompiled it and cannot find any line with the bone ponytail besides > the hitbox info.. > > > Tobias Kammersgaard wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > > Tried decompiling the model :-)? > > > > /ProZak > > > > > > On 10/11/2007, Jake Breen <[EMAIL PROTECTED]> wrote: > > > >> I just noticed The Antlion Worker's wings and such, and Chell's hair > >> have live physics. I was wondering how do you do this? Or if anyone > >> outside of Valve knows.. > >> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list archives, > >> please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > >> > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- -omega ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics on live npcs?!
Decompiled it and cannot find any line with the bone ponytail besides the hitbox info.. Tobias Kammersgaard wrote: -- [ Picked text/plain from multipart/alternative ] Tried decompiling the model :-)? /ProZak On 10/11/2007, Jake Breen <[EMAIL PROTECTED]> wrote: I just noticed The Antlion Worker's wings and such, and Chell's hair have live physics. I was wondering how do you do this? Or if anyone outside of Valve knows.. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics on live npcs?!
-- [ Picked text/plain from multipart/alternative ] Tried decompiling the model :-)? /ProZak On 10/11/2007, Jake Breen <[EMAIL PROTECTED]> wrote: > > I just noticed The Antlion Worker's wings and such, and Chell's hair > have live physics. I was wondering how do you do this? Or if anyone > outside of Valve knows.. > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics on live npcs?!
I just noticed The Antlion Worker's wings and such, and Chell's hair have live physics. I was wondering how do you do this? Or if anyone outside of Valve knows.. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Physics bounce sounds
Yes, only things that are MOVETYPE_VPHYSICS will run vphysics' collision system - so only those can generate sounds. Jay > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Saturday, July 07, 2007 12:24 PM > To: hlcoders@list.valvesoftware.com > Subject: RE: [hlcoders] Physics bounce sounds > > VPhysicsCollision() isn't overridden nor called, > PostCollision isn't called either. I take it the grenade > isn't considered a vphysics object at all? Is this because it's using > > SetMoveType( MOVETYPE_FLYGRAVITY, MOVECOLLIDE_FLY_CUSTOM ); > > rather than VPHYSICS? ( I tried changing it but keep hitting > asserts, and only want to allocate so much time per bug... a > long list to go ;) ). ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Physics bounce sounds
VPhysicsCollision() isn't overridden nor called, PostCollision isn't called either. I take it the grenade isn't considered a vphysics object at all? Is this because it's using SetMoveType( MOVETYPE_FLYGRAVITY, MOVECOLLIDE_FLY_CUSTOM ); rather than VPHYSICS? ( I tried changing it but keep hitting asserts, and only want to allocate so much time per bug... a long list to go ;) ). Anyway, I'll probably stick with a regular bounce sound anyway. I think gameplaywise it's more interesting for players to have a sound they know to be a grenade than more realistic yet less recognisable sounds. Thanks for the pointers! -- maarten > The sound is triggered by CBaseEntity's implementation of > VPhysicsCollision(). > If you've overridden that function in your leaf class without chaining > to the base class you'd lose physics sound/dust/etc effects. So that's > one possible cause. Otherwise set a breakpoint there (or in the caller: > PostCollision - src/dlls/physics.cpp) and step through the call when the > grenade bounces to see why no sound is played. > > Jay > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> [EMAIL PROTECTED] >> Sent: Saturday, July 07, 2007 11:48 AM >> To: hlcoders@list.valvesoftware.com >> Subject: Re: [hlcoders] Physics bounce sounds >> >> Aye, but the grenade has surfaceprop set to "metal", and we >> have no surfaceproperties files of our own so I take it we're >> using HL2 ones, so this should be valid if i'm not mistaken. >> >> > -- >> > [ Picked text/plain from multipart/alternative ] it has to >> do with the >> > surfaceprop that the grenade has. >> > and the surfaceprops text files in the scripts folder, to >> define them. >> > >> > On 7/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> >> >> Hi list, >> >> >> >> this is probably an easy question. Im grinding through our buglist >> >> and one of them is that our grenades do not have a bounce sound. I >> >> checked the code and there's an empty BounceSound function that is >> >> deliberately left empty since physics supposedly handles bounce >> >> sounds. I can add an EmitSound in the BounceSound function >> which does >> >> give me a bounce sound, but I'd much rather have surface-dependent >> >> bounce sounds than one hard-coded one. Any idea why these are not >> >> triggered when the (otherwise default SDK) grenade hits surfaces? >> >> >> >> Thanks >> >> >> >> -- maarten >> >> >> >> >> >> ___ >> >> To unsubscribe, edit your list preferences, or view the list >> >> archives, please visit: >> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> >> >> > >> > >> > -- >> > -omega >> > -- >> > >> > ___ >> > To unsubscribe, edit your list preferences, or view the >> list archives, >> > please visit: >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > >> > >> > >> >> >> >> ___ >> To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Physics bounce sounds
The sound is triggered by CBaseEntity's implementation of VPhysicsCollision(). If you've overridden that function in your leaf class without chaining to the base class you'd lose physics sound/dust/etc effects. So that's one possible cause. Otherwise set a breakpoint there (or in the caller: PostCollision - src/dlls/physics.cpp) and step through the call when the grenade bounces to see why no sound is played. Jay > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Saturday, July 07, 2007 11:48 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] Physics bounce sounds > > Aye, but the grenade has surfaceprop set to "metal", and we > have no surfaceproperties files of our own so I take it we're > using HL2 ones, so this should be valid if i'm not mistaken. > > > -- > > [ Picked text/plain from multipart/alternative ] it has to > do with the > > surfaceprop that the grenade has. > > and the surfaceprops text files in the scripts folder, to > define them. > > > > On 7/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> > >> Hi list, > >> > >> this is probably an easy question. Im grinding through our buglist > >> and one of them is that our grenades do not have a bounce sound. I > >> checked the code and there's an empty BounceSound function that is > >> deliberately left empty since physics supposedly handles bounce > >> sounds. I can add an EmitSound in the BounceSound function > which does > >> give me a bounce sound, but I'd much rather have surface-dependent > >> bounce sounds than one hard-coded one. Any idea why these are not > >> triggered when the (otherwise default SDK) grenade hits surfaces? > >> > >> Thanks > >> > >> -- maarten > >> > >> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list > >> archives, please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > > > > > > -- > > -omega > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the > list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics bounce sounds
Aye, but the grenade has surfaceprop set to "metal", and we have no surfaceproperties files of our own so I take it we're using HL2 ones, so this should be valid if i'm not mistaken. > -- > [ Picked text/plain from multipart/alternative ] > it has to do with the surfaceprop that the grenade has. > and the surfaceprops text files in the scripts folder, to define them. > > On 7/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> Hi list, >> >> this is probably an easy question. Im grinding through our buglist and >> one >> of them is that our grenades do not have a bounce sound. I checked the >> code and there's an empty BounceSound function that is deliberately left >> empty since physics supposedly handles bounce sounds. I can add an >> EmitSound in the BounceSound function which does give me a bounce sound, >> but I'd much rather have surface-dependent bounce sounds than one >> hard-coded one. Any idea why these are not triggered when the (otherwise >> default SDK) grenade hits surfaces? >> >> Thanks >> >> -- maarten >> >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > > > -- > -omega > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics bounce sounds
-- [ Picked text/plain from multipart/alternative ] it has to do with the surfaceprop that the grenade has. and the surfaceprops text files in the scripts folder, to define them. On 7/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi list, > > this is probably an easy question. Im grinding through our buglist and one > of them is that our grenades do not have a bounce sound. I checked the > code and there's an empty BounceSound function that is deliberately left > empty since physics supposedly handles bounce sounds. I can add an > EmitSound in the BounceSound function which does give me a bounce sound, > but I'd much rather have surface-dependent bounce sounds than one > hard-coded one. Any idea why these are not triggered when the (otherwise > default SDK) grenade hits surfaces? > > Thanks > > -- maarten > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- -omega -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics bounce sounds
Hi list, this is probably an easy question. Im grinding through our buglist and one of them is that our grenades do not have a bounce sound. I checked the code and there's an empty BounceSound function that is deliberately left empty since physics supposedly handles bounce sounds. I can add an EmitSound in the BounceSound function which does give me a bounce sound, but I'd much rather have surface-dependent bounce sounds than one hard-coded one. Any idea why these are not triggered when the (otherwise default SDK) grenade hits surfaces? Thanks -- maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] physics validation
Gravity is intentionally exaggerated in our games. Real-world gravity is ~386 in/sec^2. There are many factors which appear to affect the user perception of gravity relative to the rest of the game's presentation. I'd love to see some kind of research on this topic but I've yet to find any. Based on the testing we've done with our games we've found that exaggerated gravity is necessary - real world gravity makes objects in the game appear too light and/or too slow. Also note that we have a simple simulation of air resistance in our games. If you're trying to make a simulation using Source match up with a specific set of calculations you'll want to include air resistance or disable our simulator (set the air density to zero). The engine is doing a rigid body simulation that can be configured to be reasonably close to reality for objects that behavior like ideal rigid bodies. Jay > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Oliver > Sent: Monday, April 09, 2007 10:43 AM > To: hlcoders@list.valvesoftware.com > Subject: [hlcoders] physics validation > > -- > [ Picked text/plain from multipart/alternative ] Hi all, > > Our mod is a tool for teachers to create event-driven games > for their students. We need to evaluate the Source physics > engine to determine if teachers can create physics problems > with their games (i.e. there is an object with x mass, apply > y force vector to that object, it will go z distance). Has > anyone done tests to evaluate how closely the physics engine > emulates real life? > > Also, the gravity constant is set for either 600 or 800 > in/s^2. What was the design logic behind making this > different from Earth gravity by default (or have I done my > math wrong and it is the same)? > > Thanks! > -- > > ___ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] physics validation
-- [ Picked text/plain from multipart/alternative ] Hi all, Our mod is a tool for teachers to create event-driven games for their students. We need to evaluate the Source physics engine to determine if teachers can create physics problems with their games (i.e. there is an object with x mass, apply y force vector to that object, it will go z distance). Has anyone done tests to evaluate how closely the physics engine emulates real life? Also, the gravity constant is set for either 600 or 800 in/s^2. What was the design logic behind making this different from Earth gravity by default (or have I done my math wrong and it is the same)? Thanks! -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics props and players
-- [ Picked text/plain from multipart/alternative ] Since I have merged the recent EP1 update with the mod I work on, all our mappers physics props have stopped colliding with players. I was wondering if something went wrong during the merge or this was disabled in the latest source? They still collide with bullets, explosions, the world etc etc. Just not players. -- Lead Programmer for Resistance and Liberation www.resistanceandliberation.com -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
I'd seen this in my mod too and hadn't really had time to investigate.
Added a KI for this:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Bot_physics.2Fhitbox_not_accurate
At 2006/08/23 12:18 PM, Jeremy Swigart wrote:
>--
>[ Picked text/plain from multipart/alternative ]
>Thanks for the help. I put the code you posted above at the bottom of
>PhysicsSimulate wrapped in an IsBot check(since we dont subclass for bots).
>So far everything seems to work now. Hopefully there aren't unintended side
>effects.
>
>On 8/22/06, Paul Peloski <[EMAIL PROTECTED]> wrote:
>>
>> --
>> [ Picked text/plain from multipart/alternative ]
>> Well, I just tried this
>>
>> class CSDKBot ..
>> {
>> public:
>> ...
>> virtual void PhysicsSimulate()
>> {
>> BaseClass::PhysicsSimulate();
>>
>> // Since this isn't called for bots.. call it here?
>> UpdateVPhysicsPosition( m_vNewVPhysicsPosition,
>> m_vNewVPhysicsVelocity, gpGlobals->frametime );
>> }
>> ..
>> };
>>
>> It fixed the problem (ie, I can hit bots with combine ball now, so I'm
>> pretty sure their physics is following them around properly) and didn't
>> seem
>> to break anything..
>>
>> I think this is okay, what do you think Jay?
>> --
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>--
>
>___
>To unsubscribe, edit your list preferences, or view the list archives, please
>visit:
>http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
--
[ Picked text/plain from multipart/alternative ]
Thanks for the help. I put the code you posted above at the bottom of
PhysicsSimulate wrapped in an IsBot check(since we dont subclass for bots).
So far everything seems to work now. Hopefully there aren't unintended side
effects.
On 8/22/06, Paul Peloski <[EMAIL PROTECTED]> wrote:
>
> --
> [ Picked text/plain from multipart/alternative ]
> Well, I just tried this
>
> class CSDKBot ..
> {
> public:
> ...
> virtual void PhysicsSimulate()
> {
> BaseClass::PhysicsSimulate();
>
> // Since this isn't called for bots.. call it here?
> UpdateVPhysicsPosition( m_vNewVPhysicsPosition,
> m_vNewVPhysicsVelocity, gpGlobals->frametime );
> }
> ..
> };
>
> It fixed the problem (ie, I can hit bots with combine ball now, so I'm
> pretty sure their physics is following them around properly) and didn't
> seem
> to break anything..
>
> I think this is okay, what do you think Jay?
> --
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
--
[ Picked text/plain from multipart/alternative ]
Hmm, I didn't use m_vNewVPhysics* in my call. perhaps thats the problem. I
called UpdatePhysicsShadowToCurrentPosition(), which is apparently a rather
useless function. I'll try that when i get home. Thanks
On 8/22/06, Paul Peloski <[EMAIL PROTECTED]> wrote:
>
> --
> [ Picked text/plain from multipart/alternative ]
> Well, I just tried this
>
> class CSDKBot ..
> {
> public:
> ...
> virtual void PhysicsSimulate()
> {
> BaseClass::PhysicsSimulate();
>
> // Since this isn't called for bots.. call it here?
> UpdateVPhysicsPosition( m_vNewVPhysicsPosition,
> m_vNewVPhysicsVelocity, gpGlobals->frametime );
> }
> ..
> };
>
> It fixed the problem (ie, I can hit bots with combine ball now, so I'm
> pretty sure their physics is following them around properly) and didn't
> seem
> to break anything..
>
> I think this is okay, what do you think Jay?
> --
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
--
[ Picked text/plain from multipart/alternative ]
Well, I just tried this
class CSDKBot ..
{
public:
...
virtual void PhysicsSimulate()
{
BaseClass::PhysicsSimulate();
// Since this isn't called for bots.. call it here?
UpdateVPhysicsPosition( m_vNewVPhysicsPosition,
m_vNewVPhysicsVelocity, gpGlobals->frametime );
}
..
};
It fixed the problem (ie, I can hit bots with combine ball now, so I'm
pretty sure their physics is following them around properly) and didn't seem
to break anything..
I think this is okay, what do you think Jay?
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] Is there anything that would mess that up? I tried calling UpdatePhysicsShadowToCurrentPosition(), which calls UpdateVPhysicsPosition( GetAbsOrigin(), vec3_origin, gpGlobals->frametime ); but it didn't fix the problem. The blue box shown in the above linked screenshots remained stuck under the lift. The blue box is drawn at the location IPhysicsObject::GetPosition(), while the other is drawn at the players GetAbsOrigin(). It would seem that the calling of UpdateVPhysicsPosition( GetAbsOrigin(), vec3_origin, gpGlobals->frametime ); above would bring this physics object in sync with the entity, but it doesn't seem to. Is there a specific time that function should be called? I tried calling it right after the processing of the bots user command in CPlayerInfo::RunPlayerMove( CBotCmd *ucmd ) so far. I'm tempted to call m_pParent->VPhysicsGetObject()->SetPosition( GetAbsOrigin(), vec3_angle, true ); in there as well, but I don't want to cause any additional problems. Any ideas? J On 8/22/06, Jay Stelly <[EMAIL PROTECTED]> wrote: > > It's safe to call UpdateVPhysicsPosition() directly. It's setting a > target for the player's physics controller in the next frame of physics > simulation. > > Jay > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Jeremy Swigart > > Sent: Tuesday, August 22, 2006 8:35 AM > > To: hlcoders@list.valvesoftware.com > > Subject: Re: [hlcoders] Physics becoming out of sync > > > > -- > > [ Picked text/plain from multipart/alternative ] Thanks the > > help. Are you having the same problem with your bots or just > > going out of your way to be helpful? Either way I appreciate > > it. On further investigation, it appears the problem is due > > to the bots user commands going through a different code > > path. AFAIK, we're supposed to be calling > > > > RunPlayerMove(&cmd); and PostClientMessagesSent(); on the bot > > controller for the bot. This works fine and all, but it > > bypasses the codepath that the players usercommand takes, > > which is CBasePlayer::ProcessUsercmds > > > > Since CBasePlayer::ProcessUsercmds doesn't get called for bots, > > AllocCommandContext() doesn't get called for bots, and > > therefor why int command_context_count = > > GetCommandContextCount(); is always 0 for bots(in > > CBasePlayer::PhysicsSimulate), and its within that loop that > > UpdateVPhysicsPosition is called. > > > > Are there any special considerations to > > UpdateVPhysicsPosition being called? > > Or can I safely call it every frame at the end of the bot > > block in CPlayerInfo::RunPlayerMove. Think, first I'll see > > what happens if I call ProcessUsercmds on the bot player > > directly. Calling UpdateVPhysics on my own feels like a dirty > > hack. I'm hesitant about doing stuff like just calling the > > function directly. IMO that's masking the symptoms of a > > potentially bigger problem. > > > > It looks like this is another problem that needs addressing > > if Valve gets around to fixing the broken bot support, as > > that is the only way to feed user commands from server plugins. > > > > On 8/22/06, Paul Peloski <[EMAIL PROTECTED]> wrote: > > > > > > -- > > > [ Picked text/plain from multipart/alternative ] Okay, > > seems like the > > > problem is in CBasePlayer::PhysicsSimulate, where the > > > UpdateVPhysicsPosition is not being called for bots. > > > > > > PhysicsSimulate is the main place where > > UpdateVPhysicsPosition is called. > > > There's also a wrapper for UpdateVPhysicsPosition called > > > UpdatePhsyicsShadowToCurrentPosition that is called sometimes, for > > > example when being pushed by your lift! > > > > > > So basically what's happening is that PhysicsSimulate is > > not updating > > > physics shadow for every game frame, but some touch events > > are calling > > > a function that moves the shadow into place. Whenever the shadow > > > moves, it wakes up, but when its idle for too long (because > > > PhysicsSimulate isnt updating it) it falls asleep. > > > > > > One way to fix this would be to override PhysicsSimulate in > > the bot's > > > entity class and make sure that UpdateVPhsyicsPosition is > > called (just > > > hack up the PhysicsSimulate from CBasePlayer so that it > > calls it under > > > the right circumstances for your bots instea
Re: [hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] Ok, so I tried ProcessUsercmds(&cmd, 1, 1, 0, false); in place of IBotController::RunPlayerMove(&cmd); It fixed the lift bug it seems but broke the view angles, and the bot kept facing his spawn direction or something. That's probably not too hard to fix, but after that I also tried m_pParent->UpdatePhysicsShadowToCurrentPosition(); in CPlayerInfo::RunPlayerMove and kept my previous user command method of IBotController::RunPlayerMove(&cmd); This way he could move normally, but the lift bug wasn't fixed. I don't know what m_pPhysicsController->Update is doing in CBasePlayer::UpdateVPhysicsPosition, but apparently it isn't updating the physics position. Can't tell yet if theres an order of operation I'm missing. I guess after work I'll change it back to ProcessUsercmds method and figure out why their view angles are busted. Probably less work than trying to debug this broken bot command codepath. If theres anyone at valve who has any input or a possible 'right' solution to fixing the issue please let me know. I hate to deviate too far from the functionality that is also usable in server plugins, as I still hold out hope of that stuff being fixed in a future sdk update. J On 8/22/06, Paul Peloski <[EMAIL PROTECTED]> wrote: > > -- > [ Picked text/plain from multipart/alternative ] > Not working on bots myself just trying to be helpful. > > You're right about the user command stuff, that's why the > UpdateVPhysicsPosition is not being called, maybe someone from Valve can > suggest potential problems with calling UpdateVPhysicsPosition or > ProcessUsercmds on the bots, I wonder what the CS: Source bots do? > > Regards, > > Paul > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Physics becoming out of sync
It's safe to call UpdateVPhysicsPosition() directly. It's setting a target for the player's physics controller in the next frame of physics simulation. Jay > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jeremy Swigart > Sent: Tuesday, August 22, 2006 8:35 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] Physics becoming out of sync > > -- > [ Picked text/plain from multipart/alternative ] Thanks the > help. Are you having the same problem with your bots or just > going out of your way to be helpful? Either way I appreciate > it. On further investigation, it appears the problem is due > to the bots user commands going through a different code > path. AFAIK, we're supposed to be calling > > RunPlayerMove(&cmd); and PostClientMessagesSent(); on the bot > controller for the bot. This works fine and all, but it > bypasses the codepath that the players usercommand takes, > which is CBasePlayer::ProcessUsercmds > > Since CBasePlayer::ProcessUsercmds doesn't get called for bots, > AllocCommandContext() doesn't get called for bots, and > therefor why int command_context_count = > GetCommandContextCount(); is always 0 for bots(in > CBasePlayer::PhysicsSimulate), and its within that loop that > UpdateVPhysicsPosition is called. > > Are there any special considerations to > UpdateVPhysicsPosition being called? > Or can I safely call it every frame at the end of the bot > block in CPlayerInfo::RunPlayerMove. Think, first I'll see > what happens if I call ProcessUsercmds on the bot player > directly. Calling UpdateVPhysics on my own feels like a dirty > hack. I'm hesitant about doing stuff like just calling the > function directly. IMO that's masking the symptoms of a > potentially bigger problem. > > It looks like this is another problem that needs addressing > if Valve gets around to fixing the broken bot support, as > that is the only way to feed user commands from server plugins. > > On 8/22/06, Paul Peloski <[EMAIL PROTECTED]> wrote: > > > > -- > > [ Picked text/plain from multipart/alternative ] Okay, > seems like the > > problem is in CBasePlayer::PhysicsSimulate, where the > > UpdateVPhysicsPosition is not being called for bots. > > > > PhysicsSimulate is the main place where > UpdateVPhysicsPosition is called. > > There's also a wrapper for UpdateVPhysicsPosition called > > UpdatePhsyicsShadowToCurrentPosition that is called sometimes, for > > example when being pushed by your lift! > > > > So basically what's happening is that PhysicsSimulate is > not updating > > physics shadow for every game frame, but some touch events > are calling > > a function that moves the shadow into place. Whenever the shadow > > moves, it wakes up, but when its idle for too long (because > > PhysicsSimulate isnt updating it) it falls asleep. > > > > One way to fix this would be to override PhysicsSimulate in > the bot's > > entity class and make sure that UpdateVPhsyicsPosition is > called (just > > hack up the PhysicsSimulate from CBasePlayer so that it > calls it under > > the right circumstances for your bots instead of actual players) > > > > I hope this helps. Fortress Forever is looking terrific these days, > > best of luck to you guys. > > > > Regards, > > > > Paul > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the > list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > -- > > ___ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] Not working on bots myself just trying to be helpful. You're right about the user command stuff, that's why the UpdateVPhysicsPosition is not being called, maybe someone from Valve can suggest potential problems with calling UpdateVPhysicsPosition or ProcessUsercmds on the bots, I wonder what the CS: Source bots do? Regards, Paul -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] Thanks the help. Are you having the same problem with your bots or just going out of your way to be helpful? Either way I appreciate it. On further investigation, it appears the problem is due to the bots user commands going through a different code path. AFAIK, we're supposed to be calling RunPlayerMove(&cmd); and PostClientMessagesSent(); on the bot controller for the bot. This works fine and all, but it bypasses the codepath that the players usercommand takes, which is CBasePlayer::ProcessUsercmds Since CBasePlayer::ProcessUsercmds doesn't get called for bots, AllocCommandContext() doesn't get called for bots, and therefor why int command_context_count = GetCommandContextCount(); is always 0 for bots(in CBasePlayer::PhysicsSimulate), and its within that loop that UpdateVPhysicsPosition is called. Are there any special considerations to UpdateVPhysicsPosition being called? Or can I safely call it every frame at the end of the bot block in CPlayerInfo::RunPlayerMove. Think, first I'll see what happens if I call ProcessUsercmds on the bot player directly. Calling UpdateVPhysics on my own feels like a dirty hack. I'm hesitant about doing stuff like just calling the function directly. IMO that's masking the symptoms of a potentially bigger problem. It looks like this is another problem that needs addressing if Valve gets around to fixing the broken bot support, as that is the only way to feed user commands from server plugins. On 8/22/06, Paul Peloski <[EMAIL PROTECTED]> wrote: > > -- > [ Picked text/plain from multipart/alternative ] > Okay, seems like the problem is in CBasePlayer::PhysicsSimulate, where the > UpdateVPhysicsPosition is not being called for bots. > > PhysicsSimulate is the main place where UpdateVPhysicsPosition is called. > There's also a wrapper for UpdateVPhysicsPosition called > UpdatePhsyicsShadowToCurrentPosition that is called sometimes, for example > when being pushed by your lift! > > So basically what's happening is that PhysicsSimulate is not updating > physics shadow for every game frame, but some touch events are calling a > function that moves the shadow into place. Whenever the shadow moves, it > wakes up, but when its idle for too long (because PhysicsSimulate isnt > updating it) it falls asleep. > > One way to fix this would be to override PhysicsSimulate in the bot's > entity > class and make sure that UpdateVPhsyicsPosition is called (just hack up > the > PhysicsSimulate from CBasePlayer so that it calls it under the right > circumstances for your bots instead of actual players) > > I hope this helps. Fortress Forever is looking terrific these days, best > of > luck to you guys. > > Regards, > > Paul > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] Okay, seems like the problem is in CBasePlayer::PhysicsSimulate, where the UpdateVPhysicsPosition is not being called for bots. PhysicsSimulate is the main place where UpdateVPhysicsPosition is called. There's also a wrapper for UpdateVPhysicsPosition called UpdatePhsyicsShadowToCurrentPosition that is called sometimes, for example when being pushed by your lift! So basically what's happening is that PhysicsSimulate is not updating physics shadow for every game frame, but some touch events are calling a function that moves the shadow into place. Whenever the shadow moves, it wakes up, but when its idle for too long (because PhysicsSimulate isnt updating it) it falls asleep. One way to fix this would be to override PhysicsSimulate in the bot's entity class and make sure that UpdateVPhsyicsPosition is called (just hack up the PhysicsSimulate from CBasePlayer so that it calls it under the right circumstances for your bots instead of actual players) I hope this helps. Fortress Forever is looking terrific these days, best of luck to you guys. Regards, Paul -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics becoming out of sync
--
[ Picked text/plain from multipart/alternative ]
I think the bot's physics object has fallen asleep. If you look at the call
stack for VPhysicsShadowUpdate its called like this in physics.cppPhysFrame:
// apply updates
if ( pPhysics && !pPhysics->IsAsleep() )
{
pEntity->VPhysicsShadowUpdate( pPhysics );
}
Stepping through PhysFrame shows that the SDK bots have a valid physics
object but that its asleep. This would also explain why SDK bots are hard to
hit with combine balls, as the combine ball does its damage/dissolve effect
in VPhysicsCollision, which wouldn't happen correctly if the bots vphysics
shadow is not being updated because its fallen asleep and is lingering
somewhere else on the map.
Anyways, we just need to find why the bots physics object is sleeping on the
job and it would be fine. A really bad way to test if this would fix your
problem is to just replace the if statement in PhysFrame with
// apply updates
if ( pPhysics && (!pPhysics->IsAsleep() || pEntity->IsPlayer()) )
{
pEntity->VPhysicsShadowUpdate( pPhysics );
}
If that fixes your bots physics shadow then at least you know you just need
to figure out why its falling asleep. I'll keep looking for an answer there
as well.
Regards,
Paul
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics becoming out of sync
-- [ Picked text/plain from multipart/alternative ] So I'm doing bots for Fortress Forever and I have run into a problem that appears to be a bug with the game. The odd thing is that I can't reproduce it myself as a player, and so far have only observed it happen to the bot players. There is a func_door being used as a lift, and when someone gets under the lift, when it comes down and hits the player it will go back up. The problem is that when the bot gets underneath just once, the lift is stuck in a perpetual up and down oscillation. After some debugging it became clears that the problem was physics related, since the physics system was calling CCollisionEvent::AddTouchEvent every time the lift came down, even though the bot had already ran off and was nowhere near the lift. I added some debug drawing stuff in the function CCollisionEvent::AddTouchEvent, to draw the bounds of the collidable, like so: debugoverlay->AddBoxOverlay( pEntity0->GetCollideable()->GetCollisionOrigin(), pEntity0->GetCollideable()->OBBMins(), pEntity0->GetCollideable()->OBBMaxs(), pEntity0->GetCollideable()->GetCollisionAngles(), 255, 0, 255, 0, 10.0f); debugoverlay->AddBoxOverlay( pEntity1->GetCollideable()->GetCollisionOrigin(), pEntity1->GetCollideable()->OBBMins(), pEntity1->GetCollideable()->OBBMaxs(), pEntity1->GetCollideable()->GetCollisionAngles(), 255, 0, 255, 0, 10.0f); Here is a picture of that. http://i8.tinypic.com/258z4zk.jpg As you can see, the collidables bounding boxes at least are where they should be, and not touching. The small red lines under the lift are the collision position and collision normal also passed to the function, so there is clearly something being registered as hitting. After digging around for more stuff I came across the cvar physicsshadowupdate_render, and when enabled finally showed the problem. http://i7.tinypic.com/258z5u8.jpg The rendering for these boxes is in CBasePlayer::VPhysicsShadowUpdate. The blue box is the players IPhysicsObject->GetPosition(), the red box is at the GetAbsOrigin() of the character. Clearly they are out of sync. These boxes should be pretty much together, but for some reason they aren't. I noticed the comment at the bottom of the function that reads // UNDONE: Force physics object to be at player position when not touching phys??? Why was this undone? Anyone know what part of the code is responsible for keeping the physics synced with the entity and vice versa? Stepping through the code in CBasePlayer::VPhysicsShadowUpdate How could these get out of sync like this? I haven't been able to reproduce this as a player, only happens to the bot so far, but I can't see any reason at all that it would be bot related. We aren't messing with the physics for the bot in any way. This is really annoying. Any feedback is appreciated. Jeremy -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics
John Sheu wrote: Poking around the 'net, and I found something interesting. Looks like Jay Stelly is *the physics dude*, or something close to it ;-) http://www.mollyrocket.com/forums/viewtopic.php?p=836&highlight=&sid=20f3535e5990bc0bb1e006070caf4bde#836 http://www.mollyrocket.com/forums/viewtopic.php?t=245&sid=a4324d73c111f33cb32964b87b50d844 GJK is more about collision detection than physics... http://www.win.tue.nl/~gino/solid/jgt98convex.pdf http://graphics.stanford.edu/courses/cs448b-00-winter/papers/gilbert.pdf (but I guess you can't really do physics simulations without some collisions) :) -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics
I owe a lot to that great man. One day I wish to shake his hand; look in his eye and say "Thank you, thank you Jay. You saved my life. You are a hero.". On 14 Aug 2006 at 14:08, John Sheu wrote: > Poking around the 'net, and I found something interesting. > > Looks like Jay Stelly is *the physics dude*, or something close to it ;-) > > http://www.mollyrocket.com/forums/viewtopic.php?p=836&highlight=&sid=20f3535e5990bc0bb1e006070caf4bde#836 > http://www.mollyrocket.com/forums/viewtopic.php?t=245&sid=a4324d73c111f33cb32964b87b50d844 > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics
Poking around the 'net, and I found something interesting. Looks like Jay Stelly is *the physics dude*, or something close to it ;-) http://www.mollyrocket.com/forums/viewtopic.php?p=836&highlight=&sid=20f3535e5990bc0bb1e006070caf4bde#836 http://www.mollyrocket.com/forums/viewtopic.php?t=245&sid=a4324d73c111f33cb32964b87b50d844 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] [Physics!] FAILED Messages?
-- [ Picked text/plain from multipart/alternative ] In the mod I'm working on, we occasionally see the message "[Physics!] FAILED". I don't see this code anywhere in the mod SDK, so it appears to be from the engine. Anyone know what this means exactly? Perhaps valve can spit out a more descriptive error from the engine if thats where it comes from? -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics Problem
Thank you very much. The whole "AngularImpulse" type was throwing me off. Jay Stelly wrote: GetVelocity returns a velocity. It's already in degrees / second. SetVelocity() takes the same units. AngularImpulse is a vector type that can contain an impulse, but here it's just used as a vector. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Physics Problem
GetVelocity returns a velocity. It's already in degrees / second. SetVelocity() takes the same units. AngularImpulse is a vector type that can contain an impulse, but here it's just used as a vector. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Justin Krenz > Sent: Tuesday, July 25, 2006 9:02 PM > To: hlcoders@list.valvesoftware.com > Subject: [hlcoders] Physics Problem > > I have a physics object that I'm trying to retrieve its > angular velocity in degrees/second. Using GetVelocity(Vector > * velocity, AngularImpulse > * angularVelocity), it appears that I can retrieve the > angular impulse of the angular velocity. Getting this value, > I multiply it by 180*pi to convert from radian to degrees, > and then I divide by the object's mass. > > However, I compare this to the actual change in degrees that > the model undergoes, and the values are different. For > example, if I use > SetVelocity(...) to input an AngularImpulse of 100 for the x > axis/pitch every frame, then convert to radians and divide by > a mass of 2080, I get approximately 2.8. However, if I > sample the actual change in degrees of the object's pitch > every frame, it comes out to approximately 19 degrees/second. > > What am I doing wrong, and how can I correctly calculate an > object's change in angle in degrees/sec? > > ___ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics Problem
I have a physics object that I'm trying to retrieve its angular velocity in degrees/second. Using GetVelocity(Vector * velocity, AngularImpulse * angularVelocity), it appears that I can retrieve the angular impulse of the angular velocity. Getting this value, I multiply it by 180*pi to convert from radian to degrees, and then I divide by the object's mass. However, I compare this to the actual change in degrees that the model undergoes, and the values are different. For example, if I use SetVelocity(...) to input an AngularImpulse of 100 for the x axis/pitch every frame, then convert to radians and divide by a mass of 2080, I get approximately 2.8. However, if I sample the actual change in degrees of the object's pitch every frame, it comes out to approximately 19 degrees/second. What am I doing wrong, and how can I correctly calculate an object's change in angle in degrees/sec? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] physics shadow
Awesome! Thanks for the info. I only need to adjust the other one then; 50 is fine for the impulse. -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com > -Original Message- > From: Jay Stelly [mailto:[EMAIL PROTECTED] > Sent: June 30, 2006 1:56 AM > To: hlcoders@list.valvesoftware.com > Subject: RE: [hlcoders] physics shadow > > These limits apply to the impulses a player can exert through his > contact points. > > The mass limit is the limit at which the player controller stops pushing > through the contact. So with the code below the player will not push > against the contact normal with any object > 350kg. > > The speed limit actually controls the impulse you can apply but limiting > the velocity again through the contact. So the player won't be able to > apply an impulse greater than (50 * playermass) against the contact > normal of any contact. > > There is also a general speed limit that controls the overall velocity. > So these limits explicitly deal with contacts. The basic idea is to > allow the player to accelerate to max velocity quickly without giving > the player the ability to push really massive objects out of his way as > a result. Without the extra term increasing the acceleration rate > increases the mass a player can push. > > Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] physics shadow
These limits apply to the impulses a player can exert through his contact points. The mass limit is the limit at which the player controller stops pushing through the contact. So with the code below the player will not push against the contact normal with any object > 350kg. The speed limit actually controls the impulse you can apply but limiting the velocity again through the contact. So the player won't be able to apply an impulse greater than (50 * playermass) against the contact normal of any contact. There is also a general speed limit that controls the overall velocity. So these limits explicitly deal with contacts. The basic idea is to allow the player to accelerate to max velocity quickly without giving the player the ability to push really massive objects out of his way as a result. Without the extra term increasing the acceleration rate increases the mass a player can push. Jay > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Sheu > Sent: Thursday, June 29, 2006 9:26 PM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] physics shadow > > On Thursday 29 June 2006 8:51 pm, Tony "omega" Sergi wrote: > > m_pPhysicsController->SetPushMassLimit( 350.0f ); > > m_pPhysicsController->SetPushSpeedLimit( 50.0f ); > > Limits the mass of objects which the player's shadow > controller can push, and the maximum speed to push it away > with, I would think. > > -John Sheu > > ___ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] physics shadow
On Thursday 29 June 2006 8:51 pm, Tony "omega" Sergi wrote: > m_pPhysicsController->SetPushMassLimit( 350.0f ); > m_pPhysicsController->SetPushSpeedLimit( 50.0f ); Limits the mass of objects which the player's shadow controller can push, and the maximum speed to push it away with, I would think. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] physics shadow
Shot an email to Wrayth, he had a very complex looking yet easy to programm player shadow in a few builds ago, untill we worked out that the 'gorden' model in sp has no animations. Adam --- "Tony \"omega\" Sergi" <[EMAIL PROTECTED]> wrote: > Anyone know what these affect yet? I'm trying to do > something with the > players shadow, to make it function a little > differently, but still retain > the same basic functionality, but I cant figure out > exactly what these do. > > Valve? > > m_pPhysicsController->SetPushMassLimit( 350.0f ); > m_pPhysicsController->SetPushSpeedLimit( 50.0f ); > > -- > -- omega > Heroes of Excelsior > http://www.heroesofexcelsior.com > Blackened Interactive > http://www.blackened-interactive.com > > > > ___ > To unsubscribe, edit your list preferences, or view > the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > My Website http://www.ammahls.com Lead Programer NightFall http://www.nightfallmod.net Developer of CST and ZHLT 3.0 http://www.zhlt.info Team Lead - Prime - http://www.nigredostudios.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] physics shadow
Anyone know what these affect yet? I'm trying to do something with the players shadow, to make it function a little differently, but still retain the same basic functionality, but I cant figure out exactly what these do. Valve? m_pPhysicsController->SetPushMassLimit( 350.0f ); m_pPhysicsController->SetPushSpeedLimit( 50.0f ); -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics and Melee weapons
> It sounds like you've got collisions enabled between the sword's bone > followers and the player. The simplest way to fix this is to call > SetOwnerEntity() on each of the bone followers and set the player as > the owner of them. Yup that was it, it's working fine now (or at least the player can move, there's still a load of other problems to I need to sort out). Thanks for the help :) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Physics and Melee weapons
> Does anyone know what would be cause the server to be getting > stuck on the sword model and how I could fix this? It sounds like you've got collisions enabled between the sword's bone followers and the player. The simplest way to fix this is to call SetOwnerEntity() on each of the bone followers and set the player as the owner of them. Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Physics and Melee weapons
I'm currently writing a melee weapon system for the mod I'm working on. It's going to work rather differently to way say the HL2 crowbar works in that instead of just whacking buttons to make your character do different attacks the movements of your mouse will determine how you attack. I've setup a system whereby the mouse is tracked client side and when an attack is made the information about what kind of attack it is is sent over to the server via a client-command (i.e. if it was a slash attack for a sword it'd send over a number identifying the attack and two other numbers giving the direction the mouse was moved in). I then use pose parameters to control the attack animation (so for example you can slash a sword in any direction you want). The difficulty I'm having is in actually creating the weapon that will sit in the players hand and collide with things / effect physics objects etc. Currently I've coded a base melee weapon class (inherited from CBaseEntity not CBaseCombatWeapon) and I'm using bone followers to get a physics shadow which follows the weapon model. The weapon model follows the player's hand movement using the same method weapons inherited from CBaseCombatWeapon do (i.e. using the CBaseEntity::FollowEntity function which sets up a bone merge). Thus when the player makes an attack, the player model animation moves the weapon model and if it hits stuff the appropiate action can occur (i.e. if it hits a player damage calculations can be done, if it hits a physics object it could knock it over etc). However when I use a bone follower to create a physics shadow which follows round the weapon model I'm told the server is stuck on the sword model the player is carrying and hence the player model can't really move anywhere. If I stand next to a physics object and equip the sword I can knock over the object so it works in one respect. Does anyone know what would be cause the server to be getting stuck on the sword model and how I could fix this? Also is this the best way to do what I want (namely I'm using a bone follower which creates a physics shadow, to follow round a model bone merged to a players hand so the model can interact with physics objects etc)? I'm not particular familiar with Source's physics system yet so I could be going completely the wrong way about this. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
