Re: [hlcoders] [hlcoders]
Might actually want to do:
CBaseEntity *pEnt = CBasePlayer::Instance(pevAttacker);
if( pEnt->IsPlayer() )
{
CBasePlayer *pPlayer = (CBasePlayer*)pEnt;
pPlayer->m_Money += m_MonsterMoneyValue;
}
Just to be extra careful...
>Or (CBasePlayer *)GetClassPtr(pevAttacker);
>
>>Might want to try (CBasePlayer*)(CBasePlayer::Instance( pevAttacker
>>)) instead.
>>
>>>
>>>CBasePlayer *pPlayer = GetClassPtr((CBasePlayer *)pevAttacker);
>>>// is it a player (and not a grenade, hornet, rocket, etc.)?
>>>if (pPlayer->IsPlayer()) { pPlayer->m_Money += m_MosterMoneyValue;
>>>}
[ cruise / casual-tempest.net / transference.org ]
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: [hlcoders] RE: [hlcoders] Valve´s programmers need more sleep?
>Heh, I didn't know it was a vec... oops. I thought it was just a z value for >a vector. I guess I'm off I was just thinking along the lines of >"anything times zero = zero" > >-Mazor > So just set it to g_vecZero instead... :P [ cruise / casual-tempest.net / transference.org ] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Question about decreasing clipping rectangle
>>Halflife has no sprites for either health OR armor. They used >>numbers for >both. >> >>You may be however, thinking of the flashlight perhaps? Because >>that is precisely what was done for the flashlight's battery >>status. > > >There is a suit icon, filling and unfilling as health (maybe only >armor?) goes up and down... Yeah, I meant the armour :P It's just been a long time since I played the original HL, rather than never :P ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Question about decreasing clipping rectangle
>am >wondering if the wise all experienced members of this list could enlighten >me on their opinion of which one to use, or >another method at all. Isn't this exactly what the original health HUD did? The "full" healthsprite is shown over the top of the "empty" sprite, and progressively draw less of the "full" sprite as you loose health. Can't you just change the sprites in that code? [ cruise / casual-tempest.net / transference.org ] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] Particle System
> > > discussed, I believe, was mine, which is available for any mod that >> > > wants it. It is currently being used in Quest, Hostile Intent, and >> > > something by C4 Software. >> > > >> > > Persuter >> > > >> > > > -Original Message- >> > > > From: [EMAIL PROTECTED] [mailto:hlcoders- >> > > > [EMAIL PROTECTED]] On Behalf Of Yacketta, Ronald >> > > > Sent: Tuesday, June 25, 2002 9:25 PM >> > > > To: [EMAIL PROTECTED] >> > > > Subject: [hlcoders] Particle System >> > > > >> > > > Folks, >> > > > >> > > > I recall a recent conversation regarding the use / tutorial etc >> > > someone >> > > > had of a particle system for HL. I went searching my .pst's and >> > > > could not find a reference nor in the HL archives. >> > > > >> > > > Might someone know of a POC (Point Of Contact) for the particle >> > > > system >> > > >> > > > that was discussed? >> > > > >> > > > Regards, >> > > > Ron >> > > > ___ >> > > > 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 >> > > >> > > >> > >> > ___ >> > 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 >> >> > ___ > 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 [ cruise / www.casual-tempest.net / www.transference.org ] -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPRw2oPdi0Z5STRufAQG+SQP/egXiIQ7e/u93L0i1j1Wysu6SSC15wWOV 1FeTfJVf29b8P0XX3cKtCVH5dQeu6BdeMzJTA1saOGdZ6htaJKiklWi4b/mOCKVS 0J6t7xad7UDfdbyg6rDois3kHJIBFAIC/8P0IHcuH0PGnu+zy3GyLYKl1DgGmY8Z rCS5b0sOSPY= =PfN/ -END PGP SIGNATURE- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Fwd: Half-life fake players bug
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 This went out on BugTraq earlier...figured people here might be interested... I have the attachment he mentions in the mail (won't be allowed on this list), so if anyone wants it, let me know. [ cruise / www.casual-tempest.net / www.transference.org ] - ## Application: Half-life (and all the mods that run on it) Version: All the versions (1.1.0.9 vulnerable too) Bug: Wrong management of the players in multiplayer game Risk:The multiplayer server can be filled with fake players, so nobody can play in that server. Author: Auriemma Luigi (e-mail: bugtest at sitoverde.com) ## 1) Introduction 2) Bug 3) The Code 4) Fix 5) Philosophy - --- 1) Introduction This bug has been showed to Valve and the support of Sierra at the following mail addresses over 1 month ago: [EMAIL PROTECTED] and [EMAIL PROTECTED] Unfortunally nobody has answer to my mails (2 mails to Valve), but I have decided to publish this all the same so if Valve don't release patch somebody else can try to solve the problem... - --- 2) Bug The protocol of Half-life multiplayer server is simple, and I have seen that it is really similar to the Quake3 protocol, but this last is compressed or ciphred. However the handshake beetween the client and the server (default port 27015) is the following: - - the client send an UDP datagram to the server with the a challenge request. The request is: "\xff\xff\xff\xffgetchallenge\n" - - the server send the key of the current challenge to the client. This key change when Halflife start. (a little strange thing is that the key sended by the server is an unsigned int but the client read it as an int (???)) - - the client now have the key so for complete the handshake it send the connection request: "connect %protocol %challenge_key %cd_key %player_info" %protocol can be get by querying the server with an info request but it is not useful, the %challenge_key was get, the %cd_key is a key generated with the cd key inserted during the installation. With a same %cd_key, in the same server can play max 4 players, so we use a key filled with random chars and we can insert infinite player from the same IP. EACH PLAYER MUST HAVE AN UDP SOURCE PORT DIFFERENT!!! %player_info is a set of not important options to send to the server for give info about the new player. - - now the handshake is finished and for the server a new player is entered, but it is WRONG!!! Now the server answer with an acknowledgement, where we can see our IP and our port. If the server have reached the maximum number of players, it will answer with "Server Full", and if the challenge_key that we have sended to it is wrong, it will answer with "Bad Challenge". Naturally exist a timeout for the players connected to the server and it is 60 seconds (default). So every 60 secs (or less) the attacker can "create" new players so the server will be filled forever and the real players that want to play in it will receive a "Server full" message. The server admin can only see that the maximum number of players is reached, but when he watch the names of the players in his server, he found nobody! - --- 3) The Code I have attached a proof-of-concept of the attack that run on Linux and Win. Other detailed info about the attack can be found in the code. The UDP packets are not spoofeds but we can control the real situation on the server, because it send to us messages as "Server full" and "Bad challenge" if the key as changed (this key change every time that Half-Life is started). A spoofed version of the code is possible but, as I have explained before, we cannot control if the server is up, if the maximum number of players has been reached, if the key is changed, and others. I have also attached an utility for see info about the Half-life servers only for fun. - --- 4) Fix No official fix available. A possible fix is to set a password, so only if someone know it can attack the server, because if the attacker don't know the password, the server will answer with "BADPASSWORD". - --- 5) Philosophy It's not rigth to post an advisory if there are not patches or tricks to fix the bug, but I think that this is a good method to show the problem to the community. Then the Valve team don't have answer to me and I hope that this advisory can get their attention. I'm really hopeful about the full disclosure, because with that "everyone" can know the real effects of an attack, the real danger of a bug, someone can learn a bit of programming (I have learn a bit of C from the source code of some exploits) and it's useful for all the people that are hopef
Re[2]: [hlcoders] string to #define
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
Damnit...I sat and looked at the '#' operator for ages trying to make
it do this, and couldn't see how...I can't believe I missed something
that easy :/
/me wanders off to a corner and sulks...
> Hey Mugsy:
> Did you ever figure this out? I was browsing the comp.lang.c newsgroup FAQ
> (ok, somebody needs a life :P), and found this:
> Question 11.17
> I'm trying to use the ANSI ``stringizing'' preprocessing operator `#' to
> insert the value of a symbolic constant into a message, but it keeps
> stringizing the macro's name rather than its value.
> -
> You can use something like the following two-step procedure to force a macro
> to be expanded as well as stringized:
> #define Str(x) #x
> #define Xstr(x) Str(x)
> #define OP plus
> char *opname = Xstr(OP);
> This code sets opname to "plus" rather than "OP".
> An equivalent circumlocution is necessary with the token-pasting operator ##
> when the values (rather than the names) of two macros are to be
> concatenated.
> References: ANSI Sec. 3.8.3.2, Sec. 3.8.3.5 example
> ISO Sec. 6.8.3.2, Sec. 6.8.3.5
> http://www.eskimo.com/~scs/C-faq/q11.17.html
> I think you were trying to get the preprocessor to expand and then
> 'stringize' your #define'd constant, passing it's value as the arg to your
> func, which is what that code appears to do.
> Pat 'sluggo' Magnan
> Tour of Duty Mod
> http://www.tourofdutymod.com
> - Original Message -
> From: "Mugsy _" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, May 07, 2002 2:29 AM
> Subject: Re: [hlcoders] string to #define
>> > > > > > > > The pre-processors scan through source files replacing the
>> >define
>> > > >with
>> > > > > > > > the value.
>> > > > > > > >
>> > > > > > > > I'm not 100% sure, but about 95% that it looks in strings as
>> >well,
>> > > >so
>> > > > > > > >
>> > > > > > > > someFuncThatTakesAString("WEAPON_GARAND");
>> > > > > > > >
>> > > > > > > > will get changed to
>> > > > > > > >
>> > > > > > > > someFuncThatTakesAString("2"); file://constant string 2\0
>> > > > > > > >
>> > > > > > > > before its compiled.
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
[ cruise / www.casual-tempest.net / www.transference.org ]
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAPPX6/vdi0Z5STRufAQFqHAP/Y3BnObU5BR7taTHDTM4Nyl/q1yPwKI0P
b/L71FxQcnIUFDjzqhw0qk6vq5y0Nq32ohKRTLe5HDdZmkXnAZh8P/VdbVCOC/gc
6PiqnjQ68PsQgJ20FJglEuS8dMXdQ3nBF5UksnGbpXKByMQJxgWemmVuwvnvByCB
WD7ehi8puDM=
=56uC
-END PGP SIGNATURE-
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Blocking Entity Access Trhough World Geometry
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 Simplest way is to use a traceline...if the entity cannot 'see' the activator, don't let it be activated > -- > [ Picked text/plain from multipart/alternative ] > Bare in mind I have a limited grasp of the HL engine so this may be quite simple an >I'm just oblivious. > Anyhow, as you all may (or may not) know, entites can be used through world >geometry. For example, you have a wall mounted health recharger and you as long as >the wall is not too thick and you can > go around back of it, you can use the health charger, through the wall. My goal >here is to simply know how to keep the user from being able to use entities through a >wall. > > Lakario > ModDev.netGet more from the Web. FREE MSN Explorer download : >http://explorer.msn.com > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders [ cruise / www.casual-tempest.net / www.transference.org ] -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPPIasPdi0Z5STRufAQGejgP/eG5d1UcbEI/pEKhp3sXXfnQ+gaeL//GM Y67ljrsjtZsl9sv9zVL4MT8pUm6FcLXf6gmwuHavD9zETcZCfm5QZW97c3CNXtd1 0sjtG1yEFkMQGkognLfWTaxTUOBx13LHEGiEsJ0uNP5qLSOXNVcEXDjYD2UnT12V MQrtCbW2TKw= =YWzu -END PGP SIGNATURE- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] string to #define
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 As someone already said (but was ignored), there's built in string table functions within the HL SDK. MAKE_STRING( "somestring" ) returns an int, and then STRING( returned_int) gives you the string back. If you're dealing with string pointers rather than string constants, use ALLOC_STRING( pszStringPointer ) At initialisation, build an array of the variables/defines you want to be able to convert, and map it to the values. So instead of having a string->int mapping, build your own int->int mapping. Basically, you're making a hash table. Then, when you read in a string, run it through MAKE_STRING/ALLOC_STRING and look up the value associated with the result. It's the only way I can see of doing this...there are defines for turning text into a string, but none for the other way, I'm afraid. [ Cruise / www.casual-tempest.net ] -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPNe+Xvdi0Z5STRufAQHQ0AP/TT/OKXnN0CRnV0HytPwVZNlNzJq4/Vth 1VFsUh+P8vIkNhqg8vrz8orgg7mLUrD+o++go/w6d0EFw+iu0ZrZ4LR01UBGlsNb k0u0MRj/WZYFHCDogzgofLibJJsiKJJNpzFz9kAGaUztgGwbN+YHahL90nqgqchK ILG4NM4xQkg= =qv19 -END PGP SIGNATURE- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] UTIL_ScreenFadeAll
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 I used the VGUI :P Just a Class that literally draws a VGUI Panel across the full screen and then you can play with the opacity and colour and speed of effects to your hearts content... Just a thought... > Hm, I needed just one line for that effect: > UTIL_ScreenFadeAll(Vector(255, 255, 255), 0.8, 1.0, 255, 0); > This will fade the screen to white and back. > - Original Message - > From: "Cortex" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, April 30, 2002 11:43 AM > Subject: Re: [hlcoders] UTIL_ScreenFadeAll >> mmmhhh... Thx for the tip, but it doesn't as good as I expect :( >> Indeed, I wanted to fade really the screen... With your method, the screen >> is instantaneous "blacked out" (I've tried to change the duration value, > but >> in vain :( ). >> >> Am I the only one to have this problem ?? >> >> - Cortex : mapper & coder www.hlalbator.fr.st >> >> - Original Message - >> From: "Mike Blowers" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> Sent: Tuesday, April 30, 2002 10:55 AM >> Subject: Re: [hlcoders] UTIL_ScreenFadeAll >> >> >> > I've previously done a similar thing... Here's the 2 lines of code I > used: >> > >> > //Turn on >> > UTIL_ScreenFade( m_pPlayer, Vector(50,50,50), 0, 5, 200, FFADE_STAYOUT); >> > >> > //Turn off >> > UTIL_ScreenFade( m_pPlayer, Vector(50,50,50), 0, 1, 200, FFADE_OUT); >> > >> > I think you'll find the problem is you are using FFADE_IN to remove the >> > STAYOUT effect, which won't work... you need FFADE_OUT. >> > >> > Mike. >> > - Original Message - >> > From: "Cortex" <[EMAIL PROTECTED]> >> > To: <[EMAIL PROTECTED]> >> > Sent: Tuesday, April 30, 2002 7:34 AM >> > Subject: [hlcoders] UTIL_ScreenFadeAll >> > >> > >> > > Hello, >> > > >> > > I'm having trouble with this function :( >> > > I wanted to fade the screen juste before a round ends. So, I put this > on >> > the >> > > right place : >> > > >> > > UTIL_ScreenFadeAll ( Vector(0,0,0), 3, 1, 255, FFADE_OUT | >> > FFADE_STAYOUT ); >> > > >> > > But, I want that the screen returns to his normal state ! So, I put > this >> > in >> > > an other function : >> > > >> > > UTIL_ScreenFadeAll ( Vector(0,0,0), 3, 1, 255, FFADE_IN ); >> > > >> > > The problem I have is that the FFADE_IN effect doesn't work... If > I >> > set >> > > it a green color (for test purpose only :) ), the green stays all the >> time >> > > at the screen (so, it does the same with the black). It's really >> annoying >> > > for gameplay LOL >> > > >> > > It must be a big error from me but I can't figure it me out :( Does >> anyone >> > > see it >> > > >> > > - Cortex : mapper & coder www.hlalbator.fr.st >> > > >> > > >> > > ___ >> > > 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 >> >> > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders [ Cruise / www.casual-tempest.net ] -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPM5wFvdi0Z5STRufAQEwoQP/VsBOizIh/uATCojpUVa159hi4n8er0Rr GSoB8LbVazq6az2eKi/i7E8etNe4y5qZjqyIs2WrviNVgk8d90ySquZFUgQNDh0t crAzaGsuuOPa6Y6FpkCYFCg6zTk4iv/8gihqC0Gm8Ba8Er/Xxu46nIvjzF1KAvjt m3UElQdz8rQ= =0Pmr -END PGP SIGNATURE- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
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
Re[6]: [hlcoders] problem with GiveNamedItem need help.
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 > now its funny cause if i only use just one of them say string1 to do them > all so replace in the above code all occurences of string2 and string3 and > put > string1 in its place. Now i get back to my original problem and yet IF i use > 3 seperate strings instead of the same one for all then its ok. > Using what you said cruise say if i did > char *temp = new char[30]; > then do the sprintf's for each and give the named items then it works fine > but ONLY if i don't delete the char at the end of the function... if i put > delete temp; at the end of the function it goes screwy. But if i don't > delete it then the memory is gone is it not till the program halts... or is > it till the machine is > reset? Program end I believe. On large objects it would be a problem, but at 30 bytes a pop, I don't think most users are gonna notice :P > anyways i am now thinking the giveNamedItem function receives a const char > pointer to the string right so does this mean that if for some reason > the string > lost its scope and was removed that the pointer to it can no longer validly > give the weapon but thats kinda crap isn't it cause it passes through > the givenameditem function gives the weapon... then returns to its place > back in the code which is after the pPlayer->GiveNamedItem call? I don't have the code to hand right now, but I suspect GiveNamedItem passes it on to other functions which store the pointer, so changing that value would be Bad (tm). > Its getting to the stage where this has gone a bit beyond me i'm not sure if > its either a bug in my source that is doing something strange or if just > what i am trying to do is not doing it how i think it is ie something with > variables falling out of scope etc. I doubt it's a bug in your source...have a close look at GiveNamedItem and any functions it calls, and see what they do with the pointer. > Cruise you got any info on this and why its doing it? I'm starting to think > your onto something here and its kinda swaying my views > Any others got input... Botman? Valve Guys? Mom :( ? [ Cruise / www.casual-tempest.net ] -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPKBuDfdi0Z5STRufAQF0FAP9GuyfSFLs9lMXra6Z+6M4kzXC8iUa7jGn G+z3ish7xLtVB4v4BYSsuSqNZKSxZ90i5OBx9TWU2nQPFLrwvh/F38t785Xm2UYs w+189X4f5rS5qomDVB/U56ehkulVIOtsktaJCGyddI/wD9cZlc+lb2cWaivqeADV aYKIblXr6P4= =lSBC -END PGP SIGNATURE- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[4]: [hlcoders] problem with GiveNamedItem need help.
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 > being sent as a command??? no no the file is just a header with a complete > listing of all weapons in a made struct :/ its not actually send from the > client and picked up in the ClientCommand function. > all i pass from the client once vgui picks things is 4 ints which just > contain the weapon index that i reference to that struct object to get what > the weapons name is. The alert works fine and displays what the complete > givenameditem string is No, I meant when the client picks a certain weapon. You said that they were in the list, but not selectable...unless you've completely changed that part of the code also, switching between weapons sends the name of the weapon from the client to the server. Make sure that value is being sent correctly. > I appreciate your help none the less... any attemp at a solution is better > then nothing :). i doubt though that char *temp = new char[20]; would fix > the problem... its the same as going char temp[20]; string copying into it > the full weapon name then doing a GiveNamedItem on it its memory has > been set aside so it shouldn't have an issue... o well maybe my problem is > unfixable :/. But it has only been set aside within the confines of the function. temp is a /local/ variable. Calling new allocates the memory permanently, so it won't get written over. I agree it shouldn't make much difference, but something is screwing you over, and that's the only difference between the working and non-working versions as far as I can see. [ Cruise / www.casual-tempest.net ] -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPKBf3fdi0Z5STRufAQHoSQP6AiURhdMubWn6JvGZoAhvxoyZOxKYCFn8 zejSOpMHpALOzBFeq+kSl7CabwSQUkFW4jlwq8ElYPOoQGU7Fvp/m/Y8Rn7Wsfvj 5T2RfJxwUYZMGnGVfV6haI7mFO/H6mpFUMYk4sMexkoKpxPj7bmOpHIFMcODVeNq SeuDUFg0kAo= =92hf -END PGP SIGNATURE- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] problem with GiveNamedItem need help.
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
> so why can't i go
> char temp[20];
> sprintf(temp, "weapon_%s",
> SpeciesWeapons[0].CloseCombatWeaponName[pPlayer->m_iCloseCombatWeapon]);
pPlayer->>GiveNamedItem(temp);
> i've done it and on an alert it does indeed contain weapon_knife. And if it
> wasn't working then why would it give me the knife and yet make it
> unselectable on the hud.. well i can select but clicking won't draw it out.
> this also fails
> char temp[30];
> strcpy(temp, "weapon_knife");
pPlayer->>GiveNamedItem(temp);
> it gives and i can see it in the list select it but clicking won't draw
> it yet
pPlayer->>GiveNamedItem("weapon_knife");
> works fine lets me select and pull out etc.
The difference between the one that works and the two that don't is
that the first two use a temporary /local/ variable, which is free to
go out of scope and be reallocated at the end of the function...it
could be that that is causing the problem...
Try:
char *temp = new char[20];
sprintf(temp,
"weapon_%s",SpeciesWeapons[0].CloseCombatWeaponName[pPlayer->m_iCloseCombatWeapon]);
pPlayer->GiveNamedItem(temp);
That way the memory is allocated and won't be used by anything
else...see if that makes a difference.
The not selectable problem suggests the string passed back from the
client is incorrect...in the ClientCommand function, where it handles
"weapon_" commands, print that out and check it's being sent
correctly...
[ Cruise / www.casual-tempest.net ]
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAPKBVfvdi0Z5STRufAQGeLwQAuQHC+2Q3oLTcA3cM3m9V/nfUGM8s+jP6
jctWhm2WU5ADXIEI2DZ2aBD5faYLU2IgDI14ptm8+VhmaOblW+0z1Ue7il9HDNDz
P9JFSRuelKQAUtx3bXlQqMtzD6Ap4HGoVMPp0pbSeLStltnk1yi6gU39JRF4xbAw
Nnnt60p0scg=
=+/vI
-END PGP SIGNATURE-
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] problem with GiveNamedItem need help.
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
[snip]
> then again in the multiplay game rules when i set them up i do this instead
> // 0 = no change in vgui.. 99 = nothing
if(pPlayer->>m_iPrimaryWeapon != 0 && pPlayer->m_iPrimaryWeapon != 99)
> {
pPlayer->>GiveNamedItem(SpeciesWeapons[0].PrimaryWeaponName[pPlayer->m_iPrimaryWeapon]);
> }
if(pPlayer->>m_iSecondaryWeapon != 0 && pPlayer->m_iSecondaryWeapon != 99)
> {
pPlayer->>GiveNamedItem(SpeciesWeapons[0].SecondaryWeaponName[pPlayer->m_iSecondaryWeapon]);
> }
if(pPlayer->>m_iCloseCombatWeapon != 0 && pPlayer->m_iCloseCombatWeapon != 99)
> {
pPlayer->>GiveNamedItem(SpeciesWeapons[0].CloseCombatWeaponName[pPlayer->m_iCloseCombatWeapon]);
> }
> it works 100% fine. Now i don't see how compacting into 1 string with using sprintf
>and prefixing
> "weapon_" should hurt it or make it work any different
Because pre-pending "weapon_" makes it a completely different string?
The name you pass to GiveNamedItem should match exactly what you pass
into your LINK_ENTITY_TO_CLASS macro for the respective weapon. If
you've declared your weapon names to be just "mp5", or "knife", then
that's what you'll have to pass to GiveNamedItem.
> UPDATE
> I tryed some other things after talking to randomnine on it with him suggesting i
>should
> print the contents of the string character by character after doing so i get
>something like this
> sprintf(fullWeapName, "weapon_%s",
>SpeciesWeapons[0].CloseCombatWeaponName[pPlayer->m_iCloseCombatWeapon]);
> for(i= 0; i < 30; i++)
> {
> ALERT(at_console, "%c", fullWeapName[i]);
> if(i == 29)
> ALERT(at_console, "\n");
> }
> to the console it prints
> weapon_mp5Bj! and the close combat weapon contains
> weapon_knifej!
> i dunno what the j! is :/ or the Bj! and how it got there either.
What's wrong with ALERT(at_console, "%s", fullWeapName[i]); ?
If you print it out character by character like this then you'll go
straight past the end of the string into the undefined regions, which
naturally will have all sorts of random crap in them...
[ Cruise / www.casual-tempest.net ]
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAPKBNy/di0Z5STRufAQHkIgQAvbLmmYAF7Us62gqk4kQZ3PLyjqJl/97Z
boZMIkOvfPtNNgKKsfFqq+blhc5HCJgfRpvkmsx8N2jviQ1mE5Zbd+1Pe7Nh9cck
BGmOWcjsPz3zAtdz9lyzqW8HBWI73B1bjRrnEz4qy2cN4eyQ0edYpXlCx4rpIWMt
YIhpbcrg0Lo=
=0heP
-END PGP SIGNATURE-
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] pEnt != NULL and driving me nuts
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
Breakpoints anyone?
If you know the line the ALERT is coming from, simply put a breakpoint
on it, then when you hit the breakpoint go back through the call stack
to see where it was called from and what the code was doing.
> I had a similar problem whenI used SDK 2.0. I had the console spammed with
> "ALERT pEnt != NULL @ cbase.cpp l.159" (or something similar).
> I didn't find the cause of this but I hadn't modify the gamerules... So,
> perhaps the
> messages you become don't come from the GameRules class but from an other
> function.
> Just a possibility...
> - Cortex : mapper & coder www.hlalbator.fr.st
> - Original Message -
> From: Christopher Long
> To: [EMAIL PROTECTED]
> Sent: Wednesday, March 13, 2002 2:42 AM
> Subject: Re: [hlcoders] pEnt != NULL and driving me nuts
> Well thanks goes to you all but the solution cruise posted worked for me.
> I am not doing anything bot related.
> Even after using the solution posted by cruise everytime i try to call
> UTIL_PlayerByIndex() or the changed one UTIL_CBasePlayerByIndex()
> i still get the annoying ALERT pEnt != NULL. I find this very disturbing and
> although the original problem is solved these statements still are flowing
> around.
> All other calls to UTIL_PlayerByIndex() through the sdk work without fail
> giving no ALERTS spewing into the console. But anytime i try to do it from
> my modified gamerules it gives one for every player not connected so if i
> have a 8 player game it'll throw 7 at me each time a player is killed, i
> connect or some other function gets called that invokes the RecountTeams()
> function.
> I'm starting to think maybe i did something a long time ago that was naughty
> and never bothered with these alerts before.
> As a last question could someone maybe please explain to me why
> for(int i = 1; i < gpGlobals->maxClients; i++)
> {
>CBasePlayer *plr = UTIL_PlayerByIndex(i);
>if( plr && plr->IsPlayer() && plr->IsAlive() )
>{
>}
> }
> would generate an ALERT pEnt!=NULL console statement. the alert comes from
> cbase.h or .cpp can't remember but its in a debug statement.
> What actually does pEnt != NULL mean anyway?
> thanks again
> Christopher Long
> - Original Message -
> From: Leon Hartwig <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, March 13, 2002 3:41 AM
> Subject: RE: [hlcoders] pEnt != NULL and driving me nuts
>> This is a multi-part message in MIME format.
>> --
>> If you are dealing with bots, there are some special considerations
>> (you'll probably want to do some stuff in the disconnect callback), but
>> for reasons other than what this thread is concerned with. For your
>> problem, you shouldn't need to touch any of that. Here is an example
>> function that I use in Phineas Bot that counts all the valid, connected
>> clients:
>>
>> int UTIL_ClientsInGame( void )
>> {
>> int iCount = 0;
>>
>> for ( int iIndex = 1; iIndex <= gpGlobals->maxClients; iIndex++ )
>> {
>> CBaseEntity * pPlayer = UTIL_PlayerByIndex( iIndex );
>>
>> if ( pPlayer == NULL )
>> continue;
>>
>> if ( FNullEnt( pPlayer->pev ) )
>> continue;
>>
>> if ( FStrEq( STRING( pPlayer->pev->netname ), "" ) )
>> continue;
>>
>> iCount++;
>> }
>>
>> return iCount;
>> }
>> --
>> [ winmail.dat of type application/ms-tnef deleted ]
>> --
>>
>> ___
>> 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
[ Cruise / www.casual-tempest.net ]
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAPI9YE/di0Z5STRufAQFrBAP/VM5mcY8Pw95MAG1xiWN0LIkljhP8mlHr
G0anArx/qRi0LJ59CXRoQdWBwNZ2r1tqH1xSRCQMNaDt70xsk7zLqV/zHFo+30PN
mfFL1zEYudJ2xrrcUqvNEZN28+a95nsjEnbdJvK3A3L4zvlc1Nhg2P2NudwMbaOV
glnrIEqh59M=
=9duQ
-END PGP SIGNATURE-
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] pEnt != NULL and driving me nuts
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
Found it on the old Topica mailing list archives...
http://www.topica.com/lists/hlcoders/read/message.html?mid=800284472
I knew I'd seen this before :P
> i've strolled through the archives and there is alot of them :/ and i didn't
> find it. If someone else can find it or has the post lying around please
> give it a forward to me privately or the entire list maybe it'll be
> beneficial to others as well.
> thanks for your time.
> - Original Message -
> From: Christopher Long <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, March 12, 2002 8:46 PM
> Subject: Re: [hlcoders] pEnt != NULL and driving me nuts
>> well i'm desperate enough to spend that time... you got an archive link?
>> - Original Message -
>> From: Cruise <[EMAIL PROTECTED]>
>> To: Christopher Long <[EMAIL PROTECTED]>
>> Sent: Tuesday, March 12, 2002 8:44 PM
>> Subject: Re: [hlcoders] pEnt != NULL and driving me nuts
>>
>>
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: MD5
>> >
>> > As I mentioned before, I recall a thread a while ago about the player
>> > structure. Apparently they aren't fully cleared when a player
>> > disconnects, to save on the overhead of re-creating the structure when
>> > another player joins or some such...
>> >
>> > There was a simple fix posted by someone that cleared it properly, I
>> > believe...I really don't remember much more about it, unfortunately,
>> > so I'm hoping other people on the list will have better memories...
>> >
>> > Or if you have lots of time to burn, you could take a stroll through
>> > the archives...
>> >
>> > > Well i've kinda given up on my silly gamerules that atm seem to be
>> counting disconnected players even after they have disconnected but o well
> i
>> have something which has been bugging me for ages but
>> > > never hurt anything.
>> >
>> > > I keep getting my console flooded with junk messages of ALERT pEnt !=
>> NULL and the like. After watch the mod run and running through how the
> code
>> progresses in my mind i noticed that every time
>> > > recount teams was called it would do this or whenever this following
>> code was executed it would always spit 1 at me for every player that
> wasn't
>> connected.
>> >
>> > > for(int i = 1; i <= gpGlobals->maxClients; i++)
>> > > {
>> > > CBasePlayer *plr = UTIL_PlayerByIndex(i);
>> > > if(plr && plr->IsPlayer() && plr->isAlive() )
>> > > {
>> > > ALERT(at_console, "Connected player found at index %i \n", i);
>> > > }
>> > > }
>> >
>> > > now is it natural for it to do that :/ cause i don't think it is...
> well
>> if it was it'd happen the other million places code like that is used in
> the
>> sdk. I don't know if this is linked with my
>> > > gamerules playing up but i find it very disturbing that i am getting
>> these messages.
>> >
>> > > I am still living in the past with sdk 2.1 or 2.0 can't remember which
> i
>> have but like it matters.
>> >
>> > > Anyone here able to offer some insight as to why i am getting this :/
>> Valve others help?
>> >
>> > > help appreciated
>> > > Christopher Long
>> > > --
>> >
>> >
>> > [ Cruise / www.casual-tempest.net ]
>> >
>> > -BEGIN PGP SIGNATURE-
>> > Version: 2.6
>> >
>> > iQCVAwUAPI3b8vdi0Z5STRufAQHSMwQAiU2m8csixMKto8QynU8NGxKQi1AD32+m
>> > UBj24wk/AXf/D/+FFgWObGkHiLDhnNpaPT7TzSIp/kWFSrpBjXJRB2Uk9NH10wsI
>> > Ho1lHPu2iItwS9zkQgA+JGJjRH79jFLiHuS8sCf3EZfRv+GHl0mzl8hVVSQapoLL
>> > 8ydhxd2BTfs=
>> > =9kUO
>> > -END PGP SIGNATURE-
>> >
>> > ___
>> > 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
[ Cruise / www.casual-tempest.net ]
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAPI3wQ/di0Z5STRufAQEikwQAki0TsXaSwb33bwioXTxv535vvLRaSQhJ
OfUMfRUMQ1Qn/BkbVxNbTog2lRJCTRdiMoYNRfyWGwDf2NYcjgTht+JOaqY76swQ
HEK5nxdieTfRfylgue7aDtOnpafFtWpm9qE7qfFtQgI2wne2MmIlx7G1fRVD7B/K
mOrBCeqg8l8=
=0Kq6
-END PGP SIGNATURE-
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] pEnt != NULL and driving me nuts
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
Look at the bottom of the emails:
"
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
"
> well i'm desperate enough to spend that time... you got an archive link?
> - Original Message -
> From: Cruise <[EMAIL PROTECTED]>
> To: Christopher Long <[EMAIL PROTECTED]>
> Sent: Tuesday, March 12, 2002 8:44 PM
> Subject: Re: [hlcoders] pEnt != NULL and driving me nuts
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: MD5
>>
>> As I mentioned before, I recall a thread a while ago about the player
>> structure. Apparently they aren't fully cleared when a player
>> disconnects, to save on the overhead of re-creating the structure when
>> another player joins or some such...
>>
>> There was a simple fix posted by someone that cleared it properly, I
>> believe...I really don't remember much more about it, unfortunately,
>> so I'm hoping other people on the list will have better memories...
>>
>> Or if you have lots of time to burn, you could take a stroll through
>> the archives...
>>
>> > Well i've kinda given up on my silly gamerules that atm seem to be
> counting disconnected players even after they have disconnected but o well i
> have something which has been bugging me for ages but
>> > never hurt anything.
>>
>> > I keep getting my console flooded with junk messages of ALERT pEnt !=
> NULL and the like. After watch the mod run and running through how the code
> progresses in my mind i noticed that every time
>> > recount teams was called it would do this or whenever this following
> code was executed it would always spit 1 at me for every player that wasn't
> connected.
>>
>> > for(int i = 1; i <= gpGlobals->maxClients; i++)
>> > {
>> > CBasePlayer *plr = UTIL_PlayerByIndex(i);
>> > if(plr && plr->IsPlayer() && plr->isAlive() )
>> > {
>> > ALERT(at_console, "Connected player found at index %i \n", i);
>> > }
>> > }
>>
>> > now is it natural for it to do that :/ cause i don't think it is... well
> if it was it'd happen the other million places code like that is used in the
> sdk. I don't know if this is linked with my
>> > gamerules playing up but i find it very disturbing that i am getting
> these messages.
>>
>> > I am still living in the past with sdk 2.1 or 2.0 can't remember which i
> have but like it matters.
>>
>> > Anyone here able to offer some insight as to why i am getting this :/
> Valve others help?
>>
>> > help appreciated
>> > Christopher Long
>> > --
>>
>>
>> [ Cruise / www.casual-tempest.net ]
>>
>> -BEGIN PGP SIGNATURE-
>> Version: 2.6
>>
>> iQCVAwUAPI3b8vdi0Z5STRufAQHSMwQAiU2m8csixMKto8QynU8NGxKQi1AD32+m
>> UBj24wk/AXf/D/+FFgWObGkHiLDhnNpaPT7TzSIp/kWFSrpBjXJRB2Uk9NH10wsI
>> Ho1lHPu2iItwS9zkQgA+JGJjRH79jFLiHuS8sCf3EZfRv+GHl0mzl8hVVSQapoLL
>> 8ydhxd2BTfs=
>> =9kUO
>> -END PGP SIGNATURE-
>>
>> ___
>> 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
[ Cruise / www.casual-tempest.net ]
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAPI3dfvdi0Z5STRufAQFlQgQAg2VtbM8K6JAm8kzAzIyzt5qIy7kMPBDz
/lnGcjlKuWK6WaHUiqEqEDCf5dVxwpK1IUjEIrTbxIZh545OvyY88ise3g3ZNkrw
cO9vuhAVCbE105HtO+fhEq7RFD+bqz150HpSlBq+aVIjjl3oxX+TKXJ2nqAoOBKA
eKtHiKaqSww=
=yr39
-END PGP SIGNATURE-
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] pEnt != NULL and driving me nuts
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
As I mentioned before, I recall a thread a while ago about the player
structure. Apparently they aren't fully cleared when a player
disconnects, to save on the overhead of re-creating the structure when
another player joins or some such...
There was a simple fix posted by someone that cleared it properly, I
believe...I really don't remember much more about it, unfortunately,
so I'm hoping other people on the list will have better memories...
Or if you have lots of time to burn, you could take a stroll through
the archives...
> Well i've kinda given up on my silly gamerules that atm seem to be counting
>disconnected players even after they have disconnected but o well i have something
>which has been bugging me for ages but
> never hurt anything.
> I keep getting my console flooded with junk messages of ALERT pEnt != NULL and the
>like. After watch the mod run and running through how the code progresses in my mind
>i noticed that every time
> recount teams was called it would do this or whenever this following code was
>executed it would always spit 1 at me for every player that wasn't connected.
> for(int i = 1; i <= gpGlobals->maxClients; i++)
> {
> CBasePlayer *plr = UTIL_PlayerByIndex(i);
> if(plr && plr->IsPlayer() && plr->isAlive() )
> {
> ALERT(at_console, "Connected player found at index %i \n", i);
> }
> }
> now is it natural for it to do that :/ cause i don't think it is... well if it was
>it'd happen the other million places code like that is used in the sdk. I don't know
>if this is linked with my
> gamerules playing up but i find it very disturbing that i am getting these messages.
> I am still living in the past with sdk 2.1 or 2.0 can't remember which i have but
>like it matters.
> Anyone here able to offer some insight as to why i am getting this :/ Valve
>others help?
> help appreciated
> Christopher Long
> --
[ Cruise / www.casual-tempest.net ]
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAPI3b8vdi0Z5STRufAQHSMwQAiU2m8csixMKto8QynU8NGxKQi1AD32+m
UBj24wk/AXf/D/+FFgWObGkHiLDhnNpaPT7TzSIp/kWFSrpBjXJRB2Uk9NH10wsI
Ho1lHPu2iItwS9zkQgA+JGJjRH79jFLiHuS8sCf3EZfRv+GHl0mzl8hVVSQapoLL
8ydhxd2BTfs=
=9kUO
-END PGP SIGNATURE-
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] NULL player problem
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
> Now there are a few other things i have thought of and taken into
> consideration and i dunno if these may affect it in anyway but i better
> mention it. I changed the default spawn behavior and made an extra variable
> called b_canrespawn this way while players were rechoosing equipment etc
> they remained dead to the world and spectators etc had this set too. In the
> player::prethink i then changed the line that was something like
if(deadflag >>= dead_no) or something to if(b_canrespawn && deadflag >=
> dead_no)
> although i am sure that doesn't effect it in any way.
[snip]
> But the next thing i am going to mention makes it appear real funny.
> Once i reset the round in the gamerules function all players that
> disconnected don't then effect it at all :/ it only seems to effect the
> current round and i have looked at it many times and can't see the problem
> so i'll post some stuff here.
> in the round restart it just does
[snip]
> cbaseplayer *plr = NULL;
> for(int i = 1; i <= gpglobals->maxclients; i++)
> {
> remove from spectator mode;
> put player in observer mode;
> show plr vgui equipment menu;
> }
First impressions here is that the disconnected could be getting stuck
in spectator mode, or some kind of mishmash of alive/spectator...
However, we had a similar problem with The Opera in our rounds where
ClientDisconnect wasn't actually called for all disconnects.
Also, wasn't there a thread on here a while back about player
structures being cached on a disconnect? And so a simple "IsNull"
check wouldn't return false even tho' the player had left the game.
Hope one of those are of use...
[ Cruise / www.casual-tempest.net ]
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAPIysvvdi0Z5STRufAQGmZgP/d2CuvtyOZf+uCx/2HkyfF2nmXLuKPwAP
11ZiiLMlqcgwWasGSIQIGJtAsxMOA+aFPA1oHle1TA02/b1vmt9/ul+JzOpCL9LD
lL24QS++V8E5vAM+ahiDgDFkz64eS18sxoan6dNv/JMtwKKW2Ifc357diT6tHmFQ
re39w5r91dI=
=AHVt
-END PGP SIGNATURE-
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Items.cpp (MyTouch)
RadiusDamage (which the grenades use to inflict damage) already checks for visibility...standard HL grenades won't hurt things they can't see. --- > Have a quick question, just coded a new grenade type. I would like only > the players > In the FOV of the grenade to be affected by it, that is players behind a > wall or obscured by > Something are not affected. > I have looked through items.cpp and have not found a decent example (or > one at all) > Would I need to add some traceline code to the MyTouch? Would actually > like > To trace from the grenade out to find players and affect then, instead > of from > The player to the grenade. > Regards, > Ron > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders --- Cruise www.casual-tempest.net www.wytedragon.com opera.redeemedsoft.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[4]: [hlcoders] Server to Client effects
> "Where on the client side are the SVC_TEMPENTITY type message picked up and > handled?" > They are in the engine. You don't have access to the temporary entity > effects code. Yeah, that's what I thought. > You can look through the Quake I source code (ftp.idsoftware.com) to see how > the original Quake I TE_ effects were done. Worth a try, but Quake didn't have the effects I want to do, so likely won't help much. > You send the TE_ network messages from the server to the client using > MESSAGE_BEGIN(), WRITE_BYTE(), WRITE_LONG(), MESSAGE_END(), etc. There are > examples in the SDK source code of sending temporary entity effects to the > client. Just do a case sensitive search for "TE_" to find them. I'm well aware of the server side messages. I'd just like to do all the effects client side with one message, rather than sending three or four for each part. Anybody at Valve care to explain how they did the beam cylinder effect? :D Or anyone else have any suggestions other than doing it manually with the TriApi (which it's looking like I will have to do)? --- Cruise www.casual-tempest.net www.wytedragon.com opera.redeemedsoft.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] Server to Client effects
--- >> Is there a reference (or a source file I've missed) which shows the >> relation between the TE_* messages on the server side and the >> functions used to create them on the client side? >> >> Specifically, how do I create the beam cylinder or torus effects on the >> client side? There doesn't seem to be a direct EFX function to draw >> them. >> >> --- >> Cruise > See the common\const.h file for the TE_ client effects. > Jeffrey "botman" Broome Yes, which gives me the the server side fields needed to send the message. Doesn't help me to generate the effect on he client side, AFAICT. Where on the client side are the SVC_TEMPENTITY type message picked up and handled? Once I've found that, then I can locate how the various TE_* effects are created, but I'm starting to think those messages are handled in the engine, and the client doesn't see them... --- Cruise www.casual-tempest.net www.wytedragon.com opera.redeemedsoft.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Server to Client effects
Is there a reference (or a source file I've missed) which shows the relation between the TE_* messages on the server side and the functions used to create them on the client side? Specifically, how do I create the beam cylinder or torus effects on the client side? There doesn't seem to be a direct EFX function to draw them. ------- Cruise www.casual-tempest.net www.wytedragon.com opera.redeemedsoft.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] StartDeathCam()
Ronald, are you sure it's not a problem in your StartObserver function? Have you tried using some breakpoints to see where the code is going, and what values it has? If you're getting the log entry, then it's obviously finding the infointermission, so the only place I can see the problem being is in StartObserver. But then, what do I know? :P > Well there's one obvious flaw I see in this code. Not sure if it's related to > your problem.. That may well be true, Reedbeta, unfortunately, that code was the bit that was commented out in the original posters question. And besides, I do believe that's original valve code anyway :P --- Cruise www.casual-tempest.net www.wytedragon.com opera.redeemedsoft.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re[2]: [hlcoders] Suggestions for Debugging
> After you stop the debugger, use "View->Debug Windows->Call Stack" to see > what functions led up to the problem. You'll see functions listed in > reverse order (most recent at the top, on the top of the stack). Hey cool :P Never had to use that before... > You can > double-click on any of them to load that function into the debugger window > and examine variables from there to see why it's stuck (more than likely in > some infinite while/for loop). ...unfortunately, the only listing I get is two addresses in HW.dll So it looks like I'm properly jumping on memory somewhere. But I'll still need a bit more guidance to narrow down my search if possible... It only happens after a respawn or level transition. It's very consistent where it happens after said point. It seems pretty safe to assume therefore I'm mashing something consistently in the Save/Restore sections or associated data. Any best guesses as to what to check? In the other current thread I noticed comments about EHANDLE and entity pointers, which I'll look at, but any other common screw-ups any one can suggest? Or even an easy way to determine if it's crashing in he client or server code would be nice (it's a single-player mod, so both are on the same machine)... --- Cruise www.casual-tempest.net www.wytedragon.com opera.redeemedsoft.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Suggestions for Debugging
OK, here's the problem. After a second level load, or a respawn after death, my mod will freeze. No errors, no debug messages from it or msvc, and hit break just lands in the middle of hl.dll disassembly. Now, yes, I know that it's crashing there because of something I did somewhere else, and I know roughly where, I can even make it happen everytime...but because of he way it's crashing, I can't find out what the hell it was doing at the time i crashed. I'm going to try the Tracer logging suggestion (lots of ALERTS revealed nothing) and see if it helps, but I can't imagine I'm the first one to get this sort of crash. Any clues? How do you guys debug yours? :P --- Cruise www.casual-tempest.net www.wytedragon.com opera.redeemedsoft.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
