Re: [hlcoders] Player animation ?
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 CalcSequenceIndex( "%s%s", > DEFAULT_FIRE_IDLE_NAME, pSuffix ); > return CalcSequenceIndex( "ShootSMG1s" ); > //FIXME: pick the right weapon > } > } > > I've set my player model to be combine_soldier. When I spawn in third > person and watch my player model, if I run along start shooting it looks > like it plays only the first frame or two and then immediately goes back > to idle/jittering. If I'm running, it looks even worse since each time I > fire it looks like it restarts the ShootSMG1animation but there's no > blending between them so it looks all jittery. Has anyone had any luck > getting this to work? > > _______ > 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 > > -- Phil Bowens He who is the greatest of warriors overcomes and subdues himself. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Updated SDK source code? - Incl list of files changed
You would probably benefit more from a form of version control. The method we use is rather simple. We have a subversion repository setup. The first thing imported was the untouched SDK code from the first release. From there, we branched it to a vanilla/ branch. We then do all of our changes on trunk/ (or for you CVSers, HEAD). On this latest release, we simply checked out the vanilla branch, and copied the changed files (well, the entire directory tree) into it. Then committed, and did an svn merge of the vanilla branch back on to trunk/ Well, hmm.. maybe that isn't so simple after all. but the benefits are worth it-- we now have a history of the changes to the vanilla SDK and a good way to merge changes onto our working copies. The only conflicts were the project files when merging from vanilla/ to trunk/ but thanks to Mr Meyers' list of changed files that turned out to be a trivial issue. On Thu, 23 Dec 2004 13:27:15 -0600, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Chris Adams wrote: > > Does anyone have any suggestions for putting these new changes into our > > own code? > > If you have the money to buy Araxis Merge, it does a REALLY good job of > helping you merge 2 (or 3) source code directory trees together. > > Beyond Compare also does a pretty good job of merging 2 source code > trees together. > > Simply extract the new SDK source code out to a temporary directory, and > run the merge between your code and the latest code, pick and choose the > things you want to merge in, and merge them. > > -- > Jeffrey "botman" Broome > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- Phil Bowens He who is the greatest of warriors overcomes and subdues himself. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Animations
This is as far as I have gotten (before getting sidetracked), as well. I posted to this list a couple weeks ago describing this exact problem (there is a screenshot there showing your initial problem before this recent finding .. if you want to dig through your history or the archives). Valve-- is there any timeframe when documentation regarding the animation layers will be posted? If this is a trivial feature, any pointers as to what we're missing? I understand there are more important things than SDK documentation but even a brief insight into what should be attempted would help us a long way. =) On Thu, 16 Dec 2004 17:31:23 -0600, Matthew Lewis <[EMAIL PROTECTED]> wrote: > Just a follow up listing what I've learned. It seems that the problem lies > with the call > to UpdateAimSequenceLayers(). Everything works so long as the upper animation > is doing > the same thing as the lower animation. For example, if the lower activity is > set to > ACT_RUN and the upper sequence is set to 'run_holding_all', then everything > works as > expected. However, if the lower activity is set to ACT_RUN and the upper is > set to > 'shoot_smg1', then the lower animation goes into the ragdoll mode and drags > the legs > across the floor. So it would seem that there is no way to combine a run > animation with > a shoot sequence since the shoot sequence is based on the model standing > still rather > than running. The same goes for trying to play a reload animation while > walking or > running. Is there is way to make the models work like they did in HL1 where > the upper > and lower animations were essentially indepedently settable, or do you just > not play > shoot and reload animations while moving? > > * > Well I tried the suggestions given by the Wavelength site, but as it > turns out, I had already made most of the recommended changes already, > except for blocking the rendering of the viewmodel in third person mode. > > After fighting with the problem some more, I finally got the the upper > body to render the correct animation, but despite my best efforts, the > lower body still refuses to accept the ACT_WALK animation. The lower > body is stuck in the ragdoll mode and just drags the legs and feet > across the floor during movement. I have also tried to brute force an > animation sequence onto the model by altering the "void > CBasePlayerAnimState::ComputeMainSequence()" such that it always selects > ACT_WALK as the ideal activity and selects "run_all" as the > 'animDesired'. It still refuses to accept the lower body animation. I'm > out of ideas. Any thoughts? > ** > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- Phil Bowens He who is the greatest of warriors overcomes and subdues himself. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] HUD, fonts, and everything else not showing up
Most of coding *is* modifying other people's code. Not that I totally agree with waiting for HL2MP source myself, but the way I look at it.. I'd rather use a solid foundation from a team of 15 engineers who have worked with the same codebase for 6 years than invent some shakey system in what little spare time I have. Sure, it's great to go out and do something yourself. How else are you to learn, right? But in the real world, people have jobs, or school, and rarely have as much time to work on a system that Valve does professionally. I seriously doubt that I could pull of something that is better than Valve's implementation with just a 'little' more work. That said-- The SDK isn't as horrible as people make it out to be. At first glance it seems extremely incomplete. But after reviewing it more and more and more, it's actually a very good foundation from with to start a mod from scratch. I recommend anyone who is waiting for hl2mp to go ahead and try working on your mod with the SDK, holding no reservations. You may get futher than you expected in less time than you might think. Just get in there and do it, damnit! ;) On Mon, 13 Dec 2004 18:23:19 -0600, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Or maybe we want to see how people who developed the game would write > > multiplayer code? No, that can't be it. It must be because we're lazy > > bastards. > > Sarcasm? > > Not having an example means you learn more (you learn more from failures > than you do by copying what someone else has done). Also, not having > something you can copy-and-paste from encourages everyone to create > their own unique interface rather than having 100 MODs all using exactly > the same layout and button arrangement (see "Counter-Strike clone" for > examples). :) > > But, yeah, basically coders are lazy and will happily copy what someone > else has done rather than trying to invent the wheel themselves (even if > they could invent a much better wheel with a little bit of extra work). > > -- > Jeffrey "botman" Broome > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- Phil Bowens He who is the greatest of warriors overcomes and subdues himself. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Skyboxes & Shaders
Thanks! I've gotten it to work reasonably well, using your suggestion. The only problem I have with it is stylistic-- my goal was to leave the base as untouched as possible, but unfortunately I had to hack up ClientData_Update() a lot since that's where it seems the switch will 'stick.' Also, there are a few scenarios I can think of where it may work unexpectedly (Like a player is in a very large area with one sky_point, but gets close to another, smaller area, with a sky_point that is closer to him, so the sky changes even when its not supposed to. This can be avoided with either an entity brush defining a volume for the skybox OR just having your mappers aware of this so they design accordingly). Have you looked into changing the actual skybox material? It's my impression that this is strictly an engine thing, but, as always, there might be a way On Sun, 12 Dec 2004 17:24:53 +1000, Teddy <[EMAIL PROTECTED]> wrote: > You'll need to create an point entity that you put in each area of the > map with a skybox, then add a think function to the player that checks > which point you're closest too and sets the m_skybox3d accordingly. > Worked for me! > > > > > On Sun, 12 Dec 2004 01:00:54 -0500, Phil Bowens <[EMAIL PROTECTED]> wrote: > > [ I sent an email earlier about player models with no responses-- I > > suppose most of you are waiting for hl2mp src (if it does arrive) to > > sort this out. I've made some progress but its been put on the > > backburner to make room for other tests. Anyhow, hopefully I'll have > > better luck with this next subject ] > > > > Before the SDK was released I read somewhere that it's 'possible' to > > have multiple skyboxes. I see that the framework is in the SDK, but I > > have some questions.. :) > > > > In Sky_Camera.cpp there is a 'global' sky_camera list, but I'm not > > sure how to tell the engine which sky_camera to use. Does anyone have > > any suggestions on the best way to implement it? I have a few ideas > > bouncing around in my head (like making a sky_area brush entity that a > > sky_camera would refer to) but none seem good enough. > > > > Even though one may be able to tweak the game to have more than one > > skybox by defining more than one sky_camera and link it to certain > > areas, it still seems like there is a limitation for only one material > > set for the toolsskybox material itself, which is set in the world > > entity. I noticed in world.cpp that the 'skyname' field for the world > > entity is only used to set the sv_skyname parameter (I'm guessing for > > debugging/testing/etc).. This leads me to infer that the engine sets > > what materials to use for skybox rendering BEFORE the game gets to > > read the world ent... Am I mistaken? Any way to tell the engine to > > load a different materialset for the skybox during a game-in-progress? > > A cursory review of the client engine interface didn't turn up any > > results. > > > > So, this all led to a suggestion from the art team that perhaps a VMT > > may be able to define multiple textures in the skybox material shader > > scripts, which in turn the game code can reference. Unfortunately, I > > also see that the documentation is a little sketchy about all the > > different shader properties.. is there a list anywhere explaining all > > the properties for things like "Cloud" or "lightmappedgeneric" ? Is it > > possible to define custom shader script directives, or is this > > strictly an engine thing? > > > > > > > > Thanks > > > > -- > > Phil Bowens > > > > He is the greatest of warriors who overcomes and subdues himself. > > > > ___ > > 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 > > -- Phil Bowens He who is the greatest of warriors overcomes and subdues himself. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Skyboxes & Shaders
[ I sent an email earlier about player models with no responses-- I suppose most of you are waiting for hl2mp src (if it does arrive) to sort this out. I've made some progress but its been put on the backburner to make room for other tests. Anyhow, hopefully I'll have better luck with this next subject ] Before the SDK was released I read somewhere that it's 'possible' to have multiple skyboxes. I see that the framework is in the SDK, but I have some questions.. :) In Sky_Camera.cpp there is a 'global' sky_camera list, but I'm not sure how to tell the engine which sky_camera to use. Does anyone have any suggestions on the best way to implement it? I have a few ideas bouncing around in my head (like making a sky_area brush entity that a sky_camera would refer to) but none seem good enough. Even though one may be able to tweak the game to have more than one skybox by defining more than one sky_camera and link it to certain areas, it still seems like there is a limitation for only one material set for the toolsskybox material itself, which is set in the world entity. I noticed in world.cpp that the 'skyname' field for the world entity is only used to set the sv_skyname parameter (I'm guessing for debugging/testing/etc).. This leads me to infer that the engine sets what materials to use for skybox rendering BEFORE the game gets to read the world ent... Am I mistaken? Any way to tell the engine to load a different materialset for the skybox during a game-in-progress? A cursory review of the client engine interface didn't turn up any results. So, this all led to a suggestion from the art team that perhaps a VMT may be able to define multiple textures in the skybox material shader scripts, which in turn the game code can reference. Unfortunately, I also see that the documentation is a little sketchy about all the different shader properties.. is there a list anywhere explaining all the properties for things like "Cloud" or "lightmappedgeneric" ? Is it possible to define custom shader script directives, or is this strictly an engine thing? Thanks -- Phil Bowens He is the greatest of warriors who overcomes and subdues himself. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Player models
Has anyone here been playing with player models in the Source SDK? I've been experimenting with integrating the combine_soldier.mdl for testing purposes. I've decided to use the one from HL2, not HL2DM (the only difference is the animation set, it seems). Unfortunately, when specifying what animations to play, it seems like the game ignores the animation layers... I suppose a screenshot would best explain this (w/ cl_showanimstate & thirdperson enabled): http://andromeda.moonside.org/hlcoders/combine_ss.png If you carefully look at the stats on the right, while the player is running two animations are defined on their respective layers... Idle_Unarmed & RunALL. Yet, the 'main' sequence is still ragdoll. Am I missing something major here? I only have a limited understanding of the animation layers, but enough to believe I really don't need to touch the underlying workings for a change this 'simple.' Unfortunately the SDK docs and most websites haven't covered animations yet.. I come from a Quake2 modding background, so please be nice if I'm just totally ignorant of something. =) Thanks in advance. -- Phil Bowens He is the greatest of warriors who overcomes and subdues himself. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
