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?! ;_;
Something unusual...
Moderator: Moderators
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? >_>
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? >_>
-
Pressure Line
- Posts: 2283
- Joined: 21 May 2007, 02:09
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.
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.
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
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...
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.
Code: Select all
spring.exe my_script.txt
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.
-
BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
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
), 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 computerthey 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.
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.
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.
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.