[hlcoders] pfnPEntityOfEntIndex( 1 )
I've seen this in CTriggerCamera::Use. Which entity does it refer to? I originally thought that it was the player, but this: if ( !pActivator || !pActivator-IsPlayer() ) seems to rule that out. Which entity is it pointing at? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] pfnPEntityOfEntIndex( 1 )
The player is the first entity, 0 then? So maybe 1 is the weapon? - Original Message - From: Jon 'DesPlesda' Manning [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 27, 2003 12:24 PM Subject: [hlcoders] pfnPEntityOfEntIndex( 1 ) I've seen this in CTriggerCamera::Use. Which entity does it refer to? I originally thought that it was the player, but this: if ( !pActivator || !pActivator-IsPlayer() ) seems to rule that out. Which entity is it pointing at? ___ 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
Re: [hlcoders] pfnPEntityOfEntIndex( 1 )
I think 1 is the world. (worldspawn) At 22:24 27/06/2003, you wrote: I've seen this in CTriggerCamera::Use. Which entity does it refer to? I originally thought that it was the player, but this: if ( !pActivator || !pActivator-IsPlayer() ) seems to rule that out. Which entity is it pointing at? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- Programmer and Modeller for http://pokemod.fragoff.net/The http://pokemod.fragoff.net/Pokemod -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] pfnPEntityOfEntIndex( 1 )
--- I've seen this in CTriggerCamera::Use. Which entity does it refer to? I originally thought that it was the player, but this: if ( !pActivator || !pActivator-IsPlayer() ) seems to rule that out. Which entity is it pointing at? --- This is in fact the first player in the entity list. Players take slots 1 through 32. I think slot 0 is worldspawn. The code (if (!pActivator .) ) is there in case the 'use' function gets triggered by something other than a player (for example a trigger_multiple or a monster) so that pActivator will have some valid data in it. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] building another tcp/udp port into hlds
There should be no problems with opening a socket (udp or tcp) from a 3rd party plugin. The only thing to worry about is blocking for too long when reading from the socket (and potentially writing). Make sure the socket is non-blocking and do a zero time select() to poll the socket for data to read. Once you've set your socket up to non-blocking mode, like Alfred said, be REAL careful about reading and writing data. For normal blocking socket operations, you can write a huge block of data and the OS will suspend your process until it has completely written all of the data. For non-blocking socket operations, you MUST check the return values of the write function to see how much data was written. It might be less than the size that you passed into the write function. This is your indication that the OS can't shove any more data into the pipe right now and you should try sending the rest of the data again in a little while (perhaps during the next frame?). The point is that you can't just assume that all of the data will be written to the socket when you tell it to. The same goes for reading. You might request 1000 bytes, but you might only get back 200. You'll need to read again later to complete that read operation. This all mostly applies to TCP. UDP is nastier in that the OS won't buffer any data for you. If you don't read it all in one pass, it's gone forever. I'm not sure what the result would be if you tried to write 1400 bytes to a UDP packet and the OS was only able to write part of it. It probably won't be a problem if you stick to small packets (less than the MTU size of 1400 bytes or so), but it could become a large problem if your packet size is fairly big. Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] building another tcp/udp port into hlds
Both protocols are fine, it depends on the nature of the data you are sending as to what you should choose. I guess TCP is the best option (reliable yet a little slower), just remember to NEVER block when reading/writing to the socket. Also try to write smaller chunks (1500bytes or less) at a time, rather than huge gobs of data. Brian A. Stumm wrote: Thanks for the clarification. To be honest I already built it in a few months back :) and hadn't noticed any problems but was told I shouldn't be doing it. Would UDP be better than TCP because I'm using TCP now. The initial reason for doing this was it screwed up stuff when I was spamming it to console and reading from there (console only not logged). basically I want the data for a hlwebtv deal Im working on. On Fri, 27 Jun 2003, Alfred wrote: There should be no problems with opening a socket (udp or tcp) from a 3rd party plugin. The only thing to worry about is blocking for too long when reading from the socket (and potentially writing). Make sure the socket is non-blocking and do a zero time select() to poll the socket for data to read. Brian A. Stumm wrote: perhaps this would have been better for teh apps list, if so please tell me ;) Ok so I've been told that adding another connection or socket to a hlds server is not a good thing to do. Is this true and why? By socket I mean via one of the engine-hook-mod methods (ie botman/metamod/et al). Is it worse depending on tcp vs udp? I'm looking for a way to send data to an external parser without spamming the console. I'm talking about a fair amount of data coming out fairly often. By that I mean a few updates a second with data pertinent to player coordinates and current player status ie health, armor, current weapon, etc. And if a secondary socket is out of question anyone have any ideas on alternate ways to retrieve this data? dump to db perhaps? Or would that socket connect to the db server be just as evil? Thanks. ___ 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
Re: [hlcoders] building another tcp/udp port into hlds
I'm from aWindows background of coding, so I don't know how this applies under Linux. But it should be similar. When sending data you can dump as much as you like on the non-blocking socket (taking the maximum frame size into consideration to avoid unwanted splitting, but you have to do that with a blocking socket too). The only difference is that the snd function returns without waiting for the data to be sent. Thus the return value from the send is unreliable. You need to check your socket later if the data got sent or something went wrong. When receiving data it's pretty much the same. The only differecne is that recv doesn't wait for data. If there is none, it will return immediately. If there is (which means it's actually already received by the OS), your recv buffer will be filled. The only care must be taken with UDP packets, where reading on will always destroyit, if you got all the data or not. Note that this limitation also applies to blocking sockets. The 'bad' thing about creating sockets in HL plugins, is that most people do so in a situation where you shouldn't be using it. A good (or bad) example of this is the HLDS webserver. The idea might sound good, but dropping a webserver in a game is a BAD idea. But al long as the strain of the socket is low (only e few or even 1 client connected), you should be fine. Jeroen ShadowLord Bogers - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 28, 2003 00:28 Subject: Re: [hlcoders] building another tcp/udp port into hlds There should be no problems with opening a socket (udp or tcp) from a 3rd party plugin. The only thing to worry about is blocking for too long when reading from the socket (and potentially writing). Make sure the socket is non-blocking and do a zero time select() to poll the socket for data to read. Once you've set your socket up to non-blocking mode, like Alfred said, be REAL careful about reading and writing data. For normal blocking socket operations, you can write a huge block of data and the OS will suspend your process until it has completely written all of the data. For non-blocking socket operations, you MUST check the return values of the write function to see how much data was written. It might be less than the size that you passed into the write function. This is your indication that the OS can't shove any more data into the pipe right now and you should try sending the rest of the data again in a little while (perhaps during the next frame?). The point is that you can't just assume that all of the data will be written to the socket when you tell it to. The same goes for reading. You might request 1000 bytes, but you might only get back 200. You'll need to read again later to complete that read operation. This all mostly applies to TCP. UDP is nastier in that the OS won't buffer any data for you. If you don't read it all in one pass, it's gone forever. I'm not sure what the result would be if you tried to write 1400 bytes to a UDP packet and the OS was only able to write part of it. It probably won't be a problem if you stick to small packets (less than the MTU size of 1400 bytes or so), but it could become a large problem if your packet size is fairly big. Jeffrey botman Broome ___ 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
