Shaiya Genesis Development

[Cups]

Originally Posted by ThatBestNub™

What If Someone Steals Your Works, Just Like OS?
Can You Also Be Able To Edit The Shaiya Effects/Animations?
Can You Also Create An Guide On All/Most Of Your Developments?
Finally, Are You Going To Sell Them? If So, How Much?

Just Curious,
Thank You.

1. OS files were stolen as a result of a backdoor on one of Aeria's test servers. The server is being developed on a seperate machine from the one I use daily, and is compiled to native code. Even if somewhere was to steal the server, they'd have a hard time running it unless there were using the same OS and architecture as I.
2. I don't yet know how to edit the effects or animations, but I can force them to be displayed at will.
3. Releasing a guide on this would take an incredibly long time, and not useful for someone that wouldn't already know how to do it. Realistically the only hard part of this project is reverse engineering the packets and game protocol, and perhaps implementing and optimising an A* pathfinding algorithm.
4. I've not yet decided on how this will be released, if at all. It's primarily a project for me to further my own experience but who knows, I might release the source code in the future.

[Big_]

i dont no why people are asking for price when it is verry early in development im prity shure if cups was going to sell it wouldn't be untill the project is fully complete

[XIBOSDLL]

This is how you call good development good work man.

you need help with dlls or anything codes sources i can help.

[Big_]

Hows the project going Cups =)

[Cups]

I'd like to apologise for the lack of updates and development that I've done on this project. No, it hasn't been left to die completely. A couple weeks or so after posting this thread, I decided it'd be a good idea to wipe my Windows partition and do a fresh install, but somehow I also managed to wipe my Ubuntu partition, and lost all my previous code. I quickly wrote a prototype server from memory using JavaScript (don't judge, it was quick and dirty, and mainly so I could remember how the packets worked).

Around a week or so, I decided to pick up development of this again. This was largely thanks to the motivation given to me by , and he helped me out with obtaining an unencrypted Ep8 game client (I believe it was updated around 16th March 2016). This time around, I'm taking things a bit slower so that I don't get burned out, and have also massively redesigned the server infrastructure.

For those who recall, the original plan for Shaiya Genesis was for the core application to be written in C#, and the game content to be scripted using a Ruby plugin system. I then however switched from Ruby to Python, as the IronRuby project had been long since abandoned, and I figured Python will be easier to learn anyway. This time around, I'm using as the core language, and back to using Ruby again. The plugin system has been designed to be very easy to use and maintain. I'll even be able to host our website as a plugin - one that can call functions from the game server, which should allow for some nice features.

First we have our bootstrap script, which is used to define a few methods and classes that allow plugins to easily interface with the game server. The plugin system is based around the concept of "messages". The server handles incoming packets and decodes their data, and then constructs message data stuctures that are passed around the server. This allows us to separate the packet logic from the data structure, which in turn, will allow me to easily add support for different client episodes, without having to modify any of the core server. Here's an excerpt of the bootstrap script:


Now this might not be very interesting, so let's have a look in game. Here, we have a simple packet decoder implementation that is bound to the "check available name" packet. It reads the name to check, and then binds it to a message:


So now, we write a small script to handle that message. Thanks to our bootstrap script, we can avoid a lot of the boilerplate code, and use Ruby-style API to construct a listener and execute a block of code.


Now that we've set up the listener, we can go in game and try it out by checking if a name is available:


And we can see the output in the server console:


While this is only a small example, the end goal is to abstract away all the packets into message structures, and then pass them down a handler chain. Multiple plugins can listen for the same message, and optionally terminate the message so that it doesn't get passed to another handler. Plugins will be able to listen for any command, message, or game event, and operate on it as the programmer wishes. This will allow for game content to be easily written, without ever having to touch the core of the server.

As I said, this is still a work in progress, and there is a lot left to do, so I'm taking my time with it, rather than rushing it and forcing myself to hate the server. Apologies for the lack of updates!

[[ADM]Minxii]

Teach me senpai

[nick4ever]

Intellij, commercial version bro? I dont know how to port server to mysql server, but if I was you, I prefer postgres db, unfortunately, this is out of my knowledge. Anyway, your work is awesome, Keep going pro

[Cups]

Originally Posted by nick4ever

Intellij, commercial version bro? I dont know how to port server to mysql server, but if I was you, I prefer postgres db, unfortunately, this is out of my knowledge. Anyway, your work is awesome, Keep going pro

For now I'm just using the Community version of IntelliJ, as it provides everything I need. Until I find a reason to buy the Ultimate edition, I'll keep on using this. I was previously using Eclipse, but it's far slower and uses more resources than IntelliJ IDEA. For editing the Ruby scripts, I use the Visual Studio Code app. Prior to VSC, I was using Atom (but again, Atom is a text editor built with JavaScript, and doesn't quite perform as well as I'd like it to).

I originally intended to switch from MySQL to Microsoft's SQL Server - but the Unix versions are still in early access, and realistically for a private server, I don't think the database engine matters all that much, provided it's designed and implemented correctly.

[nick4ever]

You're cool, bro. One question, can I ask for any hint for writing a plugin? You made me start being curious, hiz...

[Cups]

Originally Posted by nick4ever

You're cool, bro. One question, can I ask for any hint for writing a plugin? You made me start being curious, hiz...

The concept and core idea of this server is to make the development of plugins easy for developers who either may not have enough experience to mess with the core of the server, or simply those who'd rather focus on content rather than getting involved with the packets and server infrastructure, and most features in the core of the server uses the producer/consumer pattern. This means that plugins can listen for most events in game, and be notified and called when they're executed.

The bootstrap script ideally should never be touched. This script is basically the API wrapper for all plugins, and make them very easy to write. All incoming messages (decoded packet data structures) are stored in the "genesis.messages.impl.incoming" package. For example when a user goes to create a character, the packet is decoded and constructed as a message called CharacterCreationRequestMessage, which contains the creation data, such as the hair, face, height, class, mode, name and so on. Ruby plugins are designed to be able to listen to these messages easily.

We can see the message is called CharacterCreationRequestMessage, so to listen to it, we'd call the on_message procedure, pass the message name in snake_case_form, and then supply the procedure block to execute, such as:

on :message, :character_creation_request do | account, message |
    puts "Character created with the name #{message.get_character_name}"
end

The call "on :message" refers to the "on" function in the bootstrap script, and the type of ":message". The function then passes the parameters to the "on_message" function, this is just to make it nicer and easier to use. The message system is built around the concept of a message chain. That is, multiple plugins can listen for the same message, and process it. This can be stopped by calling "message.terminate" in your plugin, which stops other plugins from processing it, by stopping the message being passed further down the chain.

Character actions are put in an action queue and processed every 30 milliseconds in the game world thread pool (the tick time might be changed later on after further testing). So if we wanted to listen for an npc interaction message and then execute an action based on that, we could do something like this:

class WarehouseAction < Action

    # Override the internal start function, which is called when the action is ticked through and processed
    def start
        character.open_warehouse
    end
end

# Listen for the npc interaction message
on :message, :npc_interact do | account, message |

    # If the npc id is that of a Warehouse npc
    if message.get_npc_id == 2

        # Get the active character for the account
        character = account.get_active_character

         # Queue the warehouse action
         character.do_action(WarehouseAction.new)
    end
end

A command is also similar to a message, except rather than listener for a specific message type, we call the command dispatcher instance and tell it to listen for a command identifier. The function accepts 2 parameters, the command name, and, optionally, the minimum privilege level to execute it (for now, these are PLAYER, GAME_SAGE, GAME_MASTER, ADMIN).For example, if we wanted to write a command that listens for "/notice "Hello, world" with a minimum privilege level of game master required, we would do it like this:

on :command, :notice, PRIVILEGE_GAME_MASTER do | character, command |

    # The command arguments (space delimited, except when using quotes, they are grouped into 1 argument) 0 refers to the first element in the command argument array, which would be "Hello, world" (without the quotes)
    message = command.get_argument[0]

    # Call the sendNotice function in the Scala game world instance (Scala based instance variables are prefixed with a $)
    $world.send_notice(message)
end

Remember that messages are passed down a chain, so if we wanted to stop other plugins from listening for the same message after this is execute, we should add "message.terminate" is that block. Does this help clarify how to write plugins? This is all subject to change as it's still largely in a design phase, but it should give you a rough idea. I'll release an in-depth tutorial when the server is released.

[Cups]

The character screen gave me some nice insight on the structure of packets, as it's quite a bit different from the episode 6 packet, and helped me fix a misunderstanding I had in the packet structure, but so far it's working nicely. Just need to finish up character creation and saving/loading from the database.

[nick4ever]

How hard effort are you...

[yoyosisi]

This project is awesome

[nick4ever]

How's it going, bro?

[Cups]

Apologies for the lack of development progress, I was occupied with being a staff member on a server the past few months, and recently been busy with my studies and work, so I haven't progressed as much as I'd like to, however, there has been progress.

The fate has also been decided for the Genesis Project! Once I've gotten it to a stage where it's playable and developers can start writing content for it without having to worry about packets, it will be released completely free, and open source. That being said, I have decided that the current version will be used purely for rapid prototyping and for quickly reverse engineering the game protocol. Once I've done this, I will begin work on writing a more scalable version; the current implementation performs very well, but it doesn't yet have support for multiple game servers or the ability to have database servers/login servers on different machines, and that's something I'd like to get done.

Moving on, today was the first real day where I've had nothing on and have been able to sit down, plan out my ideas for the server design, and continue working on reverse engineering the Ep8 protocol. This server framework will support all major episodes (so you can use the same scripts and content between episodes, and upgrade/downgrade episodes at your discretion), but I first wanted to complete Episode 8, as I'm not sure how much longer the OS Servers will be up, and I need them to stay up to collect research and packet data.

My last image was that of the character screen, so you can see I've made a start on the game world. Please note this is still very early in development, and I have a lot of work to do on identifying all the packet data. Either way, I'm happy with the progress so far. I'm aiming for a stable, scalable, open source release by around March.