I’m talking about two graphical user interfaces, one for server settings configuration and one for game server registering against a particular Login server. In the past, you were provided with an “ugly” DOS text-based application for the latter task and for the first one, all you had was a text editor of your choice. Please read more for for some screenshots, design and usage talkabouts…

First of all, have a peek to what they look like on windows XP:

L2J GameServer registering and configuration interfaces

And Kubuntu 9.04:

L2J Gameserver configuration interface, in GNU/Linux.

L2J server settings configuration tool

Let’s talk about the way it works. When it was first written, we agreed with KenM to keep it simple and maintenance-free for the most of it. So when you run the server config tool, it goes through the “config” directory looking for *.properties files and creates one tab per file. Any comment preceding a configuration value will become a tooltip in this GUI (as you can see in the Win screenie). A basic interpretation procedure choses whether you should see a checkbox, an IP widget or a plain text input widget. And that’s about all. Whenever a new file is added, this GUI should support it. All you should need for this tool to work (out of a graphical environment, of course) is to have write permissions for the config files and have them (as well as the languages/images directories) in the correct place. Stock L2J build should grant that. There’s a simple .exe wrapper and a bash script that will server as launchers.

L2J GS registering tool

This tool requires a MySQL server running, you should know the username/password to connect with it. Servername.xml file should be in the login folder too. If for any reason there’s no graphical interface available, this tool should gracefully fall back to the old text based system. I didn’t test it, tho

Translation files

I’ve decided to distribute translation files along with the datapack, since the only one that is mandatory for these tools to work are the english ones. The datapack build file should place them accordingly, but if you do not use eclipse for datapack moving the ‘configurator’ and ‘gsregister’ folders out from ‘l2jserver/gameserver/data/lang’ to ‘l2jserver/languages’ would do the trick. You’re encouraged to contribute any fix or missing language in the forums!

What’s missing

I’d like to have optional translations for the tooltips, included in the i18n files. It would be also good to have some more deep checking rules for whatever values are defined by the user. Maybe some xml file could tell the GUI what to validate for a given configuration entry (if no validation is defined, GUI should flawlessly let values go thru), such as “XPRate should be an integer”, etc. I’m optimistic for that you guys will come up with more ideas and functionality.

Credits

All I did out of committing, was to add i18n and some minor improvements. All the glory for this work goes to KenM and the guys at the team who contributed with translations. Enjoy!

In the past, we had these groups: 

• Inner Circle
• Core and DP developers
• Core and DP initiates

but now it goes like this:

• Inner Circle
• Senior Developers
• Junior Core Developers – Junior DP Developers
• L2J initiates

Firstly, we have merged Core initiates and DP initiates to just one group, with the only pourpose to provide a richer environment for our new team members which, in the future, will become new developers with better collaborative skills.

After this (usully short) initiation period, initiates who are ready for the battle, will be promoted to either core or datapack junior developers depending on their skills or personal willing. They will be granted developer rights to public svn so they can start their career with certain autonomy.

Those team members who had spent a  succesfully period as junior developers, highly commited with project,  with excellent team skills, … will have a chance to join Senior Developers group. Despite senior developers represent the most trustable group for active coding, some members of this group are also expected to engage some executive task related to team, such initiates/jr. developers leadership or global leadership for DP or Core projects.

Why have we done this? Main target could be improve old user->initiate->dev process, taking more care of upbringing and formation process(es) so that(those) can be done more efficiently. However, we are trying to increase/improve our coding and project global leadership(s, both for core and DP) so, again, maximize performance of coding getting more organized. In other words, rather than an independent developing process for each developer, a bunch of independent coordinated tasks engaged by each developer.

Finally, Team and me are glad to announce four new skilly Junior Developers, all of them already well-known within community:

Core: _DS_, shansoft and janiii

Datapack: Sandro

I hope you wellcome them as they are worth to and wish best of lucks!

This is all for now, on next days you will probably find new blog post or forum threads with further information abut this and some new topics.

 Best regards!

PD: We hope forum/svn problems will be fixed soon, our apologies for that nasty issue.