User login
Recording!
3. February 2007 - 21:05
All we know that recording yourself when playing online puts you in great lags becouse of g_synchronousclients 1 setting.
But I tried such binds:
bind F5 "g_synchronousclients 1; record; g_synchronousclients 0"
bind F6 "g_synchronousclients 0; stoprecord"
And it records without any lags!! I just disable g_synchronousclients after record command and lags vanishes!
How is this possible? Maybe some lag remains but I dont notice it? Or demos become corrupted somehow? (I didnt noticed any of these though).
Post what you think!
3. February 2007 - 21:44
#1
Recording!
um, thats what everyone uses 
lag is because your ping affects everything then. inlcuding mouse
3. February 2007 - 22:08
#2
![*A*C|_ASS*WON]<O](/files/screenname/9a0723bc4b1ab460d3d2236ff9b9abc1.webp "*A*C|_ASS*WON]<O"){kind=small}
Recording!
Quote:
All we know that recording yourself when playing online puts you in great lags becouse of g_synchronousclients 1 setting.
But I tried such binds:bind F5 "g_synchronousclients 1; record; g_synchronousclients 0"
bind F6 "g_synchronousclients 0; stoprecord"And it records without any lags!! I just disable g_synchronousclients after record command and lags vanishes!
How is this possible? Maybe some lag remains but I dont notice it? Or demos become corrupted somehow? (I didnt noticed any of these though).
Post what you think!
theres this weird, wacko, out-there, never-heard-before concept called GOOGLE. USE IT!
anyway. the synchronous thingy.
its not lag. it has more to do with ur gameworld updates, from what i know. (umm maybe gameworld update is the wrong term but anyway).
what g_synchronousclients 1 does is, it makes ur client wait till every other client updates. this means that u receive info only when every other client updates. hence the frame-lag (dont know what else to call it). hence the whole script to change sync, then record, then change sync back to 0 again, becomes necassary.
note that if u try this on a client side single player game, ur demo ends up "lagged". which is damn annoying cos inspite of the fact that nothing should change if ur using g_synchronousclients 1 on a client side game (cos ur the only client), physics does change for some reason. probly some redundant code that shouldnt be there on a client side synch.
ps: would be real nice to have a feature similar to the autorecord command in cpma. it eliminates the need for playing with synch, and also names demos intelligently. should be pretty easy to implement too.
3. February 2007 - 23:33
#3
Recording!
wrote:ps: would be real nice to have a feature similar to the autorecord command in cpma. it eliminates the need for playing with synch, and also names demos intelligently. should be pretty easy to implement too.
yep, vote f1 for this one 
3. February 2007 - 23:51
#5
Recording!
what causes lag is G_SyncronousClients 1
and you cant put record on without having it set.
But you CAN put it on, start record, then put it off to get rid of the lag.
What im saying is: record works without it, only quake CVARS think it wont work
4. February 2007 - 1:13
#6
Recording!
wrote:What im saying is: record works without it, only quake CVARS think it wont work
This is exactly what I care about - why then nobody knows that its possible to record w/o LAG? Why? ... 
Maybe there are some issues? 
4. February 2007 - 1:17
#7
Recording!
wrote:why then nobody knows that its possible to record w/o LAG?
hm?
just about everybody DOES know that i mean just check the ranking forums and the ammount of demos posted there
4. February 2007 - 4:19
#8
asdfasdf
umm. dude. do u mind trying to READ? pls?
ps. foksie. umm record doesnt really work without g_synch 1. unless ur on a client side single player game, or ur playing from the server client. (dont know if thats even possible heh). the reason y record only works in q3 if u have synch on is that the recording doesnt take into account the normal info getting routines in the engine. (I THINK. could be wrong). instead it only stores data received at certain fixed intervals. and the synching is done so the data can be retrieved from all clients at a single point in time. the whole thing is necassary cos recording every piece of info using the normal routine, (ie every gameworld update i suppose) is cumbersome and will probly fuck the normal working of the game up.
least ways thats the reason y i THINK g_sych needs to be 1. ofc its probly a lot more complicated.
4. February 2007 - 4:31
#9
Recording!
ok. with a little help from a promode friend. dug up this article.
Quote:
On Synchronous Q3A [April 30, 1999, 08:49 am ET] - Post a Comment
John Carmack made a .plan update revealing that there is a synchronous networking mode in Quake III Arena. Here's the poop:technical note:
Q3 can run networked player movement in either an asynchronous or synchronous manner. The default mode is to allow all client movement to be done asynchronously with the servers advancement of time.
The primary reason is to allow player movement to be predicted on the client side. The primary drawback is that while your movement is smooth, the other players that you see running around in the world move with a jerkiness that is relative to their framerate and network connection quality. It is NOT necessarily relative to their ping - a player on a fast system with a clean modem connection can move smoothly. If you see a player stuttering around, either they have a bad franerate, or the network connection between them and the server or you and the server is poor. The amount of stuttering is sort of the sum of the dropped or variable packets on BOTH connections.
You can force Q3 to run all clients synchronously by setting "g_synchronousClients 1" on the server. This will make Q3 behave similar to Q1 for networking. All movement will be lagged except view angles, which are still short-circuited immediately.
Some people claim to prefer synchronous movement when everyone had a very good ping, but I don't personally think it is ever a play benefit. It makes leading players a bit easier, but I think the crisp movement control of client side prediction is a much better tradeoff.
However, there is still a reason for using it: recorded demos come out a LOT smoother looking when running with sync. Note that q3test does not allow demo recording and playback, so this is just for future reference...
ps: sorry for long quote.
4. February 2007 - 11:37
#10
Germany
Re: Recording!
wrote:
bind F5 "g_synchronousclients 1; record; g_synchronousclients 0"
bind F6 "g_synchronousclients 0; stoprecord"
delete the g_syn in the f6 there, pretty senseless.
btw g_synchronousclients 1 fixxes jumplagging
Shout 07:17:54
: Steff, traitor. That’s a valid message
: Enter a valid Message
: Me, lol
: hello!
: I hope you had a good reason to be absent. Get well soon, my friend.
: Impressive
: I am half Russian and half black. I'm black on the bottom half. Don't forget to lubricate your ass
: ok, bring it on analbolic hohol
: Come tomorrow to watch my battle with ShadyХУЙ at SexyFraggers 8 on central european, 22:00 Moscow time. He said he would win because he was a deft monkey. ХУЙ don't forget to put on makeup, I'll record us on video. You must be beautiful.
: broheim it is oke!!! I saw Moldova elections on the news, and referendum before that. HOPE life will get better (but nothing ever changes)
Who's online
There are currently 1 user and 3 guests online.
Didnt you read my post or I didnt understood the way you understood it?
I wanted someone explain me THIS:
I put g_sync to 1, invoke record, and then while recording put g_sync back to 0 and whole lag disappears, though demo records as normal.