As far as i know, this developer problem only happens in single-player mode. So if you
are not making a single-player mod, i wouldn't worry about it.
-av
_Phantom_ wrote:
> from the problems we had with Erads with regarding models from what I can
> tell the server uses the model.mdl for all its' calcs and unless ya tell it
> otherwise the client uses the same model (this played merry hell when we was
> using oversized hulls for the large robots as the hit boxes was all out)
>
> you dont need to precache all the models for that switch using the
> SET_MODEL() stuff you have below as it's a client side thing and doesnt seam
> to need it (well, we dont have anything other than model.mdl and robo.mdl
> being cached server side and we can still use the standard HL model skins
> (zombie etc) and they aint cached anywhere, we was even using robo.mdl
> without precaching it pre-hitbox fix)
>
> Anyways, as far as I can tell this is the code setup we have :
>
> CBasePlayer::Spawn(..)
> {
> ...
> // note - player model setup here - change it
> if (m_iPlayerClass == CLASS_ERAD)
> {
> SET_MODEL(ENT(pev), "models/player/robo/robo.mdl");
> }
> else
> {
> SET_MODEL(ENT(pev), "models/player.mdl");
> }
> g_ulModelIndexPlayer = pev->modelindex;
> pev->sequence = LookupActivity( ACT_IDLE );
> ...
> }
> and called from the gamerules playerspawn() function we have the
> EquipPlayer() fucntion which sets the model depending on which class you are
> :
> For Erads :
> g_engfuncs.pfnSetClientKeyValue( pPlayer->entindex(),
> g_engfuncs.pfnGetInfoKeyBuffer( pPlayer->edict() ), "model", "robo" );
> For Humans (depending on class):
> g_engfuncs.pfnSetClientKeyValue( pPlayer->entindex(),
> g_engfuncs.pfnGetInfoKeyBuffer( pPlayer->edict() ), "model", "merc" );
> g_engfuncs.pfnSetClientKeyValue( pPlayer->entindex(),
> g_engfuncs.pfnGetInfoKeyBuffer( pPlayer->edict() ), "model", "zombie" );
> g_engfuncs.pfnSetClientKeyValue( pPlayer->entindex(),
> g_engfuncs.pfnGetInfoKeyBuffer( pPlayer->edict() ), "model", "hgrunt" );
> g_engfuncs.pfnSetClientKeyValue( pPlayer->entindex(),
> g_engfuncs.pfnGetInfoKeyBuffer( pPlayer->edict() ), "model", "hgrunt" );
>
> admitaly I never tried this with either devloper 1 or devloper 0 in place
> (unless -dev does it ;), however this all shows the correct models when the
> player is pushed into third person mode, so if you have basicaly the same
> I'd guess you've goofed something somewhere
>
> ----- Original Message -----
> From: "David Flor" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, May 18, 2002 2:18 AM
> Subject: RE: [hlcoders] Third person player / Developer mode
>
> > But doesn't that assume you set the model yourself with the "SET_MODEL"
> > command, and precache it?
> >
> > What I'm trying to avoid is precaching ALL of our player models, which
> > would mean:
> > 1) Only server-defined player models could be used. This isn't an issue
> > because I restrict the models client-side anyway through model
> > encryption.
> > 2) It would take up 40+Mb of memory for models that it never use.
> >
> > Right now my code does:
> >
> > char *szModel = "paladin"; // For instance...
> > SET_MODEL( ENT(pev), "models/player.mdl" );
> > g_engfuncs.pfnSetClientKeyValue( entindex(),
> > g_engfuncs.pfnGetInfoKeyBuffer( edict() ), "model", szModel );
> >
> > ...but what does that have to do with "developer 0"?
> >
> > For the record, I set a breakpoint inside the client-side rendering code
> > and, sure enough, "model/player.mdl" is the entity being rendered. Is
> > this some safety feature in Half-Life?
> >
> > Tnx & Rgds...
> > David Flor
> > Lead Programmer, "The Opera" - http://opera.redeemedsoft.com/
> >
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
---------
[DRP]Avatar-X
SillyZone Homepage: www.thesillyzone.com
SillyZone Forums: forum.thesillyzone.com
My Homepage: www.cyberwyre.com
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
