Spring RTS Engine

So like, a few weeks ago, i started the client up (TASClient) and didn't really pay attention ( i tend to do a lot while waiting for my programs to load) and i looked back at the screen and noticed taht it was still loading unitsync.dll

I was like, hm thats odd. So i check the processes monitor, and found that it was only using like about 4% cpu usage. Stranger still. So I uninstalled and reinstalled, the problem continues. And so for the last few weeks i have been unable to play SPRING! >_<

Anyone have an suggestions? recommendations? how do i get the client to load the game up?! ;_;

I don't understand the error. Spring uses unitsync.dll, and low cpu usage is a good thing.

thats what i'm saying tho, it won't load unitsync.dll

I let it sit for a half and hour and it still sits there at unitsync.dll

before this started happening, it would load up completely in less than 2 minutes. and i would never even see unitsync.dll show up in the loader (loads the file so fast my eyes don't catch it) and most of the loading is in the maps.

But now i can't even get past the damn thing. Anybody know how to unbreak it? >_>

Reduce the number of maps you have.

LordMatt wrote:Reduce the number of maps you have.

or the mods... since they would be what is affecting UNITsync.dll loadtimes...

The name isn't very descriptive, since one of the things unitsync does NOT do, is sync units. (Originally that was planned but Spring grew in another direction where syncing separate units wasn't really necessary.)

It makes & maintains a cache of all your maps and mods, and since one usually has more GB maps then mods, usually maps are the cullprit. It doesn't show much CPU usage even when caching because it's probably disk/bus limited, not CPU limited.

Good news is that in the next version this caching is a huge amount faster.

That's a relief. It's really frustrating atm when you want to get into spring quickly just to test a small thing in your mod and waite for a min or so to spring to load.


Tobi, would it be possible to set up startup parameters for spring.exe to where you could specify 1 map (the test map you like to use) and 1 mod (the mod you're testing) so that loading spring.exe would be uberfast?

I did happen to think that I could accomplish that by seperate installs, but that's really messy...

You could start a game in a lobby with the parameters you want, then rename the script.txt afterwards and make a batch file with just one line: Where my_script.txt should be replaced by the new name of the startscript.

Then you can just double click the batch file and you get automatically booted into a game with the same parameters (map, mod, etc.) as you set the first time in the lobby.

Do you have a .sdd with thousands of files? In my experience, that can cause huge unitsync delays.

Um, its not just a "long delay" it wont load at all...

It stops responding right at unitsync.dll

I am getting pissed. I really want to play >_<

ok, this may sound like self-ads (wich is a bit ), but how about trying with another lobby client? at least you'll be able to exclude if the problem is generated from the lobby or unitsync itself or something in your computer

they might not be as feature-complete as tasclient, but if they'll let you play it should be a progress anyway

the 2 alternatives are:

AFLobby

and

SpringLobby and this is a link for windows installation

Also if reducing mods & maps doesn't work you may try to delete ArchiveCacheV4.txt.

I don't know of any specific corruption in ArchiveCacheV4.txt that may cause infinite hangs in unitsync, but who knows, you can always try.

Half hour for a total re-scan of all maps and mods may actually happen if you have multiple gigabytes of them btw.

Probably THE reason I don't keep unused maps in my maps folder.

Well, i started up spring.exe (the problem was infact with unitsync.dll, not the client) and let it run while i did other things. It took an hour and a half, but all of the sudden, spring.exe came to life right on my main monitor.

So in utter amazement i decided to start up the client. It loaded in less than two minutes.

I have no idea why unitsync was doing that in the first place, but i suppose letting it run its course did the trick. Hopefully the new svn will fix this issue later.