Information Status update

Writing a quick status update - sorry if this isn't particularly well written or cohesive, but I want to focus on finishing up on the things I will be listing below. This will mainly be from my stand of view (coding).

Infrastructure

As first, we're going to switch to a different host. The server is better in every way, and cheaper (yay). phnx has set up the new server with more management tools available for us, so we can diagnose issues such as lag better. Along with that, it will be hosting a test server as well. Which is why it's taking a bit longer to switch hosts. Still lacking some proper tooling to control two servers properly and efficiently (which should be done this week). So far, everything looks super nice and I'm excited to start using all the new gucci tools.

Coding
What's being worked on right now

Along with that, I think the test server is a great opportunity to optimize some of Odin's old code. I'm currently rewriting the classic model of a Login, World and Channel server running in three separate processes. It just doesn't provide the scalability and manageability that could be achieved. In contrary, it has a lot of overhead involved and potential bugs that could be avoided. I'm writing a more modular design, avoiding overhead where possible for maximum performance. This will allow for more flexible set-up, that we can control without restarts.

Furthermore, I will also be replacing the current NIO framework (Apache MINA) to Netty. Based on reading, it should result in something that's roughly 10% faster. Also, the code is a lot cleaner in my opinion, and the documentation is definitely better.

I had already started on recoding how scripts are used in Odin's source (NPC chat, party quests, reactors, transportation, some quests, some portals...). I've re-writing the code that loads and calls the scripts, but because of this change, along with the fact that we'll be upgrading to Java 8, all 1,302 scripts will need to be rewritten as well.

Coding
Why

These are changes that I'm unable to do on the live server (or with a single server set up in general). The first two are too fundamental, and may take a bit to get working flawlessly. The script updates are simply not possible because of the newer Java version required, and not being able to properly test all the changes (time constraints). Although, all these changes won't make any difference to the game itself, I still think it's important to do them now.

The first change will make it a lot more easy to manage the code, while being a lot more flexible in how we set things up (e.g. it should allow to add a channel that's running the latest revision, and have people test with us). The second change won't require too much time and should decrease latency, can hardly argue with that. Changing the scripting will also allow scripts to be used better, and it's pretty much required to update the scripts themselves because of Java 8 using Nashorn, so might as well do it properly.

Coding
What's next

I'll be rewriting the GM commands, making improvements to existing commands, and adding new commands (e.g. event commands).

Along with updating and recoding the scripts. I'm planning to add missing parts of the original 0.62 experience (e.g. weddings, Amoria PQ...), after which I'll focus on completing/fixing new areas (e.g. Magatia).

If anyone has suggestions, please let us know. We read everything, and with the test server, we can definitely implement some of the suggestions and mess around with them. We have looked at the suggestions from all of you and are currently preparing to roll out some changes.

Communication

To improve communication about code changes, I've set up a separate forum section, where messages will automatically get posted on code changes. This section will only deal with changes for our test environment and may or may not actually end up being implemented. Be aware that these are auto generated messages, and that some details may get removed before publication. This has been set-up to keep everyone updated in a way that's as transparent, efficient and maintainable as possible. We'll see how this goes

 

Update: pretty much done with the first part. Still a few kinks I want to iron out (e.g. more logging during normal use, ignore connection errors during shut down as they are expected). Also still might want to refactor some of the current code, but as far as functionality goes I'm pretty happy with the result.