User talk:Kronzky

JIP and init.sqs

I think you're seeing this because 'player' is null when init.sq(s|f) is run as a player JIPs, it's very confusing.. --Salisan 12:21, 13 January 2007 (CET)

But then, why is player not null if he's there during the briefing already?

And even if player was null in those particular cases, then I would consider that to be a bug. After all, it would make the use of init.sqs for player initialization useless... --Kronzky 17:45, 13 January 2007 (CET)

Agreed, but it seems it's only null in JIP. :) I solved it with an '@!isNull player' as player gets assigned after a short delay, but it would be good if it was really fixed (or documented). --Salisan 21:07, 13 January 2007 (CET)

Oh, so it does get assigned after a while? How long is the delay normally?

I haven't done any further testing after your report, regarding whether the init file is actually activated on JIP, but you say it definitely is? How did you test it?

I guess in that case I can remove my bug report then. --Kronzky 21:20, 13 January 2007 (CET)

It's entirely possible your bug report is correct also as all my testing is on a dedicated server. It's very odd that your readme says the mission actually worked correctly for you on a dedicated though? Perhaps there is some sort of race condition. (I don't know exactly how long the delay is before player was set, but it seems to be very short.) This is certainly something BI should look into, so it's probably a good idea to let the bug report stand. :) --Salisan 21:51, 13 January 2007 (CET)

Yeah, I never had that problem on a dedicated server (but that may be because I tested it on a LAN, where I don't have to worry about bad connections). Only if you started the server from the normal game file did this problem occur. And even then only if a player joined after the briefing was done.

So, pretty weird and specific circumstances. Guess I'll leave the report, and let BIS figure out what actually is going on here... ;) --Kronzky 21:56, 13 January 2007 (CET)