[hlcoders] UTIL_TraceHull()
I am using the UTIL_TraceHull() to see if a player is standing inside or touching the box I am tracing. But I am not sure how to tell if the player was inside or not? trace_t tr; UTIL_TraceHull( closest, closest, GetPlayerMins( ( player-GetFlags() FL_DUCKING ) ? true : false ), GetPlayerMaxs( ( player-GetFlags() FL_DUCKING ) ? true : false ), MASK_SOLID, player, COLLISION_GROUP_PLAYER_MOVEMENT, tr ); tr.?? I tried a couple but they aren't working so not sure what is wrong... Hope that makes sense. r00t 3:16 CQC Gaming www.cqc-gaming.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] (semi OT) 3d panoramas
Why fake holograms when you can make REAL holograms with half-life? A real way to make 3d holograms its to save 1 s demo. Then load the demo with timespeed lowered to zero, and unsticky the player view to move around the map. got Matrix? Yet another interesting device its to put the camera looking at a player, then rotate the camera doing screenshots. Say.. 360 screenshots. Then join all the screenshots as a avi. Matrix alike effect :D I have a deja-vu :D Jay Stelly wrote: If you use the screenshot or jpeg command sequentially as below it just dumps the screen to disk, so everything is rendered through the normal path. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam amckern Mckern Sent: Tuesday, May 17, 2005 6:00 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] (semi OT) 3d panoramas Will the envmap, take your video settings into account, such as having everything up full bore? Also thanks Jay, i'll be doing this latter on Adam --- Jay Stelly [EMAIL PROTECTED] wrote: You could emulate the envmap command with setang screenshot (or jpeg) plus you need to force fov 90 for a 6 shot cubemap: fov 90 setang 0 0 0 screenshot setang 0 90 0 screenshot setang 0 180 0 screenshot setang 0 270 0 screenshot setang -90 0 0 screenshot setang 90 0 0 screenshot (this generates the cube faces in rt, bk, lf, ft, up, dn order equivalent to envmap) [...] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
Yes, every speed hacker ive seen are zooming around the map. I want it to catch them. - Plasma - Original Message - From: Jeffrey botman Broome [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 1:06 AM Subject: Re: [hlcoders] Speed hack detection? Andrew Armstrong wrote: Im curious, is it possible for hlcoders via a plugin or whatnot to track player positions? What about through console messages with a cvar turned on? I think the biggest problem with doing this is the accuracy of the detection. The internet latency between the client and the server will mean that you aren't able to sample player's actual locations at a high rate (and certainly not a constant rate since the latency will be constantly changing as packets take different routes through the internet). This is what client-side prediction is all about, smoothing out the updates between actual packet transfers between the client and the server (so you, in effect, average out the movement between each network update to give the illusion of continuous movement). You would probably not have difficulty detecting a speed hack that was a LARGE increase from the server's max speed (i.e. 2X speed, 4X speed, etc), but trying to determine if someone is going 10% to 20% faster over a small amount of time would be more difficult (and more likely to generate false positives). If you come up with a good method of doing this that doesn't falsely accuse players who have wildly varying network latencies, please let us all know about it. ;) -- 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
RE: [hlcoders] (semi OT) 3d panoramas
Thanks for the tip. Just some things to make it work currectly that I also need: - How do I pause the game without having the pause image to appear? - Is there anyway to hide the hud and weapons if you have them? Thanks, Davide (DAV) Email: [EMAIL PROTECTED] DAV Levels: http://www.planetquake.com/davlevels/ - Original Message - From: Jay Stelly [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Tuesday, May 17, 2005 11:58 PM Subject: RE: [hlcoders] (semi OT) 3d panoramas You could emulate the envmap command with setang screenshot (or jpeg) plus you need to force fov 90 for a 6 shot cubemap: fov 90 setang 0 0 0 screenshot setang 0 90 0 screenshot setang 0 180 0 screenshot setang 0 270 0 screenshot setang -90 0 0 screenshot setang 90 0 0 screenshot (this generates the cube faces in rt, bk, lf, ft, up, dn order equivalent to envmap) That will let you take envmaps at any resolution you can run the game. The envmap command is basically the same as this, but it's using the buildcubemap code which enforces some constraints (power of two output and such) for various reasons. Also, Chris Green made some high-res panoramas here at Valve while working on lost coast. Here's his explanation of how he did it: Bind a key to take a jpeg screenshot Bind keys of your choice to turn left and right and look up / down Set the field of view down a bit Pause the game. Pan from left to right in overlapping steps, taking a screenshot at each step. If you want a multi row panorama, when you get to the end of panning, look up a little and pan back. Use a panorama creation program to stitch the resultant screen shots. If you panned both horizontally and vertically, you will need to use software which supports multi-row panoramas. I used the program autostitch (http://www.cs.ubc.ca/~mbrown/autostitch/autostitch.html) to join the images together. This program requires no manual stitching at all. You don't even have to tell it what order the shots are in. I was able to make very high resolution panoramas, over 10K pixels wide. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] (semi OT) 3d panoramas
DAV wrote: - Is there anyway to hide the hud and weapons if you have them? There is a hidehud CVAR. Try setting it to 1. -- 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] (semi OT) 3d panoramas
Jeffrey botman Broome wrote: DAV wrote: - Is there anyway to hide the hud and weapons if you have them? There is a hidehud CVAR. Try setting it to 1. Doh! It would help if I read the code first. Try setting hidehud to 4. :) -- 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] Speed hack detection?
It's very possible to do that, but as Jeff said you will get a lot more false positives just due to altering latencies rather than real hackers. In theory it is sound but unless you have a decent thresh hold on hacking speeds and just lagging speeds, a better way of doing this without banning non hackers would be to use your eyes. It's not much of an answer but unless you want everyone who plays on your server to be banned because they had a nice little spike in their ping then it's the only real answer. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Odd viewing problem.
Hello all, I'm having a problem that seems to be relating to the players viewing angles; basically I have a square area on a map. The player is viewing from a top down position, onto this square area. However, I cannot get the square to be strait, its crooked one way or another. Here is a screenshot of what I'm talking about: http://www.voogru.com/images/view_error.jpg Notice how the top and bottom are perfectly strait, but the sides are slightly crooked. I messed around with the default view angles, setting the players view angles all to 0, and such, but I can't figure out why this happens. I need the square to be perfectly strait. Any ideas of what I'm doing wrong? Is this a code error or a mapping error? Any help is appreciated. Thanks. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Odd viewing problem.
Spencer 'voogru' MacDonald wrote: Hello all, I'm having a problem that seems to be relating to the players viewing angles; basically I have a square area on a map. Are you using an FOV of 90? -- 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] Odd viewing problem.
Yes, I set the FOV to several different positions, including 90, with no change. -Original Message- From: Jeffrey botman Broome [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 2:46 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Odd viewing problem. Spencer 'voogru' MacDonald wrote: Hello all, I'm having a problem that seems to be relating to the players viewing angles; basically I have a square area on a map. Are you using an FOV of 90? -- 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
Re: [hlcoders] Adding support for Con_Printf() in the SDK libraries?
Another problem is that some engine commands use Con_Print for only part of their output, so when you run the command though RCon half of it goes through RCon and half of it is printed to the server console. I think an example of this is the find command. On 5/16/05, dackz [EMAIL PROTECTED] wrote: Is it possible that you guys (Valve) could add Con_Printf() to the SDK for use with server plugins? Or perhaps make Msg() work over RCON? I'm trying to make concommands that work over rcon, but Msg() only prints to the server console when called from rcon. I was looking at what functions the server called when I did status at the server console and rcon status remotely, and it called Con_Printf() directly when called from rcon, while it called Msg() when I called it from server console. Now I could just use IVEngineServer::ServerCommand(echo text\n), but then I can't use special characters like tabs and whatnot. For what I was doing in particular, which was an extended status command for a remote PHP script, I needed to seperate values by characters that you couldn't put in your player name or server name. I ended up having to seperate values by newlines, and players by double newlines, which was a little annoying. ___ 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] Speed hack detection?
On 5/18/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: You would probably not have difficulty detecting a speed hack that was a LARGE increase from the server's max speed (i.e. 2X speed, 4X speed, etc), but trying to determine if someone is going 10% to 20% faster over a small amount of time would be more difficult (and more likely to generate false positives). If you come up with a good method of doing this that doesn't falsely accuse players who have wildly varying network latencies, please let us all know about it. ;) Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? Obviously if you consistantly ban people going 50%+ faster the hackers will lower their speed below that threshold. However, it's a lot less annoying for others to play against that kind of limited cheating as you at least have a chance of killing the SOB. The other Jeff ;) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Odd viewing problem.
are you viewing perfectly down? a few degrees of up rotation can produce an image like that. On 5/18/05, Spencer 'voogru' MacDonald [EMAIL PROTECTED] wrote: Yes, I set the FOV to several different positions, including 90, with no change. -Original Message- From: Jeffrey botman Broome [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 2:46 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Odd viewing problem. Spencer 'voogru' MacDonald wrote: Hello all, I'm having a problem that seems to be relating to the players viewing angles; basically I have a square area on a map. Are you using an FOV of 90? -- 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
Jeff Fearn wrote: Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? What I would do is keep a list of players currently on the server (store their edict as they connect along with their current location). The player's location can be obtained from the ICollideable::GetCollisionOrigin() function. If your server plugin GetFrame() function keep checking each player's current location every so often (say every 0.5 seconds). The current location (in the array of players that you keep in your plugin) becomes the previous location. Subtract the player's current location from the previous location to get a vector. Determine the length of that vector (the distance between now and then), and divide the distance by the time (to get speed, i.e. units/second). Store the new current location in the current location field of your array of players. If the speed calculated is above the server max, increment a hack counter. If the speed is below the server max, decrement the hack counter (not letting it fall below 0). When the hack counter reaches some maximum amount (let's say 6, which would be 3 seconds worth of compares), warn the player that the server thinks they are speed hacking and they will be given a 30 second grace period to turn it off or be banned from the server. Don't check them again for 30 seconds, then if they continue to reach the hack count, ban them. It's not fool proof and can lead to some false positives, but as long as you allow enough time between comparisons (the 0.5 second window) and as long as you require consecutive check failures (the counting to 6 thing), you should have less people failing due to high latency network connections. The only problem is how do you handle falling speeds (if you have a long drop that can last for 5 or 6 seconds) and how do you handle teleporters which will look like an intantaneous jump from point A to point B making a speed that approaches the speed of light! :) Again, averaging things out over several seconds should help avoid even these problems. -- 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] Odd viewing problem.
I manually set my angles using the setang command, ie, setang 90 90 0 I solved the problem by using a camera entity and making the player view the camera, which works for what I'm doing, with a map placed camera with the angles of 90 90 0, the square is perfectly strait. I don't know why it's weird on the player, but doesn't matter to me any more. - voogru. -Original Message- From: Andrew Foss [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 6:26 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Odd viewing problem. are you viewing perfectly down? a few degrees of up rotation can produce an image like that. On 5/18/05, Spencer 'voogru' MacDonald [EMAIL PROTECTED] wrote: Yes, I set the FOV to several different positions, including 90, with no change. -Original Message- From: Jeffrey botman Broome [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 2:46 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Odd viewing problem. Spencer 'voogru' MacDonald wrote: Hello all, I'm having a problem that seems to be relating to the players viewing angles; basically I have a square area on a map. Are you using an FOV of 90? -- 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 ___ 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] Player Leaning
Michael Kramer wrote: I am trying to do player leaning...I have gotten everything except the command...I am using ViewPunch(); for right now but it doesn't stay...Does anyone know if there is a way I can rotate the FOV or make it so that ViewPunch can stay? Thanx :D ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Simply rolling the view won't exactly be leaning, it'd be more like tilting your head. To do leaning properly, you need to offset the view and rotate it ;) -Kuja Digital Paintball ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
I have created a speedhack detector for amxmodx ( Not released publicy as of yet ), and i encountered alot of problems i dident think of before i started. There is alot of things in a half-life map that can effect the players speed ( Ingame Entities ), that you neeed to check for. I also found that making sure the server FPS was stable above 60 lowered false detections. A aggresive high ping kicker ( ppl with constatly changning ping get easly detected ) - Original Message - From: Jeffrey botman Broome [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 12:36 AM Subject: Re: [hlcoders] Speed hack detection? Jeff Fearn wrote: Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? What I would do is keep a list of players currently on the server (store their edict as they connect along with their current location). The player's location can be obtained from the ICollideable::GetCollisionOrigin() function. If your server plugin GetFrame() function keep checking each player's current location every so often (say every 0.5 seconds). The current location (in the array of players that you keep in your plugin) becomes the previous location. Subtract the player's current location from the previous location to get a vector. Determine the length of that vector (the distance between now and then), and divide the distance by the time (to get speed, i.e. units/second). Store the new current location in the current location field of your array of players. If the speed calculated is above the server max, increment a hack counter. If the speed is below the server max, decrement the hack counter (not letting it fall below 0). When the hack counter reaches some maximum amount (let's say 6, which would be 3 seconds worth of compares), warn the player that the server thinks they are speed hacking and they will be given a 30 second grace period to turn it off or be banned from the server. Don't check them again for 30 seconds, then if they continue to reach the hack count, ban them. It's not fool proof and can lead to some false positives, but as long as you allow enough time between comparisons (the 0.5 second window) and as long as you require consecutive check failures (the counting to 6 thing), you should have less people failing due to high latency network connections. The only problem is how do you handle falling speeds (if you have a long drop that can last for 5 or 6 seconds) and how do you handle teleporters which will look like an intantaneous jump from point A to point B making a speed that approaches the speed of light! :) Again, averaging things out over several seconds should help avoid even these problems. -- 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
Re: [hlcoders] Speed hack detection?
Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Would it easier to check if that variable or whatever they changing? Whether it would be in memory etc? Do that you would need a client / server type of detection I suppose... As botman said, there are to many factors which can cause false detections if the player is lagging. Even the physics in-game could cause false detections. Just throwing some ideas out there. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Erling K. Sæterdal [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 7:19 PM Subject: Re: [hlcoders] Speed hack detection? I have created a speedhack detector for amxmodx ( Not released publicy as of yet ), and i encountered alot of problems i dident think of before i started. There is alot of things in a half-life map that can effect the players speed ( Ingame Entities ), that you neeed to check for. I also found that making sure the server FPS was stable above 60 lowered false detections. A aggresive high ping kicker ( ppl with constatly changning ping get easly detected ) - Original Message - From: Jeffrey botman Broome [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 12:36 AM Subject: Re: [hlcoders] Speed hack detection? Jeff Fearn wrote: Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? What I would do is keep a list of players currently on the server (store their edict as they connect along with their current location). The player's location can be obtained from the ICollideable::GetCollisionOrigin() function. If your server plugin GetFrame() function keep checking each player's current location every so often (say every 0.5 seconds). The current location (in the array of players that you keep in your plugin) becomes the previous location. Subtract the player's current location from the previous location to get a vector. Determine the length of that vector (the distance between now and then), and divide the distance by the time (to get speed, i.e. units/second). Store the new current location in the current location field of your array of players. If the speed calculated is above the server max, increment a hack counter. If the speed is below the server max, decrement the hack counter (not letting it fall below 0). When the hack counter reaches some maximum amount (let's say 6, which would be 3 seconds worth of compares), warn the player that the server thinks they are speed hacking and they will be given a 30 second grace period to turn it off or be banned from the server. Don't check them again for 30 seconds, then if they continue to reach the hack count, ban them. It's not fool proof and can lead to some false positives, but as long as you allow enough time between comparisons (the 0.5 second window) and as long as you require consecutive check failures (the counting to 6 thing), you should have less people failing due to high latency network connections. The only problem is how do you handle falling speeds (if you have a long drop that can last for 5 or 6 seconds) and how do you handle teleporters which will look like an intantaneous jump from point A to point B making a speed that approaches the speed of light! :) Again, averaging things out over several seconds should help avoid even these problems. -- 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection?
r00t 3:16 wrote: Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Usually the client's system clock is running faster (slower?) than normal, I can't remember which way the system clock needs to go to make the game engine think time is passing more slowly. Your client machine is running faster than normal so normal movement speed on your machine become high movement speed on the server (who's running on a different clock speed). If the client's game engine is ticking faster/slower than the server's game engine, the client will be able to move larger distances over the same amount of time. It's sort of like the reverse of Einstein's theory of relativity. Distances become smaller for people who are moving faster in time (or something like that). -- 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] Speed hack detection?
Is there a way to test to see if someone's systems clock is running slower or quicker? From the server itself? You could probably do this in a mod where the client would notify the server of the clock speed of the client. Compared to the servers if it is threshold faster (or slower) they are speed hacking. Plugin probably wouldn't work so well unless there was some kind of client part of the plugin. Just another idea... I wonder if vac2 would be able to detect this? r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Jeffrey botman Broome [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 7:54 PM Subject: Re: [hlcoders] Speed hack detection? r00t 3:16 wrote: Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Usually the client's system clock is running faster (slower?) than normal, I can't remember which way the system clock needs to go to make the game engine think time is passing more slowly. Your client machine is running faster than normal so normal movement speed on your machine become high movement speed on the server (who's running on a different clock speed). If the client's game engine is ticking faster/slower than the server's game engine, the client will be able to move larger distances over the same amount of time. It's sort of like the reverse of Einstein's theory of relativity. Distances become smaller for people who are moving faster in time (or something like that). -- 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
Re: [hlcoders] Player Leaning
Would I use the ViewOffset() funtion? I found that out just barely using the SnapEyeAngles(); Function (I think it is that function) and it just turns the camera. On 5/18/05, Kuja [EMAIL PROTECTED] wrote: Michael Kramer wrote: I am trying to do player leaning...I have gotten everything except the command...I am using ViewPunch(); for right now but it doesn't stay...Does anyone know if there is a way I can rotate the FOV or make it so that ViewPunch can stay? Thanx :D ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Simply rolling the view won't exactly be leaning, it'd be more like tilting your head. To do leaning properly, you need to offset the view and rotate it ;) -Kuja Digital Paintball ___ 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] Speed hack detection?
I dont know what LPBs firstly. If someone has a constant ping of 400 im sure that fine, but the problem with when a users ping spikes, when this happens your speedhack detectors gets a false detection. This can easly be seen if a user is running a p2p program in the background, his ping can easly go from 50 ish to 400+++ for a minor second. Its posible someone with a better understand of the HL engine can make a better solution then what i made. You could proberbly add a ping check that made sure his ping at least was stable, as a midle ground. - Original Message - From: Andrew Foss [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 1:32 AM Subject: Re: [hlcoders] Speed hack detection? high ping kicking is mean and spiteful. I don't want to rant about it, but lag comp nullifies any complaints LPBs have. (which should be none, because HPBs don't lag the game. if anything LPBs with aggressive settings do.) On 5/18/05, Erling K. Sæterdal [EMAIL PROTECTED] wrote: I have created a speedhack detector for amxmodx ( Not released publicy as of yet ), and i encountered alot of problems i dident think of before i started. There is alot of things in a half-life map that can effect the players speed ( Ingame Entities ), that you neeed to check for. I also found that making sure the server FPS was stable above 60 lowered false detections. A aggresive high ping kicker ( ppl with constatly changning ping get easly detected ) - Original Message - From: Jeffrey botman Broome [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 12:36 AM Subject: Re: [hlcoders] Speed hack detection? Jeff Fearn wrote: Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? What I would do is keep a list of players currently on the server (store their edict as they connect along with their current location). The player's location can be obtained from the ICollideable::GetCollisionOrigin() function. If your server plugin GetFrame() function keep checking each player's current location every so often (say every 0.5 seconds). The current location (in the array of players that you keep in your plugin) becomes the previous location. Subtract the player's current location from the previous location to get a vector. Determine the length of that vector (the distance between now and then), and divide the distance by the time (to get speed, i.e. units/second). Store the new current location in the current location field of your array of players. If the speed calculated is above the server max, increment a hack counter. If the speed is below the server max, decrement the hack counter (not letting it fall below 0). When the hack counter reaches some maximum amount (let's say 6, which would be 3 seconds worth of compares), warn the player that the server thinks they are speed hacking and they will be given a 30 second grace period to turn it off or be banned from the server. Don't check them again for 30 seconds, then if they continue to reach the hack count, ban them. It's not fool proof and can lead to some false positives, but as long as you allow enough time between comparisons (the 0.5 second window) and as long as you require consecutive check failures (the counting to 6 thing), you should have less people failing due to high latency network connections. The only problem is how do you handle falling speeds (if you have a long drop that can last for 5 or 6 seconds) and how do you handle teleporters which will look like an intantaneous jump from point A to point B making a speed that approaches the speed of light! :) Again, averaging things out over several seconds should help avoid even these problems. -- 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 ___ 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] Speed hack detection?
But then whoever writes the hacks would find that exploit and make it so it tricks the server to make him think is ping was 400++ a lag hack On 5/18/05, Erling K. Sæterdal [EMAIL PROTECTED] wrote: I dont know what LPBs firstly. If someone has a constant ping of 400 im sure that fine, but the problem with when a users ping spikes, when this happens your speedhack detectors gets a false detection. This can easly be seen if a user is running a p2p program in the background, his ping can easly go from 50 ish to 400+++ for a minor second. Its posible someone with a better understand of the HL engine can make a better solution then what i made. You could proberbly add a ping check that made sure his ping at least was stable, as a midle ground. - Original Message - From: Andrew Foss [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 1:32 AM Subject: Re: [hlcoders] Speed hack detection? high ping kicking is mean and spiteful. I don't want to rant about it, but lag comp nullifies any complaints LPBs have. (which should be none, because HPBs don't lag the game. if anything LPBs with aggressive settings do.) On 5/18/05, Erling K. Sæterdal [EMAIL PROTECTED] wrote: I have created a speedhack detector for amxmodx ( Not released publicy as of yet ), and i encountered alot of problems i dident think of before i started. There is alot of things in a half-life map that can effect the players speed ( Ingame Entities ), that you neeed to check for. I also found that making sure the server FPS was stable above 60 lowered false detections. A aggresive high ping kicker ( ppl with constatly changning ping get easly detected ) - Original Message - From: Jeffrey botman Broome [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 12:36 AM Subject: Re: [hlcoders] Speed hack detection? Jeff Fearn wrote: Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? What I would do is keep a list of players currently on the server (store their edict as they connect along with their current location). The player's location can be obtained from the ICollideable::GetCollisionOrigin() function. If your server plugin GetFrame() function keep checking each player's current location every so often (say every 0.5 seconds). The current location (in the array of players that you keep in your plugin) becomes the previous location. Subtract the player's current location from the previous location to get a vector. Determine the length of that vector (the distance between now and then), and divide the distance by the time (to get speed, i.e. units/second). Store the new current location in the current location field of your array of players. If the speed calculated is above the server max, increment a hack counter. If the speed is below the server max, decrement the hack counter (not letting it fall below 0). When the hack counter reaches some maximum amount (let's say 6, which would be 3 seconds worth of compares), warn the player that the server thinks they are speed hacking and they will be given a 30 second grace period to turn it off or be banned from the server. Don't check them again for 30 seconds, then if they continue to reach the hack count, ban them. It's not fool proof and can lead to some false positives, but as long as you allow enough time between comparisons (the 0.5 second window) and as long as you require consecutive check failures (the counting to 6 thing), you should have less people failing due to high latency network connections. The only problem is how do you handle falling speeds (if you have a long drop that can last for 5 or 6 seconds) and how do you handle teleporters which will look like an intantaneous jump from point A to point B making a speed that approaches the speed of light! :) Again, averaging things out over several seconds should help avoid even these problems. -- 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 ___ 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] Speed hack detection?
On 5/19/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: r00t 3:16 wrote: Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Usually the client's system clock is running faster (slower?) than normal, I can't remember which way the system clock needs to go to make the game engine think time is passing more slowly. Your client machine is running faster than normal so normal movement speed on your machine become high movement speed on the server (who's running on a different clock speed). If the client's game engine is ticking faster/slower than the server's game engine, the client will be able to move larger distances over the same amount of time. It's sort of like the reverse of Einstein's theory of relativity. Distances become smaller for people who are moving faster in time (or something like that). Surely this is where it should be caught by the engine. I don't mean the engine should ban/stop/warn the player, but that the engine should know that even though the cheater is saying this is tick 3000, the server is only at tick 2000, and thus the movement should not be processed until tick 3000. i.e even if the game plays faster on the cheaters computer, those extra ticks should not be processed inline by the server and should not be propigated to the other clients until it's the right time. Obviously I am very wrong, because if it was that easy it would be fixed ... google is my friend, I go visit him now ;) Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player Leaning
I have player leaning working (it isn't perfect needs some tweaking but it works) You need to transition the player to the left / right Using the player angles and the ViewOffset The angle will roll the camera a little and the view will shift the camera to the left or right a little. Also you need to drop it down a little also. if you lean over your hieght drops a tad. Once the transition is done, You have to keep updating the viewoffset so when the player spins he will always be leaning to the same direction. If you do not do this , if you are standing still he will lean left but if you turn right or left we will be leaning forward or backwards depending on the way you turn. So you have to keep updating the veiwoffset. What I did was once the transition is done figure out what the maximum lean would and then just keep setting that // Would fully peek them transition time has expired lean em over. Vector vOffset, vTrueOffset,vRight; player-EyeVectors(NULL, vRight, NULL); // consume memory much ? vTrueOffset = vRight * -20; // This is the full left peek -20 units. vOffset = player-GetViewOffset(); vOffset.x = clamp(vTrueOffset.x, -20, 20); // clamp it just incase vOffset.y = clamp(vTrueOffset.y, -20, 20); // clamp it just in case player-SetViewOffset(vOffset); CategorizePosition(); // this is in the transition period... Vector vRight, vLeft, vUp; vUp = player-GetViewOffset(); player-EyeVectors(NULL, vRight, NULL ); // get the vRight vector x,y vLeft = vRight * -2.50; // below is kind of cheesy but I was figuring out a way to do it all at once player-m_Local.m_vecPunchAngle.Set( ROLL, -flPeekMilliseconds * 0.025 ); // this will roll the camera 0.025 for the transition period player-SetViewOffset(vLeft); That is a snip of code of how I did it. Yea it might not be pretty but this was back when the MP SDK first came out. I haven't had a chance to implement peaking and prone in the hl2mp sdk as of yet.. For help on the transition stuff look at the Duck() function in gamemovement.cpp Hope that helps. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Michael Kramer [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 8:14 PM Subject: Re: [hlcoders] Player Leaning Would I use the ViewOffset() funtion? I found that out just barely using the SnapEyeAngles(); Function (I think it is that function) and it just turns the camera. On 5/18/05, Kuja [EMAIL PROTECTED] wrote: Michael Kramer wrote: I am trying to do player leaning...I have gotten everything except the command...I am using ViewPunch(); for right now but it doesn't stay...Does anyone know if there is a way I can rotate the FOV or make it so that ViewPunch can stay? Thanx :D ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Simply rolling the view won't exactly be leaning, it'd be more like tilting your head. To do leaning properly, you need to offset the view and rotate it ;) -Kuja Digital Paintball ___ 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
Re: [hlcoders] Speed hack detection?
True. Any anti cheat for that matter needs to be update constantly to be affective. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Michael Kramer [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 8:54 PM Subject: Re: [hlcoders] Speed hack detection? But then whoever writes the hacks would find that exploit and make it so it tricks the server to make him think is ping was 400++ a lag hack On 5/18/05, Erling K. Sæterdal [EMAIL PROTECTED] wrote: I dont know what LPBs firstly. If someone has a constant ping of 400 im sure that fine, but the problem with when a users ping spikes, when this happens your speedhack detectors gets a false detection. This can easly be seen if a user is running a p2p program in the background, his ping can easly go from 50 ish to 400+++ for a minor second. Its posible someone with a better understand of the HL engine can make a better solution then what i made. You could proberbly add a ping check that made sure his ping at least was stable, as a midle ground. - Original Message - From: Andrew Foss [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 1:32 AM Subject: Re: [hlcoders] Speed hack detection? high ping kicking is mean and spiteful. I don't want to rant about it, but lag comp nullifies any complaints LPBs have. (which should be none, because HPBs don't lag the game. if anything LPBs with aggressive settings do.) On 5/18/05, Erling K. Sæterdal [EMAIL PROTECTED] wrote: I have created a speedhack detector for amxmodx ( Not released publicy as of yet ), and i encountered alot of problems i dident think of before i started. There is alot of things in a half-life map that can effect the players speed ( Ingame Entities ), that you neeed to check for. I also found that making sure the server FPS was stable above 60 lowered false detections. A aggresive high ping kicker ( ppl with constatly changning ping get easly detected ) - Original Message - From: Jeffrey botman Broome [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 12:36 AM Subject: Re: [hlcoders] Speed hack detection? Jeff Fearn wrote: Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin? What I would do is keep a list of players currently on the server (store their edict as they connect along with their current location). The player's location can be obtained from the ICollideable::GetCollisionOrigin() function. If your server plugin GetFrame() function keep checking each player's current location every so often (say every 0.5 seconds). The current location (in the array of players that you keep in your plugin) becomes the previous location. Subtract the player's current location from the previous location to get a vector. Determine the length of that vector (the distance between now and then), and divide the distance by the time (to get speed, i.e. units/second). Store the new current location in the current location field of your array of players. If the speed calculated is above the server max, increment a hack counter. If the speed is below the server max, decrement the hack counter (not letting it fall below 0). When the hack counter reaches some maximum amount (let's say 6, which would be 3 seconds worth of compares), warn the player that the server thinks they are speed hacking and they will be given a 30 second grace period to turn it off or be banned from the server. Don't check them again for 30 seconds, then if they continue to reach the hack count, ban them. It's not fool proof and can lead to some false positives, but as long as you allow enough time between comparisons (the 0.5 second window) and as long as you require consecutive check failures (the counting to 6 thing), you should have less people failing due to high latency network connections. The only problem is how do you handle falling speeds (if you have a long drop that can last for 5 or 6 seconds) and how do you handle teleporters which will look like an intantaneous jump from point A to point B making a speed that approaches the speed of light! :) Again, averaging things out over several seconds should help avoid even these problems. -- 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit:
Re: [hlcoders] Speed hack detection?
Yes, that is kind of crazy really. But what is weird, if they are speeding up the clock would you foot alot faster and throw grenades faster etc? I seen the speed hack only 1 or 2 times and didnt' remember seeing them fire faster but it might be hard to tell dunno.. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Jeff Fearn [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 9:32 PM Subject: Re: [hlcoders] Speed hack detection? On 5/19/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: r00t 3:16 wrote: Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Usually the client's system clock is running faster (slower?) than normal, I can't remember which way the system clock needs to go to make the game engine think time is passing more slowly. Your client machine is running faster than normal so normal movement speed on your machine become high movement speed on the server (who's running on a different clock speed). If the client's game engine is ticking faster/slower than the server's game engine, the client will be able to move larger distances over the same amount of time. It's sort of like the reverse of Einstein's theory of relativity. Distances become smaller for people who are moving faster in time (or something like that). Surely this is where it should be caught by the engine. I don't mean the engine should ban/stop/warn the player, but that the engine should know that even though the cheater is saying this is tick 3000, the server is only at tick 2000, and thus the movement should not be processed until tick 3000. i.e even if the game plays faster on the cheaters computer, those extra ticks should not be processed inline by the server and should not be propigated to the other clients until it's the right time. Obviously I am very wrong, because if it was that easy it would be fixed ... google is my friend, I go visit him now ;) Jeff ___ 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] Speed hack detection?
What I find puzzling is why the hl/src server is not authorative over the players movement? How come it doesnt internally say, hey, you cant move that fast, im sorry, back you go to where you should be. Surely going on what the client says they should be in the map is rediculous. - Plasma - Original Message - From: r00t 3:16 [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 11:56 AM Subject: Re: [hlcoders] Speed hack detection? Yes, that is kind of crazy really. But what is weird, if they are speeding up the clock would you foot alot faster and throw grenades faster etc? I seen the speed hack only 1 or 2 times and didnt' remember seeing them fire faster but it might be hard to tell dunno.. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Jeff Fearn [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 9:32 PM Subject: Re: [hlcoders] Speed hack detection? On 5/19/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: r00t 3:16 wrote: Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Usually the client's system clock is running faster (slower?) than normal, I can't remember which way the system clock needs to go to make the game engine think time is passing more slowly. Your client machine is running faster than normal so normal movement speed on your machine become high movement speed on the server (who's running on a different clock speed). If the client's game engine is ticking faster/slower than the server's game engine, the client will be able to move larger distances over the same amount of time. It's sort of like the reverse of Einstein's theory of relativity. Distances become smaller for people who are moving faster in time (or something like that). Surely this is where it should be caught by the engine. I don't mean the engine should ban/stop/warn the player, but that the engine should know that even though the cheater is saying this is tick 3000, the server is only at tick 2000, and thus the movement should not be processed until tick 3000. i.e even if the game plays faster on the cheaters computer, those extra ticks should not be processed inline by the server and should not be propigated to the other clients until it's the right time. Obviously I am very wrong, because if it was that easy it would be fixed ... google is my friend, I go visit him now ;) Jeff ___ 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
Re: [hlcoders] Speed hack detection?
Yes, speed hacks enable you to fire faster. With a 6x speed hack you can empty a clip of the AK47 in practically no time. It doesn't let you reload faster, though. - Original Message - From: r00t 3:16 [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 6:56 PM Subject: Re: [hlcoders] Speed hack detection? Yes, that is kind of crazy really. But what is weird, if they are speeding up the clock would you foot alot faster and throw grenades faster etc? I seen the speed hack only 1 or 2 times and didnt' remember seeing them fire faster but it might be hard to tell dunno.. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Jeff Fearn [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 9:32 PM Subject: Re: [hlcoders] Speed hack detection? On 5/19/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: r00t 3:16 wrote: Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Usually the client's system clock is running faster (slower?) than normal, I can't remember which way the system clock needs to go to make the game engine think time is passing more slowly. Your client machine is running faster than normal so normal movement speed on your machine become high movement speed on the server (who's running on a different clock speed). If the client's game engine is ticking faster/slower than the server's game engine, the client will be able to move larger distances over the same amount of time. It's sort of like the reverse of Einstein's theory of relativity. Distances become smaller for people who are moving faster in time (or something like that). Surely this is where it should be caught by the engine. I don't mean the engine should ban/stop/warn the player, but that the engine should know that even though the cheater is saying this is tick 3000, the server is only at tick 2000, and thus the movement should not be processed until tick 3000. i.e even if the game plays faster on the cheaters computer, those extra ticks should not be processed inline by the server and should not be propigated to the other clients until it's the right time. Obviously I am very wrong, because if it was that easy it would be fixed ... google is my friend, I go visit him now ;) Jeff ___ 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
Re: [hlcoders] Speed hack detection?
but it should reload faster though cause reloading is tick based ? Weird stuff... I know in some other games you can turn the game speed up on the server. The first speed hack I ever seen was on one of those games and it was like the client had their game speed way up but the servers and the other clients had their's set to the normal. I guess that is what botman was saying... As Andrew said you would think the server would do sanity checks on those sort of things, because those seem to be a global variable? r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Daniel Jennings [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 10:22 PM Subject: Re: [hlcoders] Speed hack detection? Yes, speed hacks enable you to fire faster. With a 6x speed hack you can empty a clip of the AK47 in practically no time. It doesn't let you reload faster, though. - Original Message - From: r00t 3:16 [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 6:56 PM Subject: Re: [hlcoders] Speed hack detection? Yes, that is kind of crazy really. But what is weird, if they are speeding up the clock would you foot alot faster and throw grenades faster etc? I seen the speed hack only 1 or 2 times and didnt' remember seeing them fire faster but it might be hard to tell dunno.. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Jeff Fearn [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, May 18, 2005 9:32 PM Subject: Re: [hlcoders] Speed hack detection? On 5/19/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: r00t 3:16 wrote: Does anyone know (please do not post it if you do know) how the speed hack actually works? It seems they are somehow changing a variable in memory ? Or are they tricking the server somehow ? Usually the client's system clock is running faster (slower?) than normal, I can't remember which way the system clock needs to go to make the game engine think time is passing more slowly. Your client machine is running faster than normal so normal movement speed on your machine become high movement speed on the server (who's running on a different clock speed). If the client's game engine is ticking faster/slower than the server's game engine, the client will be able to move larger distances over the same amount of time. It's sort of like the reverse of Einstein's theory of relativity. Distances become smaller for people who are moving faster in time (or something like that). Surely this is where it should be caught by the engine. I don't mean the engine should ban/stop/warn the player, but that the engine should know that even though the cheater is saying this is tick 3000, the server is only at tick 2000, and thus the movement should not be processed until tick 3000. i.e even if the game plays faster on the cheaters computer, those extra ticks should not be processed inline by the server and should not be propigated to the other clients until it's the right time. Obviously I am very wrong, because if it was that easy it would be fixed ... google is my friend, I go visit him now ;) Jeff ___ 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
Re: [hlcoders] Speed hack detection?
At 07:51 PM 5/18/2005, root 3:16 wrote: but it should reload faster though cause reloading is tick based ? Weird stuff... Not wierd at all. The server's clock is what determine's server tick rate and therefore the timing of Think() functions. Server alone decides when you have reloaded. Michael A. Hobson email: [EMAIL PROTECTED] (310) 344-3585 (cell) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Why do the ladders work smooth in hl2 death match but not the sdk?
Subject sum's it up.. I try a ladder in hl2 death match and it is smooth as as be. No jerking on dm_lockdown map I install a fresh copy of the hl2mp sdk compile, run dm_lockdown go to the same ladder and get on it and it is jerky.. Once you get people in the server with the hl2mp sdk it really jerks badly going up or down ladders. Does anyone know why the hl2 death match code works fine but the hl2mp sdk does not? When using cl_showpos 1 on the ladder in Half Life 2 Deathmatch the z position doesn't not move at all. and your velocity is bounces from 0.03 to 0.00 In the hl2mp sdk z position bounces about 0.60 up and down and your velocity bounces from 1 - 8 and you aren't moving. Is it a bug of some sort with the sdk ? Any help would be greatly appreciated as I have spent about 2 hours trying to figure it out I thought it could of been my code but after doing some tests it is the hl2mp sdk code in general. I have not tried it with the MP SDK though r00t 3:16 CQC Gaming www.cqc-gaming.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Odd viewing problem.
quote from lamothe (windows game programing) In a FPS the camera angle will look like a fish eye lense, with things out side of the center of the players view looking round or distroted ^^ Excuse my typos Adam --- Spencer 'voogru' MacDonald [EMAIL PROTECTED] wrote: Yes, I set the FOV to several different positions, including 90, with no change. -Original Message- From: Jeffrey botman Broome [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 2:46 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Odd viewing problem. Spencer 'voogru' MacDonald wrote: Hello all, I'm having a problem that seems to be relating to the players viewing angles; basically I have a square area on a map. Are you using an FOV of 90? -- 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 http://ammahls.com __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Why do the ladders work smooth in hl2 death match but not the sdk?
QUOTE tests it is the hl2mp sdk code in general. I have not tried it with the MP SDK though /QUOTE Do you mean SP? --- r00t 3:16 [EMAIL PROTECTED] wrote: Subject sum's it up.. I try a ladder in hl2 death match and it is smooth as as be. No jerking on dm_lockdown map I install a fresh copy of the hl2mp sdk compile, run dm_lockdown go to the same ladder and get on it and it is jerky.. Once you get people in the server with the hl2mp sdk it really jerks badly going up or down ladders. Does anyone know why the hl2 death match code works fine but the hl2mp sdk does not? When using cl_showpos 1 on the ladder in Half Life 2 Deathmatch the z position doesn't not move at all. and your velocity is bounces from 0.03 to 0.00 In the hl2mp sdk z position bounces about 0.60 up and down and your velocity bounces from 1 - 8 and you aren't moving. Is it a bug of some sort with the sdk ? Any help would be greatly appreciated as I have spent about 2 hours trying to figure it out I thought it could of been my code but after doing some tests it is the hl2mp sdk code in general. I have not tried it with the MP SDK though r00t 3:16 CQC Gaming www.cqc-gaming.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders http://ammahls.com Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Why do the ladders work smooth in hl2 death match but not the sdk?
No the multiplayer code. Halflife 2 Multiplayer SDK Compared to the Half Life 2 Deathmatch.. The Half Life 2 Multiplayer SDK is the Half Life 2 Deathmatch code right? If so then why the big difference ? Load half life 2 deathmatch climb a ladder in dm_lockdown. Then install Half Life 2 Multiplayer SDK compile and climb a ladder in dm_lockdown.. HUGE difference. I just ran 2 tests again and it seems the velocity in hl2 deathmatch fluxuates from 0.00 - 0.01 that is standing still (hard to read tho cause it kind of is fast) Once on a ladder in hl2 deathmatch you velocity fluxuates about the same standing still but your z position does not fluxuate at all.. In the hl2mp sdk standing still your velocity is around 0.00 to 0.04 standing still On a ladder however standing still your velocity jumps all over the places and so does your z position which makes it very very jerky. Hope I explained that well enough :) r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 12:06 AM Subject: Re: [hlcoders] Why do the ladders work smooth in hl2 death match but not the sdk? QUOTE tests it is the hl2mp sdk code in general. I have not tried it with the MP SDK though /QUOTE Do you mean SP? --- r00t 3:16 [EMAIL PROTECTED] wrote: Subject sum's it up.. I try a ladder in hl2 death match and it is smooth as as be. No jerking on dm_lockdown map I install a fresh copy of the hl2mp sdk compile, run dm_lockdown go to the same ladder and get on it and it is jerky.. Once you get people in the server with the hl2mp sdk it really jerks badly going up or down ladders. Does anyone know why the hl2 death match code works fine but the hl2mp sdk does not? When using cl_showpos 1 on the ladder in Half Life 2 Deathmatch the z position doesn't not move at all. and your velocity is bounces from 0.03 to 0.00 In the hl2mp sdk z position bounces about 0.60 up and down and your velocity bounces from 1 - 8 and you aren't moving. Is it a bug of some sort with the sdk ? Any help would be greatly appreciated as I have spent about 2 hours trying to figure it out I thought it could of been my code but after doing some tests it is the hl2mp sdk code in general. I have not tried it with the MP SDK though r00t 3:16 CQC Gaming www.cqc-gaming.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders http://ammahls.com Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html ___ 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
[hlcoders] Mouse question ScreenToWorld question.
Hey all, Here's a trickier question, my mod is going to need to have a mouse _always_ enabled, and I was simply wondering how would I go about making the mouse always active without having an active view panel? Next to that, I need to know if it's possible to convert the mouse cursor position into world coordinates (like ScreenToWorld in HL1); I didn't see anything like this in the HL2 SDK. My intentions for this, is I want players to be able to hover over an *invisible to the eye* brush entity and be able to get information relating to that entity if they click on it. Hopefully this is possible, since I'm up the creek without a paddle if there is no way to do this. Any points in the right direction will be great. Thanks :) - voogru. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Why do the ladders work smooth in hl2 death match but not the sdk?
Yeah i can see what you mean DM_Underpass http://img265.echo.cx/img265/7127/dmunderpass00024wi.jpg HL2CTF http://img265.echo.cx/img265/3429/dmunderpass9lx.jpg HL2:DM I have more, but yeah, i can see what you mean --- r00t 3:16 [EMAIL PROTECTED] wrote: No the multiplayer code. Halflife 2 Multiplayer SDK Compared to the Half Life 2 Deathmatch.. The Half Life 2 Multiplayer SDK is the Half Life 2 Deathmatch code right? If so then why the big difference ? Load half life 2 deathmatch climb a ladder in dm_lockdown. Then install Half Life 2 Multiplayer SDK compile and climb a ladder in dm_lockdown.. HUGE difference. I just ran 2 tests again and it seems the velocity in hl2 deathmatch fluxuates from 0.00 - 0.01 that is standing still (hard to read tho cause it kind of is fast) Once on a ladder in hl2 deathmatch you velocity fluxuates about the same standing still but your z position does not fluxuate at all.. In the hl2mp sdk standing still your velocity is around 0.00 to 0.04 standing still On a ladder however standing still your velocity jumps all over the places and so does your z position which makes it very very jerky. Hope I explained that well enough :) r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, May 19, 2005 12:06 AM Subject: Re: [hlcoders] Why do the ladders work smooth in hl2 death match but not the sdk? QUOTE tests it is the hl2mp sdk code in general. I have not tried it with the MP SDK though /QUOTE Do you mean SP? --- r00t 3:16 [EMAIL PROTECTED] wrote: Subject sum's it up.. I try a ladder in hl2 death match and it is smooth as as be. No jerking on dm_lockdown map I install a fresh copy of the hl2mp sdk compile, run dm_lockdown go to the same ladder and get on it and it is jerky.. Once you get people in the server with the hl2mp sdk it really jerks badly going up or down ladders. Does anyone know why the hl2 death match code works fine but the hl2mp sdk does not? When using cl_showpos 1 on the ladder in Half Life 2 Deathmatch the z position doesn't not move at all. and your velocity is bounces from 0.03 to 0.00 In the hl2mp sdk z position bounces about 0.60 up and down and your velocity bounces from 1 - 8 and you aren't moving. Is it a bug of some sort with the sdk ? Any help would be greatly appreciated as I have spent about 2 hours trying to figure it out I thought it could of been my code but after doing some tests it is the hl2mp sdk code in general. I have not tried it with the MP SDK though r00t 3:16 CQC Gaming www.cqc-gaming.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders http://ammahls.com Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html ___ 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 http://ammahls.com __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
