SpringLobby
Moderators: Moderators, Lobby Developers
- BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
AF, thats only partly correct. The ingame time is accounted on server side - but only when your INGAME status is set correctly (as has been said)
I assume the question is because of a bug that occurs when using wine+TASClient + linux spring: for TASClient it appears as spring exits at once - and your ingame time will never increase.
I assume the question is because of a bug that occurs when using wine+TASClient + linux spring: for TASClient it appears as spring exits at once - and your ingame time will never increase.
It depends on how you've got Linux + Wine + TASClient setup.
My particular setup does not exit as soon as the client is launched,
so my ingame time is recorded (although you wouldn't think it from
looking at my rank, unless you'd seen me play).
P.S. http://trepan.bzflag.bz/noshow/springProxy.tgz -- use at your own risk
My particular setup does not exit as soon as the client is launched,
so my ingame time is recorded (although you wouldn't think it from
looking at my rank, unless you'd seen me play).
P.S. http://trepan.bzflag.bz/noshow/springProxy.tgz -- use at your own risk
Latest tarball, a few nitpicks:
1) in single player when I change tabs the selection for the current map goes back to blank rather than sticking with the map I see
2) I should be able to right click a spawn point and hit "add bot" in single player.
3) Settings++ should be integrated
4) A "connect" button should be visible in the main window when I click play online. I shouldn't have to look up in the File menu.
1) in single player when I change tabs the selection for the current map goes back to blank rather than sticking with the map I see
2) I should be able to right click a spawn point and hit "add bot" in single player.
3) Settings++ should be integrated
4) A "connect" button should be visible in the main window when I click play online. I shouldn't have to look up in the File menu.
- BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
that's one of the many resons that using revisions > 670 is discouraged, accidentally some experimental code slipped into svn and and will requires a bit more coding in order to fix itYokoZar wrote:Latest tarball, a few nitpicks:
1) in single player when I change tabs the selection for the current map goes back to blank rather than sticking with the map I see
can you add a ticket for those pls?YokoZar wrote: 2) I should be able to right click a spawn point and hit "add bot" in single player.
4) A "connect" button should be visible in the main window when I click play online. I shouldn't have to look up in the File menu.
will have to think about this, settings++ uses GTK directly, and would work only in linux, the project goal is to work in any OS supported by spring (and even more )YokoZar wrote:3) Settings++ should be integrated
- BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
While muddling through java 5 jdk at home I needed a lobby to run at university.
Sadly the port 8200 is blocked.
But
Your singleplayer tab suffers from a drawing problem. The first tab wotn draw and just displays whatevers behind it, usually the second tab making it look awkward.
Numerous menus are empty, and numerous menu options dont actually do anything, a total lack off feedback. For example the join menu, or the about menu option.
For the main view, you should disable the tab marked as X for closing tabs when the only open tab is the $local one.
There was no indication of why it failed to connect. timeout? unknown host? I had to open a DOS prompt to figure out the port was closed.
The conenct dialog should open on startup rather than requiring the suer to wander around the Ui to figure it out, and different views should be disabled unless theres something the user cna actually do on them, such as the play online page when not connected.
Sadly the port 8200 is blocked.
But
Your singleplayer tab suffers from a drawing problem. The first tab wotn draw and just displays whatevers behind it, usually the second tab making it look awkward.
Numerous menus are empty, and numerous menu options dont actually do anything, a total lack off feedback. For example the join menu, or the about menu option.
For the main view, you should disable the tab marked as X for closing tabs when the only open tab is the $local one.
Code: Select all
[12:59] ** Server ** Connecting to server TAS Server...
[12:59] ** Server ** Disconnected from server.
The conenct dialog should open on startup rather than requiring the suer to wander around the Ui to figure it out, and different views should be disabled unless theres something the user cna actually do on them, such as the play online page when not connected.
- BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
yes, we're aware of this, we're working to solve itAF wrote:Your singleplayer tab suffers from a drawing problem. The first tab wotn draw and just displays whatevers behind it, usually the second tab making it look awkward.
atm they are left as they are because it's still a work in progress, it will get a major polish before the releaseAF wrote:Numerous menus are empty, and numerous menu options dont actually do anything, a total lack off feedback. For example the join menu, or the about menu option.
yeah, it should even not exist at all ,i'll add a ticket for thisAF wrote:For the main view, you should disable the tab marked as X for closing tabs when the only open tab is the $local one.
ticket addedAF wrote:There was no indication of why it failed to connect. timeout? unknown host? I had to open a DOS prompt to figure out the port was closed.Code: Select all
[12:59] ** Server ** Connecting to server TAS Server... [12:59] ** Server ** Disconnected from server.
it should do that, i knew about about this bug (it's not displayed the first time you open the lobby), but i forgot it, thanks for the reminderAF wrote:The conenct dialog should open on startup rather than requiring the suer to wander around the Ui to figure it out
yes, this goes under the pre-release polishingAF wrote:different views should be disabled unless theres something the user cna actually do on them, such as the play online page when not connected.
I get this error when I try to compile springlobby:
This is on Ubuntu Feisty 64bit.
Edit: Braindamage helped me get it working by using SVN instead of tarball.
Code: Select all
sed 's/REV[^"]*/REV SVN '`false . /trunk || echo svnversion failed or not found`'/' < src/revision.cpp.in > revision.cpp
sed: -e expression #1, char 29: unterminated `s' command
make[1]: *** [revision.cpp] Error 1
make[1]: Leaving directory `/home/matt/Desktop/springlobby-0.0.1.0678'
make: *** [all] Error 2
Edit: Braindamage helped me get it working by using SVN instead of tarball.
better LAN support
This may be related to ticket:http://trac.springlobby.info/ticket/224
But I was about to switch the windows Lobby from TASClient to SpringLobby (SpringLobby is a lot more intuitive for connecting, etc) for our LAN games, when I noticed you have to use:
server:port to connect...
(I'm pretty sure anyway)
I tried just putting:
server
and hoping that it would automatically connect to port 8200, but it threw a Password error (of all things) that wasn't fixed until I designated the port.
I think it'd be nice if it would assume port 8200 for fast connects for LAN games.
-Side note: I'm trying to figure out where the config files for the game are storied. Another option is to just set up a "cache" that gets installed with the rest, so that the server and all the settings are preset for people that are playing our LAN...actually it'd be a lot better that way in any case...
Edit: I did think to check: \Application Data\springlobby
but the folder "cache" is empty...no file for me to copy...
But I was about to switch the windows Lobby from TASClient to SpringLobby (SpringLobby is a lot more intuitive for connecting, etc) for our LAN games, when I noticed you have to use:
server:port to connect...
(I'm pretty sure anyway)
I tried just putting:
server
and hoping that it would automatically connect to port 8200, but it threw a Password error (of all things) that wasn't fixed until I designated the port.
I think it'd be nice if it would assume port 8200 for fast connects for LAN games.
-Side note: I'm trying to figure out where the config files for the game are storied. Another option is to just set up a "cache" that gets installed with the rest, so that the server and all the settings are preset for people that are playing our LAN...actually it'd be a lot better that way in any case...
Edit: I did think to check: \Application Data\springlobby
but the folder "cache" is empty...no file for me to copy...
*sigh*
well, another problem I guess...
"tools/unitsync/unitsync.cpp:313: Array index out of bounds. Call GetMapCount before GetMapName."
when I try to host a game (windows, LAN). It's just ready to make the game when this happens. Is this a problem with the latest windows version?
"tools/unitsync/unitsync.cpp:313: Array index out of bounds. Call GetMapCount before GetMapName."
when I try to host a game (windows, LAN). It's just ready to make the game when this happens. Is this a problem with the latest windows version?
Hey, just wanted to let you know that I haven't disappeared off the face of the earth.
I'm really glad you're still developing Springlobby. Now that Gutsy and its Wine are out the door I'm ready to start doing a lot more Spring work again.
This includes a working Ubuntu Spring repository and springlobby package :)
To that end, if you could make (or just point to) a "release" I should use for the first package to go up, I'd be very grateful. I estimate the repository will be live by this Sunday, so it would be nice to have a good springlobby package by then.
I'm really glad you're still developing Springlobby. Now that Gutsy and its Wine are out the door I'm ready to start doing a lot more Spring work again.
This includes a working Ubuntu Spring repository and springlobby package :)
To that end, if you could make (or just point to) a "release" I should use for the first package to go up, I'd be very grateful. I estimate the repository will be live by this Sunday, so it would be nice to have a good springlobby package by then.
Latest we have should be fine. The build system or dependencies have not changed lately so packaging should be identical what ever recent version you choose.
Btw, how are you going to version control your debian-directory for springlobby package? We will gladly take it upstream too, if that has any benefits. We provide read-only SVN, and for development we use Git distributedly, so you can ask any of us to pull from you. We can work out some automated deb builds when ever our official tree changes, if you send your changes upstream it's probably easiest, or what do you think?
Btw, how are you going to version control your debian-directory for springlobby package? We will gladly take it upstream too, if that has any benefits. We provide read-only SVN, and for development we use Git distributedly, so you can ask any of us to pull from you. We can work out some automated deb builds when ever our official tree changes, if you send your changes upstream it's probably easiest, or what do you think?
I'm running the latest version of the windows build, and still having problems. There hasn't been an updated build of the windows versions since I posted...so I'm not quite sure what's going on...tc- wrote:That unitsync problem should be fixed in my thread branch on my git repository.
Did you think I was using a linux build? is there a glitch that's showing up on windows that you fixed on Linux?
(oh. and my thing about the "cache" I figured out. all the stuff stored in random text boxes from previous entries...windows stores in the registry. ahh... windows )
I think it's easiest for you to just tell me whenever the package should be updated (ie, a new "release"), then I'll grab a new tarball and update the package. It's actually pretty easy.semi wrote:Latest we have should be fine. The build system or dependencies have not changed lately so packaging should be identical what ever recent version you choose.
Btw, how are you going to version control your debian-directory for springlobby package? We will gladly take it upstream too, if that has any benefits. We provide read-only SVN, and for development we use Git distributedly, so you can ask any of us to pull from you. We can work out some automated deb builds when ever our official tree changes, if you send your changes upstream it's probably easiest, or what do you think?
There's no need for you to include any debianization stuff elsewhere, like in the main tree.
We also don't want automated updates, as we should expect springlobby to break from time to time in git. Automatically updating people to the latest (with, say, a buildbot pushing the package into the repository) would be a bad idea - if you're going to be testing the latest source code, you can compile by hand.