I don't think cpu speed is a meaningful indication of performance. Letting people set it manually was just a joke; i guess I ought to support the protocol as it stands anyway... I'll do that after i get it working in win7. It crashes in wine too, so I think the problem is accessing invalid memory that XP isn't so strict about.
what is the license you use? where is the code? what language is it written in?
It would also be good if you would use something else for the CPU field then what ZK lobby uses, if you use a static value. it would make distinction of users lobbies easier, which is good for troubleshooting, as it often requires ~5min of chat with a user to find out which lobby he is using.
... Agree 100% that the protocol needs a revision. Plain text doesn't even simplify coding anyway, but makes everything hugely inefficient.
Some commands aren't necessary or could be compressed into one command. For example the "SAY[PRIVATE|BATTLE][ME] TEXT" could be reduced into one call "SAY TYPE ME TEXT" this would cut down six commands into one call. Or all the user test commands, are they even used? This should be discussed.
More on the topic: In which language is this written and will it run on Linux and/or Mac? Will it be opensource? Edit: Bah hoijui stole my questions.
To identify the user's lobby you could print out the same name and version you use in the LOGIN command into a about dialog which most applications have.
the about dialog thing is less efficient still. instead of just looking at CPU field and knowing right away, it would go like: "what lobby client are you using?" "What is lobby?" "The software you are using right now, to play." "TASpring" "No, i mean... Please go to the 'Help' or '?' menu entry, and choose 'About', and tell me what is written there." *3min later* *TADAA* "... it was not easy to write everything that stands there, cause i had to open it many times, cause i can not remember all at once!!!1111"
what is the license you use? where is the code? what language is it written in?
It would also be good if you would use something else for the CPU field then what ZK lobby uses, if you use a static value. it would make distinction of users lobbies easier, which is good for troubleshooting, as it often requires ~5min of chat with a user to find out which lobby he is using.
As far as windows-only goes, my gfx card isn't supported in linux, so i can't run spring from anything but windows. Otherwise I probably would have worked in gtk2. Personally I don't like cross-platform toolkits though. You end up looking slightly wrong everywhere.
I just ran it under wine and there were a lot of small issues. Listview Groups didnt show, it was hugely slow and it looked ugly as win95. I could get a linux binary to work using winelib, but I don't think anyone would use it. wxWidgets has far better linux support than wine ever will.
Its all in C. There are plenty of lobbies around and writing in C means I'll always have a performance edge; I'm not going to out-feature Zero-K, and I don't find I'm much more productive in c++ than c. String manipulation can be a little tedious though. Its not just about performance either, I'm writing the lobby I would want to use. Starts up instantly, never loses responsiveness, and doesn't ever get in the way of the one thing i want to to: get into a game.
I haven't released the code. I intend to though, but I would need to do a lot of work to get it to that stage. Until recently my build process was little more than "gcc *.c".
right now the repository is on my hard-drive (with backups elsewhere).
As for licencing, I'll probably use GPL2, but I haven't given it too much thought.
Its a good idea to use a static value for cpu so that lobbies can be identified.
As an aside, I regret calling this RC. AlphaLobby alpha would have been more appropriate, even more appropriate would be to keep it away from the internet for a while longer.
Oh crap my eyes, the screenshot it hurts me!!!! (--edit: i see you replaced the screenshot now)
Unfortunately it's not the beautifull lobby, but the game.... I just lost a 2vs1. Because V_Shadow_V went air and he was front and I wasnt the brightest either... with going flashes on the north. I felt we should deserve to lose anyway that, with shadow being all: 'see i m just fine', then a few secs later his com blows o_0
Anyway, eh.... how many lobbies are availible now.. tasclient, springlobby, zero-k, some minimalist one, and now yours too? Eh...... and windows only... is that not a lil bit too exclusive for a platform independant game?
But it looks clean and cool tho, I can imagine it's very quick too. The only thing with spinglobby that bugs me is that it hangs/crashes a lot when I download mods/maps with its downloader. And, the endless clicking on the spectator box to squeek yourself into a full battle.
How much time did it take to make it?
Last edited by Floris on 22 Jan 2011, 16:13, edited 1 time in total.
The only thing with spinglobby that bugs me is that it hangs/crashes a lot when I download mods/maps with its downloader.
I'd imagine that would be fairly easy to fix. In general the main message loop should never wait on the network or any slow functions.
Floris wrote:
And, the endless clicking on the spectator box to squeek yourself into a full battle.
At some stage I had an 'auto unspectate' option. I removed it because I thought it would be bad for the community.
Quote:
How much time did it take to make it?
Hard to say. I had a command line only lobby 6 months ago, but I've been writing the gui for 6 weeks or so; but thats working around my afk life and while learning the win32 api. I'm hugely impressed by the speed that cheeselobby is progressing. Its much slower to code using c and win32. It took 50 lines of code just to make tabs draggable; even the tab buttons had to be custom drawn.
Joined: 07 Feb 2005, 21:30 Location: Cheese factory
True something like gflops would be more meaningful than cpu speeds. Including a small benchmark into spring that can be run from cmd line. Also would be useful for other things like optimizing your rig to play spring. Do we have this already?
Official server is still running an old version of tasserver. Kinda tells you how little devs care about it now that it's relatively mature.
In wine for me it crashes when I try to login, but it's wine so screw it I say.
hoijui wrote:
It would also be good if you would use something else for the CPU field then what ZK lobby uses, if you use a static value. it would make distinction of users lobbies easier, which is good for troubleshooting, as it often requires ~5min of chat with a user to find out which lobby he is using.
There's the unused parameter in LOGIN to specify lobby name and version. TasServer could broadcast this in the ADDUSER message. Maybe better than using some cpu speed hack..
All lobbies I can think of: tasclient, springlobby, aflobby, qtlobby, zero-k, cheeselobby, alphalobby.. yup we got lobbies like a ho has STDs. Typical disease of opensource is redundancy..
True something like gflops would be more meaningful than cpu speeds. Including a small benchmark into spring that can be run from cmd line. Also would be useful for other things like optimizing your rig to play spring. Do we have this already?
Even if it were possible to get a reliable benchmark, I don't think there is even much point. So long as someone can stay ingame it shouldn't matter to me if they are playing at 2 fps.
Cheesecan wrote:
In wine for me it crashes when I try to login, but it's wine so screw it I say.
Yeah I don't really see the point to getting wine working, even if you can run it, there is still far too many little problems to bother; springlobby is always going to be superior on linux. The main reason why I tested it on wine was to see if I could find the reason other ppl crash. winedbg is not so good as gdb anyway
Quote:
There's the unused parameter in LOGIN to specify lobby name and version. TasServer could broadcast this in the ADDUSER message. Maybe better than using some cpu speed hack..
In my opinion the original protocol should be scrapped entirely instead of adding another extension. I will put a static cpu speed in the next release. Its a hack but its easy enough to do.
Cheesecan wrote:
In wine for me it crashes when I try to login, but it's wine so screw it I say.
Yeah I don't really see the point to getting wine working, even if you can run it, there is still far too many little problems to bother; springlobby is always going to be superior on linux. The main reason why I tested it on wine was to see if I could find the reason other ppl crash. winedbg is not so good as gdb anyway
Quote:
All lobbies I can think of: tasclient, springlobby, aflobby, qtlobby, zero-k, cheeselobby, alphalobby.. yup we got lobbies like a ho has STDs. Typical disease of opensource is redundancy..
I wouldn't do this if i didn't enjoy it. I don't mind if nobody uses it besides me.
Oh, and the link in the menu bar to 'other lobbies' didn't include Cheeselobby because it is still WIP. I'm impressed at how fast its progressing. I guess using a higher level toolkit doesnt hurt.
Users browsing this forum: No registered users and 0 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
Kinda tells you how little devs care about it now that it's relatively mature.