Stuck at loading screen, can hear sounds

[linuxx]

I have the infamous "stuck at loading screen" bug that is in so many posts ( ). This is a server that I've used to develop plugins/scripts for Epoch before. It has all the C++ libs, and .net pre-req's (even upgraded them to .net 4.5, C++ 2013 x64/x86).

 

I can load in the first time, but consecutive logins result in "stuck" status. If I kill the player in the db (alive = 0), I can login again, but consecutive logins with that character result in "stuck". 

 

I have;

• Windows server 2008 R2
• Fresh Arma2 v1.63.0.125548 (combined operations / copy paste from arma2 to arma2oa)
• Fresh Epoch server files 1.0.5.1
• Fresh Epoch client files 1.0.5.1
• Fresh database
• No mods
• No firewall
• No errors in RPT on client or server

 

I have tried any reasonable recommendations from the posts that claim to fix this issue without any luck. I didn't think a "me too" post would gather any support for this issue. 

 

Any help would be appreciated. 

[hambeast]

do a manual flush, seems to fix my clients.

 

left shift + numpad minus .  Let go then type "flush" (no quotes"

[linuxx]

So this might be a client side issue? I will try it when I get home...

[linuxx]

No dice. I see something come across the screen that says "activating flush", or something along those lines, but the problem persists. I have also cleared out my AppData directories (all of the Arma ones), with no change. 

 

P.S. you are only half evil...

[hambeast]

No dice. I see something come across the screen that says "activating flush", or something along those lines, but the problem persists. I have also cleared out my AppData directories (all of the Arma ones), with no change. 

 

P.S. you are only half evil...

 

haha thanks?

 

There's a post that gets it going for most people, it involves editing the compiles.sqf.  I don't have luck with that but the flush works 100% of the time along with that fix. 

[linuxx]

The 333 made me laugh. 

 

I saw this post, and figured that since it was in the client PBO, that it wouldn't work (I didn't believe any of that code was executed on the server). I tested anyway and it didn't fix it. I even added a few debug log lines just to see if this code even executed. 

diag_log "DEBUG: loadscreen guard started.";
_display = uiNameSpace getVariable "BIS_loadingScreen";
if (!isNil "_display") then {
		_control1 = _display displayctrl 8400;
		_control2 = _display displayctrl 102;
};
diag_log format["FINDME step1",nil];
if (!isNil "dayz_DisplayGenderSelect") then {
	waitUntil {!dayz_DisplayGenderSelect};
	diag_log format["FINDME step2",nil];
};
diag_log format["FINDME step3",nil];
// 120 sec timeout (12000 * 0.01)
while { _timeOut < 12000 } do {
	//if (dayz_clientPreload && dayz_authed) exitWith { diag_log "PLOGIN: Login loop completed!"; };
	if (dayz_clientPreload && dayz_authed) exitWith {
		endLoadingScreen;
		diag_log format["FINDME step4",nil];
		diag_log "PLOGIN: Login loop completed!";
	};

As I expected, I don't see any of the "FINDME"'s in both server and client RPT files. 

[linuxx]

Thanks to Foxx from Tempest (www.tempestportal.com) I have this fixed. 

 

I found that all of my tables were lower case. The SQL script that ships with Epoch has the tables in "CamelCase". Foxx noticed that one of the tables wasn't being read correctly by the Hive.dll. I couldn't create tables with any upper case characters (even with everything set to a case-insensitive collation). I found a config option for MySQL that fixes this. Open my.ini;

 

Find

[mysqld]

 

Add this

#allow camel case tables
lower_case_table_names=2

 

Restart MySQL

net stop mysql
net start mysql

 

Then drop all tables* and re-run the SQL Epoch script. Everything seems to work now!

 

*Warning, this will delete all player data! You've been warned...

[Darth_Rogue]

What about for folks who run a server with a provider, such as DayZ.ST and don't have access to their SQL server configs??

[Bob_the_K]

I'm running my own server and will try this but the obvious question is that if everyone is downloading the same files from Epochmod, then why isn't everyone experiencing the same issue?  If nothing else, computers are exact and repetitive.  If we all download the same files, we should all get the same files, case included.

[ZamboniBambino]

Just as an FYI, this can also be caused if you are calling a script incorrectly in init.sqf (MPMissions). i.e. If you use call preprocessFileLineNumbers on a file which should be called using execVM. On my testserver, it hung the startup process.

//Load in compiled functions
call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\variables.sqf";				//Initilize the Variables (IMPORTANT: Must happen very early)
progressLoadingScreen 0.1;
call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\publicEH.sqf";				//Initilize the publicVariable event handlers
progressLoadingScreen 0.2;
call compile preprocessFileLineNumbers "\z\addons\dayz_code\medical\setup_functions_med.sqf";	//Functions used by CLIENT for medical
progressLoadingScreen 0.4;
call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\compiles.sqf";				//Compile regular functions
progressLoadingScreen 0.5;
call compile preprocessFileLineNumbers "server_traders.sqf";				//Compile trader configs
progressLoadingScreen 1.0;
call compile preprocessFileLineNumbers "my\file_which_should_be_called_with_execVM_instead.sqf";

// .. Will hang on this bit. 

Suggestion is to comment out scripts to see which ones are causing faults. Once I sobered up (hey, it's Christmas :-P) and changed to execVM at the very bottom of init.sqf, server start worked perfectly.