On Friday 12 January 2007 3:34 pm, Justin Krenz wrote:
> Does "SweepCollideable(...)" not support OBB? I know const.h says
> SOLID_OBB is not implemented, but from what little I played with it,
> SweepCollideable seemed to correctly orient the entity's bounding box
> before doing the trace.
Not s
--
[ Picked text/plain from multipart/alternative ]
That's interesting Krenzo. I will have to check out how PhysShouldCollide
works. If it works alright, it could really help with the prediction. At the
very least we could implement something like sv_turbophysics. What may be
difficult is getting t
I have the same problem, but my anims (mostly guns)
are all courpted the first time i built the mod code -
with default settings.
Adam
--- Nate Nichols <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On the two machines I've tried it on (one of which
> is full of my
> modding stuff and the other which is
Hi,
On the two machines I've tried it on (one of which is full of my
modding stuff and the other which is a clean HL2/HL2:EP1 install), the
record command works correctly in Half-Life 2, and munges animations
and other things in Episode 1 and my mod. The animations jump all
around, NPCs looking
I believe someone from Valve mentioned earlier that SweepCollideable() and
TraceRay() are currently stub implementations in IPhysicsEnvironment, so
they don't do anything meaningful.
- Original Message -
From: "Justin Krenz" <[EMAIL PROTECTED]>
To:
Sent: Friday, January 12, 2007 1:34 PM
Does "SweepCollideable(...)" not support OBB? I know const.h says
SOLID_OBB is not implemented, but from what little I played with it,
SweepCollideable seemed to correctly orient the entity's bounding box
before doing the trace.
As far as VPhysics, what about using PhysShouldCollide( IPhysicsObj
On Friday 12 January 2007 1:00 pm, Justin Krenz wrote:
> I remember Valve said Havok doesn't want their code opened in the SDK at
> all, so I doubt Valve wants to start opening anything up in the VPhysics
> interface to get the functionality you want.
I'm just looking for a call something like:
IP
--
[ Picked text/plain from multipart/alternative ]
We are attempting to rewrite our prediction code in order to make collisions
less crazy. We might just drop the idea at this point. As for custom
physics, this is the implementation we currently have, however there is no
way to trace a collideable
I remember Valve said Havok doesn't want their code opened in the SDK at
all, so I doubt Valve wants to start opening anything up in the VPhysics
interface to get the functionality you want.
I chose client-side vehicles because it's the fastest solution. You
just move the vehicle code client-sid
And found the bug. FYI in the Makefile you shouldn't be referencing
tier0_i486.so and vstdlib_i486.so by $(GAME_DIR)/bin. As these symbolic
links are made in the Makefile when you do a 'make mod' it will suffice to
have it set to just 'tier0_i486.so' and 'vstdlib_i486.so'. If you do a 'ldd'
on the
--
[ Picked text/plain from multipart/alternative ]
This is the reason I made my vehicles purely out of SOLID_BBOX. I was able
to reduce cpu load from physics by ALOT and was able to have great
prediction. On top of that, I controled my movements with 100% precision.
Only downside was I had to fa
I've come to the conclusion, finally, that the Source engine in its present
form does not do multiplayer vehicles well.
The issue is this: for a smooth experience, we need prediction. To do
prediction, we need to be able to simulate a vehicle forward multiple
timesteps relative to the environment
12 matches
Mail list logo
