Re: [hlcoders] Linux build prediction? issues
Alfred Reynolds took care of the prediction if I recall correctly. - ScarT On 21 March 2011 23:25, Maarten De Meyer maar...@off-limits.be wrote: Bit of an old thread, but unfortunately I'm going to have to come back to it: I'm afraid I was mistaken too. IsFirstTimePredicted did fix some issues graphically, but some things are still seerriously fubar on our linux (dedicated server) build related to how client-side prediction behaves. I'm out of ideas here, and we planned to go public this friday. I'm guessing there's no direct contact person at valve for issues like this? On 25/01/2011 1:56, Andrew Ritchie wrote: Originally I had thought it would have been fixed with the IsFirstTimePredicted check as well, but even with that, I found our frames were being rolled back and for whatever reason the system wasn't marking the already predicted frames as handled, or at least resetting it. We wrapped a test case in the base MP5 provided with the SDK and could recreate the prediction issues consistently, so might have run that by the latest SDK and see if it still happens. On Mon, Jan 24, 2011 at 11:11 PM, Nick xnicho...@gmail.com wrote: If it is a problem with the valve sdk, then don't even try to fix it, track the problem down, send valve a detailed report, and hope for the best. On Mon, Jan 24, 2011 at 3:06 PM, Maarten De Meyer maar...@off-limits.be wrote: I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get
Re: [hlcoders] Linux build prediction? issues
No it was Yahn. Alfred is/was in charge of Linux support though, so copy them both in. On 21/03/2011 10:30, Tobias Kammersgaard wrote: Alfred Reynolds took care of the prediction if I recall correctly. - ScarT On 21 March 2011 23:25, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Bit of an old thread, but unfortunately I'm going to have to come back to it: I'm afraid I was mistaken too. IsFirstTimePredicted did fix some issues graphically, but some things are still seerriously fubar on our linux (dedicated server) build related to how client-side prediction behaves. I'm out of ideas here, and we planned to go public this friday. I'm guessing there's no direct contact person at valve for issues like this? On 25/01/2011 1:56, Andrew Ritchie wrote: Originally I had thought it would have been fixed with the IsFirstTimePredicted check as well, but even with that, I found our frames were being rolled back and for whatever reason the system wasn't marking the already predicted frames as handled, or at least resetting it. We wrapped a test case in the base MP5 provided with the SDK and could recreate the prediction issues consistently, so might have run that by the latest SDK and see if it still happens. On Mon, Jan 24, 2011 at 11:11 PM, Nick xnicho...@gmail.com mailto:xnicho...@gmail.com wrote: If it is a problem with the valve sdk, then don't even try to fix it, track the problem down, send valve a detailed report, and hope for the best. On Mon, Jan 24, 2011 at 3:06 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over
Re: [hlcoders] Linux build prediction? issues
Did you think about recording with a digital camera of a stopwatch and your monitor? Would be much more scientific. is this with the latest unmodified valve hl2mp sdk + linux server? shouldn't be that hard to setup,,, On Tue, Jan 25, 2011 at 5:32 AM, Adam amckern McKern amck...@yahoo.comwrote: Why i asked is becuase this was recorded directly through camista - single player, high end computer http://www.youtube.com/watch?v=Dh6Z9MqZ3JAfeature=player_profilepage Notice that the default shot gun is VERY lagged? Owner Nigredo Studios http://www.nigredostudios.com --- On *Tue, 25/1/11, Jed j...@wunderboy.org* wrote: From: Jed j...@wunderboy.org Subject: Re: [hlcoders] Linux build prediction? issues To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Tuesday, 25 January, 2011, 8:06 PM Hmm... If find your comments on the MuzzleFlash prediction interesting because it's been something I've had issues with continually. I admit, I'm still using the Source SDK 2006, but I've always had an issue with muzzleflashes and case ejection events repeating (up to half a second after the original shot) but the actual shot only coming once. I might have to dig deeper. - Jed On 24 January 2011 22:06, Maarten De Meyer maar...@off-limits.behttp://mc/compose?to=maar...@off-limits.be wrote: I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.behttp://mc/compose?to=maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also
Re: [hlcoders] Linux build prediction? issues
Nick, Please try and keep this about programming or at least video games - if you want to talk about stop watches, then please find the correct new group :). Owner Nigredo Studios http://www.nigredostudios.com --- On Fri, 28/1/11, Nick xnicho...@gmail.com wrote: From: Nick xnicho...@gmail.com Subject: Re: [hlcoders] Linux build prediction? issues To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Friday, 28 January, 2011, 2:41 PM Did you think about recording with a digital camera of a stopwatch and your monitor? Would be much more scientific. is this with the latest unmodified valve hl2mp sdk + linux server? shouldn't be that hard to setup,,, On Tue, Jan 25, 2011 at 5:32 AM, Adam amckern McKern amck...@yahoo.com wrote: Why i asked is becuase this was recorded directly through camista - single player, high end computer http://www.youtube.com/watch?v=Dh6Z9MqZ3JAfeature=player_profilepage Notice that the default shot gun is VERY lagged? Owner Nigredo Studios http://www.nigredostudios.com --- On Tue, 25/1/11, Jed j...@wunderboy.org wrote: From: Jed j...@wunderboy.org Subject: Re: [hlcoders] Linux build prediction? issues To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Tuesday, 25 January, 2011, 8:06 PM Hmm... If find your comments on the MuzzleFlash prediction interesting because it's been something I've had issues with continually. I admit, I'm still using the Source SDK 2006, but I've always had an issue with muzzleflashes and case ejection events repeating (up to half a second after the original shot) but the actual shot only coming once. I might have to dig deeper. - Jed On 24 January 2011 22:06, Maarten De Meyer maar...@off-limits.be wrote: I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your
Re: [hlcoders] Linux build prediction? issues
Hmm... If find your comments on the MuzzleFlash prediction interesting because it's been something I've had issues with continually. I admit, I'm still using the Source SDK 2006, but I've always had an issue with muzzleflashes and case ejection events repeating (up to half a second after the original shot) but the actual shot only coming once. I might have to dig deeper. - Jed On 24 January 2011 22:06, Maarten De Meyer maar...@off-limits.be wrote: I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ 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:
Re: [hlcoders] Linux build prediction? issues
Why i asked is becuase this was recorded directly through camista - single player, high end computer http://www.youtube.com/watch?v=Dh6Z9MqZ3JAfeature=player_profilepage Notice that the default shot gun is VERY lagged? Owner Nigredo Studios http://www.nigredostudios.com --- On Tue, 25/1/11, Jed j...@wunderboy.org wrote: From: Jed j...@wunderboy.org Subject: Re: [hlcoders] Linux build prediction? issues To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Tuesday, 25 January, 2011, 8:06 PM Hmm... If find your comments on the MuzzleFlash prediction interesting because it's been something I've had issues with continually. I admit, I'm still using the Source SDK 2006, but I've always had an issue with muzzleflashes and case ejection events repeating (up to half a second after the original shot) but the actual shot only coming once. I might have to dig deeper. - Jed On 24 January 2011 22:06, Maarten De Meyer maar...@off-limits.be wrote: I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux build prediction? issues
I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ 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] Linux build prediction? issues
If it is a problem with the valve sdk, then don't even try to fix it, track the problem down, send valve a detailed report, and hope for the best. On Mon, Jan 24, 2011 at 3:06 PM, Maarten De Meyer maar...@off-limits.be wrote: I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ 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] Linux build prediction? issues
Originally I had thought it would have been fixed with the IsFirstTimePredicted check as well, but even with that, I found our frames were being rolled back and for whatever reason the system wasn't marking the already predicted frames as handled, or at least resetting it. We wrapped a test case in the base MP5 provided with the SDK and could recreate the prediction issues consistently, so might have run that by the latest SDK and see if it still happens. On Mon, Jan 24, 2011 at 11:11 PM, Nick xnicho...@gmail.com wrote: If it is a problem with the valve sdk, then don't even try to fix it, track the problem down, send valve a detailed report, and hope for the best. On Mon, Jan 24, 2011 at 3:06 PM, Maarten De Meyer maar...@off-limits.be wrote: I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ 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
Re: [hlcoders] Linux build prediction? issues
Do you find your predection is broken when you record a local server demo? I know that one of the 'patches' on the VDC breaks the anaimtion, and predection stuff. Owner Nigredo Studios http://www.nigredostudios.com --- On Tue, 25/1/11, Andrew Ritchie gotta...@gmail.com wrote: From: Andrew Ritchie gotta...@gmail.com Subject: Re: [hlcoders] Linux build prediction? issues To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Tuesday, 25 January, 2011, 11:56 AM Originally I had thought it would have been fixed with the IsFirstTimePredicted check as well, but even with that, I found our frames were being rolled back and for whatever reason the system wasn't marking the already predicted frames as handled, or at least resetting it. We wrapped a test case in the base MP5 provided with the SDK and could recreate the prediction issues consistently, so might have run that by the latest SDK and see if it still happens. On Mon, Jan 24, 2011 at 11:11 PM, Nick xnicho...@gmail.com wrote: If it is a problem with the valve sdk, then don't even try to fix it, track the problem down, send valve a detailed report, and hope for the best. On Mon, Jan 24, 2011 at 3:06 PM, Maarten De Meyer maar...@off-limits.be wrote: I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what
[hlcoders] Linux build prediction? issues
Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux build prediction? issues
I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.bewrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ 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
