EpochModTeam / Epoch

Epoch Survival Game Mode for ARMA 3
http://epochmod.com/
Other
92 stars 82 forks source link

Black screen bug #803

Closed raymix closed 7 years ago

raymix commented 7 years ago

Just managed to get it again, but this time I got RPT logs which might tell some of the story.

MAP: VR Can reproduce: probably not willingly without code modification, however I think I might be on to something **What I was doing***: Nothing really, just dev shit - giving myself items via admin menu and trying to manipulate inventory from scripts RPT 1 RPT 2

This time instead of panicking, I actually allowed it to sit there for a minute and it managed to recover. First RPT log you can see errors I started getting out of nowhere, errors are not added in perfect timing, but happens every 5 seconds or so, always 4 different "type_" errors.

2:32:07 Client: Object 3:13 (type Type_127) not found.

I closed the game and on next server restart I got black screen, but it recovered after 1 minute (see time in log). All 62000 lines were exactly the same as below code

2:50:19 "DEBUG: Checking Player Object: OK"
 2:50:19 "DEBUG: Checking Player is setup: OK"
 2:50:19 "DEBUG: Checking world preloaded: OK"
 2:50:19 "DEBUG: Final Player mass check: FAILED (976 != 263)"
 2:50:19 "DEBUG: Pos check: [1688,5077.7,0.00143862] == [1720.59,5120.87,0.00143862]"

Keep in mind that this is VR Map! There are technically no bad positions except for debug area maybe. It then suddenly recovered like this

 2:50:19 "DEBUG: Checking Player Object: OK"
 2:50:19 "DEBUG: Checking Player is setup: OK"
 2:50:19 "DEBUG: Checking world preloaded: OK"
 2:50:19 "DEBUG: Final Player mass check: OK (976 != 976)"
 2:50:19 "DEBUG: Pos check: [1688,5077.7,0.00143862] == [1720.59,5120.87,0.00143862]"
 2:50:19 Speaker Male02_F not found in CfgVoiceTypes
 2:50:19 "EPOCH-LOGIN: Setup Player Object"
 2:50:19 "DEBUG TIME WAITED: 0.0279999"
 2:50:19 "EPOCH-LOGIN: Setup Player Variables"
 2:50:19 "EPOCH-LOGIN: Setup EH's"
 2:50:19 Speaker Male02_F not found in CfgVoiceTypes
 2:50:20 "EPOCH-LOGIN: Finish!"

After this I got couple of hundred errors with:

 2:50:20 Bad conversion: bool

Hope this helps with the bug hunt or at least give you an idea, @vbawol

ravmustang commented 7 years ago

The first error you mention about 2:32:07 Client: Object 3:13 (type Type_127) not found. This is arma spam concerning non-local vehicles, not to be worried about...

Final Player mass check: FAILED (976 != 263)" Final Player mass checks are done on logging in while you are still in the player_login.fsm This is being done in the "check new player not null" FSM condition which uses this code

_state = false;
_playerCheck = !(isNull _playerObject);
_playerCheckSetup = false;
_playerCheckObjectsReady = false;
_playerCheckFinal = false;
if (_playerCheck) then {
    _playerCheckSetup = _playerObject getVariable ["SETUP",false];
    if (_playerCheckSetup) then {
        _playerCheckObjectsReady = _playerPos nearObjectsReady 10;
        if (_playerCheckObjectsReady) then {
            _playerCheckFinal = (_mass isEqualTo (loadAbs _playerObject));
            if (_playerCheckFinal) then {
                _state = true;
            };
        };
    };
 };

And on the third error, I have noticed this "bad conversion: bool" for the last few months and actually have no idea whats going on there and have not paid it much thought as of late.

IN CONCLUSION: I will agree with you that if there are any login issues with complaints regarding a black screen or extended login times might have something to do with the above checks I mentioned about your second error. I have not done any testing regarding it but watch that code process many times in the rpts and its very consistent dragging ass if the server is not fully started up and ready to accept players.

vbawol commented 7 years ago

I want to change to set|getUnitLoadout as I think we can do away with the mass check as set|getUnitLoadout is supposed to have a global effect.

Only, issue is that BI states that the format may change and that could cause some issues in the future.

Ignatz-HeMan commented 7 years ago

Yeah, I'm with you. But you should add a check, if the old or new syntax is saved to the DB. So let the old script in for a while and on login check, if it is already saved in new syntax?!

ravmustang commented 7 years ago

Suggestion: set defaults like the player vars in the configs. I believe I have the empty array with comments as to what is what. This default structure will then be able to be modified on the fly by server owners if Bohemia ever updates and changes the function.

raymix commented 7 years ago

The whole FavBar is built around set/getUnitLoadout, if that damn thing changes, I am in more trouble than you are @vbawol :D

vbawol commented 7 years ago

We are now using set/getUnitLoadout after the player has connected once they will be upgraded so the subsequent logins will use it. The new code is faster and global so I think this should result in fewer propagation issues.

vbawol commented 7 years ago

Note on "bad conversion: bool": I think this due to the use of true/false boolean in configs, Arma does not really support it and we even have to use a workaround. It could possibly be fixed by changing all true/false in configs to 1/0.

raymix commented 7 years ago

I didn't even know you can use True/false in configs, was always using 0 and 1 lol

ravmustang commented 7 years ago

The true false, is this in regard to epochcore?

vbawol commented 7 years ago

I think it is from the mission files, I have added this change: https://github.com/EpochModTeam/Epoch/commit/383d67c28c2a0761e37bc26a032885e1bcca0e47 It should convert any gamemode configs that use a boolean to a 1 or 0 and hopefully fix the spam. If it does not fix it then the "bad conversion: bool" maybe from something else.

vbawol commented 7 years ago

Looks like that last change actually made the bad conversion: bool spam worse server is now failing to start.

 7:50:28 Warning Message: 'mpmissions\__cur_mp.Malden\description.ext/CfgDynamicSimulation/' is not a value
vbawol commented 7 years ago

I think this issue is solved for the most part mass check should not fail as often if at all, If we still get reports about this issue we can reopen.