Re: [hlcoders] Player HULL vs HIT BOXES
I just realized pre-defining them wouldn't help, because of the 9 way
blending stuff.
So scratch that horrible idea.
trepid_jon
- Original Message -
From: Ben Everett [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, January 18, 2007 11:41 PM
Subject: RE: [hlcoders] Player HULL vs HIT BOXES
Memory and CPU cycles are cheap ;)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jon Day
Sent: Thursday, January 18, 2007 10:29 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
I'm very interested in finding out how well Dystopia performs with the
USE_HITBOXES system as that really does seem like a good way to do it.
Could save CPU cycles if the bbox that USE_HITBOXES would compute was
instead pre-defined for each animation frame in the actual model/animation
files (or a new file for each model created by some new program), so the
game wouldn't have to go through each hitbox to create a bbox in
real-time.
I guess there would then be a tradeoff for memory, since there is an
insane
amount of animations as well as an insane amount of different hitboxes for
different models. But still, it might be worth it.
trepid_jon
- Original Message -
From: Teddy [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, January 18, 2007 9:48 PM
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
Thanks Jay! The hacky workaround fixed the triggers through doors bug,
now i can have the best of both worlds. For anyone who's interested,
here's the code snippet:
void CDYSPlayer::PhysicsTouchTriggers( const Vector *pPrevAbsOrigin )
{
CollisionProp()-SetSurroundingBoundsType( USE_OBB_COLLISION_BOUNDS );
BaseClass::PhysicsTouchTriggers( pPrevAbsOrigin );
CollisionProp()-SetSurroundingBoundsType( USE_HITBOXES );
}
On 1/18/07, Jay Stelly [EMAIL PROTECTED] wrote:
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
Re: [hlcoders] Player HULL vs HIT BOXES
I'm very interested in finding out how well Dystopia performs with the
USE_HITBOXES system as that really does seem like a good way to do it.
Could save CPU cycles if the bbox that USE_HITBOXES would compute was
instead pre-defined for each animation frame in the actual model/animation
files (or a new file for each model created by some new program), so the
game wouldn't have to go through each hitbox to create a bbox in real-time.
I guess there would then be a tradeoff for memory, since there is an insane
amount of animations as well as an insane amount of different hitboxes for
different models. But still, it might be worth it.
trepid_jon
- Original Message -
From: Teddy [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, January 18, 2007 9:48 PM
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
Thanks Jay! The hacky workaround fixed the triggers through doors bug,
now i can have the best of both worlds. For anyone who's interested,
here's the code snippet:
void CDYSPlayer::PhysicsTouchTriggers( const Vector *pPrevAbsOrigin )
{
CollisionProp()-SetSurroundingBoundsType( USE_OBB_COLLISION_BOUNDS );
BaseClass::PhysicsTouchTriggers( pPrevAbsOrigin );
CollisionProp()-SetSurroundingBoundsType( USE_HITBOXES );
}
On 1/18/07, Jay Stelly [EMAIL PROTECTED] wrote:
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
Re: [hlcoders] SteamAppId Update
So does that mean mods will be able to use a generic appid that will work with whatever Source game a player has? As in, um...maybe that appid will mount a generic GCF that just has the Source engine EXEs and whatnot in it while also mounting the shared Source content GCFs? So we'd literally be able to make Source mods and the players would just need any Source game? Or instead, maybe a few specific Source games that aren't free (like HL2, HL2DM, CS:S, DoD:S...and TF2, what?), so people wouldn't be able to just use the free HL2 demo or something like that? Also probably wouldn't want them working with SiN Episodes, right? Question mark? Jon - Original Message - From: Alfred Reynolds [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Monday, July 03, 2006 7:23 PM Subject: RE: [hlcoders] SteamAppId Update There will be a new, special, appid for multi-player Source engine apps that don't directly derive from a particular game (so rather than using the basic 220 you will have a new number). This new app depends on some SDK work before it will be enabled. - Alfred Tony omega Sergi wrote: So, what does this mena? There isn't going to be an hl2mp gcf anymore? Cuz hl2sp is 220 and hl2mp is 320.. So are they going to share the same cache? -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com -Original Message- From: Alfred Reynolds [mailto:[EMAIL PROTECTED] Sent: July 3, 2006 6:51 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] SteamAppId Update You should wait for the next SDK update to make this change unless you need to use functionality released in the recent Episode One engine update. This SDK update will walk you through the update process properly. Using 220 is still perfectly fine to do. - Alfred Justin Krenz wrote: I just want to give everyone a heads up that the SteamAppId in your mod's gameinfo.txt should be either 320 or 240, not 220. I just received an e-mail from Alfred Reynolds in reply to my inquiry about a fix that was supposed to go into HL2 regarding my mod. My mod was still using 220 for it's SteamAppID, and thus, it was not running off of the latest HL2 engine. I know there are others out there who are still using 220 and need to change 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 __ 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] Are we ever going to get an update for VS2005?
I remember reading that article back in the day, and that's actually one of the reasons I didn't worry too much when I upgraded to VS2005. When it didn't work out that way, I just figured it would all be fine soon after. Obviously, soon after didn't mean within a few weeks or a couple of months, but hopefully it at least meant mid-2006...or even better, April 2006. trepid_jon - Original Message - From: Teddy [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, April 07, 2006 12:50 AM Subject: Re: [hlcoders] Are we ever going to get an update for VS2005? I was also expecting a SDK code update back in october, because the engine update at that time broke Dystopia (along with alot of other mods), but alas we had to do some hasty workarounds of our own. I can't quite believe it's been 10 months since the last SDK code update, especially given the number of issues in the current build. Back in Novemember I was presenting at the Australian Microsoft Tech-Ed on Developing atop Half-Life 2 with Microsoft Visual C++ 2005 Express Edition, I remember telling people at the presentation that a patch to make the SDK work with VS 2005 Express would be out very soon, there was even a press announcement; http://www.microsoft.com/presspass/press/2005/aug05/08-31ValveCPlusPlusPR.mspx Now i feel like a total ass for lying to all those people :/ On 4/7/06, Jason Houston [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I was expecting a SDK update when DOD:S came. Right now it's been a good 11 months since we had an update to the source code. I want this update so I can put the BG2 code in it and see if it fixes a few problems we have with the current sdk. -- Draco -- ___ 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] Are we ever going to get an update for VS2005?
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] In my opinion, this is much more serious of a problem than a lot of people seem to be thinking. I mean, you can't even buy VS2003 anymore (unless it's used), right? So any VS2005 coders out there wanting to mod HL2 have all these problems with the code as is that they shouldn't even need to worry with in the first place. And why should they worry with those problems? They shouldn't...and I think a lot of HL2's modding scene potential has been lost (or hopefully just delayed) due to those problems. I upgraded to VS2005 and did all (most likely not all, though...which is the problem) of the supposed fixes to the code to let the DLLs at least compile all the way, but there are still tons of warnings that I pretty much just stopped caring about. I can play the mods, but I feel like my mod DLLs are dirty or something and have problems that I won't ever even know about, or that maybe they have new problems only brought on by me not fixing up the code for VS2005 in the proper way. So personally, I've just been mapping (Fortress Forever, WOOH YEAH!) instead of coding while I wait for the Source SDK to fully support VS2005. None of the mods I was coding had much of anything worth keeping, so I just plan to start all over with the code once VS2005 is officially supported. The waiting game isn't too much fun, though. So yeah, I think the Source SDK's lack of official VS2005 support is severely hurting the HL2 modding scene. I'm not blaming or mad at Valve though, because really...what in the hell was Microsoft thinking when they douched Visual Studio so badly? That's the real disappointment in all this. Still though, I think the VS2005 users have probably waited long enough for the Source SDK to fully support VS2005. trepid_jon - Original Message - From: Greg Chadwick [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Monday, March 20, 2006 6:49 AM Subject: RE: [hlcoders] Are we ever going to get an update for VS2005? You can use VS2005 with the SDK now, it just requires fixing up a few things and setting the correct compiler options (the proceedure should be exactly the same as it is for VC++2005 Express). On 3/19/06, Aditya Gaddam [EMAIL PROTECTED] wrote: Hi, Are there any real plans to update the SDK to work with the 2005 line of Visual C++ or Visual Studio? I keep hearing people say it will come in the next update, but are there any real release dates? I have VS2005 but not 2003, the other coder on our mod team can use VC++ express. The new IDEs seem to be much better than 2003 from what I have seen of 2003. So? Any updates Valve? pleease? =P -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 ___ 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] Vectorized Aiming
You don't have to look down the sights in order to aim a gun. Yeah, it's better...for me...and most people. But some people can just hold a gun out and aim without actually looking down the sights. The kind of aiming this person is wanting sounds like it would fit really well in an old western game. I guess you'd just have to feel where the gun's aiming or something...haha. Anyways, I'm kind of getting off topic. Jon - Original Message - From: Jason Houston [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Monday, January 30, 2006 7:29 PM Subject: Re: [hlcoders] Vectorized Aiming -- [ Picked text/plain from multipart/alternative ] You're right about having to be looking the same way as the gun, you pretty much have to make the gun part of you, or you will miss every time. This sort of aiming system you are talking about would feel more at home on a console system or something. Oh well, good luck, do a tute on the VDC on it when you are done, it would be usefull for other applications, like that stephoscope. -- Draco -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Loading of game_sounds txt files?
Anyone happen to know where in the code game_sounds txt files are loaded? Seems like it's deep within the engine and not in the SDK, but maybe I'm just blind. We're hoping to do something similar to how map specific soundscapes are loaded in SoundscapeSystem::Init(), except for game sounds instead...like scripts\game_sounds_mapname.txt trepid_jon ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Loading of game_sounds txt files?
Thanks for the quick reply, Yahn. But the thing is, we're wanting to autoload map specific game sounds so third party maps can have custom game sounds. As of right now, the community mappers have to edit the manifest to add their own game_sounds txt files, but they can't really spread their own manifests around as there would then be a ton of different manifests out there. So yeah, we're wanting an option to bypass the manifest. Do we have the source code in the SDK to compile our own version of soundemittersystem.dll? trepid_jon - Original Message - From: Yahn Bernier [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Tuesday, November 08, 2005 4:54 PM Subject: RE: [hlcoders] Loading of game_sounds txt files? They are loaded by the soundemittersystem.dll, but you can add to the list of .txt files by adding your file to game_sounds_manifest.txt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Day Sent: Tuesday, November 08, 2005 2:40 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Loading of game_sounds txt files? Anyone happen to know where in the code game_sounds txt files are loaded? Seems like it's deep within the engine and not in the SDK, but maybe I'm just blind. We're hoping to do something similar to how map specific soundscapes are loaded in SoundscapeSystem::Init(), except for game sounds instead...like scripts\game_sounds_mapname.txt trepid_jon ___ 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] Loading of game_sounds txt files?
Very cool, Yahn. We'll be lookin' forward to whatever y'all work your magic on. Also, we weren't actually wanting to use scripts\game_sounds_mapname.txt but maps\mapname_game_sounds.txt instead. So if you're able to work in an option for that...well, that'd be even more sweet. That's not too important, though. They're both good. And if nothing else, looking through src\public\SoundEmitterSystem\isoundemittersystembase.h is making us wonder if we can manually load and parse through game_sounds txt files that aren't listed in the manifest. So yeah, just give us all that source code or this tire's going to hunt Mary down. trepid_jon - Original Message - From: Yahn Bernier [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Tuesday, November 08, 2005 5:23 PM Subject: RE: [hlcoders] Loading of game_sounds txt files? I see what you are hitting. I'll talk to folks here and see if we can solve this in a useful way. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Day Sent: Tuesday, November 08, 2005 3:08 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Loading of game_sounds txt files? Thanks for the quick reply, Yahn. But the thing is, we're wanting to autoload map specific game sounds so third party maps can have custom game sounds. As of right now, the community mappers have to edit the manifest to add their own game_sounds txt files, but they can't really spread their own manifests around as there would then be a ton of different manifests out there. So yeah, we're wanting an option to bypass the manifest. Do we have the source code in the SDK to compile our own version of soundemittersystem.dll? trepid_jon - Original Message - From: Yahn Bernier [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Tuesday, November 08, 2005 4:54 PM Subject: RE: [hlcoders] Loading of game_sounds txt files? They are loaded by the soundemittersystem.dll, but you can add to the list of .txt files by adding your file to game_sounds_manifest.txt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Day Sent: Tuesday, November 08, 2005 2:40 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Loading of game_sounds txt files? Anyone happen to know where in the code game_sounds txt files are loaded? Seems like it's deep within the engine and not in the SDK, but maybe I'm just blind. We're hoping to do something similar to how map specific soundscapes are loaded in SoundscapeSystem::Init(), except for game sounds instead...like scripts\game_sounds_mapname.txt trepid_jon ___ 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
