Ah I think I'm starting to see how the pieces fit together then. I was thrown off by all the FX code, thinking it was a client-side function, but there's a surprisingly useful comment at the top of FX_FireBullets:
// This runs on both the client and the server. // On the server, it only does the damage calculations. // On the client, it does all the effects. So client-rendering prediction is completely unrelated to all of this. It looks like bullet weapons should still be fine (which is what I tested previously, and they did seem fine) but that bludgeon weapons in the SDK are no broken with respect to lag-compensated hit detection. I'll look into that more. At 2006/09/23 04:18 AM, Garry Newman wrote: >-- >[ Picked text/plain from multipart/alternative ] >I think it's the other way around. > >The server is moving the other players back to where it thinks they were >when you fired the bullets, then tracing and seeing if you hit then, then >moving them back. > > > >On 9/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> >wrote: >> >> Forgive my perhaps naive question, but if you only lag compensate during >> bullet firing, and not the rest of the time, won't you be rendering your >> opponents on screen in the wrong position? >> >> At 2006/09/22 06:48 PM, Teddy wrote: >> >In the new SDK, StartLagCompensation happens on line #193 of >> >sdk_fx_shared.cpp, during the FX_FireBullets() function. It's done >> >here so it doesn't effect player movement (aka sticky player >> >collisions). The problem with this is if your weapon needs unlagged >> >positions for anything other than firing bullets, it won't work. >> > >> >I would recommend you instead StartLagCompensation before >> >RunPostThink( player ) in the CPlayerMove::RunCommand() function. >> > >> >On 9/23/06, Robbie Groenewoudt <[EMAIL PROTECTED]> wrote: >> >>-- >> >>[ Picked text/plain from multipart/alternative ] >> >>Damn, you are right. There's no StartLagCompensation-call in the entire >> >>code. I don't see any reason why it isn't because it worked good. In the >> new >> >>SDK-code the lagcompensation-code is even expended... It's a bug I >> guess.... >> >> >> >>On 9/22/06, Paul Peloski <[EMAIL PROTECTED]> wrote: >> >>> >> >>> -- >> >>> [ Picked text/plain from multipart/alternative ] >> >>> I'm at home now, sv_showlagcompensation the right name, it's >> implemented >> >>> in >> >>> player_lagcompensation.cpp with the following description: "Show lag >> >>> compensated hitboxes whenever a player is lag compensated." >> >>> >> >>> If you compare the file player_command.cpp between the old SDK source >> and >> >>> the Aug 11 source, you should notice that the call to >> StartLagCompensation >> >>> is missing from CPlayerMove::StartCommand in player_command.cpp >> >>> >> >>> I wondered about this when I merged the new SDK, and decided to keep >> the >> >>> startLagCompensation for our mod and haven't had any problems with >> shots >> >>> registering. Maybe this is a bug in the new SDK? >> >>> >> >>> On 9/22/06, [EMAIL PROTECTED] < >> [EMAIL PROTECTED] >> >>> > >> >>> wrote: >> >>> > >> >>> > Closest I see is player_showpredictedposition, but it doesn't seem >> to >> >>> > visually change anything at all. >> >>> > >> >>> > At 2006/09/21 08:41 AM, Paul Peloski wrote: >> >>> > >-- >> >>> > >[ Picked text/plain from multipart/alternative ] >> >>> > >Check that the lag compensation system is still being used to move >> >>> > entities >> >>> > >when a player is shooting, IIRC you can use sv_showlagcompensation >> 1 or >> >>> > >something similar to show some hitboxes when a player is being lag >> >>> > >compensated (ie, you have to be shooting at him and lag >> compensation >> >>> has >> >>> > to >> >>> > >be turned on, etc.) I remember the >> >>> lagcompensation->StartLagCompensation >> >>> > was >> >>> > >missing in the player command code on the server side with regard >> to >> >>> the >> >>> > lag >> >>> > >compensation system when I first merged with the new SDK. >> >>> > > >> >>> > >Sorry I can't be more specific, I'm at work and don't have access >> to >> >>> the >> >>> > SDK >> >>> > >right now. >> >>> > > >> >>> > >On 9/21/06, [EMAIL PROTECTED] < >> >>> > [EMAIL PROTECTED]> >> >>> > >wrote: >> >>> > >> >> >>> > >> I'm getting lots of complaints from my user base that, following >> the >> >>> > SDK >> >>> > >> update, lag prediction has gotten worse. Has anyone else >> experienced >> >>> > >> this? I haven't really experienced much of a change, but then I >> >>> don't >> >>> > have >> >>> > >> as large of a ping to any of my mod's servers as some of my users >> do. >> >>> > >> >> >>> > >> After receiving complaints a few days ago I reviewed SDK changes >> and >> >>> > >> noticed massive amounts of code changes around prediction. But >> most >> >>> of >> >>> > it >> >>> > >> seems to be centered around the creation of a seemingly unused >> and >> >>> > pointless >> >>> > >> NO_ENTITY_PREDICTION define to segregate out the prediction >> >>> > code. Maybe >> >>> > >> it's used by Valve for debugging or something? >> >>> > >> >> >>> > >> It's unclear whether any behavioral changes exist - anyone found >> >>> > evidence >> >>> > >> of any? Unfortunately we got a years worth of SDK code thrash in >> one >> >>> > patch, >> >>> > >> so it's a bit much to try to code review. >> >>> > >> >> >>> > >> -bk >> >>> > >> >> >>> > >> _______________________________________________ >> >>> > >> To unsubscribe, edit your list preferences, or view the list >> >>> archives, >> >>> > >> please visit: >> >>> > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >>> > >> >> >>> > >> >> >>> > >-- >> >>> > > >> >>> > >_______________________________________________ >> >>> > >To unsubscribe, edit your list preferences, or view the list >> archives, >> >>> > please visit: >> >>> > >http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >>> > >> >>> > _______________________________________________ >> >>> > To unsubscribe, edit your list preferences, or view the list >> archives, >> >>> > please visit: >> >>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >>> > >> >>> > >> >>> -- >> >>> >> >>> _______________________________________________ >> >>> To unsubscribe, edit your list preferences, or view the list archives, >> >>> please visit: >> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >>> >> >>> >> >>-- >> >> >> >>_______________________________________________ >> >>To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> >>http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > >> >_______________________________________________ >> >To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> >http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >-- > >_______________________________________________ >To unsubscribe, edit your list preferences, or view the list archives, please >visit: >http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
