I actually thought about swapping it with qtlobby in the installer. But I didn't do it because I could somehow see the shitstorm coming, so I just left it as it was.
Why even thinking of removing a functional, very mature, popular, good client for spring?
There is a big userbase for tasclient.
In opinion of many, its the best lobby there is atm.
so why would you remove it?
just bc you personally dont like it?
its like chopping a leg from spring..
Please, give some reason, as i really dont understand why would you want to remove it at all, and wont like to see it removed for next releases with no warning.
do we have to make a petittion? a poll or something?
edit:
lurker wrote:
Yes, let's make a petition for something that was never going to happen.
well he is the head developper, and he is suggesting that.. so its quite possible he can make it happen.
Last edited by mongus on 23 Aug 2009, 16:43, edited 1 time in total.
I actually thought about swapping it with qtlobby in the installer. But I didn't do it because I could somehow see the shitstorm coming, so I just left it as it was.
its like chopping a leg from spring..
Yes, an infected leg that needs to be amputated before it spreads to the rest of the body.
Hi Guys it didnt (MAKE IT HAPPEN) for me afther installing the new 0.80.2 i get: GetluaAIName cant be fond in DLL-bestand UnitSync.dll. Hope some one can help me ?!
Hi Guys it didnt (MAKE IT HAPPEN) for me afther installing the new 0.80.2 i get: GetluaAIName cant be fond in DLL-bestand UnitSync.dll. Hope some one can help me ?!
is there something wrong with this new spring-dedicated.exe ? its crashed 4 times on one day since new release... before that running nicely for a week.
Removing the "old" lobby client would be stupid, the new client does not appeal at all, flooded with bad useless features and actually not allowing anyone using it to play.
Joined: 24 Jun 2007, 07:34 Location: 50┬░ 56' N, 11┬░ 35' O
TradeMark wrote:
is there something wrong with this new spring-dedicated.exe ? its crashed 4 times on one day since new release... before that running nicely for a week.
Writing path data file... Reading estimate path costs Analyzing map accessibility [32] Block offset: 0 of 1024 (size 32) Block offset: 1000 of 1024 (size 32) Path cost: 0 of 1024 (size 32) Path cost: 1000 of 1024 (size 32) Writing path data file... Pathing data checksum: 1b7cfad9 X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 128 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 6058 Current serial number in output stream: 6059 AL lib: ALc.c:1302: exit() 1 device(s) and 1 context(s) NOT deleted AL lib: alSource.c:2291: alcDestroyContext(): 32 Source(s) NOT deleted AL lib: alBuffer.c:1097: exit() 256 Buffer(s) NOT deleted
Besides the irrational random folder creation and "improved" hardcoded archivemover behavior, there seems to be still one annoying "feature" since last spring update.
What i am talking about is a delay between giving the launch command to spring.exe to where it actually begins to load.
before the update the loading started immediately when launching a game or starting spring.exe directly, now with 0,80.2 (havent tried previous 0,8x versions) it takes about 4 seconds of nothing before the exe starts to load and do its usual business. What could cause such a thing? NO version before the current has displayed similar behaviour.
Besides the irrational random folder creation and "improved" hardcoded archivemover behavior, there seems to be still one annoying "feature" since last spring update.
What i am talking about is a delay between giving the launch command to spring.exe to where it actually begins to load.
before the update the loading started immediately when launching a game or starting spring.exe directly, now with 0,80.2 (havent tried previous 0,8x versions) it takes about 4 seconds of nothing before the exe starts to load and do its usual business. What could cause such a thing? NO version before the current has displayed similar behaviour.
There was a time when this happened to me with tasclient. It was much worse though, about 30-60 seconds. In other words, long enough for the host to assume I'm not going to connect. I had to switch to Springlobby at that time.
Users browsing this forum: No registered users and 2 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
Home
Download
Login
Register
FAQ
Search
(the latest one)
