Lol, oh great. So now not only do I have a major problem, MSVC has decided not to tell me what it is. :) Well, I knew that it was somehow screwed up (since this pointers really oughtn't to change) but I was hoping it was the code. Siiiigh...
OK, well then has anyone else had a problem with sprites refusing to attach themselves to multiple entities? I've got a streetlamp entity that I want to have a glow sprite on (I'm lighting the area around it with dlighting, but I want a glow sprite on the lamp itself). I call MakeSprite in the spawn function and use SetAttachment and SetTransparency to attach it to the lamp. At first, they would all attach to one particular lamp. Now they don't seem to do that, they just don't attach to any lamp. (Or possibly they are still attached to that lamp but aren't displayed, or don't do the same washing out as it did before when they all displayed.) I'm not sure why they attach to the lamp that they do. Persuter > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Cruise > Sent: Wednesday, April 24, 2002 12:25 PM > To: Persuter > Subject: Re[2]: [hlcoders] Sprite problems > > 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 _________________________________________________________ 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
