Re: [hlcoders] In game map editing
The engine does talk back to Hammer to implement a few editing features right now. For example you can launch the engine in edit mode with Hammer open, then allow physics to run until everything is settled, then do: Hammer_update_entity (update a single entity that you are looking at) Hammer_update_safe_entities (updates a list of entities using a heuristic and an ignore list) And it will write the positions / orientations of the settled physics objects back into the vmf. Jay -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Andrew Ritchie Sent: Saturday, September 12, 2009 2:59 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] In game map editing What would the difference between this and normal hammer be? The only thing you could do was run game logic, you'd still have to run the compilers each time to see the resulting changes. There are rough features in place that make it appear like at some point Source was able to talk back to Hammer, especially with the Source BSP format having precompiled brush data in it. However the advantages of the feature you want and hammer is nothing, except ingame you'd have to reload the map all the time. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] COLLISION PROBLEM
SetSolidFlags( FSOLID_TRIGGER ); Is what sets the behavior you are after (allowing entities to pass through but still registering collisions). It looks like you are misunderstanding the other functions you are calling: If you SetSolid( SOLID_NONE ); then you are saying the object has no solid representation so nothing collides with it. If you SetSolid( SOLID_VPHYSICS ); then you are saying the object should use a vphysics representation for collisions (union of convex hulls), then SetCollisionGroup( COLLISION_GROUP_PLAYER ); you are limiting what collides with it (CGameRules::ShouldCollide determines which pairs of collision groups collide with each other). But it is still solid to anything that collides with it. Jay -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders- boun...@list.valvesoftware.com] On Behalf Of steven belmans Sent: Tuesday, September 01, 2009 9:51 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] COLLISION PROBLEM Hi all I got a small problem. We are building a model ent thad the player can pass thru and triggers a function void hallo::byby (void) If I use SetSolid( SOLID_NONE); SetCollisionGroup( COLLISION_GROUP_PLAYER ); I can pass thru the model but then my SetTouch(hallo::byby); does not register anything. Else if I use SetSolid( SOLID_VPHYSICS); SetCollisionGroup( COLLISION_GROUP_PLAYER ); I cant pass thru! plz help I Know you dont like it when people use Hotmail Sorry _ Je hele online leven op één stek met Windows Live http://www.microsoft.com/belux/nl/windows/windowslive/default.aspx ___ 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] Engine Memory Leak
I just debugged this. I'll see if I can get a fix out soon. Jay -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders- boun...@list.valvesoftware.com] On Behalf Of Arne Sikstrom Sent: Thursday, July 23, 2009 3:39 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Engine Memory Leak I can confirm this for our OB based mod. The MP3 leaks memory but the WAV does not. This is really bad, our sound guy is not very happy to use WAV for everything. Do we have an official bug report for this? On Sun, Jul 12, 2009 at 5:52 PM, Justin Krenz kre...@gmail.com wrote: MP3s don't appear to be cached. In my mod, we played the same MP3 sound effect over and over, and it eventually caused the client to crash with an out of memory error. When memory gets full, the console reports that the MP3 can't be found on disk. Then, if something tries to allocate memory or the level changes, it crashes. Playing the MP3 sound effect in my mod used up about 100 K at a time. I think it's probably related to how big the MP3 file is. Run your mod in a window with task manager open, and watch how memory changes for HL2. That's how I found the source of the leak. Memory should be stable while your mod is running. Perform all of the actions that might normally occur in your mod while watching memory. See if you can find an action that consistently causes memory to increase. On Sun, Jul 12, 2009 at 8:57 AM, Brent Lewiscoder0...@hotmail.com wrote: Have you produced an out of memory error by playing the same mp3 again and again? Just curious if maybe it's being cached. Date: Sun, 12 Jul 2009 13:25:19 +0200 From: arne.sikst...@gmail.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Engine Memory Leak How bad is it? How much memory is lost for each call? We are chasing memory leaks in our mod at the moment and are playing mp3 sounds file at level changes. On Mon, Jul 6, 2009 at 12:19 AM, Justin Krenz kre...@gmail.com wrote: I just discovered the source of a memory leak in my mod, Smashball. It appears that if you call EmitSound using an MP3 sound file, memory is allocated and never returned. Specifically, enginesound-EmitSound(...) ( /game/shared/SoundEmitterSystem.cpp line 460 ) is the function that allocates the memory. Thus, if you play an MP3 over and over, it will eventually cause HL2 to run out of memory. When playing a wave file, no memory is allocated via EmitSound. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] FW: Multiplayer Inverse Kinematics?
From Ken (who wrote the IK for the combine in hl2):
It's currently only enabled for HL2, and only for npcs. We've not done it for
multiplayer.
As it's currently written, the server doesn't do IK, only the clients. The
main issue is that the client can't do the drop all on its own, the server
needs to do the adjustment so that it can do accurate collision detection for
bullets. In order for the model to drop enough below the AABB for the feet to
touch the ground, there's backchannel in the client-server networking for when
the IK fails. All it really is is if the npc is too high, it tells the server
how much it needs to drop so that the feet will hit the ground. See
CBaseAnimating::SetIKGroundContactInfo() and related code. The funky cycling
you're seeing is the IK enabling and disabling itself on the client after
failure.
For players, you can probably go ahead and do it all on the server, just be
prepared to eat the extra per-frame animation cost. Normally animations are
only calculated if a traceline intersects the AABB, or on the client if they're
in the FOV, which is usally only a tiny fraction of the possible set. For
NPC's, on the server their animation is only calculated to about 10hz, way too
slow to catch them running up stairs. In any case, to get it to always work
you'll need to calculate every player every frame to see how much they'll need
to drop. On top of that, you'll need to synchronize the feet on the client and
server, something we've never done. All of that might not be a issue for your
game, but we couldn't afford it during HL2.
-Original Message-
From: hlcoders-boun...@list.valvesoftware.com
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Christopher Harris
Sent: Thursday, July 16, 2009 4:55 PM
To: 'Discussion of Half-Life Programming'
Subject: [hlcoders] Multiplayer Inverse Kinematics?
Hey,
I've been trying to implement IK onto our models in a multiplayer OB mod and
have been running into numerous issues.
1)The legs have a tendency, when near the max of the chain, to spaz out.
(Basically it looks as though it is trying to find the ground to put the
feet on, but fails and then tries again. It causes the offending limb to pop
up and down.
2)Unlike in Lost Coast for example or models are not fitting to the terrain
in a similar manner to that of combine soldiers for instance. Their idle
anim has the knees with literally no bend which means they are the length of
the ikchain at rest and even though this is true they can still walk up a
stairs with a proper feet to stair alignment. When our model tries to rest
idle on a set of stairs the leg on the highest stair is looking good, but
the other foot just floats in the air as if IK was not on.
Here are my QC commands that I have been toying with:
The ikchains:
$ikchain rfoot valvebiped.Bip01_R_Foot Z 0 knee 0.707 0.707 0 center 4 0 0
pad 2
$ikchain lfoot valvebiped.Bip01_L_Foot Z 0 knee 0.707 0.707 0 center 4 0 0
pad 2
$ikautoplaylock rfoot 1.0 0.1
$ikautoplaylock lfoot 1.0 0.1
And then examples from our idle animation:
$animation a_idle idle1 { loop weightlist HipsLowerbodyReplace
ikrule lfoot footstep 3
ikrule rfoot footstep 3
}
I have 3 there because I assumed it would map to IK_GROUND in code, but it
does not. I've also tried in my ikrules contact 0 and height 24 with no
noticeable difference resulting.
With these settings currently the legs only seem to have very little range
in the idle because it sets the model height to be based off the highest leg
instead of the lowest leg and so when model is at a little ledge with ground
not very far below the leg can't reach because the idle has the legs almost
full extended.
Thanks
Chris
___
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] Unintended Rotation of Parented Props
I'm not looking at the code at the moment but as I recall you can add an attachment to the player and use SetParentAttachment() to put it in hierarchy with any of the player's skeleton's coordinate systems. There's also an example prop with behavior like you want: prop_dynamic_ornament or prop_ornament as I recall. Jay -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Kohan Venets Sent: Saturday, July 04, 2009 10:57 PM To: hlcoders Subject: Re: [hlcoders] Unintended Rotation of Parented Props Uh... How would I do that? To clarify, I mean that the flag rotates *around the player*. As in, it hovers 100 units above the player's head when the player is looking forward, and if the player is looking straight down it hovers 100 units directly in front of the player. It rotates with the player as its center. -Kohan Jorge Rodriguez bs.v...@gmail.com said: You can override the render angles on the client. -- Jorge Vino Rodriguez Kohan Venets idr...@hotmail.com said: I have a flag prop which, when picked up by the player, is supposed to hover over their head. Unfortunately, setting the player as the parent of the flag causes the flag to rotate with the player's view. Is there any way to attach it to the player's position without preserving the player's rotation? Thanks. -Kohan _ Lauren found her dream laptop. Find the PC that's right for you. http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290 ___ 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] Studio Light Data
I'm not looking at the hl1 code, but as I recall we didn't actually store any character lighting info in the maps (other than the world lights - used for direct lighting). We just sampled the lightmap colors to generate it at runtime. We did the same kind of thing in the first version of source (although there is a cache and an API to query it and the cache also stores the nearest world lights). Later versions of source (Orange Box forward) store a set of cubemaps in the LEAFAMBIENT lumps in the BSP for the indirect lighting. Vrad generates those and they are filtered to generate the directional ambient light per character/object. That's why the ambient generally looks better in orange box and l4d. So for goldsrc there may be a lightmap tracing function in the SDK interface (lightvec or similar name). It would be the same as tracing a ray but you get the surface light color back as well as the normal you hit (and it's more expensive to compute because the intersection has to be clipped against the faces instead of just the bsp planes). I don't remember if we exposed that through the SDK or if it's only used by the engine. The other piece you'd need is to get the nearest world lights. If that's not exposed you could replicate it by parsing the BSP and storing your own copy of them. Jay -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Tom Leighton Sent: Wednesday, May 20, 2009 7:50 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Studio Light Data This may be of use if you want to know where in the BSP it is stored, http://www.geocities.com/cofrdrbob/bspformat.html Tom Andrew Lucas wrote: Hello. Lately, I've been experimenting with light calculations on my models, in GoldSrc. I've been trying to get light values from the world myself, but I have no idea how Half-Life stores it's light values, and gets them. For model rendering, Half-Life gets a color, an integer for shade lighting, another for ambient lighting, and a light vector. I wonder, can anyone tell me how this information is stored in the map? Thanks. Andrew. _ Windows Live(tm): Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 ___ 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] VectorRotate
You can't negate an euler parameterization like QAngles to invert it except in special cases (e.g. your QAngle is zero on two axes). matrix3x4_t boneTransform; AngleMatrix( aHitBoxAngles, vHitBoxPos, boneTransform ); Then you can VectorRotate() and VectorIRotate() to perform forward / inverse rotations. Jay -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Janek Sent: Thursday, April 23, 2009 8:31 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] VectorRotate This is the question I am thinking about. Sounds like the answer is no. I'm trying to determine which transformation of the angles I have to do. If somebody knows, I get it :) 2009/4/23 Jonas 'Sortie' Termansen hlcod...@maxsi.dk Can you really invert the angle like that in 3 Dimensional space? - Original Message - From: Janek jan...@gmail.com To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Thursday, April 23, 2009 5:09 PM Subject: [hlcoders] VectorRotate Hi all, There is something I don't understand with VectorRotate method. I did the following test : Vector vHitBoxPos; QAngle aHitBoxAngles; mstudiobbox_t *pbox = set-pHitbox(j); if ( !pbox ) continue; pPlayer-GetBonePosition( pbox-bone, vHitBoxPos, aHitBoxAngles ); Vector vBefore (10,10,10); Vector vAfter; VectorRotate( vBefore , aHitBoxAngles, vAfter ); Vector vBefore2; VectorRotate( vAfter, -aHitBoxAngles, vBefore2 ); I can see that vBefore2 has nothing to see with vBefore even if I thought it should. How can I find back vBefore using vAfter and aHitBoxAngles ? Thank you in advance for your help. --- j...@nek ___ 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 -- --- j...@nek ___ 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] Collision between Ar2 Balls and Gunships
I'm not looking at the code right now, but as I recall the ar2 energy ball is a vphysics object and only collides with other vphysics objects. The grenades have vphysics objects as well as tracelines so they can hit animated entities' hitboxes as well. The strider has bone followers so the ar2 ball (and other vphysics objects) can hit those. I don't remember what the gunship's physics representation is - but maybe it has one that doesn't enclose a bunch of the model (or maybe it doesn't have one). So you could either modify the vphysics setup of the gunship (add bone followers?) or add tracelines to the VPhysicsUpdate of the ar2 ball to hit hitboxes like the grenade does. Jay -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Jonas 'Sortie' Termansen Sent: Saturday, April 18, 2009 8:34 AM To: Discussion of Half-Life Programming Subject: [hlcoders] Collision between Ar2 Balls and Gunships Hey. In an attempt to invent some new gameplay, I tried launching the secondary fire on the Ar2 against a Combine Gunship. However the Ar2 Ball went straigth through the Combine Gunship for some reason, with no collision at all. I noticed both the Gunship and the Ar2 Ball have their own collision group, and I changed the game rules so that they always collided, but with no result. I added debug code that put them into different collision groups but with the same result. Having compared code from the Gunship with code from the Strider (which the balls do hit), I found they did a few things differently, but I was unable to pinpoint what exactly made the balls hit the strider. What makes the gunship collide differently that allows normal grenades to hit it, but not Ar2 balls? ___ 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] UTIL_EntitiesInBox cause a game to freeze.
Check the bounding box you are sending it. It doesn't clamp to the world bounds and will loop for a long time if you send it invalid bounds. -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Tony Sergi Sent: Wednesday, March 18, 2009 2:44 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] UTIL_EntitiesInBox cause a game to freeze. Post the code that uses it. -Tony -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Charkrid Pornpitackchaikul Sent: March-18-09 5:13 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] UTIL_EntitiesInBox cause a game to freeze. Hi, I just adjust my melee attack collision code to use UTIL_EntitiesInBox() so it support multiple target hit. But the function is enter a finite loop and never return. I can't debug more deeper, because I don't have a engine code. Does anyone counter this problem? Please help me with this. Thanks in advance. ___ 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] Compiling a complex static prop - Weird collision boxes
You really have to measure this stuff. It depends on so many things. If the models are used as prop_static: There is a partitioning done inside the set of convexes so if that partitioning is as good as the bbox one you'll get from the engine's code then it's a wash. The reason you could gain perf is that the convex/convex partitioning is done with a sphere tree and the engine's partitioning of entities is done with AABBs. So if your convexes fit to AABBs much better than they fit to spheres then you'll do fewer ray tests in the case where you split the models. If the models are used as prop_physics: You can't really split them and save anything since all of the pieces are still moving and the cost is proportional to that. So it may not make a difference to split. -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Aditya Gaddam Sent: Tuesday, March 10, 2009 3:29 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Compiling a complex static prop - Weird collision boxes I would think so yes. I would only be worried about the maximum model count (if there is such a thing). Otherwise, that makes a bit more sense actually :) - Aditya On Sun, Mar 8, 2009 at 9:11 PM, Minh minh...@telus.net wrote: I sometimes use models that are more than 20 convex pieces. Would it be more efficient if I broke those models up into smaller models? So if a traceline hits one of the submodels, it only has to check that model's group of convex pieces. Jay Stelly wrote: It's compiling each face as a separate convex because the normals aren't smooth. Set a single smoothing group for each piece that you want to be separate and it should work fine. Note that you can also configure studiomdl to output the 76-hull model it's computing (which would work too) but that would be really slow for physics and traces, that's why it detects and prints out an error. -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Aditya Gaddam Sent: Saturday, March 07, 2009 7:18 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Compiling a complex static prop - Weird collision boxes Hi, Sorry it took me so long to get back to this. I tried out what people said - making edges hard. I checked the normals and they seem to pointing the right direction (they all point where the polys face. My output for studiomdl is: === === C:\Program files\steam\steamapps\...@hotmail.com\sourcesdk\bin\orangebox\ bin\studiomdl.exe -game C:\Program Files\Steam\steamapps\SourceMods\Tactics E:\Documents\Work\Programming\C++\Tactics\modelsrc\map\walls\ floor_stairs.qc Process started WARNING: AppFramework : Unable to load module p4lib.dll! qdir: e:\documents\work\programming\c++\tactics\modelsrc\map\walls\ gamedir: C:\Program Files\Steam\steamapps\SourceMods\Tactics\ g_path: E:\Documents\Work\Programming\C++\Tactics\modelsrc\map\walls\ floor_stairs.qc Building binary model files... Working on floor_stairs.qc SMD MODEL floor_stairs_ref.smd SMD MODEL floor_stairs_idle.smd SMD MODEL floor_stairs_phys.smd WARNING: Model has 2-dimensional geometry (less than 0.500 inches thick on any axis)!!! ... exactly 76 of these WARNING: Model has 2-dimensional geometry (less than 0.500 inches thick on any axis)!!! WARNING: COSTLY COLLISION MODEL (76 parts - 20 allowed) WARNING: Error with convex elements of floor_stairs_phys.smd, building single convex Model has 1 convex sub-parts Collision model completed. - writing C:\Program Files\Steam\steamapps\SourceMods\Tactics\models/map/walls/floo r_stairs.mdl: bones 964 bytes (1) animations 112 bytes (1 anims) (1 frames) [0:00] sequences 220 bytes (1 seq) ik/pose164 bytes eyeballs 0 bytes (0 eyeballs) flexes 0 bytes (0 flexes) textures 136 bytes keyvalues0 bytes bone transforms0 bytes Collision model volume 4907876.50 in^3 collision0 bytes total 1916 - writing C:\Program Files\Steam\steamapps\SourceMods\Tactics\models/map/walls/floo r_stairs.vvd: vertices 20400 bytes (425 vertices) tangents 6800 bytes (425 vertices) total27264 bytes - Generating optimized mesh C:\Program Files\Steam\steamapps\SourceMods\Tactics\models/map/walls/floo r_stairs.sw.vtx: body parts: 8 bytes models:20 bytes model LODs:12
Re: [hlcoders] Compiling a complex static prop - Weird collision boxes
You should only have one $collisionmodel statement. Studiomdl does not support
aggregating those.
You didn't post any output. studiomdl must be reporting an error if it's
falling back to a single convex hull. What is the error? Post the output.
There are two likely cases:
1) The smoothing group suggestion. There's a simple vertex welding algorithm
in the collision model code that requires you to share normals at vertices to
have those faces belong to a single convex. This is why you have to set
smoothing groups.
2) Too many convex pieces. The default is 20 (I think 40 in l4d on). This is
a budget, the physics system can support large numbers but performance may be a
problem. Anyway, you can set this in your script with $maxconvexpieces:
$collisionmodelfloor_stairs_floor_phys.smd
{
$concave
$maxconvexpieces 100
}
Jay
-Original Message-
From: hlcoders-boun...@list.valvesoftware.com
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of
Aditya Gaddam
Sent: Wednesday, March 04, 2009 5:15 AM
To: Discussion of Half-Life Programming
Subject: [hlcoders] Compiling a complex static prop - Weird
collision boxes
Hi,
I am currently trying to compile a complex static prop. I
say complex
because it is basically the little stairway prop shown in
this screenie:
http://upload.pixelfaction.com/files/49ae7dad_stairs.jpg
It is however being a PITA to export.
Just exporting the same merged mesh as the ref, idle and phys
smds didn't
work out. I get a shrinkwrapped (as the wiki called it)
collision model
out of studiomdl.
I then tried exporting the phys smd as several phys smds,
each containing a
piece of the model positioned from the origin in the right place. So I
exported a stairs_floor_phys.smd, stairs_toprail_phys.smd etc and then
changed the qc file to this:
$modelname map/walls/floor_stairs.mdl
$body floor_stairs floor_stairs_ref.smd
$surfaceprop concrete
$cdmaterials models/map/walls/1/
$sequence idle floor_stairs_idle.smd loop fps 15
$scale 1.0
$collisionmodelfloor_stairs_floor_phys.smd
{
$concave
}
$collisionmodelfloor_stairs_toprail_phys.smd
{
$concave
}
$collisionmodelfloor_stairs_bottomrail_phys.smd
{
$concave
}
$collisionmodelfloor_stairs_stairs_phys.smd
{
$concave
}
$staticprop
This didn't work out well either. Only the stairs seemed to
get a collision
mesh and it was funky (some of the stairs worked like stairs,
others had
holes in the mesh at random places (my grenades would go
through to the
floor) and others were just covered by a flat plane type
collision mesh.
What is the right way to go about these kinds of meshes? Any
pointers would
be appreciated. Tutorials I have seen online always work with
very simple
props like a barrel etc.
Thanks,
Aditya
--
http://www.pixelfaction.com
AIM:ApeWithABrain
___
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] Looping .mp3 music
We don't support looping mp3 files. You can loop PCM waves and ADPCM waves though using CUE chunks or Sampler chunks to specify the loop point. Lots of tools will write those chunks. -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of ][akep nuxdie Sent: Sunday, March 01, 2009 7:16 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Looping .mp3 music maybe this will help you: http://www.interlopers.net/tutorials/27356 On Sun, Mar 1, 2009 at 1:59 AM, Walter Gray chrysal...@gmail.com wrote: Hey again list, A member of my team's been a little stumped on this, and I've done some quick checking around the wiki and hlcoders archives, but I've been unable to find anything on looping music, or more specifically looping .mp3 sound files. Does anyone know of any good references or if it's even possible to loop .mp3s? ___ 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] Grenade aftermath sound effect.
The dsp effects are set up in a script:
Scripts/dsp_presets.txt
The ringing sound is a sinewave generated by an LFO (low frequency osciallator)
in those effects:
{ 35 LINEAR 0.2 0.7 1.6 -1.0 80 0.5
// *** SHOCK MUFFLE 1 ***
// DFR size #dly
feedbk
{ DFR 1.0 2
0.15}
// LFO wavtype
ratefoneshot gain
{ LFO SIN
3000.0 0.0 0.25}
}
{ 36 LINEAR 0.2 0.7 1.6 -1.0 80 0.5
// *** SHOCK MUFFLE 2 ***
// DFR size #dly
feedbk
{ DFR 1.0 2
0.15}
// LFO wavtype
ratefoneshot gain
{ LFO SIN
3000.0 0.0 0.25}
}
{ 37 LINEAR 0.2 0.7 1.6 -1.0 80 0.5
// *** SHOCK MUFFLE 3 ***
// DFR size #dly
feedbk
{ DFR 1.0 2
0.15}
// LFO wavtype
ratefoneshot gain
{ LFO SIN
3000.0 0.0 0.25}
-Original Message-
From: hlcoders-boun...@list.valvesoftware.com
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of
Aditya Gaddam
Sent: Saturday, February 28, 2009 5:35 PM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Grenade aftermath sound effect.
enginesound-SetPlayerDSP( user, effect, false );
That seems to be the magic function. The value (an integer)
you pass to effect results in different effects.
35-37 does the ringing with muffled noises
32-34 does the muffled noises only
I haven't found a list of constants to pass to this
anywhere... searching for SetPlayerDSP on the wiki gives me nothing :(
Anyone know of a list of these constants?
Thanks,
Aditya
On Sat, Feb 28, 2009 at 11:51 AM, Yorg Kuijs
yorg.ku...@home.nl wrote:
If you're trying to find the sound itself, afaik it's generated by
audio part of source I guess and isn't in a .wav If not I
don't know
if this will help but in CBasePlayer where you've been
messing around
I have found that this does handle ear ringing at least,
maybe not the
DSP thing but I modified the constant defininitions in my
mod to this:
#define MIN_SHOCK_AND_CONFUSION_DAMAGE999.0f
#define MIN_EAR_RINGING_DISTANCE999.0f // 20 feet
this results in disabling the ear ringing effect, but the
sound muffle
is still there so look around where these constant definitions are
used to find out what handles the ear ringing.
Aditya Gaddam wrote:
Sorry, that was... stupid. That does the muffling effect. I will
just
play
around more before asking useless questions.
Thanks again Andrew.
___
To unsubscribe, edit your list preferences, or view the
list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
http://www.pixelfaction.com
AIM:ApeWithABrain
___
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] Flight controls problem
Our math library has functions for converting to/from QAngle and a matrix (use matrix3x4_t for a standard rotation + translation). So you'd do something like: matrix3x4_t currentRotation, incrementalRotation, nextRotation; QAngle angles = GetAbsAngle(); AngleMatrix( angles, currentRotation ); // compute an incremental 1 degree of roll AngleMatrix( QAngle( 0, 0, 1 ), incremenetalRotation ); ConcatTransforms( incrementalRotation, currentRotation, nextRotation ); MatrixAngles( nextRotation, angles ); SetAbsAngles( angles ); To do your previous example of adding 1 degree to roll. You could just use a matrix all the way through, but I'm describing it this way in case you're using a bunch of our other code (like player orientation) that is already using/networking a QAangle for orientation. Jay -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Christopher Harris Sent: Friday, February 27, 2009 1:48 PM To: 'Discussion of Half-Life Programming' Subject: Re: [hlcoders] Flight controls problem Instead of doing angle.x/y/z += value you need to instead compute a rotation matrix and then multiply it with the current angle and set that to the new angle. Chris -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Grash Sent: Friday, February 27, 2009 4:28 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Flight controls problem My students are asking... Where would I apply this matrix translation? Im currently just using setabsangle(qangle) --- On Fri, 2/27/09, Julian Moschüring ar...@gmx.com wrote: From: Julian Moschüring ar...@gmx.com Subject: Re: [hlcoders] Flight controls problem To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Date: Friday, February 27, 2009, 4:11 PM http://en.wikipedia.org/wiki/Gimbal_lock Garry Newman schrieb: Rotate using a Matrix garry On Fri, Feb 27, 2009 at 8:23 PM, Grash mr_gr...@yahoo.com wrote: They've been trying to figure this out for the past 3 weeks. What's the best way to tackle this problem? - Grash --- On Fri, 2/27/09, Christopher Harris char...@resrchnet.com wrote: From: Christopher Harris char...@resrchnet.com Subject: Re: [hlcoders] Flight controls problem To: 'Discussion of Half-Life Programming' hlcoders@list.valvesoftware.com Date: Friday, February 27, 2009, 3:05 PM I think that the more rolled toward 90 degrees on side you are the more yaw will need to adjusted versus pitch since to the game each axis of the angle is independent of each other. Chris -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Grash Sent: Friday, February 27, 2009 1:58 PM To: Discussion of Half-Life Programming Subject: [hlcoders] Flight controls problem One of my students is writing this email out about a problem they are having. Any help would be greatly appreciated. We are looking to replace the player with an aircraft model. We changed the mouse controls to affect the pitch and roll, rather then the pitch and yaw. the mousex is affecting the roll and the mousey is affecting the pitch(which hasn't changed) for some reason when we roll the player lets say 90 degrees on its side. when we change the pitch, the player model is not pivoting right. the pitch will still have the player look to the sky rather then rotating sidewards. The 90 degree change on the roll should be affecting the pitch, but it is not. This is an example of the code we are using. QAngle angle = GetAbsAngle(); angle.z+=1; SetAbsAngle(angle); ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] MDL question
HW bones is the count of bones actually used to render the model. (HW = hardware) Those are the bone transforms that are loaded into constant registers for skinning on the GPU each time the model is drawn. Also, you can use this qc command to remove unnecessary bones from the model: http://developer.valvesoftware.com/wiki/$collapsebones -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Jorge Rodriguez Sent: Wednesday, January 21, 2009 8:43 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] MDL question I believe HW bones uses some kind of video card hardware acceleration to make things to faster, and is an OB feature. I know all the TF2 models use it. I believe it may have optimized nine of your bones out, automatically doing the attachment offset dealie. I could be wrong. -- Jorge Vino Rodriguez ___ 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] Explanation of mapautocompile.txt Compile parameters?
You should time it to be sure, but -staticproppolys shouldn't be very much more expensive in Source 2007 and beyond. It does increase vrad startup time; that's probably the most significant cost. -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Robert Briscoe Sent: Tuesday, January 06, 2009 9:51 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Explanation of mapautocompile.txt Compile parameters? Yes, but only costly on compile time and not at runtime. - Original Message From: Matt Hoffman lord.matt.hoff...@gmail.com To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Tuesday, 6 January, 2009 16:57:19 Subject: Re: [hlcoders] Explanation of mapautocompile.txt Compile parameters? VDC says it's very costly, seeing as it's using the actual polies instead of the collision model, which is rather basic for alot of things. On Tue, Jan 6, 2009 at 4:08 AM, Robert Briscoe bris...@yahoo.co.uk wrote: I believe -staticproppolys specifies that VRAD use the model for shadow casting instead of the collision model for more accurate shadows at the cost of a slightly longer compile time. - Original Message From: Matt Hoffman lord.matt.hoff...@gmail.com To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Tuesday, 6 January, 2009 1:37:14 Subject: [hlcoders] Explanation of mapautocompile.txt Compile parameters? Goodday list, writing in for the first time. Inside of Episode Two Content.gcfscripts, there's a mapautocompile.txt. Inside is stuff like this: map: ep2_outland_04 vbsp: vvis:-mpi vrad:-final -dispchop 2 -staticproppolys -staticproplighting -textureshadows -both -mpi For each map. I assume that this is used by an internal program of Valve's to do a final compile of the maps. However, I'm curious as to what some of the parameters are. -MPI. Is this VMPI minus the V? Or is it something completely different? -Dispchop 2: What does this do? Is it chopping up displacements? If so, how does 2 affect it? What's -staticproppolys do? I know -staticproplighting is to make static_props cast more specific lighting(?), and i know -textureshadows improves the shadows too. Thanks guys. ___ 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] Grenades going through spawned models
If you are using the frag grenades from hl2 they use collision groups to specifically disable collisions between their physics objects and other objects (NPCs for example). Then they trace rays to fake it in their VPhysicsUpdate() function. That allows them to bounce off of the NPCs' hitboxes without those hitboxes actually being in the physics simulation. It's possible that the reason they aren't colliding is this collision rule behavior. Try changing the collision group of the grenade or the other entity to COLLISION_GROUP_NONE and see if that fixes the problem. Jay -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Aditya Gaddam Sent: Thursday, January 01, 2009 8:32 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Grenades going through spawned models BUMP. Anyone have any clues about this? On Tue, Dec 23, 2008 at 5:41 AM, Aditya Gaddam adityagad...@gmail.comwrote: Hi, I have project where I am spawning some models programmatically. They collide fine with me and most ammunition (including rockets, crossbow bolts, SMG secondary fire), but grenades and the secondary fire for the assault rifle seem to just go through. The models being spawned derive from CBaseAnimating and have SOLID_VPHYSICS via SetSolid. Does anyone have any idea why this would be? Thanks, Aditya -- http://www.pixelfaction.com AIM:ApeWithABrain -- http://www.pixelfaction.com AIM:ApeWithABrain ___ 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] Expanding trigger (from a newbie)
I can't think of a way to do this if the trigger is a brush. If you use a bounding box (SOLID_BBOX) you should be able to change the trigger's bounds and just call TriggerMoved(). Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, December 08, 2008 10:53 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Expanding trigger (from a newbie) I am creating a king of hill game called lava in which players are pushed off of platforms into a pit of so called LAVA I have a lavaTrigger that marks the players out. What I would like to do is have the lava trigger grow and expand to cover the entire map over a period of time. (to eliminate stalemates between players) How would I go about doing this? I would Also Like to have the floor grow also if I could any points in the right direction would be more than helpfull thank you ~Nemus (Hlcoder Newbie) ___ 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] Player solidity
Player collisions aren't that simple because there are multiple systems for them. There are three systems that interact with player collisions: Gamemovement - the player sweeps a box through the world, hitting things that are solid. This is where the player's movement happens. If you want to modify which things impede the player's movement, you do it in gamemovement. Player's solid flags / solid type / collision property - Other entities also sweep a box through the world like the player does. These flags determine whether the player is solid to them (along with those entities' trace filters and contents masks). This will determine whether NPCs bump into the player, etc. Vphysics object - this is only used to control collisions between the player and entities that are MOVETYPE_VPHYSICS. In HL2 (this is not true for all of the multiplayer games, so it depends on which set of rules you are using) the player is represented by a separate physics object. After gamemovement determines where the player would like to go the physics simulator runs and tries to move this proxy/shadow object to that location. If it succeeds then nothing changes. Otherwise if it hits some simulated object along the way the player code may decide to to the results of the physics simulation instead of gamemovement. Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Static prop skins = more draw calls?
Each vmt change is a new batch. So yes, that will be 3 draw calls minimum. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz Sent: Sunday, October 19, 2008 1:44 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Static prop skins = more draw calls? I'm glad this was brought up. How does a material proxy affect the number of batches done? For example, I have a player model who uses a single texture. However, I have the model's triangles divided up so that there are 3 separate vmts referenced. Each vmt uses the same texture file, but each one has a proxy that will change the texture's color. IE, the player's shirt is tinted with one color while the pants are tinted with another color. Is that causing an extra draw call even though the same texture is used? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Driving/Racer Mod
What vehicle script are you using? The vehicle scripts are not the same between orange box and hl2. You can use the hl2 buggy model, but if you're developing a mod for the orange box engine you should start with the vehicle script from ep2, not the one from hl2. The steering parameters and code are different in the orange box. Also, be sure to set ent_bbox on the vehicle and vcollide_wireframe 1 so you can see the underlying physics visualized. That will help you see the difference between animation problems and physics problems. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lekkere Soep Sent: Sunday, October 12, 2008 7:24 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Driving/Racer Mod Dear HLCoders, While working on a small (first) project to create a(n OrangeBox) mod where one can drive vehicles in 3rd person, I've immediately run into several problems. I am not looking for you to chew out strands of code for me to copy paste; I am willing to put in my own time. I am just still not completely home to the engine. - First and foremost, and likely the most illogical, is the steering issue. When using the original Buggy from HL2, all works fine in a custom room within HL2. However, when you select 'Create a Mod', change nothing, and then run the same identical room, you can drive front and back, but are unable to steer. When you save this game and load it back, you cán steer, only at lower increments. Are there certain flags to (not) be set when starting the game..? - Then as a different issue; I'm looking to lock the camera in place behind the car, disabling free view (like when playing in first person, the direction you face is always forward). I am not sure if getting the vehicle to turn when moving the mouse is doable without too much work, but if thats the case wasd controls will suffice. Free look however is still a nuisance, and should be disabled. Any pointers on where I should be looking would be apreciated. There are obviously some other issues, but I have to look into those myself first. Regards, Jay _ Jouw nieuws en entertainment, vind je op MSN.nl! http://nl.msn.com/ ___ 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] Cloth and Liquids
IPhysicsFluidController is used to control the simulation of objects within a fluid. It does not simulate the fluid itself. So this is the code that implements the floating behavior of objects and other fluid effects. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of red box Sent: Tuesday, October 07, 2008 8:53 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Cloth and Liquids There's currently a discussion over on the Steam forums about using Physx for cloth physics. Here's the entire thread: http://forums.steampowered.com/forums/showthread.php?t=732486 I already seen it, but thank you. Another question: in vphysics_interface.h I find class IPhysicsFluidController;. possible this is that I need but don't know how use it. whether exists some exampes of using it in game (episode two)? -- реклама --- http://FREEhost.com.ua - доступный хостинг, домен в подарок ___ 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] grenade code
Add this line. It will get vphysics to generate touch functions for the
grenade.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Yorg Kuijs
Sent: Sunday, August 24, 2008 9:09 AM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] grenade code
ok been trying out more stuff and found the culprit:
it's:
bool CGrenadeMelon::CreateVPhysics()
{
// Create the object in the physics system
VPhysicsInitNormal( SOLID_BBOX, 0, false );
VPhysicsGetObject()-SetCallbackFlags(
VPhysicsGetObject()-GetCallbackFlags() | CALLBACK_GLOBAL_TOUCH |
CALLBACK_GLOBAL_TOUCH_STATIC );
return true;
}
if I would remove this then melon explodes when it touches
something BUT it just drops to the ground like a brick and so
can't be thrown anymore, been trying to find a workaround but
can't really find it.
argument for solid_bbox is good afaik, so it's either has to
do with the false/true values I think, but changing them
didnt seem to change anything.. AT ALL.
so any advice on what to do?
___
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] Get/dump console output to file
Depending on which version of the engine you're using you will have access to some or all of these: -condebug command line parameter will do this (mentioned below) con_logfile will dump to a specific file (and can be turned on off). If you're writing a mod or plugin you can write/set your own Spew function using tier0/dbg.h -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 1nsane Sent: Wednesday, August 13, 2008 4:29 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Get/dump console output to file If this is on srcds, add -condebug to your launch options. This will create a file called console.log which will log everything. If you are running this in developer X mode you will get all the console output logged. However... it will log evereything to that one file, so you can get 1gb text files it you dont rename/delete. On Wed, Aug 13, 2008 at 6:39 PM, Chris Deegan [EMAIL PROTECTED] wrote: Not sure if this is useful, but as I used to run all of my srcds instances in 'screen' on Linux - very handy when you are running headlesss remote servers. Doing it this way you can simply spawn the screen with the -L switch. This will pump all text into a file called screenlog.0. It gets everything! I hope this helps. Chris Tiago Conceição wrote: Now can i get the console output from srcds using a plugin Anyway without redirecting stdout?? or dup stdout to a file?? thanks _ Receba GRÁTIS as mensagens do Messenger no seu celular quando você estiver offline. Conheça o MSN Mobile! http://mobile.live.com/signup/signup2.aspx?lc=pt-br ___ 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] Map won't load with these errors, possible explanation?
The important error is here: Missing RecvProp for DT_BasePlayer - DT_BasePlayer/m_iFOV Host_EndGame: CL_ParseClassInfo_EndClasses: CreateDecoders failed. That's what is causing the issue. This error means that the server-side definition of DT_BasePlayer has m_iFOV but the client-side definition does not. Do a find in files for DT_BasePlayer and check it. Did you add m_iFOV to the server or maybe integrate some code from a different version of the sdk? It just needs the matching receive prop in the client so the networking knows what to do with the data it gets. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cory de La Torre Sent: Sunday, April 27, 2008 7:37 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Map won't load with these errors,possible explanation? Ah On Sun, Apr 27, 2008 at 6:11 PM, Mark Chandler [EMAIL PROTECTED] wrote: It's a 'not' defined. Hes not running any xbox code at all. The problem is that the tracking libs use timeGetTime and valve doesn't want people to use that for some reason. Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cory de La Torre Sent: Monday, April 28, 2008 8:57 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Map won't load with these errors, possible explanation? Seems your running Xbox code... On Sun, Apr 27, 2008 at 4:44 PM, Timothy Chilvers [EMAIL PROTECTED] wrote: When I run my map, I get the dev console up with these errors at the end: material vgui/hud/xbox_reticle not found --- Missing Vgui material vgui/hud/xbox_reticle No pure server whitelist. sv_pure = 0 CAsyncWavDataCache: 0 .wavs total 0 bytes, 0.00 % of capacity Initializing renderer... Missing RecvProp for DT_BasePlayer - DT_BasePlayer/m_iFOV Host_EndGame: CL_ParseClassInfo_EndClasses: CreateDecoders failed. I think it might be because I had to take this out to compile with my motion tracking libraries: Code from protected_things.h here, line 154-159 by default: #ifndef _XBOX #if defined( timeGetTime ) #undef timeGetTime #endif #define timeGetTimetimeGetTime__USE_VCR_MODE #endif Is this likely to be the problem (Which I don't particularly understand how it could be) or something else? Thanks in advance, Tim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- Gear Dev ___ 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 -- Gear Dev ___ 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] randomness
Do you mean that you get the same sequence of numbers over consecutive runs of your mod? If so, that is the expected behavior. Low-level random number generators are typically deterministic functions. If you want them to give you different values each time you run you need to set them up with different initial conditions. The initial conditions are usually (and definitely in our case) set using a single value called a seed. A typical way to make this non-deterministic is by taking a sample of the system clock and using it as the seed for the random number generator. E.g. #include time.h RandomSeed( (int)time(NULL) ); Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Gornall Sent: Friday, March 21, 2008 3:40 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] randomness Hi, I'm using the Advanced SDK, Ep1 edition and I seem to be having real trouble getting radomness in the random numbers. I can see that there is code there for predicted/shared randoms, but I'm just using RandomFloat or random-RandomFloat but it seems to always give the same numbers. Anyone know why that would be? Am I doing it wrong? Thanks, Mark. ___ 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] extract detail model positions from a .bsp file?
Look at src/game/client/detailobjectsystem.cpp. It's the part of the client DLL that loads and processes all of the data output by vbsp for detail sprites. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Donovan Sent: Friday, March 14, 2008 8:14 AM To: Ryan Sheffer Cc: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] extract detail model positions from a .bsp file? Hi Ryan, By detail props I mean the type of models that are generated automatically on a WorldVertexTransition transition texture based on alpha ranges I always thought it was done at compile time because I see the following line when compiling Placing detail props : 0...1...2...3...4...5...6...7...8...9...10 or is this something else? I would look in the bsp file if there was a simple way to read it as text? -is there? - it just looks like garlbe mess when i open one in notpad..maybe i should try a hex editor? I havent looked into the code for the bsp files yet maybe I will now have a look..any help on this would be cool cause then we might be able to make a small tool that others can use to place any type of entity. thanks again adam Date: Thu, 13 Mar 2008 23:18:45 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] hlcoders digest, Vol 1 #3715 - 6 msgsextract detail model positions from a .bsp file? Are you sure they are compiled? I thought those were generated as func_detail on runtime. If surface detail models are done on compile, they are probably merged with Model 0 (worldspawn). If you find those are generated in vbsp, then just alter vbsp to dump a list of coordinates for you. We have the vbsp code, not the orange box ones yet though I don't think. On Thu, Mar 13, 2008 at 7:02 PM, Adam Donovan [EMAIL PROTECTED] wrote: Hi Again all, Is there any way anyone knows of a way to extract detail model positions from a .bsp file? I would like to be able to rip the x,y,z information of the detail models so that I can use the coordinates to place static props. By detail models I mean the unlit models that are emitted from a .vbsp file at compile time. Any ideas help? Adam _ New music from the Rogue Traders - listen now! http://ninemsn.com.au/share/redir/adTrack.asp?mode=clickclientID=832re ferral=hotmailtaglineOct07URL=http://music.ninemsn.com.au/roguetraders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ~Ryan _ Overpaid or Underpaid? Check our comprehensive Salary Centre http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fcontent%2Emycareer%2Ecom %2Eau%2Fsalary%2Dcentre%3Fs%5Fcid%3D595810_t=766724125_r=Hotmail_Email _Tagline_MyCareer_Oct07_m=EXT ___ 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] Which EmitSound method should I use?
Duration is an output that tells you how long the sound will take to play. Soundtime is for sub-frame timing on wave playback. i.e. without a soundtime the sound will start on the next client frame. We use this for things like machine gun sounds that need to be played exactly 75ms apart regardless of the client framerate for example. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Edwards Sent: Friday, March 07, 2008 1:09 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Which EmitSound method should I use? The simplest overload I can find is this one: voidEmitSound( const char *soundname, float soundtime = 0.0f, float *duration = NULL ) It's used by the playgamesound convar. I've no idea what the difference between soundtime and duration is though. :-s Jed wrote: Hey all. I want to play a sound file on a game event handled in my gamerules file. I just want to play it normally for each player with no apparent source - basically like a global sound. I know I want the EmitSound function ( or at least I *think* I do :) ) but it's got quite a few differnt constructs and for the life of me I can't find the simple version to do what I want. So how should I call EmitSound to just play a WAV or MP3 file once from gamerules with no origin, i.e. like a soundtrack? - Jed ___ 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] Steam not working?
tracert is not failing there it's being rejected. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Leighton Sent: Tuesday, March 04, 2008 2:56 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Steam not working? They're all the same (obviously not addresses), but there is always 1 single point of failure: Tracing route to steam15.steampowered.com [207.173.177.150] over a maximum of 30 hops: 11 ms1 ms1 ms www.routerlogin.com [10.0.0.1] 224 ms24 ms22 ms rt-losta08.dial.aol.com [195.93.23.8] 3 ** 25 ms iptfarmla-los-sw0-V3.net.aol.com [195.93.17.30] 425 ms23 ms23 ms accessl1-los-A0.net.aol.com [172.17.169.11] 524 ms24 ms24 ms pop1-loh-S2-1-0.atdn.net [66.185.146.65] 624 ms24 ms24 ms sl-gw23-lon-12-0.sprintlink.net [213.206.157.153 ] 725 ms25 ms24 ms sl-bb22-lon-8-0.sprintlink.net [213.206.128.60] 893 ms92 ms92 ms sl-bb20-nyc-2-0.sprintlink.net [144.232.9.163] 991 ms91 ms92 ms sl-bb26-nyc-6-0.sprintlink.net [144.232.13.9] 1091 ms92 ms92 ms sl-bb22-nyc-6-0.sprintlink.net [144.232.7.42] 11 116 ms 115 ms 116 ms sl-bb21-chi-3-0-0.sprintlink.net [144.232.20.102 ] 12 117 ms 115 ms 116 ms sl-bb20-chi-14-0.sprintlink.net [144.232.26.1] 13 116 ms 115 ms 115 ms sl-st20-chi-13-0-0.sprintlink.net [144.232.20.3] 14 117 ms 116 ms 115 ms sl-INTEG92-124539-0.sprintlink.net [144.228.158. 46] 15 178 ms 176 ms 176 ms tg9-2.cr01.chcgildt.integra.net [209.63.114.37] 16 176 ms 175 ms 176 ms p4-0-0.cr01.mplsmncd.integra.net [209.63.113.85] 17 176 ms 176 ms 176 ms te9-4.cr02.mplsmncd.integra.net [209.63.98.30] 18 297 ms 190 ms 174 ms p4-0-0.cr02.sttlwatw.integra.net [209.63.98.26] 19 175 ms 174 ms 175 ms tg9-1.ar10.tkwlwazs.integra.net [209.63.114.130] 20 198 ms 196 ms 191 ms gw0-cust-valvesoftware-com.tkwl.eli.net [209.63. 173.46] 21 gw0-cust-valvesoftware-com.tkwl.eli.net [209.63.173.46] reports: Destinati on net unreachable. Kevin Ottalini wrote: Tom, try delete any existing firewall permissions for Steam.exe and let it learn the permissions or manually re-add them again. - Original Message - From: Tom Leighton To: hlcoders@list.valvesoftware.com Sent: Tuesday, March 04, 2008 1:55 PM Subject: [hlcoders] Steam not working? Guys, i would ask BurtonJ (But since steam isnt working, i cant), does anyone else have any problems loading steam? It wouldn't load (Even after restarting), so i deleted clientregistry.blob, tried again, not working. Tried reinstalling, didn't work. Tried restarting, reinstalling, restarting and it still doesnt work. It's stuck on 0% update. Any other ideas? ___ 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] Think() documentation
DEFINE_THINKFUNC is there to support saving the game. Datadescs implement entity serialization. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Edwards Sent: Saturday, February 23, 2008 1:50 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Think() documentation Thanks Josh. I've added the updated article to VDC: http://developer.valvesoftware.com/wiki/Think() . I know there is a DATADESC macro to define a Think function, DEFINE_THINKFUNC. I'm not sure of what it gains you, however, and from what I've been able to tell everything works fine without it. I'd guess that it prevents an entity from changing its mind about something every time a saved game is loaded. It's a good enough theory to be going on with. You mention ClientThink at the beginning of the document, and then again at the end. I'd put them together. There's actually a link down to the ClientThink heading in the HTML version. That's the best way of doing it: you don't want to less useful stuff pushing down the core information, but you do want people who need to perform a special task to be aware that the page will be useful to them. Are you sure the Think function is called automatically at Spawn? Yes. :-) Think is the logic_auto of entities. I'd mention that passing 0 (some code samples I've seen use NULL) to SetNextThink will prevent a Think function from being fired again. Good tip, I'll add that. The code samples and explanations are perfect for how to use the Think functions and how they're based on time. Also, the more advanced example regarding the gun is a great way of showing how those functions can be expanded into something more detailed, that's not necessarily AI. In other words, it's another use of the Think functions. What code samples? Josh Rehm wrote: -- [ Picked text/plain from multipart/alternative ] Some good info. I learned a bit from it. I am by no means a professional (anything), so take my comments with a grain of salt! This is all just my own little opinion. I can't speak for everyone, but to me it would seem like anyone who understands basic programming concepts, functions, and methods (member functions), should be able to realize they can call functions from anywhere (inside Think functions). I'd recommend picking a target audience that allows you to focus on explaining the purpose of the Think functions, how to use them, and write as if you're talking to them. Organize the document in such a way where it states its assumptions about the reader's knowledge, where the reader can find information about those assumptions (if they don't know those things), and then the document itself. I know there is a DATADESC macro to define a Think function, DEFINE_THINKFUNC. I'm not sure of what it gains you, however, and from what I've been able to tell everything works fine without it. However, since it exists, it may be good to understand the purpose of DATADESC so you can describe what using that macro gains you. (This would teach me something too!) Though, following what I mention in the paragraph above, I wouldn't go into a lot of detail about the purpose of DATADESC itself. You could write a separate document on that. As for AI, at most I would suggest that these functions could be used for AI, and then cover the AI in another document. Again, this keeps the document focused on the Think functions and how to use them. Elaborate a little on what internal logic is, as it's an important concept in terms of what a Think function is for. Something like Think functions are used to implement your entity's internal logic, how your entity thinks. In other words, an Entity can use a think function to determine how it should react to external stimuli and its current situation. For example, an entity that uses a weapon could use a Think function to check its current ammunition stock. If its low, it would switch to another Think function that implements how it should go about finding ammunition. This could tie in well to the AI comment I made above. You mention ClientThink at the beginning of the document, and then again at the end. I'd put them together. Are you sure the Think function is called automatically at Spawn? I always thought you had to set the correct think function with SetThink, and call SetNextThink from within Spawn() to get the a Think function to fire the first time. I may be wrong here, and if so someone please correct me (I don't have the code available to test it at the moment). I'd mention that passing 0 (some code samples I've seen use NULL) to SetNextThink will prevent a Think function from being fired again. The code samples and explanations are perfect for how to use the Think functions and how they're based on time. Also, the more advanced example
RE: [hlcoders] snapping objects to a specific position
Moving an object from one position and orientation to another without hitting any obstacles is a very hard problem. Google for piano mover's problem and you can find a ton of research into algorithms for analyzing problems like that. We don't actually try to solve that in real time in Source - we apply a bunch of constraints to make motion planning problems tractable. So it's hard for me to give you more specific suggestions on that because I think it's not really a good choice to try and solve that problem without introducing some constraints or cheats. As far as rotating around a point that isn't the center of the object - that's really simple. You can build the transform you want and then apply it directly or separate it into a linear part (translation, velocity, force) and an angular part (rotation, angular velocity, torque) and apply those parts. An intuitive way to explain how to build such a transformation is to compute the vector that moves the center of mass to the desired rotation center, then compute the matrix that performs only the rotational part (like rotate 90 degrees around the x axis). So to get the combined transform you'd apply the translation vector, then apply the rotation, then apply the negative translation vector but rotated by the rotation. Hopefully that makes sense. In practice we don't usually do this as a combined transformation in physics - we just set target positions/orientations and solve for the velocities that move the object linearly and angularly to those targets - treating those parts as independent problems. This means that the path will diverge from the curved path you'd expect to take, but we generally take steps over small enough periods of time to not care about that error. That's how shadow controllers work, for example. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Sent: Wednesday, February 06, 2008 9:46 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] snapping objects to a specific position I also wondered how to do this. Jay, if you could please look at my diagram and try to explain exactly how to do this??? http://img231.imageshack.us/img231/2334/howtofn1.jpg Could you give a code example? It would help out a ton, I have looked through the sdk for months and cannot find any clue on how to do such a thing. On Feb 6, 2008 12:35 PM, Jay Stelly [EMAIL PROTECTED] wrote: If you have one vector pointing in a direction (like say the X-axis of an object) and another that points where you'd like the first vector to be pointing after applying the torque, then ComputeRotSpeedToAlignAxes() will calculate an angular velocity (this is mass/inertia independent) that rotates the first axis in the direction of the second axis taking into account the current rotational velocity of the object. So I think you have the right idea when you say they are normal that show the desired and current alignment. testAxis is the current alignment, alignAxis is the desired alignment in your case. It doesn't matter what space you use as long as you know that the current and desired axes as well as the output angular velocity are in that space. Also, this function has a pretty specific purpose so it may not be tuned exactly for your situation; it doesn't take time into account for example. Shadow controllers have a better concept of hitting a target position/orientation while obeying some physical constraints. Maybe that is a better tool for what you are trying to do. When you ask how to change the rotation axis of a physics object you aren't asking a very precise question. Applying a torque to the object will most likely change the rotation axis of the object. The center of mass is the point around which all applied torques rotate, but there are infinitely many rotation axes passing through that point. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of coderdude Sent: Wednesday, February 06, 2008 8:31 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] snapping objects to a specific position How do I calculate the torque needed to move an object to it's goal position? How to change the rotation axis of a phys object? will PhysSetMassCenterOverride() do the job? I want the object to point a specific direction, but fail on extreme conditions (obstacle), I looked at ComputeRotSpeedToAlignAxes() but I don't know the parameters. Are they normals which show the desired, then current alignment? Or maybe the other way around? Local or world space? Dam, it's hard to use APIs when you don't know what they do :/ ___ 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] snapping objects to a specific position
If you have one vector pointing in a direction (like say the X-axis of an object) and another that points where you'd like the first vector to be pointing after applying the torque, then ComputeRotSpeedToAlignAxes() will calculate an angular velocity (this is mass/inertia independent) that rotates the first axis in the direction of the second axis taking into account the current rotational velocity of the object. So I think you have the right idea when you say they are normal that show the desired and current alignment. testAxis is the current alignment, alignAxis is the desired alignment in your case. It doesn't matter what space you use as long as you know that the current and desired axes as well as the output angular velocity are in that space. Also, this function has a pretty specific purpose so it may not be tuned exactly for your situation; it doesn't take time into account for example. Shadow controllers have a better concept of hitting a target position/orientation while obeying some physical constraints. Maybe that is a better tool for what you are trying to do. When you ask how to change the rotation axis of a physics object you aren't asking a very precise question. Applying a torque to the object will most likely change the rotation axis of the object. The center of mass is the point around which all applied torques rotate, but there are infinitely many rotation axes passing through that point. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of coderdude Sent: Wednesday, February 06, 2008 8:31 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] snapping objects to a specific position How do I calculate the torque needed to move an object to it's goal position? How to change the rotation axis of a phys object? will PhysSetMassCenterOverride() do the job? I want the object to point a specific direction, but fail on extreme conditions (obstacle), I looked at ComputeRotSpeedToAlignAxes() but I don't know the parameters. Are they normals which show the desired, then current alignment? Or maybe the other way around? Local or world space? Dam, it's hard to use APIs when you don't know what they do :/ ___ 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] OB Scratch Mod (Movement Stutter)
It sounds like you guys are all talking about different problems. The original post said: Also the default movement for players stutters as you walk, jump or fall. That doesn't sound like it's related to motion blur, or physics objects and it certainly doesn't happen in tf2 (at least not on my machine). That sounds more like a prediction or interpolation problem. It should be easy enough to isolate by disabling prediction or running on a listen server in single player mode. As far as problems with physics objects and movement - I did fix a couple of things on that between ep1 and TOB. There are still prediction errors in that case because the simulation is still server only, but the player command scheduling code changed to fix a problem with jitter/batching in the usercmds arriving at the server. You wouldn't notice any of these problems in single player except on the low end where sv_alternateticks 1 creates a similar situation. I haven't tested that code against HL2MP but I imagine it would help with the player movement over physics props if integrated. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Bearman Sent: Tuesday, February 05, 2008 12:51 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] OB Scratch Mod (Movement Stutter) -- [ Picked text/plain from multipart/alternative ] It's also definitely not motion blur as the SourceForts build that has the bug is in an older SDK. The problem most commonly occurs in SourceForts when people push a physics object up against another one, unfortunately even after extensive testing we couldn't replicate it to any degree of success. It would just happen, seemingly randomly. I've only ever got it once or twice, some people get it to an unbearable level. Our proposed fix was Make player jump 0 units (stop looking at me funny) every few seconds or every time a movement key is pressed to minimise the noticeable effect of jitter bug. I'm not sure whether this has been tested yet our end, so you may want to try this as a fix. On Feb 5, 2008 8:32 PM, Tony omega Sergi [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] The problem he's reporting can't possibly have anything to do with motion blur. Motion blur is a post processing effect done purely after everything has been rendered. He said he's printing cl_pdump 1 (1 being his player's entity) and it's showing that m_vecNetworkOrigin is constantly out of sync. This definitely leads me to believe there is a prediction problem, but I don't really know what it is either. I've had this happen after I slam into a wall while walking, and then having it fix itself by jumping. It actually all started after a steam update a while back, and nothing that I can see in the game code itself has changed. On Feb 5, 2008 2:30 PM, Garry Newman [EMAIL PROTECTED] wrote: I think the stuttering only happens in listen servers when you're the host and is just the motion blur stuttering. I'm pretty sure it happens in TF2 too. garry On Tue, Feb 5, 2008 at 7:18 PM, Joel R. [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I still haven't figured this out, it seems to happen on Scratch Mod and Multiplayer Mod. When I use cl_pdump 1 to show my data it says that m_vecNetworkOrigin is always out of sync with the server (shows in red) when I move. I tried upping the prediction tolerance to 100.0f and it still was incorrect. I'm able to debug fine so it is loading the correct DLLs, but I don't understand how no one else has this problem or notices it. -- ___ 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 -- Regards, Ross Bearman -- ___ 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] OB Scratch Mod (Movement Stutter)
The code is in the latest sdk beta. However some of the code is in the latest version of vphysics.dll. Anyway, to see the changes to how the usercmds are scheduled with respect to vphysics take a look at src/game/server/player.cpp in the function CBasePlayer::PhysicsSimulate(). We made a slight change to the way the commands are sent over to vphysics. Then there's another change inside vphysics that handles movement of the player's vphysics object when the game hasn't processed a new usercmd. The other problem that I didn't fix involves the player object colliding with another object that has had too many collisions for that simulation tick and getting its solve postponed until the next tick. This can create hitches on the player's movement. It's easy to test to see if this is a problem for you by having: bool CCollisionEvent::ShouldFreezeObject( IPhysicsObject *pObject ) always return false (src/game/server/physics.cpp). That will use more CPU in the worst cases (and could result in some pretty bad perf cases or I would have done this in ep2) but it will never end up in the bad case of this specific problem for player movement. So that test should at least help isolate the cause of any kind of player vs physics object movement issue you have. So moving to the new vphysics and sdk code will definitely help. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Bearman Sent: Tuesday, February 05, 2008 2:50 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] OB Scratch Mod (Movement Stutter) -- [ Picked text/plain from multipart/alternative ] Jay, do you want to post the code, or could you get in contact with us at [EMAIL PROTECTED] Would be a great help, a soon as we can merge it in an test it I'll get back to the list about how it performs in MP. On Feb 5, 2008 10:22 PM, Jay Stelly [EMAIL PROTECTED] wrote: It sounds like you guys are all talking about different problems. The original post said: Also the default movement for players stutters as you walk, jump or fall. That doesn't sound like it's related to motion blur, or physics objects and it certainly doesn't happen in tf2 (at least not on my machine). That sounds more like a prediction or interpolation problem. It should be easy enough to isolate by disabling prediction or running on a listen server in single player mode. As far as problems with physics objects and movement - I did fix a couple of things on that between ep1 and TOB. There are still prediction errors in that case because the simulation is still server only, but the player command scheduling code changed to fix a problem with jitter/batching in the usercmds arriving at the server. You wouldn't notice any of these problems in single player except on the low end where sv_alternateticks 1 creates a similar situation. I haven't tested that code against HL2MP but I imagine it would help with the player movement over physics props if integrated. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Bearman Sent: Tuesday, February 05, 2008 12:51 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] OB Scratch Mod (Movement Stutter) -- [ Picked text/plain from multipart/alternative ] It's also definitely not motion blur as the SourceForts build that has the bug is in an older SDK. The problem most commonly occurs in SourceForts when people push a physics object up against another one, unfortunately even after extensive testing we couldn't replicate it to any degree of success. It would just happen, seemingly randomly. I've only ever got it once or twice, some people get it to an unbearable level. Our proposed fix was Make player jump 0 units (stop looking at me funny) every few seconds or every time a movement key is pressed to minimise the noticeable effect of jitter bug. I'm not sure whether this has been tested yet our end, so you may want to try this as a fix. On Feb 5, 2008 8:32 PM, Tony omega Sergi [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] The problem he's reporting can't possibly have anything to do with motion blur. Motion blur is a post processing effect done purely after everything has been rendered. He said he's printing cl_pdump 1 (1 being his player's entity) and it's showing that m_vecNetworkOrigin is constantly out of sync. This definitely leads me to believe there is a prediction problem, but I don't really know what it is either. I've had this happen after I slam into a wall while walking, and then having it fix itself by jumping. It actually all started after a steam update a while back, and nothing that I can see in the game code itself has changed. On Feb 5, 2008 2:30 PM, Garry Newman [EMAIL PROTECTED] wrote: I think the stuttering only happens in listen servers when
RE: [hlcoders] New SDK engine interface problems
That feature is not supported in the orange box version of the engine. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vitaly Protasov Sent: Sunday, January 27, 2008 7:53 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] New SDK engine interface problems Hey, where dissapear : virtual void ApplyTerrainMod( TerrainModType type, CTerrainModParams const params ) form engine interface members? WTF? Vitaly ___ 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] How do I get $jointconstrain details?
It's hard to tell if you are asking two questions or the wrong question. Nothing about $jointconstrain will affect the collisions between players and an AI. So if you really want to author a bunch of $jointconstrain statements to solve some other problem (like say ragdoll motion - which it will affect) you can do that inside hlmv with slides and hit the generate qc button to put the qc for those slider settings on the clipboard. Then just paste it into your qc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Harris Sent: Monday, January 21, 2008 10:19 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] How do I get $jointconstrain details? Take a look at the strider model/npc. He is the holy grail of what you are looking for. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of abc def Sent: Sunday, January 20, 2008 10:14 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] How do I get $jointconstrain details? -- [ Picked text/plain from multipart/alternative ] how do i define the bones? using the $jointcontrains? in the hlmv, it shows the hitboxes, but in game, the player still can go through... From: [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] How do I get $jointconstrain details? Date: Sun, 20 Jan 2008 18:53:15 -0800 -- [ Picked text/plain from multipart/alternative ] There's two ways to prevent people from going through your monster: 1) Define a collision box that is big enough to contain your monster. (this is done in code) 2) Define collision boxes for the bones on your monster, and then use the $bonefollowers option in your .qc file . This will allow the player to walk into the nooks and crannies of your monster while preventing him from going through his legs/arms. #1 is easiest method to do. - Original Message - From: abc def [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, January 20, 2008 6:21 PM Subject: [hlcoders] How do I get $jointconstrain details?-- [ Picked text/plain from multipart/alternative ] I'm new using source, i created a monster, but the collision box is is the center of the model, where my player can just walk through its legs... I wonder if its because I never include the bones in the monster... Plus, how do i get the $jointconstrain details for my bones which i used 3DMAX _ Easily manage multiple email accounts with Windows Live Mail! http://www.get.live.com/wl/all -- ___ 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 _ Help Splitzo Sally Before It's Too Late! http://www.thegirlwhosplitinto5.com/ -- ___ 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] DSP in source
The DSP in Source is not done with Miles even though Miles does have a bunch of DSP features (and may be able to do the same thing). It's a custom modular system we built for HL2. There isn't currently a way to modify it without changing code. Licensees have access to this code but it isn't in the mod SDK. The automatic DSP algorithm uses surface material properties and geometry along with a custom controller to configure delay lines and reverb parameters. As I recall, we use Miles sound system for multiplayer voice codecs and mp3 playback as well as steam voice chat. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Mann Sent: Thursday, January 17, 2008 12:01 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] DSP in source Thank you!! that was an invaluable piece of information! You mention it is used for a 'large part of its playback' do you know exactly what extent the source engine controls the miles API's? or what version of the API is used? I am also contacting miles directly regarding this info, I have managed to find out a LOT more information already just from the details you provided again thanks very much Ant On 17 Jan 2008, at 06:50, Adam amckern McKern wrote: You would want to maybe email [EMAIL PROTECTED] and ask them about it as the source engine uses the miles sound system for a large part of its playback. Adam --- Anthony Mann [EMAIL PROTECTED] wrote: Hi again Im writing a paper at the moment on sound design for games and i have a few questions some of you may be able to help me out with! I have been enjoying manipulating and creating soundscapes in the hl2 engine, and have been using hammer since CS 1.4. I'm especially interested in the DSP built into the source engine. Does anyone know any details of how the DSP system calculates the echo/ reverb for the room size/room geometry? is it rt-60 based? is it modular? is it possible to add DSP code without a total re-compile? How are these DSP elements written? Does anyone also have any good resources on the sound engine used within source? i have found some sparse documentation, and the SDK references but i would love to know the workings on a lower level than these provide. Hope someone can point me in the right direction, Thanks Ant ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Owner Nigredo Studios http://www.nigredostudios.com Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ 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] The rib bone's connected to?
On the server you'd do this: int boneIndex = LookupBone(head); int ragdollBoneIndex = GetPhysicsBone(boneIndex); Then get the ragdoll element by ragdollBoneIndex and that has the physics object, etc. Is that what you want to do? I don't think we have an implementation of GetPhysicsBone() on the client, but the data is part of the model so the same code would work. pStudioHdr-pBone( boneIndex )-physicsbone is the map from any bone in the skeleton to the nearest part of the ragdoll by hierarchy order. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maarten De Meyer Sent: Thursday, December 27, 2007 1:55 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] The rib bone's connected to? No, that's just it; I can poll the bone data fine via that member; but the names in all the bones are set to the name of the .mdl itself. I'm gonna try getting the CSDKRagdoll and doing a bone lookup on that one, it's the best shot to still indexing it by name. -- [ Picked text/plain from multipart/alternative ] Also on the topic of the ragdoll, you maye want to look at the m_pRagdoll member of C_BaseAnimating, if that's valid you can use the GetRagdoll method in it to retrieve the ragdoll_t structure which is where AFAIK an array of the actual ragdoll physics info is kept. I'm not sure if that's right though and I don't know if the physics objects in reach ragdollelement_t structure retain the names of the bone to even be of use. -- ___ 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 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
RE: [hlcoders] Back from FollowEntity
When you set the parent on the object it adds a shadow controller to the physics object so it can follow the motion. When you unset the parent you need to either remove the shadow controller or recreate the vphysics object (destroy it and call VPhysicsInitNormal() again) So the easiest fix is probably just item-VPhysicsGetObject()-RemoveShadowController(); item-SetMoveType( MOVETYPE_VPHYSICS ); and leave out all of the other -Enable...() calls -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Peloski Sent: Wednesday, December 12, 2007 1:51 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Back from FollowEntity -- [ Picked text/plain from multipart/alternative ] #include player_pickup.h flag-Teleport( desired_origin, desired_angles, NULL ); Pickup_OnAttemptPhysGunPickup( flag, player, PICKED_UP_BY_CANNON ); physcannon-AttachObject( flag, desired_origin ); Try that.. I think it fixed the issue but I can't remember. Regards, Paul On Dec 12, 2007 4:27 PM, Janek [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Paul, Thank you very much. It is working very well. Now I have gravity. But I now encoutered another weird problem (it was also accuring before I tried your code). Here is the problem: it is like the flag is not at the position I am when attaching it to the gravgun. I see the flag coming from a long distance and attaching to gravgun. I noticed it is coming from the position where I executed FollowEntity(player) for the first time. It is really strange. I can probably manage this problem by setting EF_NODRAW and removing this flag when it is really near gravgun but it is really strange. I will try to understand why it happens. Btw, Paul, thank you again for your help. I really appreciate. 2007/12/12, Paul Peloski [EMAIL PROTECTED]: -- [ Picked text/plain from multipart/alternative ] IPhysicsObject *phys= VPhysicsGetObject(); phys-EnableMotion( true ); phys-EnableGravity( true ); phys-EnableCollisions( true ); phys-Wake(); One of those should do it, taken from some old hl2ctf code that moved the flag from a bonmerge follow to your gravity gun. Regards, Paul On Dec 12, 2007 1:07 PM, Janek [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Hi, I am encountering a weird problem using FollowEntity. My mod is HL2MP based and is using gravgun. When a player is holding an item (CPhysicsPropRepsawnable) with gravgun, he can use reload key to make it following the holder. To do that I use: ForceDrop(); item-FollowEntity( player ); It is working well. When a player has a following entity and active weapon is gravgun, he is able to press reload key again to make following entity held by gravgun. To do that I proceed as follow : item-FollowEntity( NULL ); // or StopFollowingEntity which results the same item-SetMoveType( MOVETYPE_VPHYSICS ); // cos previous method set move type to movetype_none Vector forward; ((CBasePlayer *)GetOwner())-EyeVectors( forward ); Vector pos = GetOwner()-Weapon_ShootPosition() + forward * 50; AttachObject( item, pos ); item-SetMoveType( MOVETYPE_VPHYSICS ); It is working well BUT when I use secondaryattack of gravgun to drop my item, it doesn't drop. It is exactly like there is no mass, or gravity effect. I tried item-SetGravity(1.0f); item-SetMoveType(MOVETYPE_FLYGRAVITY); but it hasn't got what I want. I just want item falling to floor as usual. Any idea on this problem ? -- --- [EMAIL PROTECTED] -- ___ 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 -- --- [EMAIL PROTECTED] -- ___ 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] Vis 2005 error
The compiler appears to be correct. You haven't told us what
PD_GlobalData is (struct/class/typedef?). Unless PD_GlobalDataInterface
is a typedef of PD_GlobalData I can't see how this is valid.
Let's say PD_GlobalDataInterace is a subclass of PD_GlobalData (what I'd
guess from your arrangement anyway):
class PD_GlobalData
{};
class PD_GlobalDataInterface : public PD_GlobalData
{};
then you could do this:
extern PD_GlobalData *g_PDGlobals;
static PD_GlobalDataInterface g_PDGlobalInterface;
PD_GlobalData *g_PDGlobals = g_PDGlobalInterface;
But they have to be consistent types (that includes whether or not
you're using a pointer) and you can't put a static in a header file and
expect to access it in other modules (static means it's local to one
module. So you have two type errors and a scope error in the first bit
of code. The second bit removes one of the type errors, but you've
still got the other two errors.
Anyway I'm just guessing since I haven't seen the rest of the code.
This isn't a VS2005 issue - the code is not consistent.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark
Chandler
Sent: Tuesday, December 11, 2007 9:55 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Vis 2005 error
This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I recently moved some code from a 2003 mod to a 2005 mod (vis im talking
about here) and besides the new compile sads at some syntax im getting
one
major error. It doesn't like me making a static class handle (which gets
init elsewhere).
Ok in my h file I declared it as extern so any class including that file
can
use it. It looks like so:
extern PD_GlobalData *g_PDGlobals;
Now in my cpp file I have it declared as:
static PD_GlobalDataInterface (g_PDGlobals);
Then when trying to compile I get the error:
pd_globaldata.cpp(126) : error C2040: 'g_PDGlobals' :
'PD_GlobalDataInterface' differs in levels of indirection from
'PD_GlobalData *'
Now I think this is caused by one being a pointer and the other not. But
when I remove the * from extern it has a bigger sad:
pd_globaldata.cpp(126) : error C2371: 'g_PDGlobals' : redefinition;
different basic types
PD_GlobalData.h(59) : see declaration of 'g_PDGlobals'
Any ideas of how to fix this? This code ran fine under vis 2003.
Mark [Lodle]
--
___
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] FSOLID_NOT_SOLID_SHOOTABLE flag not working..
Physics props can be non-solid and still touch triggers. There is an optimization in collisionproperty.cpp that disables COLLISION_GROUP_DEBRIS vs. triggers to save touchlinks (there are lots of big triggers and lots of debris objects in hl2, for example). You can always disable that code in your mod or make your physics prop a different collision group if that's the issue. I can't think of any other reason why you couldn't do this. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Sent: Saturday, December 08, 2007 6:10 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] FSOLID_NOT_SOLID_SHOOTABLE flag not working.. I've played with FSOLID flags for some time. I've found them extremely buggy. I tried to make a prop_physics, work with triggers but be non-solid. I had no luck doing it. If anyone could help that would be great. On Dec 8, 2007 2:07 AM, Minh [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Hey guys, I been racking my brain on this problem for awhile now. Was hoping you could shed some light on it. So I have this hostage NPC that I'm parenting to my player (using SetParent) and in order to make him not get stuck with the player, I add the solid flag FSOLID_NOT_SOLID_SHOOTABLE. Now, adding this flag removes the unwanted collision between hostage NPC and player (who's holding the hostage), but unfortunately, now the hostage becomes unhittable. Other player's can't shoot him anymore (which defeates the purpose of using him as a meatshield). Shouldn't the flag FSOLID_NOT_SOLID_SHOOTABLE make an entity non-solid to collisions but also able to be hit with RayTraces? Is it not working in properly? -- ___ 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] Brush Dimensions
Look at the code for UTIL_SetModel() (in the server game util.cpp)
If you have the model index for the entity (GetModelIndex()) you can do
this:
const model_t *mod = modelinfo-GetModel( i );
if ( mod )
{
Vector mins, maxs;
modelinfo-GetModelBounds( mod, mins, maxs );
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
TheDisturbedOne
Sent: Tuesday, December 04, 2007 6:27 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Brush Dimensions
If I have a brush entity, how do I get the length/width/height?
___
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] RE: prop_dynamic don't have animated collision boxes
Are you sure the bullets are going through the bone followers on the server? Or do they just appear to because the client-side effects go through them? Anyway, I'm pretty sure I fixed all of the issues with using bone followers more generally like this between ep1 ep2 (not being client-side, vcollide_wireframe 1 not working or not working well, automatic setup from a $collisionjoints qc script, some solid flag issues on the parent prop, maybe some others). When you get the latest code you should be able to merge those changes over. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony omega Sergi Sent: Wednesday, November 28, 2007 7:27 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] RE: prop_dynamic don't have animated collision boxes -- [ Picked text/plain from multipart/alternative ] Well one thing of note is that bone followers are server-side only. You'll have to initialize them on the client too. I had this problem a year or two ago when I was working on something else. Off-hand, I can't answer the question directly other than what I said. I'll investigate though, to come up with a solution ;) -Tony On Nov 28, 2007 10:03 AM, Minh [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I specified surfaceprop metal in the .qc file so it should have the correct decals/special fx. Since it's a model, the surfaceproperty of the material is irrelevant. Only brushes use the surfaceproperty of a material when creating decals/special fx. - Original Message - From: Adam Donovan [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, November 28, 2007 5:23 AM Subject: [hlcoders] RE: prop_dynamic don't have animated collision boxes -- [ Picked text/plain from multipart/alternative ] Do the bullets go right through or is it because of the material it uses doesnt have a surface prop and so it doesnt seem to collide because the engine isnt creating the decals/particles? I have no idea really but thats what first comes to mind adam _ Your Future Starts Here. Dream it? Then be it! Find it at www.seek.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2 Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext_t=764565661 _r=OCT07_endtext_Future_m=EXT -- ___ 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] npc_blob
It was an experiment. It's not going to be in the sdk. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jake Breen Sent: Thursday, November 15, 2007 1:22 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] npc_blob To be honest, i totally forgotten about it. hehe But hmm...any chance on an official answer? Tobias Kammersgaard wrote: -- [ Picked text/plain from multipart/alternative ] It was. And I believe Jake is aware of that. It was probably a test entity of sorts (don't know the mechanics behin it etc.) like the Stickygun (development gun as far as I know) and the Physgun (Garry's mod in short terms) in the leaked content! /ProZak On 15/11/2007, Kori [EMAIL PROTECTED] wrote: I belive it was a entity in the Particle benchmark. - Original Message - From: Jake Breen [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, November 15, 2007 3:52 PM Subject: [hlcoders] npc_blob This entity is in the fgd but not in Ep2's Code...Anyone know what it is? ___ 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 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: hlcoders@list.valvesoftware.com
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
RE: [hlcoders] TF2 sky issues during compliling process in hammer
That warning is from the code in vbsp that builds a default cubemap for you to use until you run buildcubemaps. Normally it does that by making a lower res copy of the sky texture. What it's telling you is that it doesn't support sky textures that have different resolutions or flags on each side. TF2 has reduced res on some of the sides to save memory so you get a worse default cubemap (might be the checkerboard or something) until you run buildcubemaps. So Jake is totally right - the workaround is to run buildcubemaps in the engine. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jake Breen Sent: Friday, November 09, 2007 12:08 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 sky issues during compliling process in hammer Shouldn't really be a problem, I get that with all skies when compiling for anything. Just build cube maps in-game. Sacrifist wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I get this when compiling anytime I use a TF2 sky. *** Error: Skybox vtf files for skybox/sky_well_01 weren't compiled with the same size texture and/or same flags! Can't load skybox file skybox/sky_well_01 to build the default cubemap! *** Error: Skybox vtf files for skybox/sky_well_01 weren't compiled with the same size texture and/or same flags! Can't load skybox file skybox/sky_well_01 to build the default cubemap! Why is this and is there a fix or a work around? -- ___ 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] Collision Model never compile correctly
The test your model is failing is one that basically checks for minimum
thickness. If any single convex piece of your model is too thin, then
the tool is guessing that it's actually 2-dimensional and won't compile
it. If you run with -fullcollide it should ignore that and compile it
anyway. The orange box version of studiomdl has a few more commands to
let you script this behavior but generally if you're getting the warning
then you're doing something that will cause unintentional behavior in
the physics system (like bad performance or penetration problems) so
it's trying to keep you from doing that unless you know that will happen
but you're ok with it.
Anyway, my guess given your description is that there are some verts on
the model getting shared that you didn't intend to be shared. So if you
have some verts exactly overlapping among the various boxes move them a
little so they're not exactly the same position. Otherwise you should
be able to build with -fullcollide and look at the convex chunks and see
what it's including as an individual convex element and figure it out
that way.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Minh
Sent: Monday, November 05, 2007 11:27 AM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Collision Model never compile correctly
--
[ Picked text/plain from multipart/alternative ]
What I've found from working with smoothing groups is the following:
- Make sure that you dont have any models that are less than 2 units
thick/wide/tall. (for example, i had a model for a table, and the table
was
1 inch thick... The smoothing group wouldn't compile properly and gave
me
the same errors you are getting. I had to scale up the table physics
model
to get it to properly compile). So if your pole is too thin, you may
want to
try thickening the physics model a bit (you dont have to thicken the
actual
model itself, just the physisc model). The model and the phys model
won't be
exactly in synch (ie. the phys model will be a bit larger than the
actual
model) but when you're dealing with models that thin, it is hardly
noticable
when the player interacts with it.
Try assigning each of your 5 boxes to a different smoothing group.
If that doesnt work, you can send me your model files and I can check it
out
for you. I have a lot of experience compiling models of various
shapes/sizes
and I have run into (and fixed) these errors several times.
- Original Message -
From: Adam Donovan [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Monday, November 05, 2007 11:12 AM
Subject: [hlcoders] Collision Model never compile correctly
--
[ Picked text/plain from multipart/alternative ]
Hi all,
Ive been having allot of problems with some simple model
compiling
trying to get my collision models to work correctly. I have a basic
model
for my collision made up of 5 boxes(lowest possible polys 26verts 12
faces)
all attached to one bone. They all have smoothing groups on 1 and the
all
share the same material channel. If I use 2 simple boxes for the model
then
that seems to work but with more than this its always giving me this
error
Working on ukraine_pole.qc
SMD MODEL ukraine_pole_ref.smd
SMD MODEL ukraine_pole_idle.smd
SMD MODEL ukraine_pole_phy.smd
WARNING: Bad collision model, check your smoothing groups!!!
WARNING: Truncating model
WARNING: ukraine_pole_phy.smd has bad smoothing groups
Model has 1 convex sub-parts
Collision model completed.
Thing is ive checked and re checked that the smoothing groups are ok
(set to
1), but it never works. Ive been working with 3dsmax7 mostly so I tried
switching to edsmax9 to see if the new exporter worked any differnt but
still the same problem. Ive gone over anything I could see on the web
and
there is nothing new there that I didnt know about before. Qc file
follows
just to show I can write one..I have also tried full collide..and that
dont
work eitherWhat the hell is going on with this?
// Output .MDL
$modelname ukraine_pole/ukraine_pole.mdl
// Directory of .BMP
$cdmaterials models/ukraine_pole
$staticprop
$scale 1.0
// whole body
$body studio ukraine_pole_ref
// sequences: all sequences are in $cd
$sequence idle ukraine_pole_idle loop fps 15
$collisionmodel ukraine_pole_phy.smd
{
// Mass in kilograms
$Mass 100
$concave
}
_
New music from the Rogue Traders - listen now!
http://ninemsn.com.au/share/redir/adTrack.asp?mode=clickclientID=832re
ferral=hotmailtaglineOct07URL=http://music.ninemsn.com.au/roguetraders
--
___
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] prop_dynamic don't have animated collision boxes
Here's an example from hl2:
// combine_door01.qc
//
// .qc file version 1.0
//
$modelname props_combine\combine_door01.mdl
$cdmaterials models\props_combine
$body Body combine_door01_reference.smd
$surfaceprop metal
// - Animation sequences ---
$sequence idle_closed combine_door01_Open frames 0 0 fps 30
$sequence idle_open combine_door01_Close frames 0 0 fps 30
$sequence Open combine_door01_Open fps 30 {
{ event AE_CL_PLAYSOUND 2 novaprospekt.combinedoor_move_1 }
{ event AE_CL_PLAYSOUND 62 novaprospekt.combinedoor_close_1 }
{ event AE_CL_PLAYSOUND 86 novaprospekt.combinedoor_close_1 }
{ event AE_CL_STOPSOUND 87 novaprospekt.combinedoor_move_1 }
}
$sequence Close combine_door01_close fps 30 {
{ event AE_CL_PLAYSOUND 2 novaprospekt.combinedoor_move_1 }
{ event AE_CL_PLAYSOUND 82 novaprospekt.combinedoor_close_1 }
{ event AE_CL_STOPSOUND 83 novaprospekt.combinedoor_move_1 }
}
$lod 70
{
replacemodel combine_door01_reference combine_door01_lod1
}
$lod 80
{
replacemodel combine_door01_reference combine_door01_lod2
}
$lod 90
{
replacemodel combine_door01_reference combine_door01_lod3
}
$lod 95
{
replacemodel combine_door01_reference combine_door01_lod4
}
$collisionjoints combine_door01_Ragdoll
{
// Mass in kilograms
//$Mass 60
//$concave
}
$keyvalues
{
bone_followers
{
bone door.door1
bone door.door2
bone door.door3
}
}
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Minh
Sent: Thursday, November 01, 2007 5:03 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] prop_dynamic don't have animated collision boxes
--
[ Picked text/plain from multipart/alternative ]
ahh. thanks kevin. that helps heaps..
- Original Message -
From: Kevin Ottalini [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, November 01, 2007 4:43 PM
Subject: Re: [hlcoders] prop_dynamic don't have animated collision boxes
I found this:
http://www.chatbear.com/unity2/4990/124,1152124504,3705?v=flatold
and from the ravendoor model:
$modelname props_lab/RavenDoor.mdl
$model Body RavenDoor_reference.smd
$lod 35
{
replacemodel RavenDoor_reference lod1_RavenDoor_reference
}
$cdmaterials models\props_lab/
$hboxset default
$hbox 0 RavenDoor.Door_Bone -90.535 -2.066 -4.194 90.847 112.003
4.194
// Model uses material ravendoor_sheet.vmt
$surfaceprop metalpanel
$keyvalues { bone_followers { bone RavenDoor.Door_Bone } }
$illumposition 0.000 0.156 54.969
$sequence idle idle ACT_IDLE 1 fps 30.00
$sequence RavenDoor_Open RavenDoor_Open fps 30.00
$sequence RavenDoor_Hold RavenDoor_Hold fps 30.00
$sequence RavenDoor_Drop RavenDoor_Drop fps 30.00
$sequence RavenDoor_Drop_postidle RavenDoor_Drop_postidle fps 30.00
$collisionmodel phymodel.smd {
$mass 1.0
$inertia 1.00
$damping 0.00
$rotdamping 0.00
}
- Original Message -
From: Minh minh_le
To: hlcoders@list.valvesoftware.com
Sent: Thursday, November 01, 2007 4:10 PM
Subject: Re: [hlcoders] prop_dynamic don't have animated collision
boxes
actually Jay, do you have an example .qc you can show us because I
can't
seem to find any information on bonefollowers on the Valve SDK
Wiki.
- Original Message -
From: Jay Stelly To: hlcoders@list.valvesoftware.com
Sent: Thursday, November 01, 2007 3:57 PM
Subject: RE: [hlcoders] prop_dynamic don't have animated collision
boxes
prop_dynamic already does this. In the orange box version of the
engine
you just set it up like a ragdoll and it happens automatically. In
the
previous versions you have to add a bonefollowers section to the
qc to
specify which bones need animated collisions.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Minh
Sent: Thursday, November 01, 2007 3:45 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] prop_dynamic don't have animated collision boxes
I want to make a big animating oil pump (that has a moving
piston)
and
have the player be able to walk on top of it and be affected by the
moving
piston.. but realised that animating props don't actually animate
their
phys
box.
Currently, is there any prop that supports animating phys boxes?
or
is
this something I need to modify..?
I guess I should take a look at prop_door_rotating...
___
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
RE: [hlcoders] tracking down infinite loops
If you launched from the debugger, just do debug...Break. Otherwise you can start dev studio, attach to the hl2.exe process, then do debug...Break. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Wednesday, October 31, 2007 4:37 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] tracking down infinite loops -- [ Picked text/plain from multipart/alternative ] I've been playtesting my mod lately and every so often it will hang (with looping sound) Resulting in no minidumps. I'm guessing this is due to an infinite loop in my code somewhere. Does anyone know a good method of debugging this sort of bug ? (ie. infinite loops). The fact that they dont spit out any minidumps makes tracking them impossible for me.. -- ___ 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] Quaternion to AxisAngle
Maybe it's something we've fixed? I added your code:
Quaternion qNewOrientation;
Vector axis;
float angle;
AngleQuaternion( QAngle(0,90,0), qNewOrientation );
QuaternionAxisAngle( qNewOrientation, axis, angle );
Msg(Q:Axis: %.2f %.2f %.2f :: %.3f\n, VectorExpand(axis),
angle );
// If I pass QAngle(0,90,0) I will get 0.707106 or 90 angle
AngleQuaternion( QAngle(0,270,0), qNewOrientation );
QuaternionAxisAngle( qNewOrientation, axis, angle );
Msg(Q:Axis: %.2f %.2f %.2f :: %.3f\n, VectorExpand(axis),
angle );
// If I pass QAngle(0,270,0) I also get 0.707106 or 90 angle
And I get these results:
Q:Axis: 0.00 0.00 1.00 :: 90.000
Q:Axis: -0.00 0.00 1.00 :: -90.000
But I'm running the orange box sdk.
Here's the code for QuaternionAxisAngle()
void QuaternionAxisAngle( const Quaternion q, Vector axis, float
angle )
{
angle = RAD2DEG(2 * acos(q.w));
if ( angle 180 )
{
angle -= 360;
}
axis.x = q.x;
axis.y = q.y;
axis.z = q.z;
VectorNormalize( axis );
}
Is that the same code you're using?
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joel R.
Sent: Monday, October 01, 2007 3:06 AM
To: hlcoders
Subject: [hlcoders] Quaternion to AxisAngle
--
[ Picked text/plain from multipart/alternative ]
I'm having a problem getting the correct angle. I seem to be stuck
getting
an angle between 0 and 180, due to the W value always being 0.0 to 1.0
and
not -1.0 to 1.0.
---CODE---
Quaternion qNewOrientation;
Vector axis;
float angle;
AngleQuaternion( m_angSpawnAngle, qNewOrientation );
QuaternionAxisAngle( qNewOrientation, axis, angle );
If I pass QAngle(0,90,0) I will get 0.707106 or 90 angle
If I pass QAngle(0,270,0) I also get 0.707106 or 90 angle
The latter is suppose to be negative. When I revert the quaternion back
to
a QAngle it gets the orientation correctly.
The formula QuaternionAxisAngle uses is correct because websites show
the
same algorithm used.
Anyone out there familiar with Quaternions know how I could possibly
solve
this? Thanks in advance!
--
___
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] vrad ignores texlights on func_details
I vaguely remember fixing this at some point for Orange Box. Checking
the history:
In src/utils/vrad/lightmap.cpp, in this function:
bool GatherSampleLight( sampleLightOutput_t out, directlight_t *dl, int
facenum,
Vector const pos,
Vector *pNormals, int normalCount, int iThread,
int nLFlags,
int
static_prop_index_to_ignore,
float flEpsilon )
{
...
switch (dl-light.type)
{
case emit_point:
out.m_flFalloff = 1.0 /
(dl-light.constant_attn + dl-light.linear_attn * dist +
dl-light.quadratic_attn * dist * dist);
break;
case emit_surface:
dot2 = -DotProduct (delta,
dl-light.normal);
if (dot2 = EQUAL_EPSILON)
return false; // behind light
surface
out.m_flFalloff = dot2 / (dist * dist);
// move the endpoint away from the
surface by epsilon to prevent hitting the surface with the trace
src += dl-light.normal * DIST_EPSILON;
break;
I fixed this by adding the line above (src += ...). The starting point
of the trace was in solid due to slightly different tracing on details
vs. non-detail brushes so this just pushes it out slightly along the
normal to avoid starting inside the brush. So the light was casting,
but the detail brushes were effectively shadowing themselves. Note that
vrad has changed a fair amount in general so it's possible that this fix
won't correct the issue by itself in the version of vrad you're using -
but it's also possible that it will fix it - and it's really likely that
the problem you are seeing will go away if you update to the new SDK
when released.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Baker
Sent: Friday, September 28, 2007 2:20 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] vrad ignores texlights on func_details
Well that's weird. All func_details are gone after vbsp is run, so vrad
should see them as world geometry. I was fooled by the file
vraddetailprops.cpp in vrad.
The problem I am seeing is that func_details with texlights painted on
them do not cast light. Anyone know why this might happen? texlights
work for brush entities and regular worldspawn geometry.
- Original Message -
From: Tim Baker [EMAIL PROTECTED]
Would it be very difficult to change vrad to respect texlights on
func_details?
___
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] Creating a Sphere Trace
I have a few comments on this thread: a) The proposed algorithm for RecursiveHullTrace won't work. You can't just expand a fixed set of planes to produce a swept sphere vs. polyhedron test. The number of planes you'd need would be infinite because the surface of the expanded polyhedron (you're expanding the polyhedron by the sphere to reduce the swept sphere to a swept point) will be curved. Intuitively, it seems possible to reduce that to a small finite number if you dynamically calculate some of the planes (but you might have to know the set of all edges and vertices on the polyhedron in order to do this). These are effectively what people refer to as the bevel planes. They are the planes along the potential separating axes that are not on the surface of the polyhedron already. If it's possible to do this I'm sure there's some existing research around; google it. Anyway, it's definitely possible to write a sphere tracer against brushes if you consider the edges and verts as separate features. I'm just not sure you can express that as a fixed set of ray/plane tests since it seems like it will have some second order equations in it somewhere. So what I'm suggesting above is that those sqrt()s (to solve the second order equation) can be done in a prepass that computes some of the planes. b) This is kind of a dead-end anyway unless all you care about are brushes. This won't give you a true sphere trace in the sense that engine-TraceRay() does a trace against everything in the scene (displacements, vcollides, bboxes, hitboxes, custom traces, etc). c) I think (b) is what John means below when he says swept vcollides don't work. Swept vcollides work just fine in the sense that you can use vphysics to compute sweeps of vcollides against other vcollides or boxes vs. vcollides. But it's not a framework that lets you sweep a vcollide against the entire scene - which is probably what you want (and what John wanted as I recall). In fact it's pretty straightforward to extend vphysics to do this, but the current implementation would be incredibly slow if you used any displacements at all because it would have to consider each triangle separately. d) physics tests only happen once per frame in static positions - not exactly sure what you are trying to say here but it sounds incorrect to me. The movement in vphysics though not described as sweeps/traces is still computed as continuous motion. It's not like all of the objects move and then do a static test to see if they are inside another object or have passed through another object. The collisions are computed continuously along the path of translation/rotation. It may still be a pain for your player movement strategy, but it certainly isn't evaluated in static positions if that helps to understand it better. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Sheu Sent: Wednesday, September 26, 2007 3:35 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Creating a Sphere Trace Joel R. wrote: -- [ Picked text/plain from multipart/alternative ] I really don't like the Physics system due to the many limitations we have with it, including tracing. Which is why I want to build my own trace. I took a quick look at the Quake2 source code and they do a RecursiveHullTrace which I believe HL/HL2 uses, maybe if I mimic it and take into account the radius of my sphere I could get the trace I'm looking for. I'll have to test this method out and see how it pans out. If I do happen to get this trace working I'll be glad to share my results with the everyone. The last time I was into this, the Source SDK as we have it has no support for sweeping anything other than AABBs. Swept VCollides don't work (I forgot the name exactly), and physics tests only happen once per frame in static positions. Really a PITA when you're trying to do anything with unusual player movement (read: proning, vehicles). -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] SDK Update heads up?
Enhanced shadows is referring to the shadowmapping light code (e.g. ep2 flashlight), but the orange box vrad will trace through textures now to generate tree/fence shadows from alpha-tested textures if that's what you're after. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Wednesday, September 12, 2007 3:50 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] SDK Update heads up? -- [ Picked text/plain from multipart/alternative ] Does Enhanced Shadows mean we'll have shadowmapping techniques allowing us to do trees like how FarCry does the shadows for their trees (as well as the Splinter Cell series for stuff like fences and what have you). That would be teh mansauce! - Original Message - From: Mike Durand [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, September 12, 2007 9:26 AM Subject: RE: [hlcoders] SDK Update heads up? Hi All- Once I do the big merge I will be able to provide a better preview of changes that you will be getting with the next SDK update. But for now here is the high-level list of new features and improvements in Orange Box games and the latest version of the Source Engine: Non-photo-realistic Rendering Cinematic Physics Simulations Utilization of Multi-core Processors Improved HDR Enhanced Particle System Human Skin Shader Improvements Enhanced Foliage Rendering New Motion Blur Effect Pixel Shader Model 3.0 Enhanced Shadows Hopefully some of this stuff looks interesting to some of you. :) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joel R. Sent: Monday, September 10, 2007 1:43 PM To: hlcoders Subject: [hlcoders] SDK Update heads up? -- [ Picked text/plain from multipart/alternative ] There hasn't been much talk about what updates we'll be receiving to the SDK for Episode 2. I was hoping you guys at Valve would enlighten us a bit on what to expect. The only things I've heard are from the Ep 2 video that was shown, regarding the new technologies put in, like the cinematic physics, enhanced foliage rendering and better expansive outdoor rendering. It'd be great to have a heads up on what we'll be receiving. It's not very fun to just throw us these new updates, and have us figure out whats new. Updates I'm hoping for is some enhancement with the Physics system to allow for better network predicting. Shaders to allow multiple passes, or dynamically change a shader for one model without having to switch skins of the models, and an increase on the limit of 64 instructions for the .fxc shaders. I've also been trying to implement my own physics, however its a bit hard to do with the standard line and ray traces we have. I know we won't be receiving SOLID_OBB or anything of that sorts, but this engine is suppose to be top of the line, and it is still using only AABB. I'm sure there is more things others have been hoping for, shedding some light on us would be much appreciated! Thanks. -Joel -- ___ 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] CompatibilityAttenuation
As I recall that's a feature we did for porting mods from goldsource (HL1 engine). We changed the sound attenuation response curve in source and that reverts those changes for a particular sound. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Cook Sent: Tuesday, August 14, 2007 9:55 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] CompatibilityAttenuation This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Hi there, I'm looking for some documentation on how the CompatibilityAttenuation soundscript parameter works. I've seen it used in CS:S and some 3rd party mods, but I'm still clueless as to whether it will fix my insane gunfire soundlevels. Any idea on what this does? Regards, Dave Cook No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.17/951 - Release Date: 13/08/2007 10:15 -- ___ 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] Freeze a physics model?
PhysForceEntityToSleep() will clear velocity and stop it from moving until acted upon by an external force VPhysicsGetObject()-EnableMotion(false); will lock it in place and prevent any motion (even due to external forces/contacts) until you do VPhysicsGetObject()-EnableMotion(true); Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jed Sent: Thursday, August 02, 2007 2:28 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Freeze a physics model? Heres a fun one... I've created a timed smoke greande weapon which detonates after 4.5 seconds. The smoke effect originates from location of the thrown grenade entity when the fuze timer is reached. Problem is, being a round grenade and the fact that it doesn't explode, the model needs to remain and has annoying habit of rolling away from the centre of the effect which doesn't look right. I basically want to make it stop moving when it detonates or at least be able to bleed off its velocity but I can't seem to get it to work. I'm using SetAbsVeloctiy( Vector(0,0,0) ) in the detonate method to try and freeze it but it has no effect. Any idea to to stop the grenade model moving and freeze it in place? ___ 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
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] Vehicle pose parameters instability
If the change I sent below doesn't fix the problem, then the problem isn't due to the bug I fixed for portal. It must be something else. I'll check to see if the fix got merged up to the current SDK, but it sounds like it won't solve your problem. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, July 08, 2007 8:12 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Vehicle pose parameters instability Hi Jay/list, I can confirm this fix does not solve the problem. I was wondering of the CNetworkArray fix was in the SDK code and if so, if you could share it with us? It's definately somewhere in the sending from server-side poseparams to clientside poseparams that there's an error. I copy the 'steer' param over to the player where it's networked too, since the player is holding the steering wheel, and that one is nice and constant - proving that serverside the input is clean. I also monitored the poseparam as soon as I could in the client and there it was already corrupted. It's only visible with vehicles, but boy is it a graphical showstopper. I'd love to get it fixed since 1. were probably going public soon and 2. I'd hate to see this bug celebrate it's first anniversary, I feel old enough as it is ^^ If it should help, I can easily make a video of the problem. Thanks for any help/info, -- Maarten Sorry, that didn't fix it for me :( - Original Message - From: Jay Stelly [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Tuesday, January 30, 2007 4:11 PM Subject: RE: [hlcoders] Vehicle pose parameters instability I fixed a bug in Portal with CNetworkArray. The symptoms sound similar to this where a networked array would not get the correct values on the client. Because of the nature of the bug you could actually update element zero and get the values networked properly. You might try forcing element zero to update: // add something like this to your vehicle think float flTmp = GetPoseParameter(0); SetPoseParameter( 0, flTmp + 0.5f ); SetPoseParameter( 0, flTmp ); Does that fix the problem? Jay -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Minh Sent: Tuesday, January 30, 2007 3:50 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Vehicle pose parameters instability Yea, I have the same problem as well. The pose parameter keeps flickering to 0.0f. If you check the values of the pose parameter on the server and client, I believe you'll notice that it only flickers on the client, which leads me to believe that it's not getting sent to the client properly. It's odd how this only happens with vehicle entities, while other entities don't exhibit this pose parameter flickering. - Original Message - From: [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Tuesday, January 30, 2007 1:52 PM Subject: [hlcoders] Vehicle pose parameters instability This is a problem we've had over half a year, but I've only discovered this mailing list now and I think my mails to Yahn are somewhere in his spam-archives :) Ever since we ported to the newer SDK version of august last year, we've had problems with our vehicle's pose parameters. It's been a while since I've debugged this but from what I remember the pose parameters received client side are incorrect. E.g. when we're steering the vehicle, the wheels turn, but when the steering angle stays constant the wheels snap back to forward position. Physics still act normal, the steering is taking place, it's just the pose parameters that are incorrect. E.g. suspension is all over the place too. I know of other mods that suffer from the same problem. I'm not sure if this is a known issue or not, but any help or clarification on the subject would be appreciated. It's not blocking as our vehicles work fine, but visually it's a serious turnoff. ___ 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
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] con_command lag with multiple processors
Just a random guess, but if all of the multi-core machines are AMD x2 processors then there's a driver you can install that changes some problematic timing behavior on those systems: AMD Dual-Core Optimizer http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_970 6,00.html Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Sent: Sunday, June 24, 2007 1:44 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] con_command lag with multiple processors -- [ Picked text/plain from multipart/alternative ] CONTEXT: In our mod, the default state is to have a mouse cursor on-screen. Right-click and hold is mouselook, left-click selects entities, left-click and drag moves the selected entities. This is achieved by sending a trace client-side at the location of the mouse and sending the endpos to the server to update the position of the selected entities. This update is done every tick. PROBLEM: On some test machines, this works well. On other test machines, it works for a couple of seconds, then the position updates begin to lag worse and worse over time. The only consistency we've seen is that single core machines work and multi-core machines lag. QUESTIONS: Is this a known problem? Or are we just not optimizing well enough? Any ideas how to optimize this process? NOTE: We have tried setting the affinity of hl2.exe to single processor to no avail. -- ___ 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] Updating physics...
It's telling you you've done something that doesn't make sense. You created a vphysics object for the entity and set its movetype to MOVETYPE_VPHYSICS. That means the entity position/orientation should get updated directly from the physics simulation. Then you set a parent on the object which means it should rigidly follow the movement of the parent. Both of these behaviors write the same data. The entity cannot use both sets of position/orientation data so it throws away the data from physics and warns you about that. If you see the text it means that the physics object has moved but the entity isn't reflecting that because it's using the position/orientation from the hierarchy instead. If you mean for the physics object to kinematically follow the movement of the hierarchy then you should add a shadow controller to the object (VPhysicsInitShadow() instead of VPhysicsInitNormal()) I believe the code does that automatically if a level designer sets the parent of the MOVETYPE_VPHYSICS entity if you are using the ep1 codebase. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of TheDisturbedOne Sent: Saturday, June 09, 2007 11:41 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Updating physics... Updating physics on object in hierarchy What's this warning about? Am I not supposed to set something's parent after the object is active? ___ 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] Re: Player shadows
pEnt-RemoveEffects( EF_NORECEIVESHADOW ); Is the flag I was referring to. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, May 13, 2007 2:12 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Re: Player shadows I could not find the flag for enabling shadows on entities. Instead I used the impact effects for projecting a decal shadow on the entity below the player. The problem is that the decal shadow stays on the entity for some time instead of going away. I then tried creating a quad using the fx stuff, which is what seems to give the best result. For now it will do, but if you guys have some code which will give a better result I would be very glad. Jimmy This message was sent using IMP, the Internet Messaging Program. ___ 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] Re: Player shadows
Also, the code that gets called back from the shadow system is:
Client.dll (c_baseentity.cpp)
//--
---
// Should this object receive shadows?
//--
---
bool C_BaseEntity::ShouldReceiveProjectedTextures( int flags )
{
}
So you could just return true from that for your entities and it should
get shadowed.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 13, 2007 2:12 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Re: Player shadows
I could not find the flag for enabling shadows on entities.
Instead I used the impact effects for projecting a decal
shadow on the entity below the player. The problem is that
the decal shadow stays on the entity for some time instead of
going away. I then tried creating a quad using the fx stuff,
which is what seems to give the best result.
For now it will do, but if you guys have some code which will
give a better result I would be very glad.
Jimmy
This message was sent using IMP, the Internet Messaging Program.
___
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] Re: Player shadows
We do have code in there to cast shadows on props. There should be a receive shadows flag on the prop entity that is off by default - turn it on for your props. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Saturday, May 12, 2007 11:24 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Re: Player shadows -- [ Picked text/plain from multipart/alternative ] Yea, that's a limitation of the Source engine. Right now, shadows only get casted on brushes. You'd have to make some major adjustments to the shadow rendering engine to have it cast on models. Actually, I think the new stuff in Episode2 has shadow casting on models, so maybe you can wait for the next SDK update. - Original Message - From: [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, May 12, 2007 10:56 AM Subject: [hlcoders] Re: Player shadows Thanks Minh, I got the player casting shadows now. Unfortunately they are not received by the props - only the Hammer brushes. My terrain is made of props, so I really need to get shadows working on them too. As the player is flying it is very hard to land when the shadow is not being recieved by the props. This message was sent using IMP, the Internet Messaging Program. ___ 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] Shapecasts in Source
The entities are easy, it's the world that is the problem. There is no simple way to get a list of collsion models for the world + displacements from the API. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 12:43 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Shapecasts in Source Ok, thanks. Can I use this primitive shapecast to collide against the world? Is it represented by a collideable too or is vphysics only used to collide between physics entities and is the world not considered a physics entity? If I can use vphysics to collide against the world but the only functionality missing is to find other nearby entities to collide against I can work my way around that. I'm mostly trying to find a way to basically have a StepMove oriented in a random direction; I'm used to working with PhysX so I'm not sure about what Source supports exposes. If there's no way to do sweeps other than AABB against the world, I'm not sure if there's a decent solution for this in source; except breaking the trace down into multiple raycasts but I'm not sure about the cost of that and pretty sure about the complexity of it :) -- maarten vphysics has a shapecast primitive function (i.e. you can cast one shape represented as a CPhysCollide at another) but no way of getting a list of CPhysCollides to cast against. The changelevel trigger uses the primitive routine to find exact intersections between physics props and the trigger, for example. But the fully general - trace at the whole scene - thing is only implemented for AABBs. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, April 30, 2007 12:21 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Shapecasts in Source I'm somewhere in between disappointed an desperate, so before I launch myself on the crazy solution, just wanted to make sure I understood this correctly. Is it true that there's no other kind of shapecast in Source than an axis-aligned bounding box!? No sphere, no oriented box, no capsule, nothing? I thought I was finalizing our mod (finally) by polishing up our wallwalking, but with only an axis-aligned bounding box trace it's pretty much impossible. [ Well, not impossible, I'll probably end up writing code using multiple raycasts to simulate some kind of OBB, but that is *very* error-prone in complex maps ] I've read about SOLID_OBB, but that's supposedly not supported; and I've read about using vphysics as an alternative, but is it feasible to use vphysics and end up with the same feeling as normal player movement? Thanks for the information! -- 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] Shapecasts in Source
vphysics has a shapecast primitive function (i.e. you can cast one shape represented as a CPhysCollide at another) but no way of getting a list of CPhysCollides to cast against. The changelevel trigger uses the primitive routine to find exact intersections between physics props and the trigger, for example. But the fully general - trace at the whole scene - thing is only implemented for AABBs. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, April 30, 2007 12:21 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Shapecasts in Source I'm somewhere in between disappointed an desperate, so before I launch myself on the crazy solution, just wanted to make sure I understood this correctly. Is it true that there's no other kind of shapecast in Source than an axis-aligned bounding box!? No sphere, no oriented box, no capsule, nothing? I thought I was finalizing our mod (finally) by polishing up our wallwalking, but with only an axis-aligned bounding box trace it's pretty much impossible. [ Well, not impossible, I'll probably end up writing code using multiple raycasts to simulate some kind of OBB, but that is *very* error-prone in complex maps ] I've read about SOLID_OBB, but that's supposedly not supported; and I've read about using vphysics as an alternative, but is it feasible to use vphysics and end up with the same feeling as normal player movement? Thanks for the information! -- 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
RE: [hlcoders] Looping MP3
There is code support for determining the duration of MP3s but not looping. As I recall we didn't have support for mp3 duration when hl2 shipped; it was added in an update. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Paloma Sent: Saturday, April 21, 2007 10:14 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Looping MP3 I already thought about that and looked at GetSoundDuration, but was discouraged by the comments above the declaration: // Just loads the file header and checks for duration (not hooked up for .mp3's yet) // Is accessible to server and client though virtual float GetSoundDuration( const char *pSample ) = 0; But I never actually tried it. If it works, I'll probably have no other choice than to do that. I was just hoping there was a way that the engine supported like it does with WAVs. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Skillet Sent: Saturday, April 21, 2007 9:45 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Looping MP3 -- [ Picked text/plain from multipart/alternative ] You can use enginesound-GetSoundDuration() with the .mp3 to figure out how long it is then stop the old sound and start a new one once that time has elapsed. On 4/19/07, Tony Paloma [EMAIL PROTECTED] wrote: Will support for this be added someday? I really would prefer not to do this manually as I am trying to do it from a server plugin. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam amckern McKern Sent: Thursday, April 19, 2007 4:51 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Looping MP3 As far as i understand, the copy of miles that source runs has no support for looping mp3s. Adam --- Tony Paloma [EMAIL PROTECTED] wrote: This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] As many of you probably know, you can have the engine automatically loop a wav file by inserting a cue point into the wav at the place where you want the loop to start. Is there a similar way to do this with an MP3 or is it WAV only. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios 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 ___ 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] Setting Think
There are two pieces of data - the think function and the think time.
You have to set both.
For goldsrc:
// this will schedule a think right away
SetThink ( CCan::CanThink );
pev-nextthink = gpGlobals-time;
If you want the think function to get called again every second then you
need to reschedule the call in CanThink
void CCan::CanThink()
{
//...
pev-angles = angles;
ALERT(at_console,Can Thinking...);
// think again in 1 second
pev-nextthink = gpGlobals-time + 1;
}
Source has the same concept, but also adds multiple think contexts (an
entity can be processing more than one think simultaneously) and the
syntax is a bit different.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Drak
Sent: Sunday, April 15, 2007 5:27 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Setting Think
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
(GoldSrc)
Why is it when I use SetThink, it doesn't really do
anything, it will randomly call the function. What exactly is
it doing? What I'm trying todo is, set the entitys angles
every second.
(Trying to make the UT weapon spining on a entity)
void CCan::CanThink( void )
{
Vector angles;
angles = pev-angles;
angles.y += 25.0 / 10.0;
if(angles.y = 180.0)
{
angles.y -= 360.0;
}
pev-angles = angles;
ALERT(at_console,Can Thinking...); }
And in the spawn function, i set SetThink( CanThink); But
this function never calls, should it be located somewere else?
--
___
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] Setting Think
SetThink( CanThink );
Will work fine on many compilers, but the C++ standard currently
requires the and class scope for pointers member functions. As I
recall that wasn't always required by the standard.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Drak
Sent: Sunday, April 15, 2007 6:30 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Setting Think
Sweet, thanks man, works fine :D
But one question, why did you use SetThink ( CCan::CanThink
); instead
of:
SetThink( CanThink); or, it really has no purpose which way
you do it?
- Original Message -
From: Jay Stelly [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Sunday, April 15, 2007 8:36 PM
Subject: RE: [hlcoders] Setting Think
There are two pieces of data - the think function and the
think time.
You have to set both.
For goldsrc:
// this will schedule a think right away SetThink (
CCan::CanThink );
pev-nextthink = gpGlobals-time;
If you want the think function to get called again every
second then you
need to reschedule the call in CanThink
void CCan::CanThink()
{
//...
pev-angles = angles;
ALERT(at_console,Can Thinking...);
// think again in 1 second
pev-nextthink = gpGlobals-time + 1;
}
Source has the same concept, but also adds multiple think
contexts (an
entity can be processing more than one think simultaneously) and the
syntax is a bit different.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Drak
Sent: Sunday, April 15, 2007 5:27 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Setting Think
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
(GoldSrc)
Why is it when I use SetThink, it doesn't really do
anything, it will randomly call the function. What exactly is
it doing? What I'm trying todo is, set the entitys angles
every second.
(Trying to make the UT weapon spining on a entity)
void CCan::CanThink( void )
{
Vector angles;
angles = pev-angles;
angles.y += 25.0 / 10.0;
if(angles.y = 180.0)
{
angles.y -= 360.0;
}
pev-angles = angles;
ALERT(at_console,Can Thinking...); }
And in the spawn function, i set SetThink( CanThink); But
this function never calls, should it be located somewere else?
--
___
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] Rotating something about it's own axis
Maybe this will help - I wrote it to answer a similar question: http://developer.valvesoftware.com/wiki/Rotation_Tutorial Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Paloma Sent: Thursday, April 12, 2007 10:42 PM To: [EMAIL PROTECTED] Subject: [hlcoders] Rotating something about it's own axis This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] I need help rotating an entity about its own axis. Basically, what I want to be able to do is add 90 degrees to the entity's y-axis rotation. This works fine by simply doing a angles.x+=90 when the entity's orientation matches that of the world's. However, if the entity is tilted or aligned differently, this doesn't give the desired result since it will rotate it 90 degrees to the world's perspective. I have tried using cross-products and vector multiplication, but everything I am doing is wrong and not giving the right result. All I want to do is make a wheel aligned with a plane. If I do VectorAngles(tr.plane.normal, angles) then apply the angles, the wheel sticks out perpendicular to the plane instead of running tangent to it. Rotating by 90 degrees along the y-axis will fix this, but only if the plane's up is the same as the world's up. There is some kind of vector math trick to get this to work that I don't know. If any of you know how to solve this, please let me know. Thanks a lot! -- ___ 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 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
RE: [hlcoders] Re: Open Source Mods (again)
We had a bug like this a while back - maybe the fix isn't out on the SDK tools yet. The workaround is to run from one directory above the map: Vbspinfo maps\dm_overwatch.bsp So if it's the same problem that should be a usable workaround until the fix is out. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Ottalini Sent: Monday, February 12, 2007 1:25 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Re: Open Source Mods (again) If I try and use vbspinfo it gives me the filesize then errors out: vbspinfo dm_overwatch - dm_overwatch.bsp: 4480012 Error opening dm_overwatch.bsp - Original Message - From: Mike Durand [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Monday, February 12, 2007 1:13 PM Subject: RE: [hlcoders] Re: Open Source Mods (again) Oh, sorry. It was a missing link: http://developer.valvesoftware.com/wiki/PreviousReleaseNotes ___ 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] Ragdolls not colliding with phys_props
If the ragdoll is client-side and the prop is server side you won't get a collision unless you make the prop or the ragdoll client/server. Prop_door_rotating does this - look at that for an example. Keep in mind that the server must be authoritative so the props won't be able to move in response to a ragdoll colliding with them (only the ragdoll can be moved, the server objects must be kinematic). The other option is to make the ragdoll server side. Server side ragdolls will have the usual latency of server-side object updates and cost bandwidth. Or you could come up with some other solution :) I don't know your game well enough to say which is best. Either way the most likely answer to your question is that the vehicle is being simulated by the server and the ragdoll is being simulated by the client. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Tuesday, February 06, 2007 2:22 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Ragdolls not colliding with phys_props This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] My ragdolls aren't colliding with prop_physics entites but ARE colliding with prop_static entities and of course the world. I'm not sure if it was this way by default or if I changed the code (doubtful). Does anyone know how to make the ragdolls collide with physics props (namely prop_vehicle). It looks weird when my ragdoll is going through an entire vehicle. I tried adding : SetCollisionGroup ( COLLISION_GROUP_DEBRIS ); to the C_SDKRagdoll::CreateRagdoll() function but that didn't seem to help... -- ___ 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] IVModelRender::DrawModel() returning 0
It looks like there are only a few cases where it returns zero. The most common issues under your control in the client DLL would be: Set r_entity to something other than -1 skips drawing entities No pStudioHdr-numbodyparts == 0 (probably not this if it actually works sometimes - this would indicate a bad/corrupt mdl) IClientRenderable::SetupBones() returns 0 (this is the most likely thing I'd guess) Can't lock the studiohwdata (seems really unlikely that this could cause blinking unless you're manually flushing the model cache somehow) There are a couple of other exit without draw conditions but those return 1 (like if you don't set the STUDIO_RENDER flag). So check the code in setupbones for the player. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge Rodriguez Sent: Wednesday, January 31, 2007 8:33 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] IVModelRender::DrawModel() returning 0 -- [ Picked text/plain from multipart/alternative ] I'm trying to replace the player model, but when I get it in game it blinks a lot, and sometimes doesn't display at all. I tracked it down to IVModelRender::DrawModel() returning 0 instead of drawing. I can't see anything in the parameters that would indicate something I'm doing wrong, I tried playing with them but I couldn't get it rendering correctly. I can't find any documentation on what the return values of IVModelRender::DrawModel() mean, or how I can figure out what's going wrong, and there's no information on Google. Can anybody help? -- Jorge Vino Rodriguez -- ___ 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] Vehicle pose parameters instability
I fixed a bug in Portal with CNetworkArray. The symptoms sound similar to this where a networked array would not get the correct values on the client. Because of the nature of the bug you could actually update element zero and get the values networked properly. You might try forcing element zero to update: // add something like this to your vehicle think float flTmp = GetPoseParameter(0); SetPoseParameter( 0, flTmp + 0.5f ); SetPoseParameter( 0, flTmp ); Does that fix the problem? Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Tuesday, January 30, 2007 3:50 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Vehicle pose parameters instability Yea, I have the same problem as well. The pose parameter keeps flickering to 0.0f. If you check the values of the pose parameter on the server and client, I believe you'll notice that it only flickers on the client, which leads me to believe that it's not getting sent to the client properly. It's odd how this only happens with vehicle entities, while other entities don't exhibit this pose parameter flickering. - Original Message - From: [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Tuesday, January 30, 2007 1:52 PM Subject: [hlcoders] Vehicle pose parameters instability This is a problem we've had over half a year, but I've only discovered this mailing list now and I think my mails to Yahn are somewhere in his spam-archives :) Ever since we ported to the newer SDK version of august last year, we've had problems with our vehicle's pose parameters. It's been a while since I've debugged this but from what I remember the pose parameters received client side are incorrect. E.g. when we're steering the vehicle, the wheels turn, but when the steering angle stays constant the wheels snap back to forward position. Physics still act normal, the steering is taking place, it's just the pose parameters that are incorrect. E.g. suspension is all over the place too. I know of other mods that suffer from the same problem. I'm not sure if this is a known issue or not, but any help or clarification on the subject would be appreciated. It's not blocking as our vehicles work fine, but visually it's a serious turnoff. ___ 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] VPhysics Crash Dump
The callstack from the crash dump appears to be crashing referencing a bad pointer while creating a contact point in vphysics. Maybe you've freed one of these simpler collision models while it's still in use? That's just a guess; all I can conclude from the minidump is that vphysics has a bad pointer not where the bad pointer came from. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Menard Sent: Wednesday, January 24, 2007 5:27 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] VPhysics Crash Dump -- [ Picked text/plain from multipart/alternative ] I have managed to narrow it down somewhat. After some digging we found a bad model on the map, but we were still getting the crashes. We are using custom CPhysCollide objects created on the fly at the start of the map (with the hopes of getting better performance). This makes the vphysics model (simple, 1 convex) not match up with the hitbox/trace model (used for player movements and bullets). The interesting thing is after switching back to the more complex collision model stored in the MDL, the crashes seem to be gone, and its not hitching nearly as bad. I'm not sure if the model is just not generated entirely properly, or if there is something missing in the VPhysics to make it work right. Regardless, I would still like this mdmp checked out if possible. On 1/24/07, Teddy [EMAIL PROTECTED] wrote: He's right, this bug is weird. I've seen it on a test map for dystopia, luckily it's never happened on any production maps. You could try stripping the map back, and testing it piece by piece until you find the culprit. Or try some sacrafices to your gods, both methods are equally effective :-) On 1/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Uh-oh, if you've followed this mailing list for a while, you'll know I sure don't envy you! :) At 2007/01/21 04:11 PM, Daniel Menard wrote: -- [ Picked text/plain from multipart/alternative ] Hey, I have this vphysics crash dump which I am getting only in a specific map with the spacecraft from Eternal-Silence. This map is the only one with displacements. The crash seems almost random and the call stack offers no information whatsoever, the whole thing is in vphysics.dll. I was wondering if someone at valve could tell me in what part of the physics code it is crashing so I can make appropriate modifications. Here is the file: http://www.eternal-silence.net/vphysics_crash.mdmp Thanks, Dan -- ___ 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] How do I get a QAngle from a Vector?
It's called VectorAngles() Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Wednesday, January 17, 2007 2:08 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] How do I get a QAngle from a Vector? This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Is there a function that will take in a normalized vector and return a QAngle? I guess what I'm looking for is the opposite of the ever-popular AngleVectors function. I seem to recall in the old HL1 engine, there was a function called Vector2Angles, but I can't seem to find the equivalent in the Source engine. -- ___ 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] Player HULL vs HIT BOXES
Players touching triggers through thin doors is a bug. It will be fixed a future version of the engine, but that's not going to help you now. The important thing to know is the SolidMoved() is using surrounding bounds to intersect with triggers rather than the bbox for SOLID_BBOX objects like the player. You could do a bbox vs. trigger test in the game DLL to fix it when the engine calls back to mark the ents as touching and one is a FSOLID_TRIGGER and the other is SOLID_BBOX. A hacky workaround would be switching to USE_SPECIFIED_BOUNDS or USE_GAME_CODE just before the call to engine-SolidMoved() when the solid entity moving is a player and then switching back to hitbox after. The second issue is supposed to happen though - I mean either you want it to hit the hitboxes outside the hull or you don't. If you only want to hit them when they aren't protruding through some geometry you'll have to add some kind of code to detect that condition and account for it. As a heuristic you could trace a ray back from the impact point to the center of the player (ignoring the player) and make sure it makes it and filter out the hit if it doesn't... Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Sent: Wednesday, January 17, 2007 8:35 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES Some major issues have appeared as a result of this change, I've had to revert it unfortunately. Players were able to touch triggers through thin doors, and get shot if any part of their model was protruding through a brush/prop/etc. I looked into setting the surrounding bounds before any weapons ray trace runs, but this eats up alot of CPU time, and doesn't work with projectile weapons anyways.. So the only solution I've got now is to modify all the player model animations so they don't stray outside the movement collision bounds, -or- increase the size of the movement collision bounds. Our mappers will kill me if i do that (especially this close to release)!!! Anyone got any advice or a workaround for this problem? Cheers, Teddy On 1/17/07, Teddy [EMAIL PROTECTED] wrote: Thanks Jay, I did some measuring, and it had very little impact on performance. It turns out, near misses are pretty frequent (must be those 30 raytrace/sec weapons)! Nic2: Try putting the call to SetSurroundingBoundsType at the end of the spawn function, just in case something in the baseclass is overriding it -Teddy On 1/16/07, Jay Stelly [EMAIL PROTECTED] wrote: I tried to answer this in the wiki page: USE_SPECIFIED_BOUNDS could also be used to solve this problem by specifying a constant box that is always larger than the space occupied by hitboxes in any animation. As a tradeoff, this will be cheaper than USE_HITBOXES as the player animates and moves, but more a conservative boundary resulting in more hitbox queries happening against ray tests that miss. The highest performance method will depend on the mod's number of players moving vs. number of ray/box traces computed against players (and how many of those queries actually miss). It really depends on several variables (like how many rays are near misses, the number of hitboxes and the complexity of the player skeleton). The only way to determine exactly how much is to measure it in your mod. HL2 uses this method for striders' bounds so it's not insanely expensive or anything, just more expensive when you have only a few ray traces nearly missing players in a frame. It may be less expensive if you have a enough rays being rejected as a result or less expensive if the animation of the player varies enough to require a large enough USE_SPECIFIED_BOX. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Sent: Monday, January 15, 2007 7:29 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES Exactly how much more load does USE_HITBOXES put on the server, say for a 16 player with a similar amout of raycasts as counterstrike (for example)? I've found it gives much more accurate reg on player's extremities, but i wonder at what cost? Would it be cheaper to make an exagerated bbox using USE_SPECIFIED_BOUNDS (considering all the extra ray casts that may collide)? On 1/11/07, Jay Stelly [EMAIL PROTECTED] wrote: Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki
RE: [hlcoders] Re: Player HULL vs HIT BOXES
That looks correct - so most likely the player's hitbox code isn't getting called or the hitbox test is failing for some reason. There's another debug command called cast_ray that visualizes traces. I'd probably put a breakpoint in there and use it to cast a ray that should hit but misses and then try to step through the player collision code at that point using breakpoints. If the player's testhitboxes is not being called for some reason you can always force it by adding FSOLID_CUSTOMRAYTEST on the players. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Niclas Sent: Wednesday, January 17, 2007 2:32 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Re: Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] Jay: Is the absbox correctly surrounding the hitboxes? http://img.photobucket.com/albums/v485/Nic2/gr_hightown0004.jpg this is what the Ent_absbox and Sv_showhitboxes is showing me. To answer Jay's question I would say yes. :P http://img.photobucket.com/albums/v485/Nic2/gr_hightown.jpg this is what the Ent_bbox shows. (The big green here is the Ent_absbox). And to Teddy, I did add the function call at the end of Spawn(). But the fact remain, I can still shoot through the upper part of the player. Nic2 Subject: RE: [hlcoders] RE: Player HULL vs HIT BOXES Date: Tue, 16 Jan 2007 18:18:37 -0800 From: Jay Stelly [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Reply-To: hlcoders@list.valvesoftware.com That sounds right. Use third person and the visualization code to check it: thirdperson Ent_bbox player (this will show you the bbox/collision hull) Ent_absbox player (this will show you the surrounding bounds) Sv_showhitboxes 1 (this will visualize the hitboxes) Is the absbox correctly surrounding the hitboxes? Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Niclas Sent: Tuesday, January 16, 2007 6:03 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] RE: Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I still cant get it to work. I put: CollisionProp()-SetSurroundingBoundsType( USE_HITBOXES ); at top of the CHL2_Player::Spawn() function. And in CHL2_Player::TestHitboxes(...) all I have is this line: return BaseClass::TestHitboxes( ray, fContentsMask, tr ); (that was checked with this line before: if( g_pGameRules-IsMultiplayer() ) ) What am I doing wrong? Maybe I should add that one of my player classes is using a different HULL and view vectors than the rest of the classes that uses the normal HL2 ones. Nic2 Message: 2 Subject: RE: [hlcoders] RE: Player HULL vs HIT BOXES Date: Thu, 11 Jan 2007 13:18:30 -0800 From: Jay Stelly [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Reply-To: hlcoders@list.valvesoftware.com You should put it in Spawn(). Also, if you're using the hl2_player code as your base player class then you'll need to make sure you are using the multiplayer/default implementation in CHL2_Player::TestHitboxes. The single player HL2 code hooks this to use a hull-sized cylinder instead of hitboxes. 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] RE: Player HULL vs HIT BOXES
That sounds right. Use third person and the visualization code to check it: thirdperson Ent_bbox player (this will show you the bbox/collision hull) Ent_absbox player (this will show you the surrounding bounds) Sv_showhitboxes 1 (this will visualize the hitboxes) Is the absbox correctly surrounding the hitboxes? Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Niclas Sent: Tuesday, January 16, 2007 6:03 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] RE: Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I still cant get it to work. I put: CollisionProp()-SetSurroundingBoundsType( USE_HITBOXES ); at top of the CHL2_Player::Spawn() function. And in CHL2_Player::TestHitboxes(...) all I have is this line: return BaseClass::TestHitboxes( ray, fContentsMask, tr ); (that was checked with this line before: if( g_pGameRules-IsMultiplayer() ) ) What am I doing wrong? Maybe I should add that one of my player classes is using a different HULL and view vectors than the rest of the classes that uses the normal HL2 ones. Nic2 Message: 2 Subject: RE: [hlcoders] RE: Player HULL vs HIT BOXES Date: Thu, 11 Jan 2007 13:18:30 -0800 From: Jay Stelly [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Reply-To: hlcoders@list.valvesoftware.com You should put it in Spawn(). Also, if you're using the hl2_player code as your base player class then you'll need to make sure you are using the multiplayer/default implementation in CHL2_Player::TestHitboxes. The single player HL2 code hooks this to use a hull-sized cylinder instead of hitboxes. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Niclas Sent: Thursday, January 11, 2007 1:09 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] RE: Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I tried putting: CollisionProp()-SetSurroundingBoundsType( USE_HITBOXES ); in CBasePlayer, first in VPhysicsUpdate(), and then in Spawn() but neither worked. Where should I put it? Nic2 Subject: RE: [hlcoders] Player HULL vs HIT BOXES Date: Wed, 10 Jan 2007 11:56:50 -0800 From: Jay Stelly [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Reply-To: hlcoders@list.valvesoftware.com Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki/CollisionPropertyhttp://devel oper.valvesoftware.com/wiki/CollisionProperty Jay - Original Message - From: Niclas [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, January 10, 2007 2:44 AM Subject: [hlcoders] Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I changed the player hull and view to very low and now it seems like I cant hit the model over that hull (projectiles go right through) even though that the hitboxes cover the whole model (custom model). - Nic2 -- ___ 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] Player HULL vs HIT BOXES
I tried to answer this in the wiki page: USE_SPECIFIED_BOUNDS could also be used to solve this problem by specifying a constant box that is always larger than the space occupied by hitboxes in any animation. As a tradeoff, this will be cheaper than USE_HITBOXES as the player animates and moves, but more a conservative boundary resulting in more hitbox queries happening against ray tests that miss. The highest performance method will depend on the mod's number of players moving vs. number of ray/box traces computed against players (and how many of those queries actually miss). It really depends on several variables (like how many rays are near misses, the number of hitboxes and the complexity of the player skeleton). The only way to determine exactly how much is to measure it in your mod. HL2 uses this method for striders' bounds so it's not insanely expensive or anything, just more expensive when you have only a few ray traces nearly missing players in a frame. It may be less expensive if you have a enough rays being rejected as a result or less expensive if the animation of the player varies enough to require a large enough USE_SPECIFIED_BOX. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Sent: Monday, January 15, 2007 7:29 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES Exactly how much more load does USE_HITBOXES put on the server, say for a 16 player with a similar amout of raycasts as counterstrike (for example)? I've found it gives much more accurate reg on player's extremities, but i wonder at what cost? Would it be cheaper to make an exagerated bbox using USE_SPECIFIED_BOUNDS (considering all the extra ray casts that may collide)? On 1/11/07, Jay Stelly [EMAIL PROTECTED] wrote: Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki/CollisionProperty Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Wednesday, January 10, 2007 11:01 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES I believe any hitbox that lies outside of the player's hull cannot be hit. I am pretty sure you must keep your hitboxes inside of the hull. So you cannot make your hull too small or else the traceline will not detect the hitbox. - Original Message - From: Niclas [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, January 10, 2007 2:44 AM Subject: [hlcoders] Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I changed the player hull and view to very low and now it seems like I cant hit the model over that hull (projectiles go right through) even though that the hitboxes cover the whole model (custom model). - Nic2 -- ___ 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] RE: Player HULL vs HIT BOXES
You should put it in Spawn(). Also, if you're using the hl2_player code as your base player class then you'll need to make sure you are using the multiplayer/default implementation in CHL2_Player::TestHitboxes. The single player HL2 code hooks this to use a hull-sized cylinder instead of hitboxes. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Niclas Sent: Thursday, January 11, 2007 1:09 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] RE: Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I tried putting: CollisionProp()-SetSurroundingBoundsType( USE_HITBOXES ); in CBasePlayer, first in VPhysicsUpdate(), and then in Spawn() but neither worked. Where should I put it? Nic2 Subject: RE: [hlcoders] Player HULL vs HIT BOXES Date: Wed, 10 Jan 2007 11:56:50 -0800 From: Jay Stelly [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Reply-To: hlcoders@list.valvesoftware.com Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki/CollisionPropertyhttp://devel oper.valvesoftware.com/wiki/CollisionProperty Jay - Original Message - From: Niclas [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, January 10, 2007 2:44 AM Subject: [hlcoders] Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I changed the player hull and view to very low and now it seems like I cant hit the model over that hull (projectiles go right through) even though that the hitboxes cover the whole model (custom model). - Nic2 -- ___ 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] Player HULL vs HIT BOXES
Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki/CollisionProperty Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Wednesday, January 10, 2007 11:01 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES I believe any hitbox that lies outside of the player's hull cannot be hit. I am pretty sure you must keep your hitboxes inside of the hull. So you cannot make your hull too small or else the traceline will not detect the hitbox. - Original Message - From: Niclas [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, January 10, 2007 2:44 AM Subject: [hlcoders] Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I changed the player hull and view to very low and now it seems like I cant hit the model over that hull (projectiles go right through) even though that the hitboxes cover the whole model (custom model). - Nic2 -- ___ 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] IPhysicsEnvironment::SweepCollideable()
SweepCollideable() and TraceRay() are currently stub implementations in IPhysicsEnvironment, so no. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Sheu Sent: Friday, January 05, 2007 11:40 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] IPhysicsEnvironment::SweepCollideable() Is IPhysicsEnvironment::SweepCollideable() supposed to work? It looks to me like a decent way to get a collision hull swept at arbitrary angles, but it doesn't seem to work. The allsolid and startsolid flags are set true on return, and fraction is set to an un-$DEITY-like small value, and the two Vector fields are set to strange values. Even the ShouldHitObject() on the IPhysicsTraceFilter I pass in doesn't seem to be called. -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] SOLID_OBB or similar?
The easiest way to reduce the cost of vehicles would be to remove the wheels. Just use ray traces to find the wheel contacts and write your own simulation for the suspension dynamics (I'm assuming you're doing that anyway if you've got some kind of SOLID_BBOX car going). The airboat does this in HL2 (so it's totally possible and effective), but not all of the code is visible to mods because it shares some of the underlying havok suspension dynamics used on the jeep (and havok doesn't want their source code in our SDK). If you want to attempt this you'd just create a convex hull for the vehicle entity, set it to MOVETYPE_VPHYSICS (basically call VPhysicsInitNormal()), then attach it to a motion controller and apply impulses to simulate the dynamics in the motion controller Simulate() function. You could do your wheel raytraces there or in a think function depending on how frequently you want to update the contacts. Lots of games use this general technique. Also - dynamic moving/rotating SOLID_OBB entities aren't coming in ep2 and wouldn't likely be faster than using vphysics for a single convex hull if implemented. SOLID_BBOX is faster because the swept collision problem is much simpler solve. We use vphysics for anything with dynamic rotation that needs to have varying collisions under rotation. It is true that the physics objects will be moving according to the rules of physics so you can only exert control over once per timestep. That is going to make really high frequency control impossible without decreasing the timestep of the simulator (which will cost more CPU as a result). This wasn't a big deal for the buggy or the airboat in HL2 though, so unless your vehicles are really different it's probably not a big deal for you either. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joel R. Sent: Friday, December 22, 2006 11:08 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] SOLID_OBB or similar? -- [ Picked text/plain from multipart/alternative ] Vehicles use 5 physics objects, 1 for each tire and then the body. Physics objects are always obeying the laws of physics, so your control over them is not as precise as could be. On 12/22/06, Jed [EMAIL PROTECTED] wrote: I've a similar problem with player models actually when it comes to bounds for prone. They are always square and always orientated north so using a rectangular bounding box doesnt work as it doesn't rotate with the player. Just out of curiousity, is there anything that the HL2 Jeep uses that might be of use? That seems to drive over terrain pretty well so I wonder if theres something in it's collision detection you could use. - Jed -- ___ 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] Movetype Problem
Sounds like you're writing through a bad pointer or something. I'd set a memory breakpoint on a test entity's movetype member variable and debug it that way. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Sheffer Sent: Wednesday, December 13, 2006 4:39 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Movetype Problem -- [ Picked text/plain from multipart/alternative ] We are still on the search for this problem, but I am sure we will figure it out sooner or later. Currently both the client and server side MoveType for ents on spawn and durring usage are using the correct movetypes. PhysicsSimulate in physics_main_shared.cpp on the other hand is giving us numbers way out of range, but not always. Moving ents and beams usually cause the most problems. we still are not sure what is changing the movetype of these objects and a little insight on how the physics system is receiving these numbers would be great. We need to figure out why this is happening and with such random numbers. On 12/11/06, Hyperjag 3 [EMAIL PROTECTED] wrote: Hello, My mod has recently started encountering a problem with movetypes. It seems that the movetypes of some entities (so far I have observed it happening to env_beam, trigger_once, trigger_hurt, func_door, and func_door_rotating) are getting forcibly changed to random numbers and triggering a warning and an assert in physics_main_shared.cpp. These seem to occur every server think and really take a toll on the server's performance. One example of what the warning prints is: PhysicsSimulate: trigger_hurt bad movetype 170. I have seen almost any number up to 254 as the movetype, and sometimes I am able to watch the console and see the number change every few thinks, growing until it reaches 254 and then starting over again from 0. The assert seems to only start happening once a player (or possibly other entities, I have not tested) touch the beam/trigger/door. I have tried to debug this problem myself, but I just can't figure out what is changing the movetype. I have put breakpoints in CBaseEntity::SetMoveType, but they never trigger as the movetype on the entity changes and causes the asserts. Any help that anyone can give is appreciated. Jory - Hyperjag3 _ Visit MSN Holiday Challenge for your chance to win up to $50,000 in Holiday cash from MSN today! http://www.msnholidaychallenge.com/index.aspx?ocid=taglinelocale=en-u s ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ~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] Movetype Problem
Yeah, that's probably just an indication of a specific piece of data being written there. Like some array that contains small numbers in CBaseEntity is overflowing or underflowing the array bounds. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Sheffer Sent: Wednesday, December 13, 2006 5:02 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Movetype Problem -- [ Picked text/plain from multipart/alternative ] Definitely seems like it, but the values remain clamped to at least below 1k which seems odd. Will report back after more debugging. On 12/13/06, Jay Stelly [EMAIL PROTECTED] wrote: Sounds like you're writing through a bad pointer or something. I'd set a memory breakpoint on a test entity's movetype member variable and debug it that way. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Sheffer Sent: Wednesday, December 13, 2006 4:39 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Movetype Problem -- [ Picked text/plain from multipart/alternative ] We are still on the search for this problem, but I am sure we will figure it out sooner or later. Currently both the client and server side MoveType for ents on spawn and durring usage are using the correct movetypes. PhysicsSimulate in physics_main_shared.cpp on the other hand is giving us numbers way out of range, but not always. Moving ents and beams usually cause the most problems. we still are not sure what is changing the movetype of these objects and a little insight on how the physics system is receiving these numbers would be great. We need to figure out why this is happening and with such random numbers. On 12/11/06, Hyperjag 3 [EMAIL PROTECTED] wrote: Hello, My mod has recently started encountering a problem with movetypes. It seems that the movetypes of some entities (so far I have observed it happening to env_beam, trigger_once, trigger_hurt, func_door, and func_door_rotating) are getting forcibly changed to random numbers and triggering a warning and an assert in physics_main_shared.cpp. These seem to occur every server think and really take a toll on the server's performance. One example of what the warning prints is: PhysicsSimulate: trigger_hurt bad movetype 170. I have seen almost any number up to 254 as the movetype, and sometimes I am able to watch the console and see the number change every few thinks, growing until it reaches 254 and then starting over again from 0. The assert seems to only start happening once a player (or possibly other entities, I have not tested) touch the beam/trigger/door. I have tried to debug this problem myself, but I just can't figure out what is changing the movetype. I have put breakpoints in CBaseEntity::SetMoveType, but they never trigger as the movetype on the entity changes and causes the asserts. Any help that anyone can give is appreciated. Jory - Hyperjag3 _ Visit MSN Holiday Challenge for your chance to win up to $50,000 in Holiday cash from MSN today! http://www.msnholidaychallenge.com/index.aspx?ocid=taglinelocale=en -u s ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ~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 -- ~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] Question about materials
It can depend on the material. In this case I'd guess you have a sprite material and it's the rendermode key that's set to normal (which is not transparent) and you change it to kRenderGlow (which is). Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Van Huss Sent: Sunday, November 12, 2006 8:18 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Question about materials [ Converted text/html to text/plain ] Trying to fix a visual bug. What can you set in a .vmt file where aMaterial-IsTranslucent() would return True? I tried the obvious $translucent 1 but that didn't work(I've tried lots of other stuff). Here's some more info. If a temp sprite ,using the same material, calls SetTransparency( kRenderGlow, 255, 255, 255, 200, kRenderFxNoDissipation ) then the material gets changed and aMaterial-IsTranslucent() returns True. If I call aMaterial-Refresh(), IsTranslucent() returns False and the visual bug returns. Which means Refresh() is working(I think). So I just need to know what settings in a .vmt file makes aMaterial-IsTranslucent() return True. EJ ___ 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] New SDK Update is Out As Beta
Windiff is free and in the windows platform sdk so you probably already have it if you can compile code. We use Beyond Compare at Valve: http://www.scootersoftware.com/ There's a free trial version, but it's not freeware (although it's pretty cheap - $30 I think). Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Swires Sent: Friday, November 03, 2006 10:33 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] New SDK Update is Out As Beta This is more of a general thing to do with Source SDK updates, but does anyone know any good (freeware) tools that can tell detect differences in files so I know which new files I'll need to replace/copy from? ___ 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] Forcefield which only lets through based on team
Having a collision group per team is probably the simplest solution. I don't understand why you can't replace uses of COLLISION_GROUP_PLAYER_MOVEMENT with a new group. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robbie Groenewoudt Sent: Friday, September 15, 2006 12:21 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Forcefield which only lets through based on team -- [ Picked text/plain from multipart/alternative ] That is harder then it seems... You can only override CBaseEntity::ShouldCollide( int collisionGroup, int contentsMask ) const. I can't smell with only these 2 variables on which the team the colliding entity is... Overriding this function in the player-class is no use. It often doesn't get called... Instead the entity seems to collide with COLLISION_GROUP_PLAYER_MOVEMENT. Making a new collisiongroup per team is also a bit useless considering I can't check these in the player-class considering COLLISION_GROUP_PLAYER_MOVEMENT comes from lots of tracelines... ( I can't replace COLLISION_GROUP_PLAYER_MOVEMENT with new collisiongroups) On 9/15/06, Tony omega Sergi [EMAIL PROTECTED] wrote: Make an entity that has a custom ShouldCollide function, and if the team the forcefield is on matches the team of the player touching it, return false. -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com -Original Message- From: Robbie Groenewoudt [mailto:[EMAIL PROTECTED] Sent: September 15, 2006 4:53 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Forcefield which only lets through based on team -- [ Picked text/plain from multipart/alternative ] *bump* I'd like to want a combine forcefield that only lets NPC/players through based on team. Any know how to manage this in the code? Robbie -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders __ NOD32 1.1454 (20060321) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ 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] Predicted VPhysics entity
You can always EnableDrag(false) on your object to isolate the air density/drag from the motion of the object. If doing this fails to fix the problem, then it's not an air density issue. Other factors that could be different: damping, rotdamping: Make sure these are the same on your client and server objects (hardcode them to something constant as a test). The other factor that is almost certainly different unless you've changed it in your mod: The client and server apply user input at different points relative to physics simulation. The server runs at a fixed framerate which is always an integer multiple of the physics simulation rate. This can all be configured by your mod, but the default behavior is that ticks are 15ms for both server logic and vphysics simulation. That means that all user input is applied at the beginning of a tick. The client runs at a variable framerate - as fast as it can render frames. The vphysics simulation still runs at a fixed interval (15ms). It intepolates between fixed frames to match the client clock. This means that any impulses applied do not take effect until the next simulation frame is reached. This will probably complicate your client-side prediction or at least introduce additional error. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maurino Berry Sent: Tuesday, September 12, 2006 9:29 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Predicted VPhysics entity It is a networked entity. They use a shared CreateVPhysics method to initialize their physics objects to be identical. If the clientside representation of an entity has its own vphysics object it will not get forced changes from the server (which is what we want) but I can use GetAbsAngles/Origin to get the proper server position. The idea was to eventually use sendproxies to write out appropriate server physics data (inertia's etc) to correct the client vphysics object. Within the void CGameMovement::PlayerMove( void ) method I call a simulate method on the players controlled entity, and look at the most recent usercmd with #ifdef GAME_DLL cmd = pPlayer-GetLastUserCommand(); #else cmd = pPlayer-GetCurrentUserCommand(); #endif and then based on keys down (like IN_FORWARD) etc I apply thrust, and use the mouse deltas to figure angular rotation, but the point is even with a single keypress (I'm echoing the amount of times this method is called) the client drifts longer than the server, so repeated keypresses of left and right end up throwing the client object way out of sync with the servers. On 9/12/06, Robbie Groenewoudt [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] The client and server have different times and ticks so it's quite possible the 2 are different. Some more code would help. Also, you should make it an networked entity so the client predicts it but receives the right position from the server. On 9/12/06, Maurino Berry [EMAIL PROTECTED] wrote: I'm attempting to simulate physics for an entity on the client as well as the server (a type of vehicle) Everything works fine except what feels like the 'drag' is different on the client/server, they're set to ignore gravity so they are hovering and a single boost with ApplyForceCenter/Offset results in different positions and I can't seem to figure out why, it's like the client has less air density almost, but I've made sure it's the same. Is the simulate rate of havok different between the client/server? or is there anything I should know about regarding this? 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 ___ 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] invalid fogcontroller memcmp?
This is a bug, the line should read:
if ( Q_memcmp( fog,
CFogController::s_pFogController-m_fog, sizeof(fog) ))
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, September 04, 2006 11:48 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] invalid fogcontroller memcmp?
It's not clear to me what this code is trying to accomplish,
but memcmping a struct is of course always dangerous and
never a good idea. In this case, it's actually memcmping an
inhereted class which is even worse, as the vtable pointer
gets involved, causing the memcmp to seemingly never succeed.
It's not clear though whether this memcmp might be masking
some other buggy codepath, so I haven't added a KI yet.
Anyone understand the CFogController? Do certain maps make
use of this?
Patch to use correct comparisons:
--- src/dlls/fogcontroller.cpp 26 Aug 2006 21:24:29 - 1.2
+++ src/dlls/fogcontroller.cpp 4 Sep 2006 18:43:46 -
@@ -381,8 +381,22 @@
{
if ( CFogController::s_pFogController )
{
- if ( Q_memcmp( fog,
CFogController::s_pFogController, sizeof(fog) ))
- {
+ if (
+ fog.enable.Get() !=
CFogController::s_pFogController-m_fog.enable.Get()
+|| fog.blend.Get()!=
CFogController::s_pFogController-m_fog.blend.Get()
+|| fog.dirPrimary.Get() !=
CFogController::s_pFogController-m_fog.dirPrimary.Get()
+|| fog.colorPrimary.Get() !=
CFogController::s_pFogController-m_fog.colorPrimary.Get()
+|| fog.colorSecondary.Get() !=
CFogController::s_pFogController-m_fog.colorSecondary.Get()
+|| fog.start.Get()!=
CFogController::s_pFogController-m_fog.start.Get()
+|| fog.end.Get() !=
CFogController::s_pFogController-m_fog.end.Get()
+|| fog.farz.Get() !=
CFogController::s_pFogController-m_fog.farz.Get()
+|| fog.colorPrimaryLerpTo.Get() !=
CFogController::s_pFogController-m_fog.colorPrimaryLerpTo.Get()
+|| fog.colorSecondaryLerpTo.Get() !=
CFogController::s_pFogController-m_fog.colorSecondaryLerpTo.Get()
+|| fog.startLerpTo.Get() !=
CFogController::s_pFogController-m_fog.startLerpTo.Get()
+|| fog.endLerpTo.Get()!=
CFogController::s_pFogController-m_fog.endLerpTo.Get()
+|| fog.lerptime.Get() !=
CFogController::s_pFogController-m_fog.lerptime.Get()
+|| fog.duration.Get() !=
CFogController::s_pFogController-m_fog.duration.Get()
+) {
fog = CFogController::s_pFogController-m_fog;
return true;
}
___
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] AssertOnce( pModelCache-IsFrameLocking() );
No, we just rely on virtual memory for that. This is for when you hit the cache ceiling (which is usually 256MB depending on the physical ram on the machine). Obviously on consoles it's lower given the usual memory configurations there (which isn't relevant to any of you guys, but is to us). Also, I would definitely NOT recommend the code changes you posted on the wiki. That will cause way too much overhead to protect against a pointer dangling. The scope frames should be at a much higher level. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, September 02, 2006 12:17 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); So if the box is low on ram, the HL2 core will memory it's not actively using right that moment? I think I now understand what the issue is, although I'm confused by the use of scope locking for something like this. In any case I've added MDLCACHE_CRITICAL_SECTION per Jay's instruction, and the result is several dozen fixes, added to the KI list: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List# IsFrameLocking_assert Confirmation from Valve would be appreciated that this is correct with respect to the way the closed-source core works. -bk At 2006/08/30 09:02 PM, Jay Stelly wrote: Since there are no explicit unlock operations on the studio headers we use a concept we call frame locking where they are guaranteed to remain in memory (i.e. not get flushed for some other memory allocation request) as long as the frame is in scope. There's a macro for generating these lock frames called: MDLCACHE_CRITICAL_SECTION(); If you search, you'll see these frames declared at the top of a bunch of the systems (entity think, save/load, etc) So any studio headers that are loaded in the scope of that can't be freed until you exit that scope. The assert is saying that you aren't within one of those scopes so theoretically your pointer could get freed if some other memory request causes the cache to fill later on - so it's not safe to hang on to this pointer and still call memory management functions in datacache. It's easy enough to fix the assert by adding a frame using the macro above to whatever entry point is causing you to page in the model. Don't put one in GetModelPtr() however as that defeats the whole purpose of this debug instrumentation. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Schiff Sent: Wednesday, August 30, 2006 5:47 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); -- [ Picked text/plain from multipart/alternative ] More like a problem with the calls we make to them. It seems to only show up when initially showing a model... On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Im also wondering what this is, IsFrameLocking()... Possible problem with our models? On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: AssertOnce( pModelCache-IsFrameLocking() ); This assert is always hit, both server-side baseanimating.cpp(2352) and client-side c_baseanimating.cpp(931) when a player joins a server. The purpose of this assert is unclear. Unfortunately the function it is asserting is closed-source with no documentation on its purpose either. I've added a KI recommending commenting it out for now. ___ 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] AssertOnce( pModelCache-IsFrameLocking() );
Since there are no explicit unlock operations on the studio headers we use a concept we call frame locking where they are guaranteed to remain in memory (i.e. not get flushed for some other memory allocation request) as long as the frame is in scope. There's a macro for generating these lock frames called: MDLCACHE_CRITICAL_SECTION(); If you search, you'll see these frames declared at the top of a bunch of the systems (entity think, save/load, etc) So any studio headers that are loaded in the scope of that can't be freed until you exit that scope. The assert is saying that you aren't within one of those scopes so theoretically your pointer could get freed if some other memory request causes the cache to fill later on - so it's not safe to hang on to this pointer and still call memory management functions in datacache. It's easy enough to fix the assert by adding a frame using the macro above to whatever entry point is causing you to page in the model. Don't put one in GetModelPtr() however as that defeats the whole purpose of this debug instrumentation. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Schiff Sent: Wednesday, August 30, 2006 5:47 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); -- [ Picked text/plain from multipart/alternative ] More like a problem with the calls we make to them. It seems to only show up when initially showing a model... On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Im also wondering what this is, IsFrameLocking()... Possible problem with our models? On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: AssertOnce( pModelCache-IsFrameLocking() ); This assert is always hit, both server-side baseanimating.cpp(2352) and client-side c_baseanimating.cpp(931) when a player joins a server. The purpose of this assert is unclear. Unfortunately the function it is asserting is closed-source with no documentation on its purpose either. I've added a KI recommending commenting it out for now. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ~skidz -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ts2do -- ___ 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] Bogus Compile Errors
Sounds like you've got a bad code merge or something.
// weapon_357.cpp
// ...
class CWeapon357 : public CBaseHL2MPCombatWeapon
{
DECLARE_CLASS( CWeapon357, CBaseHL2MPCombatWeapon );
public:
CWeapon357( void );
voidPrimaryAttack( void );
DECLARE_NETWORKCLASS();
DECLARE_PREDICTABLE();
#ifndef CLIENT_DLL
DECLARE_ACTTABLE();
#endif
If that #ifndef CLIENT_DLL is missing (or somehow you haven't got
CLIENT_DLL defined in your client) then it's going to give the error you
posted below because you've forward declared something you haven't
actually implemented.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, August 11, 2006 11:09 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Bogus Compile Errors
--
[ Picked text/plain from multipart/alternative ]
Content-description: Mail message body
client error LNK2001: unresolved external symbol public:
virtual int __thiscall C_Weapon357::ActivityListCount(void)
([EMAIL PROTECTED]@@UAEHXZ)
client error LNK2001: unresolved external symbol public:
virtual struct acttable_t * __thiscall
C_Weapon357::ActivityList(void)
([EMAIL PROTECTED]@@UAEPAUacttable_t@@XZ)
client fatal error LNK1120: 2 unresolved externals
Has anyone any idea how I can resolve these? I have tried
making scence out of them but evidently failed.
I have no idea what this ActivityListCount is about?
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
RE: [hlcoders] No Linux specific data?
As of episode 1, the engine no longer requires linux-specific data for physics. There is a new method implemented for terrain collision in vphysics that is shared between win32 and linux. Obviously that means that you can only use the latest compile tools with mods running the latest game DLL code. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam amckern Mckern Sent: Wednesday, August 09, 2006 8:26 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] No Linux specific data? Hi Owen, I was looking at the code found in the source sdk update in relation to the tools, and hope to have a HDR update to CST Soon, but going on my own testing using just the CST BSP tool, along with VVIS, and VRAD, will return the same as if you where to use the Feburay VBSP. I would wait for word from valve or other list members, before you would go and quote me though. Adam --- Owen Smith [EMAIL PROTECTED] wrote: woo, my first post to the list :) I cannot verify/replicate this since I have no linux server to test on, but it appears that since the SDK update vbsp.exe no longer outputs the linux specific data it used to. Hence, newly-compiled maps crash when run on a Linux Server. This has been mentioned on VERC ( http://www.chatbear.com/board.plm?a=viewthreadt=536,115488601 3,22253id=999083b=4986v=flatold http://www.chatbear.com/board.plm?a=viewthreadb=4986t=52,115 4933595,22231s=0id=999679) but I couldnt see anything on the list archive about it. Any news on this? current workaround is to use CST/Zoners to compile but people are reporting suboptimal lighting. On Interlopers I suggested people use the CTS version of VBSP maybe VVIS, then use Valve VRAD to get HDR lighting, i avent had any confirmation that this works. Anyone know if it will work, or are zoners tools output too different? And more importantly, will this error be resolved by Valve? is it a bug, or a dropped feature? is the linux dedicated serve being upgraded some time soon or something? apoloigies if this is already covered, couldnt see it in any recent known issues threads, or on this list, etc etc. This is not to be confused with the other Linux-compiling issue here http://developer.valvesoftware.com/wiki/Source_SDK_Known_Issue s#SDK_Does_Not_Compile_Under_Linux_.28Since_8.2F4.2F2006.29 Thanks for any response. And hello, by the way ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] No Linux specific data?
Also, there's a command line option in vbsp: -novirtualmesh This will not revert to the previous behavior exactly (it essentially reverts to the linux behavior on win32 linux - which uses more memory on win32 than the previous code). I haven't tested this with an old mod under linux yet, but it's possible that this can be used as a workaround. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jay Stelly Sent: Wednesday, August 09, 2006 10:54 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] No Linux specific data? As of episode 1, the engine no longer requires linux-specific data for physics. There is a new method implemented for terrain collision in vphysics that is shared between win32 and linux. Obviously that means that you can only use the latest compile tools with mods running the latest game DLL code. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam amckern Mckern Sent: Wednesday, August 09, 2006 8:26 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] No Linux specific data? Hi Owen, I was looking at the code found in the source sdk update in relation to the tools, and hope to have a HDR update to CST Soon, but going on my own testing using just the CST BSP tool, along with VVIS, and VRAD, will return the same as if you where to use the Feburay VBSP. I would wait for word from valve or other list members, before you would go and quote me though. Adam --- Owen Smith [EMAIL PROTECTED] wrote: woo, my first post to the list :) I cannot verify/replicate this since I have no linux server to test on, but it appears that since the SDK update vbsp.exe no longer outputs the linux specific data it used to. Hence, newly-compiled maps crash when run on a Linux Server. This has been mentioned on VERC ( http://www.chatbear.com/board.plm?a=viewthreadt=536,115488601 3,22253id=999083b=4986v=flatold http://www.chatbear.com/board.plm?a=viewthreadb=4986t=52,115 4933595,22231s=0id=999679) but I couldnt see anything on the list archive about it. Any news on this? current workaround is to use CST/Zoners to compile but people are reporting suboptimal lighting. On Interlopers I suggested people use the CTS version of VBSP maybe VVIS, then use Valve VRAD to get HDR lighting, i avent had any confirmation that this works. Anyone know if it will work, or are zoners tools output too different? And more importantly, will this error be resolved by Valve? is it a bug, or a dropped feature? is the linux dedicated serve being upgraded some time soon or something? apoloigies if this is already covered, couldnt see it in any recent known issues threads, or on this list, etc etc. This is not to be confused with the other Linux-compiling issue here http://developer.valvesoftware.com/wiki/Source_SDK_Known_Issue s#SDK_Does_Not_Compile_Under_Linux_.28Since_8.2F4.2F2006.29 Thanks for any response. And hello, by the way ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios 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 ___ 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] No Linux specific data?
Yes, unless you build with -novirtualmesh I'd expect there to be no collisions between physics objects and your terrain if you were to recompile your maps with the new tools. On linux, users here are reporting crashes instead of that behavior; I'm looking into that now. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Sent: Wednesday, August 09, 2006 12:13 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] No Linux specific data? When you mention lastest game DLL code does that mean latest mod compiled code? I haven't yet gotten the time to upgrade my code to the latest sdk code base, If I were to recompile all of my maps, would my older code sdk fail to use those recompiled maps on linux? On 8/9/06, Jay Stelly [EMAIL PROTECTED] wrote: As of episode 1, the engine no longer requires linux-specific data for physics. There is a new method implemented for terrain collision in vphysics that is shared between win32 and linux. Obviously that means that you can only use the latest compile tools with mods running the latest game DLL code. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam amckern Mckern Sent: Wednesday, August 09, 2006 8:26 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] No Linux specific data? Hi Owen, I was looking at the code found in the source sdk update in relation to the tools, and hope to have a HDR update to CST Soon, but going on my own testing using just the CST BSP tool, along with VVIS, and VRAD, will return the same as if you where to use the Feburay VBSP. I would wait for word from valve or other list members, before you would go and quote me though. Adam --- Owen Smith [EMAIL PROTECTED] wrote: woo, my first post to the list :) I cannot verify/replicate this since I have no linux server to test on, but it appears that since the SDK update vbsp.exe no longer outputs the linux specific data it used to. Hence, newly-compiled maps crash when run on a Linux Server. This has been mentioned on VERC ( http://www.chatbear.com/board.plm?a=viewthreadt=536,115488601 3,22253id=999083b=4986v=flatold http://www.chatbear.com/board.plm?a=viewthreadb=4986t=52,115 4933595,22231s=0id=999679) but I couldnt see anything on the list archive about it. Any news on this? current workaround is to use CST/Zoners to compile but people are reporting suboptimal lighting. On Interlopers I suggested people use the CTS version of VBSP maybe VVIS, then use Valve VRAD to get HDR lighting, i avent had any confirmation that this works. Anyone know if it will work, or are zoners tools output too different? And more importantly, will this error be resolved by Valve? is it a bug, or a dropped feature? is the linux dedicated serve being upgraded some time soon or something? apoloigies if this is already covered, couldnt see it in any recent known issues threads, or on this list, etc etc. This is not to be confused with the other Linux-compiling issue here http://developer.valvesoftware.com/wiki/Source_SDK_Known_Issue s#SDK_Does_Not_Compile_Under_Linux_.28Since_8.2F4.2F2006.29 Thanks for any response. And hello, by the way ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios 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 ___ 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] No Linux specific data?
Yeah - that's what I'd expect because your mod wouldn't have the hook for virtual terrains in game_shared/physics_shared.cpp. On linux there is an extra wrinkle because the engine expects maps to contain linux-specific data if your mod is exposing the previous version of the server game DLL interface. As far as this goes: I'm wonder if this change means that we'll be able to manipulate displacements properly in game.. complete with collision data. it's pretty close to that now. If you actually move a displacement surface, those triangles are connected to the virtual terrain in their updated state. What isn't connected is: a) the virtual terrain has a cache that can't be directly invalidated b) There is no code to push on objects that have contact points with the current virtual mesh surface So in the current implementation you'd get correct collisions after a deformation once any objects touching the surface were removed and the cache was rebuilt. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garry Newman Sent: Wednesday, August 09, 2006 12:44 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] No Linux specific data? -- [ Picked text/plain from multipart/alternative ] I think so. The displacements stopped colliding with physics objects with maps compiled using the new SDK. I've updated to the new SDK code and it collides fine now though. I'm wonder if this change means that we'll be able to manipulate displacements properly in game.. complete with collision data. On 8/9/06, Nick [EMAIL PROTECTED] wrote: When you mention lastest game DLL code does that mean latest mod compiled code? I haven't yet gotten the time to upgrade my code to the latest sdk code base, If I were to recompile all of my maps, would my older code sdk fail to use those recompiled maps on linux? On 8/9/06, Jay Stelly [EMAIL PROTECTED] wrote: As of episode 1, the engine no longer requires linux-specific data for physics. There is a new method implemented for terrain collision in vphysics that is shared between win32 and linux. Obviously that means that you can only use the latest compile tools with mods running the latest game DLL code. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam amckern Mckern Sent: Wednesday, August 09, 2006 8:26 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] No Linux specific data? Hi Owen, I was looking at the code found in the source sdk update in relation to the tools, and hope to have a HDR update to CST Soon, but going on my own testing using just the CST BSP tool, along with VVIS, and VRAD, will return the same as if you where to use the Feburay VBSP. I would wait for word from valve or other list members, before you would go and quote me though. Adam --- Owen Smith [EMAIL PROTECTED] wrote: woo, my first post to the list :) I cannot verify/replicate this since I have no linux server to test on, but it appears that since the SDK update vbsp.exe no longer outputs the linux specific data it used to. Hence, newly-compiled maps crash when run on a Linux Server. This has been mentioned on VERC ( http://www.chatbear.com/board.plm?a=viewthreadt=536,115488601 3,22253id=999083b=4986v=flatold http://www.chatbear.com/board.plm?a=viewthreadb=4986t=52,115 4933595,22231s=0id=999679) but I couldnt see anything on the list archive about it. Any news on this? current workaround is to use CST/Zoners to compile but people are reporting suboptimal lighting. On Interlopers I suggested people use the CTS version of VBSP maybe VVIS, then use Valve VRAD to get HDR lighting, i avent had any confirmation that this works. Anyone know if it will work, or are zoners tools output too different? And more importantly, will this error be resolved by Valve? is it a bug, or a dropped feature? is the linux dedicated serve being upgraded some time soon or something? apoloigies if this is already covered, couldnt see it in any recent known issues threads, or on this list, etc etc. This is not to be confused with the other Linux-compiling issue here http://developer.valvesoftware.com/wiki/Source_SDK_Known_Issue s#SDK_Does_Not_Compile_Under_Linux_.28Since_8.2F4.2F2006.29 Thanks for any response. And hello, by the way ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios http://www.nigredostudios.com
