Jump to content
Sign in to follow this  
deady

JIP Lag

Recommended Posts

Sure we can check with scripts if object still exists or a certain timeframe has passed. 3-4 seconds you say, this is probably on a server running at maximum fps with not too much going on? How does it work out when 4 players are connecting in a 20 player game that runs at ~25 server fps and a bandwidth output of 1500kbit and input of 300kbit?

Share this post


Link to post
Share on other sites

UNN, I noticed that time is always 0 for clients when they first connect and set up the map (init objects).. this is true for JIP also. Then the server syncs the time variable.

I was trying a if (not isnull this) then {do something} for all setVehicleInits... but it seems like the object "exists" for that 1 second and then is killed.

I think I get publicVariable and JIP now.

server:

pubvar = 3;

publicVariable "pubvar";

pubvar = 4;

client on JIP will have pubvar set to 3, the last value that was broadcast.

So... what if we publicVariable "pubvar" on client connect? Then it gets 4. I think..

Share this post


Link to post
Share on other sites
Quote[/b] ]How does it work out when 4 players are connecting in a 20 player game that runs at ~25 server fps and a bandwidth output of 1500kbit and input of 300kbit?

Can't say for sure until I test it under those conditions. But I'm certainly going to try and push those commands to thier limit. I suspect it will be no worse than calling an equal amount of strings, of the same length, as public variables. The players on the server should take priority over someone JIP'ing. I hope BIS have made it so it takes the JIP a little longer to join, rather than lagging out all the current players.

Don't get me wrong, I might have implied that this should replace publicvariable, but that wasn't my intention. For things like scores and resource or money counts, that are updated at regular intervals. I think publicvariable is ideal. But for the MP scripts I'm doing atm, I've managed to remove all those server side loops, that used to check for publicvariables being updated. It was a nightmare to do in OFP.

I don't think ClearVehicleInit is bugged, as I can't see what else you would use it for, in it's current state? I think another command is needed. One that takes an index returned from SetVehicleInit, and allows you to remove that specific init event. A bit like RemoveAction or RemoveEventHandler.

Quote[/b] ]UNN, I noticed that time is always 0 for clients when they first connect and set up the map (init objects).. this is true for JIP also. Then the server syncs the time variable.

The actual time is taken from a client in game, and passed to the JIP script as an integer. JIP works the same way as starting a regular MP mission, in some respects. It will halt when it encounters the sleep command, until the second stage of joining the mission. So after the script progresses beyond the first sleep command, you know that all the calls to that script have been made, and you know the time of the very last call.

Quote[/b] ]I was trying a if (not isnull this) then {do something} for all setVehicleInits... but it seems like the object "exists" for that 1 second and then is killed.

I haven't tried it on a proper, remote, dedicated server yet. But the problem you mentioned can be fixed by moving the checks underneath the first call to sleep.

You have to do this with objects that inherit from class Strategic anyway, because they always return Null when a player first JIP's. At least they do since the MP SetPos bug was fixed for Ammo crates e.t.c

Share this post


Link to post
Share on other sites

i too getting this problem when someone joins on the server....

however i'm getting it only when the player does not have the map and has to download it....when the player has the map there is no lag...

and cannot be bandwith because is 100mb dublex.....

but i guess you guys are referring to the lag when JIP due to the mission?

Share this post


Link to post
Share on other sites
UNN, I noticed that time is always 0 for clients when they first connect and set up the map (init objects).. this is true for JIP also. Then the server syncs the time variable.

I was trying a if (not isnull this) then {do something} for all setVehicleInits... but it seems like the object "exists" for that 1 second and then is killed.

I think I get publicVariable and JIP now.

server:

pubvar = 3;

publicVariable "pubvar";

pubvar = 4;

client on JIP will have pubvar set to 3, the last value that was broadcast.

So... what if we publicVariable "pubvar" on client connect? Then it gets 4. I think..

Apparently, the server re-send the latest publicVariable it has done (with the last values it broadcasted, not the current variable's one) to each JiP client (it must retain a cache of its latest PV for each PVd variable).

So as long as you update live your variables by PVing them each time they change value, you don't need to bother broadcasting them on client connection

Share this post


Link to post
Share on other sites

I've just tested some and don't see publicVariables being resent when a client connects. I am still having to send them during onPlayerConnect event.

I've changed how I use setVehicleInit now so that I don't stack inits on top of each other.

EDIT: maybe only certain types of vars are resent? No luck with Array & string that are changing as game is played.

Doolittle

Share this post


Link to post
Share on other sites
I've just tested some and don't see publicVariables being resent when a client connects. I am still having to send them during onPlayerConnect event.

I've changed how I use setVehicleInit now so that I don't stack inits on top of each other.

EDIT: maybe only certain types of vars are resent? No luck with Array & string that are changing as game is played.

Doolittle

The only things sent are init's if i am correct. I could search logs and see though.

Share this post


Link to post
Share on other sites

I'm getting terrible lag when players JIP. High disync and red chains. When the player downloads the map everything is fine.

It is a dedicated server 100mb dublex so there is no bandwith issue. However, i have noticed that when a player joins sometimes the outgoing bandwith is going right down. Last night a player was joining and it was taking him ages to download the map...i checked the upload of the server and it was about 3-6k/s, so it seemed to me that a slow connection player was causing the whole server to lag until he joined...

not so sure if my settings of minerror and maxmsg is too high and that contributes to it. I will try and change them and see what happens.

These are my files:

server.cfg

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">//Basic Settings

HostName="Revive-Reality Server =RTY=";

Password="";

PasswordAdmin="*****";

reportingIP="armedass.master.gamespy.com";

maxPlayers=10;

persistent=0;

verifySignatures=0;

voteMissionPlayers=1;

voteThreshold=0.20;

motdInterval=40;

kickduplicate=1;

equalModRequired=0;

LogFile="Logfile_Public.log";

//Von options

disableVoN=1;

vonCodecQuality=0;

//Message of the day

motd[]=

{

"Welcome to Reality Friends",

"Visit us at www.realityfriends.com",

"Teamspeak @ 78.129.142.65",

"Teamspeak pass: reality9",

"Usual rules of contact apply",

"Visit us at www.realityfriends.com",

"Visit us at www.realityfriends.com",

"Visit us at www.realityfriends.com",

"Visit us at www.realityfriends.com",

"Visit us at www.realityfriends.com",

"All maps use the revive script, no respawn. Stay close to your team mates",

};

//Cheat detection

checkfile=0; //1=slow 0=default

//Missions

class Missions

{

class coop1

{

template=co16_Beachassault_rev.Sara;

cadetmode=1;

};//end of this mission

class coop2

.

.

.

.

arma.cfg

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">language="English";

adapter=-1;

3D_Performance=7389.000000;

Resolution_W=800;

Resolution_H=600;

Resolution_Bpp=32;

MaxMsgSend=4096;

MaxSizeGuaranteed=512;

MaxSizeNonguaranteed=128;

MinBandwidth=70000000;

MaxBandwidth=100000000;

MinErrorToSend=0.0001;

MaxCustomFileSize=36000;

any ideas?

Share this post


Link to post
Share on other sites

so no other checkfile / signature related stuff in there?

Share this post


Link to post
Share on other sites
I've just tested some and don't see publicVariables being resent when a client connects. I am still having to send them during onPlayerConnect event.

I've changed how I use setVehicleInit now so that I don't stack inits on top of each other.

EDIT: maybe only certain types of vars are resent? No luck with Array & string that are changing as game is played.

Doolittle

I don't understand why your results differ from mine.

Let's make a little example:

dedicated server, mission, 2 players, init.sqf:

if ( isServer ) then

{

test = "h"; publicVariable "test";

} else {

while { true } do { player globalChat format ["%1 - %2", time, test]; sleep 1 };

};

I'm fairly confident that if you JIP (disconnect and reconnect while other player is on server or server is running persistent), you will receive the variable test again with value "h", and you will be able to read that back from the globalChat.

Suma even confirmed to me by PM that at least in v1.08, there was no way to nil a variable so that it would not be sent to JIP players upon their connect.

Am I just confused? Maybe the variables are only synced to jippers when persistent mode is enabled on server (with or without the proper respawn type set for it)?

Share this post


Link to post
Share on other sites
so no other checkfile / signature related stuff in there?

nope...nothing else...no checks, signatures or anything...

the server is C2D @ 2.9ghz with 2gb ddr2-800 memory and 80gb sataII 7200rpm hdd...

it looks like arma is not using the whole bandwith, or it is processing thing...

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×