Server chooser GUI

[Entropy]

I would like to have a 'server chooser' menu with the log in screen.

There should be a window under the log in/new char buttons, where the servers.lst info is displayed (only the name and description), and people can select which server they want to log in to.

Can someone implement this please?

[bluap]

I would like to have a 'server chooser' menu with the log in screen...

That would be nice but what about the config directory? To start the client you need to select a config directory. Once the client is started, you would have to close most of it down to switch to another config directory. Obviously, if all the server options use the same config directory, there is no problem. For the debian/ubuntu packages I added an external launcher GUI to allow the line to be chosen from the servers.lst then start the client. Would an external launcher program be OK?

[Entropy]

What do you mean, isn't the config directory selected automagically, depending on the OS?

[Learner]

What do you mean, isn't the config directory selected automagically, depending on the OS?

The config directory he is talking about is the per server directories that are created so your settings, spells, logs, etc are seperate between machines.

 

Also, the login screen normally doesn't come up until after you are connected to the server, so changing servers means almost everything needs to be trashed.

 

\

[The_Piper]

Hu?

 

Under Linux servers.lst is in the EternalLands directory, and hopefully too under Windows and Mac.

 

Just fopen("servers.lst", "rb"), display its content in a window or part of the log in screen and everything should be fine IMO.

 

What else do you need for a server selection box/window/whatever?

 

Piper

[Entropy]

The config dir IS included in the servers.lst, so I don't understand what the problem is.

 

And yes, the Log In screen comes after connecting to the server, so I guess that screen must be placed before it.

[bkc56]

A bit off-topic: this will be a great way to get wider exposure to the existence of the PK server.

[Entropy]

A bit off-topic: this will be a great way to get wider exposure to the existence of the PK server.

 

Yes, and make it easy to go to the test server, and also give us the ability to add new servers.

[bluap]

The main issue is that the config directory contains the el.ini file and el.cfg files. By the time the login screen is available, these files have been read and the client set-up according to those files. If you select a server that uses a different config directory (and hence a different el.ini and el.cfg), you would have to basically restart the client to make use of those settings.

 

Edit:

There is a similar issue with the language selection window. By the time it is displayed, all the strings have been read. If you select anything other than the default language, the client has to restart. I thought that was OK as you only do it once, first time you run the client. With a server selection GUI, you will be selecting different servers regularly.

Edited April 15, 2009 by bluap

[Torg]

That would be nice but what about the config directory? To start the client you need to select a config directory.

The config dir IS included in the servers.lst, so I don't understand what the problem is.

Once the client is started, you would have to close most of it down to switch to another config directory.

The problem is that each config dir can contain a different el.ini file, which in turn can contain a different data dir. This is especially important for the test server as there are often new or updated data files being tested for a new release. This new data dir essentially requires that the client be restarted to reload all the data from the new directory.

 

Obviously, if all the server options use the same config directory, there is no problem.

This could be checked as part of the server selection process deciding if the client needs to be reloaded or not. Also, as part of that process, it could possibly initially read the new el.ini file from the config dir and establish if the data files need to be reloaded, or simply just the ini file settings (which would not necessarily require a client reload).

 

I'm willing to have a shot at this, as this was the original intent for adding the separate config files and expanded servers.lst syntax. That said, I believe some discussion and a general consensus on the best way to tackle reloading the client info is worthwhile before starting to hack the code.

 

Under Linux servers.lst is in the EternalLands directory, and hopefully too under Windows and Mac.

Actually, that isn't the in-use one, it is just a default. The one used by the client is in the base config directory which is in the user specific directory structure as defined by the OS (C:/Docs&Set/[user]/Eternal Lands/ for Windows, ~/.elc/ for Linux and possibly Mac).

[The_Piper]

Under Linux servers.lst is in the EternalLands directory, and hopefully too under Windows and Mac.

Actually, that isn't the in-use one, it is just a default. The one used by the client is in the base config directory which is in the user specific directory structure as defined by the OS (C:/Docs&Set/[user]/Eternal Lands/ for Windows, ~/.elc/ for Linux and possibly Mac).

 

Maybe it's a good idea to use the one in the EternalLands folder

 

I don't see a need for different server.lst's for main, test or PK server

 

K.I.S.S. (Keep it simple, stupid)

 

Piper

[Entropy]

The reason to use one in the config dir is that if we use the one in the main el data dir, we can not auto update it on some OSes due to permission issues.

[Entropy]

Anyway, how about we display that window as the very first thing, before even reading the ini file? We can move the servers.lst file in the root of the main el config dir, one level up from the /main /test etc directories.

[Torg]

Anyway, how about we display that window as the very first thing, before even reading the ini file?

Well the resolution and full screen, etc settings are read from the ini file. Also, the data dir needs to be known to load the fonts.

 

It might be reasonable to make the assumption to use the default "main" initially, unless there was a specific server provided on the command line.

 

If there was a specific server provided then we could initially ignore the server selection window, unless it is chosen at the login page?... thoughts?

 

We can move the servers.lst file in the root of the main el config dir, one level up from the /main /test etc directories.

Why?

[DogBreath]

Hrm, how about a mini-app, or screen that loads before all of this starts up? All it does is read the server list (from the main el directory) and based on that decides what config directory to look in, and then launches the client? I realize I might be way off here, as I haven't really messed with the client code a lot, but it at least 'sounds' logical to me... lol

[Torg]

Hrm, how about a mini-app, or screen that loads before all of this starts up?

That is exactly what bluap's Debian/Ubuntu packages do. They show a simple graphical menu using a command-line tool so it can be launched as part of a script, passing the response back to the script which is then passed to the EL client. What this does mean however, is that you need to exit the client to get the menu again.

 

Ent is wanting something integrated into the client. I tend to agree that it would be much nicer to have something integrated into the EL interface. An external solution is really just a hack.

[DogBreath]

Sounds like back to square one then, as you pointed out, test and live might not be close enough to keep the client 'alive', especially if there's some change in graphics engine... Hrm...

 

EDIT: if exiting the client puts you back to the menu each time, would that be that bad? considering the issue listed above, I'm not sure how that could be avoided... *brainstorming, yeah, I know, it's possbile anything in my brain must be a storm...*

Edited April 15, 2009 by DogBreath

[Fedora]

I programmed a textual selection screen last year, and here is the patch. It's ugly, and i don't even remember how it works, but maybe it can be a start

 

EDIT:

wrong url

Edited April 15, 2009 by Fedora

[DogBreath]

Thinking about this a bit more, most MMOs I can think of use this type of procedure. A server select screen, choose server, then it launches client... Upon exit of client, you go back to the server select screen... (Everquest, WoW, and several others come to mind...)

[Entropy]

We can move the servers.lst file in the root of the main el config dir, one level up from the /main /test etc directories.

Why?

So that we won't have to read the ini to get the data dir

 

Thinking about this a bit more, most MMOs I can think of use this type of procedure. A server select screen, choose server, then it launches client... Upon exit of client, you go back to the server select screen... (Everquest, WoW, and several others come to mind...)

 

Then it would need to be ported for all the platforms we support.

[The_Piper]

Anyway, how about we display that window as the very first thing, before even reading the ini file?

Well the resolution and full screen, etc settings are read from the ini file. Also, the data dir needs to be known to load the fonts.

 

It might be reasonable to make the assumption to use the default "main" initially, unless there was a specific server provided on the command line.

 

If there was a specific server provided then we could initially ignore the server selection window, unless it is chosen at the login page?... thoughts?

 

o You could first read the EL.INI from "main" to get the data directory to load a font (i assume, everybody has a "main" directory)

 

o then size the window to 640x480, which should fit on every screen and should be big enough to hold all servers from servers.lst and pop up a window to select a server (eventually turn on poor man to avoid crashes)

 

o then read EL.INI from the choosen servers directory, connect, log on, thats it

 

Piper

[bluap]

That is exactly what bluap's Debian/Ubuntu packages do....An external solution is really just a hack.

Cheers Torg!

 

Seriously. The other advantage of an external app is that you can wrap some other checking into it; like crash detection, log file display and ensuring data_dirs are OK etc. Learner and I have discussed the relative merits before. Also, it could be release soon, before the next client update. However, I know and accept that an integrated selection system is what people want.

Edited April 15, 2009 by bluap

[Entropy]

Another merit would be that it doesn't have to change with the new engine.. Might be also useful to auto update the client binary as well..

If we go this way how do you plan to make the GUI? Raw OpenGL or some multiplatform GUI lib?

[bluap]

Another merit would be that it doesn't have to change with the new engine.. Might be also useful to auto update the client binary as well..

If we go this way how do you plan to make the GUI? Raw OpenGL or some multiplatform GUI lib?

I guess that's up to the person writing it. There are many possibilities but the simple GUI I use on Linux could not simply be ported to Windows AFAIK. It is basically a shell script that uses a generic app called Zenity for the GUI. Using OpenGL would allow the app to be written using the same graphic style as the client which might be nice.

[DogBreath]

Another merit would be that it doesn't have to change with the new engine.. Might be also useful to auto update the client binary as well..

If we go this way how do you plan to make the GUI? Raw OpenGL or some multiplatform GUI lib?

I guess that's up to the person writing it. There are many possibilities but the simple GUI I use on Linux could not simply be ported to Windows AFAIK. It is basically a shell script that uses a generic app called Zenity for the GUI. Using OpenGL would allow the app to be written using the same graphic style as the client which might be nice.

Why not another c or c++ application, like the application is in already? That seems the easiest way, using the same drivers/includes, this way the compile process would be the same as well... Porting to multiple OSs should be exactly the same then.