Spring's widget loading needs to be fixed...

[Forboding Angel]

Ppl continually time out because of the massive amount of time this takes for some people.

[KDR_11k]

No. Widgets just need to do less calculations in the Initialize() function.

[imbaczek]

I think the problem might be a little bit more complex, e.g. TASClient shows high virtual size, which may cause some computers to swap during loading the game.

I'd suggest everyone who has this issue to:
- move unused maps and mods to some other directory
- or try AFLobby

[AF]

Current aflobby crashes trying to load the new ranks, and does not implement the protocol changes. You'll have to wait for the newer version to be released with all the goodies.

[kiki]

Call init as soon as you as game is loaded, without waiting for everyone to be rupped or for countdown to finish. How about that?

[lurker]

But doesn't the network code claim to keep sending updates in a separate thread until loading is done? We need a dummy widget that sits there and twiddles it's thumbs for 60 seconds in initialize(). If loading fails where it used to work, then the network code is at fault.

[Tobi]

While loading yes. While simulating frame 0, no.

The latter is when a lot of widget/AI/LUA initialization happens, AFAIK.

Have one simulation frame take more time then network timeout has never worked (and probably will never work).

[Argh]

Ok, so... um, for us LUA dummies... how do we get anything that requires massive calculations to run, before gameframes start? I have some stuff in the pipeline now, that can take over a second to finish, and will probably get longer... however, it can't run in the pre-units phase, because it manipulates units. Can we have a "frame -1", and an appropriate LUA function (idk, maybe "BeforeSimFramesExecute()" or something) that allows us to do some big operations, then push the results to players before starting frame 0 of the sim, thus avoiding desync? Not every host has a super-computer, so I'm a little concerned about this, now that I'm building stuff that will, basically, rewrite a lot of the game world...

Er, and I should say for the record, what I'm doing is Gadget code, for obvious reasons. However, the problem is pretty much identical. I think that there needs to be a way for clients to all report that they've finished pre-gameframe Widget precalc stuff, as well as server-side Gadget code, so that everybody's on the same page with pre-calc stuff before a sim frame runs.

[lurker]

Isn't frame 0 when the commanders spawn? That's not when these people are dropping. It's during finalizing. If finalizing is during frame 0, then what real reason is there to not continue sending ping equivalent packets until frame 1?

[Argh]

That's pretty much what I'd want, if I understood you correctly.

Ideally, until all functions return, just not bother trying to sync with anybody- that way, if player X takes 10 seconds to run some amazing, mind-bogglingly awesome Widget that does everything but shine your shoes, and nobody else has it, everybody else starts talking to one another, but you wait until you've gotten a "finished" from X before proceeding, or some fairly-lengthy timeout- maybe 30 seconds? There has to be some upper limit, even for Godlike AI Widget code.

Right now, though, there isn't a real limit- everybody comes in on frame 0, syncs, then boom, sim starts. Then everybody gets hammered- disk access to load the Commanders and process their Create() functions, all of the LUA stuff that starts on the first frame, etc., etc., etc.

Everything that should run on a frame(t) basis should not be initialized until frame 1. If it needs some precalc to run efficiently, fine, do it in Initialize(), store the results in a globally-available table, read them in on frame 1, imo...