To update: I sent out the latest fgd and they sent back a map that works. The maps they send Persuter on a whim no workyworky, although they tell me to fix the problems. :)
However, KeyValue still isn't being called and the GetClassPtr function is still being skipped over. So it was a map problem masquerading as a code problem. Oh that tricky MSVC!!! :) I suppose I'll just let it go on doing that, although I suspect when the keyvalue data actually becomes important I'll have to look into it. Ah well. Thanks all. Persuter --- Persuter <[EMAIL PROTECTED]> wrote: > 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 === message truncated === ===== [EMAIL PROTECTED] "Humanity I love you for when you're hard up you pawn your intelligence for a drink" -e.e. cummings __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
