As I recall, the blood uses a range of colors in the base palette of
your mod - gfx/palette.lmp
It looks like it uses 10 colors for one of the particle effects (blood
stream), so 245 would use palette entries in the range [245, 254]. So
you should either modify the palette lump for your mod
This is a bug. The fix is included with the next SDK release.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Foss
Sent: Tuesday, November 23, 2004 7:22 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] filesystem_stdio.dll
aaah, my
1) I live in Kyiv, Ukraine. I have Half-Life 2 which can't
reach my country regarding political situation. How do I get the SDK?
I'm not sure I understand the question. I would tell you that you get
the SDK through steam, but I assume you already know that.
2) I want to install SDK on
I haven't duplicated this experiment, but this is most likely a poor
explanation of a performance tuning parameter. If you're working with
the Source SDK, you can bound the CPU cost per simulation step of
vphysics using a parameter:
physenv-SetPerformanceSettings()
After you initialize your
Entity index 0 is the world entity.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Ronny Schedel
Sent: Sunday, December 05, 2004 10:14 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] IVEngineServer::PEntityOfEntIndex(int
iEntIndex) issue in
Exactly. They are compressed on the wire, but not on disk.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jeffrey botman Broome
Sent: Sunday, December 05, 2004 1:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] sourcesdk.gcf question
te_largefunnel doesn't define a class with those members. They are
members of CBaseEntity - declared in BaseEntity.h - so they aren't
available (unless you add them) to a class derived from CBaseTempEntity.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
The reason we use the versioned interfaces in the Source SDK is to make
it extremely unlikely that any mods will break as we upgrade the engine.
We've done lots of engine updates over the years without breaking mods,
and the interfaces are a new tool that make it even easier to do this
However this goes back to the point made before where the
implementation might change and you can't rely on it.
However there is no useful interface equivalent for entities,
so worse come to worst you simply rebuild the plug-in come an
update to the base entity.
No. CBaseEntity can be
The box is trivially changeable from within code. Just change the
constants VEC_HULL_MIN or VEC_DUCK_HULL_MIN or the code that uses them.
Also, turn on developer mode (run with -dev or type developer 1 at the
console) and you can see debug overlays. They do many things including
visualization
the shadow of the player's hull on the
physics engine, or something like that.
On Fri, 10 Dec 2004 16:26:59 -0800, Jay Stelly
[EMAIL PROTECTED] wrote:
The box is trivially changeable from within code. Just change the
constants VEC_HULL_MIN or VEC_DUCK_HULL_MIN or the code
that uses them
Sv_alternateticks 1 cuts the server framerate in half for performance.
You'll either get 15ms ticks or 30ms ticks depending on this variable's
setting.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ray
Sent: Monday, December 13, 2004 4:24 PM
To:
So basically what your saying is Vehicle based mods are a no
go for the source engine?
This is totally not true. The SDK does not currently have an optimized
network data model for vehicles, but it's completely possible to
optimize (or otherwise redefine) the network data for vehicles in a
Just FYI:
Some of the built in engine logs only work in multiplayer. So you need
to set maxplayers 1 (run with +maxplayers 4 or something) to get
output.
Jay
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
The thirdperson view uses a set of cvars for the relative position.
Set cam_idealyaw 0 to get it behind the model. It's probably set to 90
(default) which is the sideways view you mention.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
To be clear: The per-entity gravity mentioned below only applies to
entities with movetypes that are simulated by the game (e.g.
MOVETYPE_STEP, etc)
For anything MOVETYPE_VPHYSICS, you run the Havok code for gravity (in
vphysics).
The only in-between case is players - where you have to do both
Excellent!!!
This is just what I need!
So with VPHYSICS controllers, we can effectively extend
Havoc/VPhysics, if we want to?
That's got to be the most low-level access offered by any
game engine SDK *EVER*.
Thanks a whole bunch :D
Yes - you can write your own code that gets called
QAngles represent an euler angle sequence in degrees. They have the
same convention as Half-Life (and Quake). There are routines in mathlib
that convert them to/from matrices and basis vectors. Those routines
should give you a precise specification of the euler sequence, but it's
the usual
to do with collision. it can
go through walls, etc.
http://img110.exs.cx/img110/5110/small00068tp.jpg
On Sun, 12 Dec 2004 21:11:45 -0800, Jay Stelly
[EMAIL PROTECTED] wrote:
Vphysics shadow objects are for objects that are controlled by the
game logic. They follow the motion that happened
First, is there a way to re-enable 'fopen()'?
Fopen is redefined in the preprocessor settings for the debug build.
It's fine to reenable it as long as you realize you won't get the
features of the steam filesystem (like searchpaths, support for gcf
files, automatic updates, etc). For a log
This is just status from the ragdoll separation solver. It only prints
in developer 2. There are a bunch of messages like these in developer 2
mode that are only useful to a programmer working on that part of the
code. You can safely ignore this message.
Jay
-Original Message-
All of the code for player movement is in the SDK. Take a look at
game_shared/gamemovement.cpp
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Mark Ettinger
Sent: Monday, January 03, 2005 8:02 PM
To: hlcoders@list.valvesoftware.com
Subject:
The easiest way to do this is to turn bullets into projectiles. In HL2
they are a single raycast. But in your mod you could decide how fast
they travel and sweep a ray over each tick from the previous position to
the current position of the projectile. You could add gravity easily
enough. This
It depends on what you want to have happen. If you want to pop the box
back to some orientation, then you can just save the angles and teleport
the object when it comes to rest.
Otherwise you may be able to achieve something like what you want using
a ragdoll constraint (with no translational
COLLISION_GROUP_NONE is the default collision group. These collide with
everything. Other collision groups have special rules. E.g.
COLLISION_GROUP_DEBRIS doesn't collide with other
COLLISION_GROUP_DEBRIS.
In the end, collision group is simply an id. The behavior of it is
controlled by the
This won't work because you aren't debouncing the key. Two commands get
processed in a row and you prone/unprone because you haven't checked to
see that the user has released the key before you attempt to change
states.
We do this (normally called debouncing keys) in the game code using bit
Yes, and the getpos command will dump this out at the console in a
format that can be pasted back in as a command to teleport you to the
current position.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
David Speyrer
Sent: Wednesday, January 12,
The vgui vertex has two members, and screenspace position (in screen
coords) and a texture coordinate (in normalized UV space). You can get
the screen dimensions from the vgui surface with
surface()-GetScreenSize().
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
It sounds like your prop is set to a collision group that doesn't
collide with the player or you've got the player set as the prop's
owner.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Maurino Berry
Sent: Friday, January 28, 2005 8:10 PM
Yes in vbsp/textures.cpp:
// Handle ladders.
if ( ( propVal = GetMaterialVar( matID, %compileLadder
) ) StringIsTrue( propVal ) )
{
textureref[i].contents |= CONTENTS_LADDER;
}
That's where the custom
Just create an entity and have it trace from it's current position to
the next position (current + velocity * dt + gravity * dt) each tick.
Unless you want the entity to have a physics hull or something, then
you'll need to increase the max allowable speed. You can do that by
modifying:
ConVar
There are three issues here:
1) Collision representation for the bullet
In HL2, they are point sized. You can also make them out of
boxes or fully general vcollides.
2) Velocity of the bullet
In HL2 the velocity is infinite - they travel instantaneously
until they hit something
The ammodef defines an impulse (mass * velocity) for the bullet to apply
to physics objects when it hits them. Applying an impulse is equivalent
to a collision.
That macro just converts units so we could use some standard ballistics
data with bullet mass in grains and speed in feet per second.
Actually slowing the game down to 1 fps I can now see the
traces properly and it does not trace all the points i passed
to the FX_FireBullet method, only about 30 traces appear, so
my original question still stands. Is there a limit for that
method or for the engine on the number of traces I
It's hard to debug this with such a small amount of information, but I
can try to help:
Server-side ragdolls don't have this bug in Half-Life 2. The people you
grab with the super gravity gun, the citizens who get skewered by
striders, and enemies you kill by running over with the jeep are all
I use InvalidateBoneCache before calling CreateServerRagdoll
and don't work, still appears in Spawn point.
Did you try the other tests I mentioned? Do other server ragdolls
appear in the right places in your mod? It's important to figure out
which code is broken. You need to isolate the
When I comment the SyncAnimation function, the problem solved
Yes, I use MOVETYPE_STEP instead maintain the PHYSICS move.
Ok. Commenting this out is ok if you don't have other server ragdolls
that are MOVETYPE_VPHYSICS. But it also means that somewhere you have
an invisible strider head with
Is Source DX7 compatible only so it can someday be ported to X-BOX?
(Question from one of my mod members)
Source supports DX7 because lots of people had dx7 cards in the various
steam hardware surveys we did (GF2, GF2MX, GF4MX, the original Radeon).
Also, XBOX is dx8.
Jay
One other detail: ShouldCollide() sorts the collision groups, so in
order for that code to work exactly as written, the enum for
COLLISION_GROUP_*_FORT must be less than the enum for
COLLISION_GROUP_*_WEAPONS
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
But this doesn't work, it still hits it.
So you also need a case for collision groups lower than the brush's
collision group:
if ( collisionGroup1 == COLLISION_GROUP_FORTSITE_TEAM1 ||
collisionGroup1 == COLLISION_GROUP_FORTSITE_TEAM2 )
return false;
You can't hit it with a trace if it's SOLID_NONE. The collision group
thing should keep all other traces/physics from hitting it. Players can
definitely walk through SOLID_BSP entities as long as their collision
groups don't collide.
-Original Message-
From: [EMAIL PROTECTED]
SOLID_VPHYSICS static prop with no vphysics model!
(models/props_lab/corkboard001.mdl)
This is a map bug, but the message is harmless. There's a prop_static
that has collisions turned on, but the model doesn't have collision
geometry. This message is just letting you know that the corkboard
I'll try to repro it here. To be clear, I'm just pointing out that if
you experience these problems, it's most likely a bug. It's not a
consequence of doing too much physics. So try to find a way to
reproduce it or help debug it. It probably won't go away because you
turn off some of the
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
I looked at the should freeze object code and it's
boolShouldFreezeObject( IPhysicsObject *pObject ) { return true; }
Return true all the time? Is it supposed to be like this?
Yes. I described the exact behvaior in my previous mail. But basically
this function gets called after you hit
I posted a fix for this on verc. Basically the code is intentionally
creating an Elight (only lights entities) instead of a full dlight in
the muzzle flash case. So change the E to a D and you're set.
(AllocElight - AllocDlight)
-Original Message-
From: [EMAIL PROTECTED]
It will only have friction controllers if it's in contact with another
object. If it's flying/falling then drag+gravity only is normal.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Knifa
Sent: Sunday, March 13, 2005 8:10 AM
To:
...in the HL2 DSK.
I've been trying to get a round model entity (based off
CBaseAnimating) to have collision based on the model, and not
on the bounding box (it's round, so a radial/spherical
collision would work too!).
You can definitely do this.
Setting my solid type to SOLId_VPHYSICS
Mins/maxs pairs always defined bounding boxes. Those boxes are
implicitly in some space. In HL2 we use the terminology: AABB
(axis-aligned bounding box) which means a bounding box in world space
(aligned with the world's axes, or aligned to an identity orientation)
and OBB (oriented bounding
Josh Matthews wrote:
Actually, I'm still confused about how the classname method won't
work. When it reaches the light entity, it'll trigger
correctly and
do its thing. Then it moves on, can't find any more entities so it
skips to searching for light_spot. In this case, pEnt will
be
With this post you sorta imply that you will be releasing an
update that fixes the vehicles problems. Do you plan on
doing that, or was I simply misreading it?
It's not being worked on right now.
The SDK already has a framework for writing your own predicted entities.
The client DLL has full
So I went ahead and created my own frontend to motionmapper
and processed all the sdk example anims with my custom models
skeleton as the target, compiled the resulting anims and
brought the model into HLMV, to my dismay the anims were
exactly the same as before. I then ran windiff, and yes -
You could emulate the envmap command with setang screenshot (or jpeg)
plus you need to force fov 90 for a 6 shot cubemap:
fov 90
setang 0 0 0
screenshot
setang 0 90 0
screenshot
setang 0 180 0
screenshot
setang 0 270 0
screenshot
setang -90 0 0
screenshot
setang 90 0 0
screenshot
(this
PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] (semi OT) 3d panoramas
Will the envmap, take your video settings into account, such
as having everything up full bore?
Also thanks Jay, i'll be doing this latter on
Adam
--- Jay Stelly [EMAIL PROTECTED] wrote:
You could
I'm not sure it's applicable to what you are doing, but you could also
just set host_timescale to something really small if you need to be
paused, but not really paused.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Teddy
Sent: Friday, May 20, 2005
Dlights affect the lightmaps, elights do not. Both are supported on all
hardware source supports.
Dlights can be turned off for performance by using the convar r_dynamic.
By default, HL2 sets r_dynamic 0 for dx7, but you could turn it back on
in your mod (although the user could still turn it
My best guess from looking at the code is that
m_ArmRagdoll-VPhysicsGetObject() is not returning a pointer to the
correct piece of that ragdoll. You can use VPhysicsGetObjectList() to
get all of the arm's pieces and then pick the one with the correct index
by asking each object GetGameIndex().
The break sections are in the qc files. Here's the one for the table
you pasted below:
$collisiontext {
break
{
model gibs\furniture_gibs\FurnitureTable003a_gib01
health 10
fadetime 10
}
break
{
Why is the angles check testing angles.x twice and angles.z
not at all?
Shouldn't this just check angles.IsValid() instead? It's
probably not
related to my issue, it's just curious.
Maybe they're just checking to be doubly sure that angles.x
is valid. ;)
clearly angles.x is twice as
weapon_physcannon.cpp:
void CPlayerPickupController::Use( CBaseEntity *pActivator, CBaseEntity
*pCaller, USE_TYPE useType, float value )
has the code
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kamran
Sent: Thursday, July 21, 2005 12:13 PM
To:
2:15 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Throwing phys objects
Nevermind my other email, it does work with just hand picking
up. Now I need to figure out if it was thrown using the
physgun or hands...
Jay Stelly wrote:
weapon_physcannon.cpp:
void
You don't set it. You just build everything to that scale. Assets for
HL2/cstrike/etc are built to 1 unit = 1 inch scale. If you want your
mod to run at a different scale you will need to modify any HL2 assets
you are using.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
func_detail is not a brush entity. It just uses some convenient entity
features of hammer to set properties on a group of brushes. The
func_detail entities are stripped out in vbsp - where they become part
of the world geometry.
-Original Message-
From: [EMAIL PROTECTED]
The collision models built by the MDL/studiomdl path have the same
low-level features as the ones built in Hammer. But the tools do not
put per-face materials on the collision models. So you would have to
modify the model compiler or do this in a post-process in your mod. At
runtime, there is a
Put an uncompressed zip file named zip0.zip (for additional zip files
increment the number) in your mod root directory.
Also you can use bspzip.exe to add files to a BSP and those will get
loaded before anything in the filesystem.
HL2 CS:S don't use this feature (so it is less well
The main entry points to each DLL are interfaces that the DLL exports to
the engine.
For the server, these are:
IServerGameEnts
IServerGameClients
IServerGameDLL
These are defined in public/eiface.h. For objects, you'll also need to
implement IServerNetworkProperty and ICollideable (or use the
in the command window.
Can you offer any advice? My brain is fried for now, but I
suppose it's just a matter of messing with it until it works.
I only hope that the exported .phy file is actually saving
the material index for the faces.
Jay Stelly wrote:
The collision models built by the MDL
the index number that I set when
compiling it. Is the material index of each triangle
actually being saved in the collision model file
automatically as being a part of the class or is it being
ignored and the blanket value of 77 being applied elsewhere?
Jay Stelly wrote:
You definitely don't want
PROTECTED] On Behalf Of Jay Stelly
Sent: Monday, September 12, 2005 4:44 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Model Surface Properties
I'm not sure why you're seeing a 77 everywhere. However it
looks like the code only supports one remapping table for the
level
animatedTextureFrameRate
look at src\cl_dll\baseanimatedtextureproxy.cpp to see how all of the
variables are used or make changes.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Michael A. Hobson
Sent: Friday, September 16, 2005 3:30 AM
To:
Oky, so in this case one would need a seperate texture for
each tread with a material proxy that references the entity
it is bound to, to get the amount of offset to do.
Yes
question would be... Lets say I have two tanks ont he screen.
Does the each tank get it's own instance of the texture
There was a bug fix a while back that changed code in
player_lagcompensation.cpp.
Make sure you have the latest version of that file. If you started your mod a
while back and haven't merged in updates you won't have it. That's my best
guess as to the problem you're having.
Jay
This is a common misconception. The world surfaces are not being split
just tesellated differently (i.e. you'll have the same # of world
surfaces whether you separate the func_detail from the wall or not).
The code in vbsp adds the vertices to the base face to sew the edges and
prevent cracks, so
It sounds like your process isn't producing an equivalent .phy file.
Try using the original file.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Matthew Lewis
Sent: Saturday, October 22, 2005 12:56 PM
To: hlcoders@list.valvesoftware.com
Subject:
Sounds likely. But the thing is that the decompiler didn't
produce a .phy file.
Well it probably wouldn't have. The PHY file is an output file (like
the MDL) not a source file. The source for the PHY file is in an SMD
file and the qc file. What I was saying is that your process for
LINK_ENTITY_TO_CLASS creates a factory for entities of that type. So it
tells the code how to create a CGameRules object when the bsp contains
an entity with a classname of my_gamerules. There isn't necessarily
only one entity of a given class (though there should be for gamerules).
Anyway, you
I don't think that is possible. The low-level direct sound code is
certainly not exposed in the source SDK.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Michael Kramer
Sent: Sunday, January 29, 2006 8:15 PM
To: hlcoders@list.valvesoftware.com
As I understand your question, you just want a bunch of bone
orientations to come from your code rather than a pre-defined animation.
That is exactly what the ragdoll code does, but the bulk of the code for
ragdolls is about doing the simulation; none of that is likely to be
useful for this
So you're suggesting to simply replace the RagdollBone() call
with my own data transformations?
yes
When you are editing the matrix given back from
GetBoneToWrite( boneIndex ), what is the scope of this
matrix?
It's just giving you a pointer to a matrix inside pBoneToWorld. So the
scope
It sounds like you are missing this info:
The compiled HLSL shaders are not in the shader DLL. That DLL has the
C++ code that does the state setup and linkage. The shaders themselves
are in your mod directory under the shaders/ subdirectory. They are
.VCS files. When you run the buildshaders
I'd have to look at the code to be sure, but I'm guessing that the
shader you're using uses the constant color not per-vertex color.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jorge Rodriguez
Sent: Monday, March 13, 2006 3:15 PM
To:
13, 2006 3:31 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] IMesh::Draw() ignoring colors
Jay Stelly wrote:
I'd have to look at the code to be sure, but I'm guessing that the
shader you're using uses the constant color not per-vertex color.
LightMappedGeneric
, 2006 2:29 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] the vphysics bug worse in latest srcds?
Hmm this one's a little different - has a tier0 in there.
I think Jay Stelly said one time that should be impossible.
Well it's rare, anyway.
I have minidumps of all of these btw
Unless someone has defined a valid assignment or conversion path for
this that I don't normally use you have to do this to your constant
strings:
sString = MAKE_STRING(Find the case!);
at least that's why MAKE_STRING exists in the first place.
It's not surprising that
] On Behalf Of Jay Stelly
Sent: Thursday, March 30, 2006 11:02 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Works in debug mode, does not it release mode.
Unless someone has defined a valid assignment or conversion
path for this that I don't normally use you have to do
This is a pretty good summary, but you're missing a couple of things:
For player movement, what happens is that player's aren't
really physically simulated at all!
But your own explanation says this isn't true:
After physics simulation occurs, the player entity is
reconciled with the
There aren't any intermediate states, so there is a loss of precision as
the entire movement is linearized per batch of updates (single target
position). The important difference is that the velocity and error
stuff doesn't get aggregated across the batch of user commands so the
player doesn't
to
Update() on the shadow controller matters?
Quoting Jay Stelly [EMAIL PROTECTED]:
There aren't any intermediate states, so there is a loss of
precision
as the entire movement is linearized per batch of updates (single
target position). The important difference is that the
velocity
What platform? (linux/win32)? On linux realtime is just accumulating
changes from repeated calls to gettimeofday()
Have you compared gpGlobals-realtime to the output of Plat_FloatTime()
? Are they both slow/stopped or just realtime?
Has anyone else encountered this problem?
-Original
] gpGlobals-realtime standing still
Jay Stelly wrote:
What platform? (linux/win32)? On linux realtime is just
accumulating
changes from repeated calls to gettimeofday() Have you compared
gpGlobals-realtime to the output of Plat_FloatTime() ?
Are they both
slow/stopped or just realtime
If you turn off server-side physics (phys_timescale 0), does the issue
still happen?
Also, if you turn off prediction (cl_predict 0) does the issue still
happen?
The answers to these questions would help narrow down the possible
causes of the problem you're having.
-Original Message-
3 issues in
the original email.
At 2006/04/12 03:02 PM, Jay Stelly wrote:
If you turn off server-side physics (phys_timescale 0), does
the issue
still happen?
Also, if you turn off prediction (cl_predict 0) does the issue still
happen?
The answers to these questions would help narrow
; #endif
At 2006/04/12 12:14 PM, Jay Stelly wrote:
The master game clock is driven by QueryPerformanceCounter()
on win32
and gettimeofday() on linux.
Still, we have had reports of clock issues with QPC() (not this
particular issue however) on AMD x2 systems that were fixed
by forcing
affinity
);
last_realtime = gpGlobals-realtime;
#endif
At 2006/04/12 12:14 PM, Jay Stelly wrote:
The master game clock is driven by
QueryPerformanceCounter() on win32
and gettimeofday() on linux.
Still, we have had reports of clock issues with QPC() (not this
particular issue however) on AMD x2
For use you need to return something from ObjectCaps()
Either or on FCAP_IMPULSE_USE or FCAP_ONOFF_USE depending on the type of
behavior you want with respect to the +USE key.
Also, if you call the function Use() you won't be able to SetUse() to
anything else. The base class function Use() is
The z values are interesting - I'm not sure what to make of that.
Obviously those are out of the world coordinate range.
If it helps, the code for solidmoved is basically this:
// pSolidCollide is the CollisionProp of the entity that
moved
ObjectCaps( void ) {
return (BaseClass::ObjectCaps() FCAP_IMPULSE_USE); }
I'm sure you meant:
return (BaseClass::ObjectCaps() | FCAP_IMPULSE_USE); }
You can also use FCAP_ONOFF_USE and FCAP_CONTINUOUS_USE to get different
call behavior. FCAP_USE_IN_RADIUS (use when close enough,
Given the callstack you posted, I only see one likely option. The crash
is most likely happening inside ClipRayToHitbox because of a bad bone
matrix pointer.
So most likely, you're not getting a valid bone cache. You've either
got a NULL for a matrix that shouldn't or a hitbox referencing an out
.
- Jay
-Original Message-
From: [EMAIL PROTECTED] [mailto:hlcoders-
[EMAIL PROTECTED] On Behalf Of Jay Stelly
Sent: 19 April 2006 16:27
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Strange crash backtrace.
Given the callstack you posted, I only see one likely
Ok, I was able to repro the bug with those changes. Here's the fix:
// add these lines to hl2mp_gamerules.cpp:
bool CHL2MPRules::ShouldCollide( int collisionGroup0, int
collisionGroup1 )
{
if ( collisionGroup0 collisionGroup1 )
{
// swap so that lowest is always
1 - 100 of 228 matches
Mail list logo
