Re: [hlcoders] gpGlobals->curtime inaccessable from animationlayer.h
-- [ Picked text/plain from multipart/alternative ] Thanks that worked out! ~M It's because one of the header files that BaseAnimatingOverlay.cpp > includes goes back and defines that class. You need to include the > header file that defines it by adding: > > #include "globalvars_base.h" -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] gpGlobals->curtime inaccessable from animationlayer.h
It's because one of the header files that BaseAnimatingOverlay.cpp includes goes back and defines that class. You need to include the header file that defines it by adding: #include "globalvars_base.h" Michael Chang wrote: -- [ Picked text/plain from multipart/alternative ] Hello once again guys. I'm trying to implement clientside SetAnimation() so it required me to much around in animationlayer.h One of the required functions that I needed to duplicate was Init() from BaseAnimatingOverlays. Inside Init, there's a call to gpGlobals->curtime to store last time stamp a frame was accessed (I think). However in implementing the same function on animationlayer.h, my compiler tells me Error1error C2027: use of undefined type 'CGlobalVarsBase' c:\bb\src\cl_dll\animationlayer.h102 How come BaseAnimatingOverlays has access to CGlobalVarsBase but not animationlayer? Is it because animationlayer is a header, and won't have scope of that variable? If that's the case, should I create some form of animationlayers.cpp in order to obtain such scope? Thanks guys. I'm a bit rusty with my C++ so bear with me. ~M -- ___ 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] gpGlobals->curtime
I guess I don't get a reply then. Oh well. On Sun, 2006-06-04 at 01:57 -0500, John Sheu wrote: > On Sat, 2006-06-03 at 18:45 -0500, [EMAIL PROTECTED] wrote: > > Not sure if that helps clear things up for you, or if I'm on a tangent. :) > > That's great and all, and rather informative, but I'm afraid you're on a > tangent. The question is this: what kind of timebase is the client > rendering on? Does it try to be exactly synchronized with the server, > regardless of latency, or does it just monotonically increase its > current time as it receives packets? Again, two scenarios: > > If the former is true, then for a client and server of any > arbitrary latency, curtime is exactly synchronized. > > If the latter is true, then for a client and server of X seconds > round-trip latency, curtime on the client (when rendering) is > X/2 seconds behind curtime on the server. > > Which one? > > -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] gpGlobals->curtime
On Sat, 2006-06-03 at 18:45 -0500, [EMAIL PROTECTED] wrote: > Not sure if that helps clear things up for you, or if I'm on a tangent. :) That's great and all, and rather informative, but I'm afraid you're on a tangent. The question is this: what kind of timebase is the client rendering on? Does it try to be exactly synchronized with the server, regardless of latency, or does it just monotonically increase its current time as it receives packets? Again, two scenarios: If the former is true, then for a client and server of any arbitrary latency, curtime is exactly synchronized. If the latter is true, then for a client and server of X seconds round-trip latency, curtime on the client (when rendering) is X/2 seconds behind curtime on the server. Which one? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] gpGlobals->curtime
Apparently this curtime fluctuation issue to is due to ConCommands not being handled within CServerGameDLL::GameFrame() but instead starting from within the ConCommand::Dispatch() callback. This is all very bizarre, and what few comments there are on this are things like // tickcount currently isn't set during prediction, although gpGlobals->curtime and // gpGlobals->frametime are. We should probably set tickcount (to player->m_nTickBase), // but we're REALLY close to shipping, so we can change that later and people can use // player->CurrentCommandNumber() in the meantime. which leads me to believe there are known limitations here that just aren't otherwise documented. It's not clear whether the GameFrame/Dispatch dichotomy was intentional or a bug. The upshot is that, apparently, you should never do anything involving simulation time inside a console command. Instead it looks like the only reliable process is to set flags and such inside the ConCommand, and then wait until later in the CServerGameDLL::GameFrame() callback inside PhysicsSimulate etc to actually make use of the command data that was fed in. Confirmation from someone (presumably Valve) that the above statement is true and there is no simple work around to this limitation/bug would be helpful. Not sure if that helps clear things up for you, or if I'm on a tangent. :) At 2006/06/03 02:04 PM, Tony \"omega\" Sergi wrote: >He's probably referring to network snapshots, where it may run code at x >time; for a previous snapshot, for prediction purposes and whatnot. > >-- >-- omega >Heroes of Excelsior >http://www.heroesofexcelsior.com >Blackened Interactive >http://www.blackened-interactive.com > >> -Original Message- >> From: John Sheu [mailto:[EMAIL PROTECTED] >> Sent: June 3, 2006 2:36 PM >> To: hlcoders@list.valvesoftware.com >> Subject: Re: [hlcoders] gpGlobals->curtime >> >> On Sat, 2006-06-03 at 13:21 -0500, [EMAIL PROTECTED] wrote: >> > Coincidentally I'd just been doing some more research into gpGlobals- >> >curtime server-side. Not sure if this applies to client-side too, >> however it seems that gpGlobals->curtime server side is able to go >> slightly backwards in some situations. Apparently it depends on what call >> back is occurring to get you to the mod code. >> > >> > My guess is that when the server is compensating for lagged packets it >> sets curtime to the time it thinks the thing should have happened? This >> is all very sketchy, but at least it seems more reasonable than realtime. >> >> That seems entirely plausible, but I've never seen it happen. On which >> callbacks is gpGlobals->curtime reversing server-side? In any case, I >> think there is less reason (other than that outlined above) for curtime >> to change server-side than client-side. >> >> As an aside, I considered tacking this onto the end of your realtime >> thread, but decided that it's sufficiently different to warrant a new >> thread. :) >> >> -John Sheu >> >> ___ > > >___ >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] gpGlobals->curtime
He's probably referring to network snapshots, where it may run code at x time; for a previous snapshot, for prediction purposes and whatnot. -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com > -Original Message- > From: John Sheu [mailto:[EMAIL PROTECTED] > Sent: June 3, 2006 2:36 PM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] gpGlobals->curtime > > On Sat, 2006-06-03 at 13:21 -0500, [EMAIL PROTECTED] wrote: > > Coincidentally I'd just been doing some more research into gpGlobals- > >curtime server-side. Not sure if this applies to client-side too, > however it seems that gpGlobals->curtime server side is able to go > slightly backwards in some situations. Apparently it depends on what call > back is occurring to get you to the mod code. > > > > My guess is that when the server is compensating for lagged packets it > sets curtime to the time it thinks the thing should have happened? This > is all very sketchy, but at least it seems more reasonable than realtime. > > That seems entirely plausible, but I've never seen it happen. On which > callbacks is gpGlobals->curtime reversing server-side? In any case, I > think there is less reason (other than that outlined above) for curtime > to change server-side than client-side. > > As an aside, I considered tacking this onto the end of your realtime > thread, but decided that it's sufficiently different to warrant a new > thread. :) > > -John Sheu > > ___ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] gpGlobals->curtime
On Sat, 2006-06-03 at 13:21 -0500, [EMAIL PROTECTED] wrote: > Coincidentally I'd just been doing some more research into gpGlobals->curtime > server-side. Not sure if this applies to client-side too, however it seems > that gpGlobals->curtime server side is able to go slightly backwards in some > situations. Apparently it depends on what call back is occurring to get you > to the mod code. > > My guess is that when the server is compensating for lagged packets it sets > curtime to the time it thinks the thing should have happened? This is all > very sketchy, but at least it seems more reasonable than realtime. That seems entirely plausible, but I've never seen it happen. On which callbacks is gpGlobals->curtime reversing server-side? In any case, I think there is less reason (other than that outlined above) for curtime to change server-side than client-side. As an aside, I considered tacking this onto the end of your realtime thread, but decided that it's sufficiently different to warrant a new thread. :) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] gpGlobals->curtime
Coincidentally I'd just been doing some more research into gpGlobals->curtime server-side. Not sure if this applies to client-side too, however it seems that gpGlobals->curtime server side is able to go slightly backwards in some situations. Apparently it depends on what call back is occurring to get you to the mod code. My guess is that when the server is compensating for lagged packets it sets curtime to the time it thinks the thing should have happened? This is all very sketchy, but at least it seems more reasonable than realtime. At 2006/06/01 11:24 PM, you wrote: >I'm trying to get my head around the synchronization of curtime between >and server. First, a few comments, from globalvars_base.h: > >// Current time >// >// On the client, this (along with tickcount) takes a different meaning >// based on what piece of code you're in: >// >// - While receiving network packets (like in PreDataUpdate/ >// PostDataUpdate and proxies), this is set to the SERVER TICKCOUNT >// for that packet. There is no interval between the server ticks. >// [server_current_Tick * tick_interval] >// >// - While rendering, this is the exact client clock >// [(client_current_tick + interpolation_amount) * tick_interval] >// >// - During prediction, this is based on the client's current tick: >// [client_current_tick * tick_interval] > >So, as I understand it client-side, in PreDataUpdate/PostDataUpdate (and >perhaps OnDataChanged as well?) gpGlobals->curtime is set to what >gpGlobals->curtime was on the server when this particular data update >was stuffed into the pipeline. > >When rendering, though, what is the curtime? As I see it, there are two >possibilities: > >The client's current tick tries to sync with what it thinks the >server's current tick is. Thus, in a perfect situation, if the >server is at tick 12, the client's tick is at 12, even if the >last packet received was stamped with a tickcount of 9. > >The client's current tick is only barely ahead of its last >received tick. If the server is at tick 12, but the client's >last received packet is at tick 9, then the client will be >rendering at somewhere between tick 9 and 10 (subject to >interpolation_amount above). > >Which one of these is true? And which one of the three "different >meanings of curtime" is used during entity thinking and IGameSystem >updating? (I suspect the render one, but I can't be sure.) > >-John Sheu > >___ >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
