I've not had the same problem with GetClassPtr...but I have noticed
the same problem when stepping through code...
The mod runs fine, but if I try to step through code, everything is
haywire...the stack trace is nonsense (function above has no reference
to the function I'm in), this pointers changing their value as I step
through a member function, memeber variables treated as out of scope.
Basically, really insane stuff...but the code is actually executing
fine...I can see the effects on screen. Basically it means I can't
step through the code at all...
All the latest service packs, etc. Very odd...
[ Cruise / www.casual-tempest.net ]
----
> Further troubles... I tried making this a non-static function, but that
> didn't work either. But here's the REALLY weird part. I was stepping
> through the new function in the debugger:
> CSprite* CStreetlamp::MakeSprite( const char* pSpriteName, const Vector
> &origin, BOOL animate )
> {
> CSprite* pSprite = GetClassPtr( (CSprite *)NULL );
> pSprite->SpriteInit( pSpriteName, origin );
> pSprite->pev->classname = MAKE_STRING("env_sprite");
> pSprite->pev->solid = SOLID_NOT;
> pSprite->pev->movetype = MOVETYPE_NOCLIP;
> if ( animate )
> pSprite->TurnOn();
> return pSprite;
> }
> It has the exact same error as before. However, I noticed that as I step
> through the function that the value of this, i.e., the street lamp,
> changes three times. First it goes to some seemingly random memory
> location, then it changes to 1, then it goes back to its regular
> location. Is that CRAZY or what?
> Upon further inspection, I found that in addition to this calamity, the
> Keyvalue function for the entity is not being called at all. This, too,
> seems a bit odd. My suspicion was that somehow the game is stumbling
> over some of the fgd files and somehow, some way, that's messing up the
> files.
> However, I then dropped into the disassembler to check what the assembly
> had to say about it, and learned to my shock that CSprite* pSprite =
> GetClassPtr( (CSprite *)NULL ); has absolutely no assembly counterpart.
> In other words, the compiler is somehow skipping right the f**k over it.
> I have absolutely no clue. I'm going to try recompiling all the maps and
> the models involved in the hopes that somehow this will fix itself. Is
> there anyone who's had a similar problem with GetClassPtr? The rest of
> them seem to be compiling so I can't imagine it's a problem with the
> template implementation, but the problems like KeyValue suggest to me
> that it's a run-time problem of some sort, because the fact that
> GetClassPtr didn't compile shouldn't do anything to KeyValue...
> Persuter
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:hlcoders-
>> [EMAIL PROTECTED]] On Behalf Of Persuter
>> Sent: Monday, April 22, 2002 6:42 PM
>> To: [EMAIL PROTECTED]
>> Subject: [hlcoders] Sprite problems
>>
>> Hey all, having a bit of a problem here:
>>
>> CSprite *CSprite::SpriteCreate( const char *pSpriteName, const Vector
>> &origin, BOOL animate )
>> {
>> CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This line
>> pSprite->SpriteInit( pSpriteName, origin );
>> pSprite->pev->classname = MAKE_STRING("env_sprite");
>> pSprite->pev->solid = SOLID_NOT;
>> pSprite->pev->movetype = MOVETYPE_NOCLIP;
>> if ( animate )
>> pSprite->TurnOn();
>>
>> return pSprite;
>> }
>>
>> For some reason, when I execute the following code with
>> "sprites/glow01.spr", multiple times, the indicated line doesn't
> execute
>> at all except for one instance, the last that is tried. When I use the
>> debugger, it completely steps over the line, even when I try to step
>> into GetClassPtr. It's like the line doesn't exist... I try pleading
>> with the debugger, pointing at the line very insistently and so forth,
>> but to no avail.
>>
>> Anyway, so it doesn't execute the line, which means that pSprite does
>> not exist. This does not trouble the program, however, which happily
>> goes along executing the rest of the code, even while the debugger
> shows
>> that pSprite doesn't exist. If I step into the function and check the
>> value of this, I find that indeed it DOES have an address. But that
>> address is never returned, and the program proceeds as if nothing had
>> been returned from the function at all! It doesn't even throw errors.
>> It's very odd.
>>
>> Any ideas?
>>
>> Persuter
>>
>>
>> _________________________________________________________
>> Do You Yahoo!?
>> Get your free @yahoo.com address at http://mail.yahoo.com
>>
>> _______________________________________________
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.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
