Re: [hlcoders] Player Position
Actually I think I found maybe a possible solution to this. If you load the map sdk_vehicles they change the box as the vehicle moves around, probably will need to do something similar. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "r00t 3:16" <[EMAIL PROTECTED]> To: Sent: Thursday, January 13, 2005 10:32 PM Subject: Re: [hlcoders] Player Position ok now that I can see what the bound box looks like. Instead of change the player from | to ___ I think the bound box needs to be change. Basically if you go into the game and type cl_ent_absbox 1 It will should you the bounding box while standing. That is basically what I need for when the player is prone. Currently (if you go crouch) I have something similar to the crouch probably a little smaller actually. If the bounding box needs to be around the entire player, this box will be huge unless I can rotate it . r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Thursday, January 13, 2005 9:10 PM Subject: Re: [hlcoders] Player Position Ian Tyrrell wrote: Hehehe, "Bortman!" (sorry) Yah! Bort! Bort! Bort! (hey, I can't type for shit. i've been at work 65 hours this week already and it's not even Friday yet). Crunch time sucks! Mind thinking not clearly. Sleep imminent. -- Jeffrey "botman" Broome ___ 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 Position
ok now that I can see what the bound box looks like. Instead of change the player from | to ___ I think the bound box needs to be change. Basically if you go into the game and type cl_ent_absbox 1 It will should you the bounding box while standing. That is basically what I need for when the player is prone. Currently (if you go crouch) I have something similar to the crouch probably a little smaller actually. If the bounding box needs to be around the entire player, this box will be huge unless I can rotate it . r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Thursday, January 13, 2005 9:10 PM Subject: Re: [hlcoders] Player Position Ian Tyrrell wrote: Hehehe, "Bortman!" (sorry) Yah! Bort! Bort! Bort! (hey, I can't type for shit. i've been at work 65 hours this week already and it's not even Friday yet). Crunch time sucks! Mind thinking not clearly. Sleep imminent. -- Jeffrey "botman" Broome ___ 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 Position
Nevermind im an idiot lol the bound box just needs to be big enough to hold the prone player no matter what direction they turn. As the box does not rotate with them (thought it did sorry) I just need to make it large enough to fit the player while prone r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Thursday, January 13, 2005 7:05 PM Subject: Re: [hlcoders] Player Position r00t 3:16 wrote: Actually cause things brings up another point, now that you show me this. I am going to be making a lean left / right also. This would basically the same case when leaning and the bounding box would need to be big enough to to the side the lean on. In most games, leaning is accomplished by sliding the camera out to the right (when leaning right) or the left (when leaning left) and having an animation that tilts the player's body to the right (or left). Your animator would have to make sure that the player's hit boxes don't extend outside the player's collision box when this lean animation is taking place (assuming the Half-Life2 still uses collision box detection first before trying to check for hit box collisions). If the animation leans outside of the collision box, the hit boxes will follow the bone positions in the skeletalmesh and people will shoot at those "bones" (head, right arm, etc), but since the bones are outside the collsion box, the player won't be "hit" (you have to hit the big player collision box first, before it checks to see which hit box you have hit). As long as the width of your player collision box is wide enough so that none of the animations will extend outside the collision box when those animations are played, players should be able to be hit when they are leaning left or right. -- Jeffrey "botman" Broome ___ 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 Position
Ty, I had to go do some reading up on axis bounding hitboxes :P Thanks for the link. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "jeff broome" <[EMAIL PROTECTED]> To: Sent: Thursday, January 13, 2005 8:35 PM Subject: Re: [hlcoders] Player Position On Thu, 13 Jan 2005 20:26:46 -0500, r00t 3:16 <[EMAIL PROTECTED]> wrote: Is there a console command to be able to see this bounding box? So you can see exactly where it is located on the player, as well as other objects? http://www.valve-erc.com/srcsdk/console/developer_console.html Check some of the "cl_" or "r_" commands. Jeffrey "bortman" Broome ___ 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 Position
ent_absbox player On Thu, 13 Jan 2005 20:26:46 -0500, r00t 3:16 <[EMAIL PROTECTED]> wrote: > Is there a console command to be able to see this bounding box? > So you can see exactly where it is located on the player, as well as other > objects? > > r00t 3:16 > CQC Gaming > www.cqc-gaming.com > - Original Message - > From: "Justin Harvey" <[EMAIL PROTECTED]> > To: > Sent: Thursday, January 13, 2005 7:35 PM > Subject: Re: [hlcoders] Player Position > > >I haven't done lean yet for Source but how I did in the UT2004 version of > >my mod > > was similar to what you said. To prevent players from leaning into > > walls(and > > thus seeing through them etc) was to do a trace when trying to lean and > > while > > leaning. As far as 3rd person, I did the lean animation in code, rotating > > from > > a spine bone, I'm sure this can be done for Source as well with some set > > up in > > the QC before compiling. It's always best to do as much as you can with > > out > > involving artists ;). > > > > -- > > www.neotokyohq.com > > > > > > Quoting "Jeffrey \"botman\" Broome" <[EMAIL PROTECTED]>: > > > >> > >> In most games, leaning is accomplished by sliding the camera out to the > >> right (when leaning right) or the left (when leaning left) and having an > >> animation that tilts the player's body to the right (or left). > > > > > > > > > > > > ___ > > 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 Position
Ian Tyrrell wrote: Hehehe, "Bortman!" (sorry) Yah! Bort! Bort! Bort! (hey, I can't type for shit. i've been at work 65 hours this week already and it's not even Friday yet). Crunch time sucks! Mind thinking not clearly. Sleep imminent. -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Position
Hehehe, "Bortman!" (sorry) jeff broome wrote: Jeffrey "bortman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Position
On Thu, 13 Jan 2005 20:26:46 -0500, r00t 3:16 <[EMAIL PROTECTED]> wrote: > Is there a console command to be able to see this bounding box? > So you can see exactly where it is located on the player, as well as other > objects? http://www.valve-erc.com/srcsdk/console/developer_console.html Check some of the "cl_" or "r_" commands. Jeffrey "bortman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Position
Is there a console command to be able to see this bounding box? So you can see exactly where it is located on the player, as well as other objects? r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Justin Harvey" <[EMAIL PROTECTED]> To: Sent: Thursday, January 13, 2005 7:35 PM Subject: Re: [hlcoders] Player Position I haven't done lean yet for Source but how I did in the UT2004 version of my mod was similar to what you said. To prevent players from leaning into walls(and thus seeing through them etc) was to do a trace when trying to lean and while leaning. As far as 3rd person, I did the lean animation in code, rotating from a spine bone, I'm sure this can be done for Source as well with some set up in the QC before compiling. It's always best to do as much as you can with out involving artists ;). -- www.neotokyohq.com Quoting "Jeffrey \"botman\" Broome" <[EMAIL PROTECTED]>: In most games, leaning is accomplished by sliding the camera out to the right (when leaning right) or the left (when leaning left) and having an animation that tilts the player's body to the right (or left). ___ 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 Position
I haven't done lean yet for Source but how I did in the UT2004 version of my mod was similar to what you said. To prevent players from leaning into walls(and thus seeing through them etc) was to do a trace when trying to lean and while leaning. As far as 3rd person, I did the lean animation in code, rotating from a spine bone, I'm sure this can be done for Source as well with some set up in the QC before compiling. It's always best to do as much as you can with out involving artists ;). -- www.neotokyohq.com Quoting "Jeffrey \"botman\" Broome" <[EMAIL PROTECTED]>: > > In most games, leaning is accomplished by sliding the camera out to the > right (when leaning right) or the left (when leaning left) and having an > animation that tilts the player's body to the right (or left). ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Singleplayer port to Multiplayer
I solved the problem (with a bit help), so I thought I'd post the
solution in case anyone has a similar problem.
You must point to GetLocalPlayer() every paint (or think, in health's
case), or else the pointer becomes invalid (I think it may be a scope
issue). So by adding
if(!local){
local = C_BasePlayer::GetLocalPlayer();
m_fNewSpeed = 0;
}
else{
local = C_BasePlayer::GetLocalPlayer();
m_fNewSpeed = VectorLength(local->GetAbsVelocity());
}
to my paint() function, I retain the pointer, and it doesn't crash out.
Hope this helps someone :)
On Wed, 12 Jan 2005 18:41:31 -0800, Nick Roth <[EMAIL PROTECTED]> wrote:
> Ok, I finally ended up commenting out everything in my code (a hud
> element) but the basic function frame, and it compiled and ran in
> multiplayer mod mode on Steam. Then I began to uncomment blocks of
> code until I could get it to crash. It turns out this is the line
> that is causing it to crash:
>
> m_fNewSpeed = VectorLength(local->GetAbsVelocity());
>
> At first I had it in the think function, and I thought it didn't like
> having to do the calculation that quickly :), so I dropped it into the
> paint function, and it still crashes. any ideas?
>
> Basically I need to update the velocity every time I draw the element.
>
>
> On Wed, 12 Jan 2005 12:06:02 -0700, Hasan Aljudy <[EMAIL PROTECTED]> wrote:
> > I got that once when I tried to add classes to the vgui library .. got
> > an error "SDKGameRuels not registered on the client" or something like
> > that.
> > I thought that's becuase I messed with the vgui (i.e. it's not in
> > synch with the engine's vgui). but I'm not so sure ..
> >
> > On Wed, 12 Jan 2005 09:45:40 -0800, Mike Dussault
> > <[EMAIL PROTECTED]> wrote:
> > > Can you run in the debugger and get a call stack? Also, are you building
> > > both the client and the server DLL or just one of them? (Try building
> > > both).
> > >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Nick Roth
> > > Sent: Wednesday, January 12, 2005 12:43 AM
> > > To: hlcoders@list.valvesoftware.com
> > > Subject: [hlcoders] Singleplayer port to Multiplayer
> > >
> > > ok, so I made a few new classes (nothing that changes the existing cpp
> > > files), and it compiles and runs fine using the "Create Single Player
> > > Mod" package, but when I try placing the files in the Multiplayer mod
> > > package, it compiles fine, but crashes out when I try to load a map. I
> > > know others have had similar problems with this. Unfortunately, I
> > > haven't seen any solutions to the problem. I've tried loading single
> > > player maps, hl2mptest.bsp, and a CS map. All crash out.
> > >
> > > Any ideas or a thread I missed?
> > > --
> > > Nick Roth
> > >
> > > ___
> > > 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
> >
> >
>
>
> --
> Nick Roth
> [EMAIL PROTECTED]
>
--
Nick Roth
[EMAIL PROTECTED]
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Position
r00t 3:16 wrote: Actually cause things brings up another point, now that you show me this. I am going to be making a lean left / right also. This would basically the same case when leaning and the bounding box would need to be big enough to to the side the lean on. In most games, leaning is accomplished by sliding the camera out to the right (when leaning right) or the left (when leaning left) and having an animation that tilts the player's body to the right (or left). Your animator would have to make sure that the player's hit boxes don't extend outside the player's collision box when this lean animation is taking place (assuming the Half-Life2 still uses collision box detection first before trying to check for hit box collisions). If the animation leans outside of the collision box, the hit boxes will follow the bone positions in the skeletalmesh and people will shoot at those "bones" (head, right arm, etc), but since the bones are outside the collsion box, the player won't be "hit" (you have to hit the big player collision box first, before it checks to see which hit box you have hit). As long as the width of your player collision box is wide enough so that none of the animations will extend outside the collision box when those animations are played, players should be able to be hit when they are leaning left or right. -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Position
r00t 3:16 wrote: Hmm, I think I understand what your saying. What if the movement left / right was limited to like 5 degrees? If they moved 5 degrees right or left the entire body would move? (sorry i just don't understand the axis aligned boxes yet ) Axis aligned means that the edges of the box ALWAYS line up with the X & Y axis in the map (the box doesn't rotate when the player rotates). For example, you can't have the collision box around a player look like this (top down view)... __ / /^ / / | / / | / / | /_/| x-axis y-axis > ...since the sloped side doesn't lie along the X axis (even if the player was rotated 15 degrees clockwise). -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Position
Actually cause things brings up another point, now that you show me this. I am going to be making a lean left / right also. This would basically the same case when leaning and the bounding box would need to be big enough to to the side the lean on. Something like. Lean left +--+ | 0 | | /|\| | | | | /\ | +--+ Lean Right +---+ | 0| | /|\ | | || | /\| +---+ r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Thursday, January 13, 2005 6:26 PM Subject: Re: [hlcoders] Player Position r00t 3:16 wrote: I have been playing around with the player position for my prone. I believe that collision boxes (used around players) are axis aligned in Half-Life2 (as they were in Half-Life1). The collision box DOES NOT rotate as the player rotates. If you made this be the player collision box when the player was prone (head facing North, feet facing South)... +---+ | o | |/|\| | | | |/ \| +---+ ...here is what you would see when the player turn 90 degrees to the left... +---+ |/ |/ 0| |\ |\ | | +---+ ...notice the bounding box DOES NOT rotate along with the player. If you are going to do a prone position you would make a bounding box that looks like this... +-+ |o| | /|\ | ||| | / \ | +-+ ...which means you can't have the left or right side of your body be right up against colliding geometry in the level (axis aligned bounding boxes are a pain, aren't they?). -- Jeffrey "botman" Broome ___ 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 Position
Hmm, I think I understand what your saying. What if the movement left / right was limited to like 5 degrees? If they moved 5 degrees right or left the entire body would move? (sorry i just don't understand the axis aligned boxes yet ) r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Thursday, January 13, 2005 6:26 PM Subject: Re: [hlcoders] Player Position r00t 3:16 wrote: I have been playing around with the player position for my prone. I believe that collision boxes (used around players) are axis aligned in Half-Life2 (as they were in Half-Life1). The collision box DOES NOT rotate as the player rotates. If you made this be the player collision box when the player was prone (head facing North, feet facing South)... +---+ | o | |/|\| | | | |/ \| +---+ ...here is what you would see when the player turn 90 degrees to the left... +---+ |/ |/ 0| |\ |\ | | +---+ ...notice the bounding box DOES NOT rotate along with the player. If you are going to do a prone position you would make a bounding box that looks like this... +-+ |o| | /|\ | ||| | / \ | +-+ ...which means you can't have the left or right side of your body be right up against colliding geometry in the level (axis aligned bounding boxes are a pain, aren't they?). -- Jeffrey "botman" Broome ___ 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 Position
r00t 3:16 wrote: I have been playing around with the player position for my prone. I believe that collision boxes (used around players) are axis aligned in Half-Life2 (as they were in Half-Life1). The collision box DOES NOT rotate as the player rotates. If you made this be the player collision box when the player was prone (head facing North, feet facing South)... +---+ | o | |/|\| | | | |/ \| +---+ ...here is what you would see when the player turn 90 degrees to the left... +---+ |/ |/ 0| |\ |\ | | +---+ ...notice the bounding box DOES NOT rotate along with the player. If you are going to do a prone position you would make a bounding box that looks like this... +-+ |o| | /|\ | ||| | / \ | +-+ ...which means you can't have the left or right side of your body be right up against colliding geometry in the level (axis aligned bounding boxes are a pain, aren't they?). -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Player Position
I have been playing around with the player position for my prone. Maybe I am not asking correctly or asking the right question but here goes. When the player pushes the prone button it will bring the came down. However the position of the player is still | Which means if i backup to a wall it will allow me to basically be right against it. If I could change the player position to ___ then when I backup against a wall it would stop where my feet are. Left to right movement would probably be the same as it is now. Forward backwards would be a little different. I tried changing the VHullMin / Max for my prone but that does not produce the results which I am looking for. I have been messing with this now for 2 days, although the going prone / changing the camera view works good, I wanted to change the player position from | too ___ also, so it will match the model. Hope that makes sense. r00t 3:16 CQC Gaming www.cqc-gaming.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player animation ?
Thank you both for finally replying to this specific question-- there
have been two threads (that I know of previously) that dealt with this
same issue. =)
On Tue, 11 Jan 2005 14:21:05 -0800, Adrian Finol
<[EMAIL PROTECTED]> wrote:
> Actually, it looks like he's not loading the HL2DM models but the HL2
> ones. In HL2DM Humans and Combine share the same animations.
>
> Make sure you are loading from the right *_animations.mdl animation
> files. Both set of models should have the same animation and activity
> names.
>
> Other than that Major Boone speaks the truth. Using the Weapon's
> activity translation table is the cleanest way to handle different
> animations per weapon.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Matt Boone
> Sent: Tuesday, January 11, 2005 2:05 PM
> To: hlcoders@list.valvesoftware.com
> Subject: RE: [hlcoders] Player animation ?
>
> HL2DM player animation uses a different system than is in the sdk.
> Basically you have a list of base sequences, preblended with 9-way aims
> and 9-way runs - those are the aim animations and are called in game
> code via activities ( why you see different animation names in combine
> vs rebels ).
>
> Shooting is done by adding the fire animation as a gesture over top of
> the base sequence.
>
> For Dod we're doing a hybird, with the activities on base sequence and
> fire/reload/hand signal gestures over top, but non-networked like the
> sdk does it to reduce net traffic.
>
> I would recommend moving at least to using activities for your player
> animations so avoid all the nasty string construction and comparing.
>
> As far as your animations only playing the first and last frame, this
> function doesn't appear to be causing that. I would check with a a
> different model/sequence to see if it's a problem in your model.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Patrick
> Flanagan
> Sent: Tuesday, January 11, 2005 11:33 AM
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] Player animation ?
>
> I'm trying to get player animation working with some non-CS models.
> Specifically, I'd like to get animations working with the models used in
> HL2DM. I used model viewer to load up the combine models from HL2DM and
> some of the resistance models from HL2DM.
>
> Not only are their animations totally different from CS, they're
> different from each other. The combine models have different animations
> than the resistance models. I've been working on converting the
> animation names in sdk_playeranimstate.cpp to call the animations in
> combine_solder.mdl, which I think is the one used in HL2DM.
>
> I've run into some problems with this though.
>
> First off, there's doesn't seem to be any walking or running shooting
> animations. There are animations like ShootSGs, ShootSGc, ShootSMG1s,
> ShootSMG1c, etc but there's no walk_upper_mp5 or run_upper_mp5 like in
> the CS models. There doesn't seem to be any animation to be running and
> shooting at the same time.
>
> Second, the animations seem to only play the first frame and then stop.
> For example, I changed CalcFireLayerSequence to look like this:
>
> int CSDKPlayerAnimState::CalcFireLayerSequence(PlayerAnimEvent_t event)
> {
> // Figure out the weapon suffix.
> CWeaponSDKBase *pWeapon = m_pHelpers->SDKAnim_GetActiveWeapon();
> if ( !pWeapon )
> return 0;
>
> const char *pSuffix = GetWeaponSuffix();
> if ( !pSuffix )
> return 0;
>
> // Don't rely on their weapon here because the player has
> usually switched to their
> // pistol or rifle by the time the PLAYERANIMEVENT_THROW_GRENADE
> message gets to the client.
> if ( event == PLAYERANIMEVENT_THROW_GRENADE )
> {
> pSuffix = "Gren";
> }
>
> switch ( GetCurrentMainSequenceActivity() )
> {
> case ACT_PLAYER_RUN_FIRE:
> case ACT_RUN:
> //return CalcSequenceIndex( "%s%s",
> DEFAULT_FIRE_RUN_NAME, pSuffix );
> return CalcSequenceIndex( "ShootSMG1s" );
> //FIXME: totally wrong
>
> case ACT_PLAYER_WALK_FIRE:
> case ACT_WALK:
> //return CalcSequenceIndex( "%s%s",
> DEFAULT_FIRE_WALK_NAME, pSuffix );
> return CalcSequenceIndex( "ShootSMG1s" );
> //FIXME: totally wrong
>
> case ACT_PLAYER_CROUCH_FIRE:
> case ACT_CROUCHIDLE:
> return CalcSequenceIndex( "%s%s",
> DEFAULT_FIRE_CROUCH_NAME, pSuffix );
>
> case ACT_PLAYER_CROUCH_WALK_FIRE:
> case ACT_RUN_CROUCH:
> return CalcSequenceIndex( "%s%s",
> DEFAULT_FIRE_CROUCH_WALK_NAME, pSuffix );
>
> default:
> case ACT_PLAYER_IDLE_FIRE:
> //return Cal
RE: [hlcoders] filesystem_steam.dll
Thats pretty good going, only in the new place 4 days and already your taking whole afternoons to write personal code :) Get me a job there ! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Scott McNaught Sent: 13 January 2005 08:43 To: hlcoders@list.valvesoftware.com Subject: [hlcoders] filesystem_steam.dll Hi guys, I started a full time job at the start of this week, so I havent been doing anything since the last steam update... I went to do some modding this afternoon and got this error: Can't load c:\games\\half-life2\bin\filesystem_steam.dll I have copied the steam\bin dll to half-life2\bin and this didnt help either. Heres my launch params: "C:\Games\Half-Life\steam\SteamApps\fragmented\half-life 2\hl2.exe" -steam -game "C:\Games\Half-Life\steam\SteamApps\SourceMods\hlrally" -dev -sw -width 800 -allowdebug +map construction_test +sv_lan 1 +maxplayers 8 +mat_picmip 3 -dti This has only happened since the last update - whats going on? Scott ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders *** This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods. Please note that e-mail communications may be monitored. The registered office of Littlewoods Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods Limited is 262152. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] filesystem_steam.dll
try to run the game once from the steam menu before debugging it. On Thu, 13 Jan 2005 18:42:51 +1000, Scott McNaught <[EMAIL PROTECTED]> wrote: > Hi guys, > > I started a full time job at the start of this week, so I havent been doing > anything since the last steam update... > I went to do some modding this afternoon and got this error: > > Can't load c:\games\\half-life2\bin\filesystem_steam.dll > > I have copied the steam\bin dll to half-life2\bin and this didnt help > either. > > Heres my launch params: > > "C:\Games\Half-Life\steam\SteamApps\fragmented\half-life > 2\hl2.exe" -steam -game > "C:\Games\Half-Life\steam\SteamApps\SourceMods\hlrally" -dev -sw -width > 800 -allowdebug +map construction_test +sv_lan 1 +maxplayers 8 +mat_picmip > 3 -dti > > This has only happened since the last update - whats going on? > > Scott > > ___ > 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] External ballistics
Sorry for the late reply. Windows decided to die on me. The people mainly concerned with this want full realism, IE, time of flight. I suggested not using tracelines for impact determination. As I concluded, it'd probably be better to simulate drop by using re-purposed grenade launcher code (just speed up the amount of force the projectile comes out, change the model, etc.) On Mon, 10 Jan 2005 12:33:46 -0800, David Byttow <[EMAIL PROTECTED]> wrote: > The problem is that these are line traces, not fast moving bullets. > > So, the best way I can see is to precalculate the target and then move > the object down based on gravity. > > When a bullet is fired, you can line trace to see what it hits, then, > you can easily determine (based on time) how far down gravity would > have taken it. If you are just concerned with showing "hit fx" at this > location so that if the player is shooting at a wall far away it is > shown accurately, then just use this position and end it. However, if > you are concerned w/ actual accuracy where this "gravity" would > actually cause the gun to "miss" a target far away (which I really > don't see a need for), then you need to do a bit more. Using this "new > position" then do *another* line trace from the muzzle to it. If it > hits the same object, you're done, if not, find a new position and > repeat until it hits the same object after adjusting the position. > Does this make sense? I think that's as good as you're going to get > and should work well w/out any conceivable inaccuracy. > > > On Sun, 9 Jan 2005 13:36:03 -0800, Andrew Foss <[EMAIL PROTECTED]> wrote: > > Okay, when a bullet leaves a gun, it doesn't fly in a straight line, > > it drops at 9.8m/s^2. You can, if you fire a gun over a level > > surface, with the barrel parallel to the ground, drop a bullet at the > > same height as the muzzle, and the two bullets will impact the ground > > at the same time. > > > > Now, every shooter knows this, and will "zero" their sights at a > > certain range. If you zero your sights at 100 yards, your bullet will > > hit the exact spot you aimed at (not considering crosswind, and other > > factors.) at 100 yards. Your sights could also be correct for another > > solution at a closer range (5-10 yards) Consider: when you shoot, the > > bullet follows a very shalow parabola in path. when your sights are > > zeroed, you cut a line through the parabola. there are 2 solutions > > where that line intersects the parabola. Your sights aren't right on > > the path of the bullet, and this is why you have to zero them. > > > > http://chrony.ca/tgraph.gif is an example of .222 remington's > > ballistic path. Take that image and add a line that slopes from 5 > > pixels above (0, 0) and intersects the point at 200 yards. anything > > above that line is shooting high, anything below that is shooting low, > > and if the points intersect, you have a zero at that range. > > > > That is with a sight zeroed at 200 yards. If you re-zero your sight to > > 250 yards, the bullet will hit higher on a 200 yard target. (to get > > more distance, you have to angle the barrel higher) this has the > > effect of changing the angle of your sights in relation to the barrel. > > While the actual difference isn't as extreme as the above makes it out > > to be, it's not trivial. > > > > (I strongly suggest everyone wanting to implement ballistics should > > download the demo copy of Ballistic Explorer or another such program. > > it has data for all sorts of common and uncommon calibers.) > > > > points I overed in my previous post: I'll touch on them briefly. > > Minute of angle: MOA is usually a cone, where 1 MOA is a 1 inch > > diameter cone, 100 yards long, with the point originating in the > > barrel of the weapon. > > > > You probably won't have to worry too badly about perfection in your > > calculations. If you can do them quickly but less accurately, or just > > use regular physics and forget the concept of traceline-based bullets. > > It looks like suicidecommando is doing/has done this, so it's do-able. > > you might want to keep an eye on calculation load and check accuracy > > against known real life data, I have no clue how Source would handle > > something moving ingame at a few thousand feet per second. > > > > ___ > > 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] filesystem_steam.dll
Hi guys, I started a full time job at the start of this week, so I havent been doing anything since the last steam update... I went to do some modding this afternoon and got this error: Can't load c:\games\\half-life2\bin\filesystem_steam.dll I have copied the steam\bin dll to half-life2\bin and this didnt help either. Heres my launch params: "C:\Games\Half-Life\steam\SteamApps\fragmented\half-life 2\hl2.exe" -steam -game "C:\Games\Half-Life\steam\SteamApps\SourceMods\hlrally" -dev -sw -width 800 -allowdebug +map construction_test +sv_lan 1 +maxplayers 8 +mat_picmip 3 -dti This has only happened since the last update - whats going on? Scott ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
