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:
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:
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 pro
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:
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
> > > y
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: 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: 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: 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: 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
Re: [hlcoders] "This Steam account is being used in another location"
Works for me now. Wasn't before. Thanks for the fix. trepid_jon - Original Message - From: "Alfred Reynolds" <[EMAIL PROTECTED]> To: Sent: Wednesday, December 07, 2005 1:30 AM Subject: RE: [hlcoders] "This Steam account is being used in another location" We have released a fix for this in Beta form. Run Steam with "-beta hl1" on the command line to get this update (note that you CANNOT run both the SDK beta and this beta at the same time). I would appreciate feedback from people verifying that this fixes the problem. If you do see this message after running the beta log out of Steam and back in again (via the File->Change user... option) to make sure you login credentials are updated. This update will be made public in a day or so if our internal testing and feedback from the beta goes well. - Alfred Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] I've had the problem myself as well as someone else I know...I just tested now and got that error On 11/29/05, Alfred Reynolds <[EMAIL PROTECTED]> wrote: You get that error message for a couple of reasons. Firstly, the obvious one being when that account it being used in two places at once, I assume you aren't doing that. You can also get it if your Steam2 ticket is invalid (i.e you logged into that account in another location and then ran again at the first location). Logging into Steam again will fix that (or using the login dialog the game presents). If neither of these applies to you then contact me offlist with the sequence of events for your account and launching HL and I will debug it with you. - Alfred Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] Yes...I think everyone gets that problem hosting listenserver for goldsource You say sv_lan fixes it? Can't sv_lan be changed to 0 while it's running and be functional? If it can, then that's the workaround On 11/29/05, Jeff Fearn <[EMAIL PROTECTED]> wrote: When trying to run my HL1 mod as a listen server I get "This Steam account is being used in another location" error. Setting sv_lan 1 in listenserver.cfg bypasses this problem. Fully updated Dedicated Server seems to work ok. -- Jeff Fearn "Postmodernism: Once more without feeling." -- Geoffrey Nunberg ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] 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_.txt" but "maps\_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: 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: 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_.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
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: 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_.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
[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_.txt" trepid_jon ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Pause System
Feels like a silly question, but how does the pause system for the game
work?
I'm trying to have an option so that my level begin paused. I tried
running a engine->ServerCommand("pause"); and
engine->ClientCmd("pause");, etc on both the server and the client but
it never seemed to work. Looking through the engine-> and the gpGlobals
stuff I couldn't see any variable of function that we a clear indicator
of the gamestate. Anyone?
Jon
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Velocity and teleport
I teleport the player in my current project this is how it is done. Note
that I am warping them to a target entity so your slap would move them
relative to their current position instead of too the info_target...
pPlayer = UTIL_GetLocalPlayer();
CBaseEntity *pTargetLocation = NULL;
pTargetLocation = gEntList.FindEntityByName(NULL, "trialLocation", NULL);
if(pTargetLocation) {
// find target for trials
Vector temp = pTargetLocation->GetAbsOrigin();
// align the player facing a painting
float paintingAngles[3] = { 0.0f, 180.0f, 90.0f };
QAngle viewAngle(0, paintingAngles[random->RandomInt(0, 2)], 0);
pPlayer->SetAbsAngles(viewAngle); // Pasting
this code in the email makes me realize it may be redundnat
Vector velocity(0,0,0);
pPlayer->Teleport(&temp, &viewAngle, &velocity);
// turn off movement
pPlayer->SetMoveType(MOVETYPE_NONE);
}
The key function is pPlayer->Teleport(location, viewAngles, velocity)
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Playing custom .vcd (faceposer) files
Well things seem to be working alright except that any expression tracks that I have in a .vcd that are from my own set of expressions in an expressions file (lets call it jonsexpressions.txt or jonsexpresssions.vfe) don't seem to work. Should .vfe files be loaded automatically when they are refrenced by a .vcd, do they need to be precached or refrenced somewhere? Jon Yahn Bernier wrote: I would look at one of the .vcds referenced in the response_rules.txt file and see how it's set up. It could be as simple as not having the target / actor names set up correctly. Yahn ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Playing custom .vcd (faceposer) files
To answer my own quest at least a bit (for the sake of the community):
At first I saw that the BaseActor class had m_izaIdleExpression and
AngryExpression and so on as variables that were
MAKE_STRING("scenes/expressions/blah.vcd"). You can trace around and
then eventually find places that say
SetExpression(STRING(m_izaIdleExpression)) and so on so I figured this
function must be the key to call and do a custom.vcd. Not so :(
However, when I changed m_izaIdleExpression to a .vcd from HL2 and I
made sure my custom NPC class was in NPC_STATE_IDLE it played just fine.
Ok, good enough, but when I tried my own custom .vcd it didn't work.
Now I'm gonna assume that my path/file.vcd is ok since its the same
format ass all the other custom resources I access and they work just
fine (materials, GUI elements and so on). And the .vcd itself plays fine
in face poser, in fact i exctracted a valve .vcd that I knew worked and
just renamed it and still no luck.
Tracing around further in the /scripts/talker dir there are tons of NPC
rules that tell the NPCs what .vcd to play in what AI state and what
rules there are for being in a state and playing certain VCDs. There is
even a response_rules.txt file that seems to outline the format. I
wonder if I should just add my .vcd's to one of these or if there is
some other resource list somewhere else that my .vcds need to be added
to...
Anyone's suggestions or help on the topic appriciated!
Jon wrote:
I'm having some trouble getting .vcds made in face poser to play
properly. I have an avatar class based on the CBaseActor class (as most
of the humanoid NPC's seem to be) and although I have precached the
instanced scene (ie the VCD) and done SetExpression("blah/blah.vcd") the
avatars still aren't playing the facial expression. Tracing through the
npc_citizen17.cpp the only real changes in VCD seem to be through the
overloaded function SelectRandomExpressionForState(NPCState). However,
overloading this function in my own class didn't do the trick.
Really I just need a totally dumb NPC that is going to have just one
looping VCD of either happy or sad or whatever emotions on their face,
they don't move or change states or anything of the sort. If anyone
could step me through the process of playing a custom facial animation
on a model that would be great. For reference my class is just borrowing
the model files from the citizen17 entities so everything should be set
up for rigging I'd assume (they currently display the idle, looking
around animation just fine).
TIA
___
To 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] Playing custom .vcd (faceposer) files
I'm having some trouble getting .vcds made in face poser to play
properly. I have an avatar class based on the CBaseActor class (as most
of the humanoid NPC's seem to be) and although I have precached the
instanced scene (ie the VCD) and done SetExpression("blah/blah.vcd") the
avatars still aren't playing the facial expression. Tracing through the
npc_citizen17.cpp the only real changes in VCD seem to be through the
overloaded function SelectRandomExpressionForState(NPCState). However,
overloading this function in my own class didn't do the trick.
Really I just need a totally dumb NPC that is going to have just one
looping VCD of either happy or sad or whatever emotions on their face,
they don't move or change states or anything of the sort. If anyone
could step me through the process of playing a custom facial animation
on a model that would be great. For reference my class is just borrowing
the model files from the citizen17 entities so everything should be set
up for rigging I'd assume (they currently display the idle, looking
around animation just fine).
TIA
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] pfnPEntityOfEntIndex( 1 )
I've seen this in CTriggerCamera::Use. Which entity does it refer to? I originally thought that it was the player, but this: if ( !pActivator || !pActivator->IsPlayer() ) seems to rule that out. Which entity is it pointing at? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Trigger on level start
I'm trying to make a trigger that will fire upon level start, but not at level spawn, like trigger_auto. There is a delay between the level spawn and when the level is visible. How can I trigger an entity at the moment the player has interaction with the map? Thanks Jon 'DesPlesda' Manning ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
