6f7e58ff35
Moves AdaMu's working Castle Siege onto the upstream data model that the previous commit introduced, without changing how the siege plays. State model - CastleSiegePhase is replaced by DataModel's CastleSiegeState, whose values are exactly what the game client's CASTLESIEGE_STATE enum expects. The cycle now runs Idle1(0) -> RegisterGuild(1) -> Ready(6) -> Start(7) -> End(8) -> EndCycle(9) -> Idle1(0). - Idle2(2), RegisterMark(3), Idle3(4) and Notify(5) keep their numbers for client compatibility but are never entered: AdaMu registers guilds directly and has no Mark of Lord step. Guild identity - Guilds are now identified by their persistent Guid instead of by name, so a rename (or a delete and re-create under the same name) can no longer hand castle ownership to the wrong guild. Names are carried alongside only for display and for the packets that send a name to the client. - Interfaces.Guild deliberately has no id and the guild server's short ids are in-memory only, so the persistent id is resolved through the guild name once and cached per process. This avoids adding a method to IGuildServer, which upstream keeps changing. Persistence - The castle owner is stored in the CastleSiegeData row and the registrations in CastleSiegeGuildRegistration rows, replacing the previous plugin-configuration JSON blob. Only the current state and when it started still ride on the plugin configuration, because they have no column in the upstream schema. Castle NPCs - The hard-coded gate, catapult, crown and switch coordinates are gone. They are read from GameConfiguration.CastleSiegeConfiguration, seeded by CastleSiegeInitializer. Definitions flagged IsPersistedToDatabase are the breakable defenses and count towards the throne, which additionally brings in the 4 guardian statues the previous implementation did not spawn. - The crown hold time now comes from the seeded configuration instead of the plugin settings. The AdaMu operational settings (cycle durations, registration fee, designated server id, auto-open schedule) moved to a renamed CastleSiegeSettings class, so they no longer collide with upstream's CastleSiegeConfiguration entity. Verified: full server build succeeds with 0 errors. Not yet done: the 0xB2 0x00 CastleSiegeState request handler, and the docker / local run.
OpenMU Project
| Platform | Build Status |
|---|---|
| Windows | |
| Linux (Docker) |
| NuGet Packages | |
|---|---|
| MUnique.OpenMU.Network |  |
| MUnique.OpenMU.Network.Packets |  |
This project aims to create an easy to use, extendable and customizable server for a MMORPG called "MU Online". The server supports multiple versions of the game, but the main focus is version of Season 6 Episode 3 using the ENG (english) protocol. Additionally, the long-term focus is on the open source client which supports a slightly extended network protocol. However, parts of the software can also be suitable for the development of other games, even for other kind of games.
The code is a complete rewrite from scratch - it's not based on pre-existing projects, and it's also explicitly not based on decompiled server sources or their countless derivates.
There also exists a blog which may contain some valuable information about this development.
Current project state
This project is currently under development without any release. You can try the current state by using the available docker image, also mentioned in the quick start guide.
Licensing
This project is released under the MIT license (see LICENSE file).
Used technologies
The project is mainly written in C# and targets .NET 10.0.
The servers admin panel is hosted on an embedded ASP.NET Core webserver (Kestrel) and implemented as Blazor Server App.
At the moment the persistence layer uses the Entity Framework Core and PostgreSQL as database. Additionally, it's also possible to start it in a non-persistent in-memory mode.
The project is prepared to be hosted in a single process or distributed in multiple processes. For the communication between the processes, we use Dapr.
Deployment
We provide Docker images and docker-compose files for easy deployment. Please take a look at the deploy-folder of this project.
Contributions
Contributions are welcome if they meet the following criteria:
-
Language is english.
-
Code should be StyleCop compliant - this project uses the StyleCop.Analyzers for VS2022 so you should see issues directly as warnings.
-
Coding style (naming, etc.) and quality should fit to the current state.
-
No code copied/converted from the well-known decompiled source of the original server.
If you want to contribute, please create a new issue for the feature or bug (if the issue doesn't exist yet) so we can see who is working on something and can discuss possible solutions. If it's a small thing, you can also just send a pull request without adding an issue.
Apart of that, contributions from non-developers are welcome as well. You can test the server, submit issues or suggestions, packet descriptions or documentations about the concepts and mechanics of the game itself. Please use markdown files/syntax for this purpose.
If you have questions about that, don't hesitate to ask in our discord channel or by submitting an issue.
How to contribute code
If you want to contribute code, please do the following steps:
- fork this project from the original MUnique OpenMU Project.
- create a feature branch from the master branch
- commit your changes to your feature branch
- please test your changes, don't send AI generated code without testing it yourself
- submit a pull request to the original master branch
- wait for the code review and merge :)
How to use
Please have a look at the quick start guide.
Gameplay differences to the original server
This project doesn't have the goal to copy the original MU Online server behavior to 100 %. This is not entirely possible, because the original server is written in another programming language and has a completely different architecture. With some points we make our life easier in this project, with other points we try to improve the gameplay.
Calculations
The calculations of attribute values (like character damage decrement etc.) are done with 32 bit float numbers and without rounding off, like the original server does at some places. E.g. distributed stat points always have effect, while in the original server effects might get rounded down. For example, when 4 points of strength gives 1 base damage, the original server doesn't calculate a fraction of 1 damage for 3 points, while OpenMU calculates 0.75 damage. This damage has then an effect in further calculations.
Countdown when changing character or sub-server
The original server uses a five second countdown when a player wants to change his character or the sub-server. Maybe this was done for some performance reasons, as the original server would then save the character/account data. We think that's really annoying and see no real value in that, so we don't use a countdown.