Recording!

12 replies [Last post]

3. February 2007 - 22:05

Offline

Joined: Feb 2006

Posts:

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 - 22:44

Offline

Joined: Jun 2005

Posts:

Recording!

um, thats what everyone uses

lag is because your ping affects everything then. inlcuding mouse

I am proud of spreading a pirated Excessive Plus version and claim to be the original author, yay!

3. February 2007 - 23:08

Offline

Joined: Jul 2006

Posts:

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.

#e+pickup #excessiveplus #class.clan

4. February 2007 - 0:33

Offline

Joined: Jun 2005

Posts:

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

I am proud of spreading a pirated Excessive Plus version and claim to be the original author, yay!

4. February 2007 - 0:45

Offline

Joined: Feb 2006

Posts:

Recording!

Didnt you read my post or I didnt understood the way you understood it?

I wanted someone explain me THIS:

Quote:

bind F5 "g_synchronousclients 1; record; g_synchronousclients 0"

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.

4. February 2007 - 0:51

Offline

Joined: Jun 2005

Posts:

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

I am proud of spreading a pirated Excessive Plus version and claim to be the original author, yay!

4. February 2007 - 2:13

Offline

Joined: Feb 2006

Posts:

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 - 2:17

Offline

Joined: Jun 2005

Posts:

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

I am proud of spreading a pirated Excessive Plus version and claim to be the original author, yay!

4. February 2007 - 5:19

Offline

Joined: Jul 2006

Posts:

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.

#e+pickup #excessiveplus #class.clan

4. February 2007 - 5:31

Offline

Joined: Jul 2006

Posts:

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.

#e+pickup #excessiveplus #class.clan

4. February 2007 - 12:37

#10

Offline

Joined: Dec 2005

Posts:

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

hurrenson: "This idiot is apparently not familiar with a rail/sniper style."

Shout 01:32:06

CZE|BEAZT : Hey khaz. Yop would be nice to go back into the 2006 or 2007 for example and enjoy this game with all of those great people. We had a great times.