Replies: 4 comments
-
I think this is the best, to have an orderly structure, besides I'm more faithful to having a pserver as close to an official one and I also believe that people who are going to dedicate themselves to maintaining pservers must have the minimum knowledge to make changes like these |
Beta Was this translation helpful? Give feedback.
-
@k3ldon I'm not sure I understood what you said, it sounds like you don't like this idea, because you prefer vanilla servers, and because you believe pserver owners are supposed to know enough to make changes like the ones I described themselves. Did I get that right? |
Beta Was this translation helpful? Give feedback.
-
One more thing we used this for on Aura is a wiki. Its web server comes with a wiki-like site, that displays markdown based articles, and those articles adjust automatically to the server's enabled features. For example, if something was only obtainable one way until update 3 and another after that, the page will only display the first method until update 3 is enabled. This was useful because the normal wikis for the game naturally only ever reflected the latest update, which caused confusion because the latest updates weren't implemented in Aura yet. No matter how the user customized the feature db, the player could always rely on getting accurate information from the wiki for that specific server. Though I don't know if that would be really useful for iToS. I should probably look into how exactly IMC handles updates^^ An example might be the start cities. One wiki on the internet might say you can choose the start city, one might not say that, you don't know how your server handles it, but a char creation article on your server's wiki would tell you. |
Beta Was this translation helpful? Give feedback.
-
Well, by now there's been a slew of changes, and I think we will need this^^ Luckily we also have client scripting now, so we'll even be able to make UI changes based on feature settings. This will be awesome. |
Beta Was this translation helpful? Give feedback.
-
This is something that doesn't really affect us just yet, but that I think we should talk about before it does affect us.
Problem
It's pretty typical for MMOs to change with updates, and often times these updates include changes that players don't like. In turn these changes are often times disabled on pservers, but I feel like most server emulators do a pretty lackluster job of providing ways to quickly and comfortably change these settings.
Let's take Ragnarok as an example, and more specifically, the destruction of Morroc. When this update hit, eAthena changed all warps and NPCs to match the new official ones. A lot of warps were even removed from the desert. Now if you wanted to restore Morroc, you not only had to modify your client, but you had to get an older version of eAthena to copy the old warps and NPCs from, while disabling the new ones. So far so doable with some tinkering, but then Morroc and the desert went through another change in RE. Now you had three Morrocs to choose from for the client, changes in more warps and NPCs, and even new entrances and exits for Ant Hell in the desert.
I recently went through puzzling together a pre-RE server with a restored Morroc, and while doable, it's simply not fun, and the entire time I was wondering why nobody had thought of a better way to handle these changes, to make them toggleable more easily. I mean... they didn't even leave the old code in, they just removed it, as if it wasn't important anymore.
Same thing goes for how they handled RE, with separate sub-folders, duplicate scripts and databases, where it gets really annoying to even find what you're looking for.
Solution
For a potential solution, let me introduce you to the "feature db" we have in our Mabinogi emulator, Aura. It's basically a list of toggles for every feature that changed or was added at some point in Mabinogi's life. Organized in a tree of "Generation" and "Season" updates (major and minor updates in Mabinogi), a user can enable and disable entire updates by changing a single bool. Don't want a certain skill to be attainable? Change one bool. Don't want pets? Change one bool. Want updates 1~5 and 7~8, but not 6, because that changed several systems, which you didn't like? Enable all bools but that one.
These are then checked in the code and the databases to adjust the game to whatever the user wants. Monsters will drop certain items that have a feature setting only if that feature is enabled, dungeons can only be entered if they're enabled, and if an item changed completely, in addition to the old one you add the new version with a feature check, so it's loaded and overrides the older version if the feature is enabled.
If we go back to the Ragnarok example, having such a feature db in eAthena would've meant that instead of spending an hour looking for the correct older eAthena versions to copy from, figuring out new warps that I'm then missing, and navigating the RE folders, I would've simply changed a few bools, and that would've been it. In and out in 3 minutes.
You may also consider classic servers, pre-Adv and so on, which are supposed to run at Episode XY, while they want to use the latest client for convenience and QoL functions. The further back you go, the harder it becomes to create such a server in Athena, because tons of monsters, drops, skills, and so on have to be changed. With a feature db it's, again, a matter of minutes.
I don't know what the future of Melia will look like, and how many features that are to come we will actually be able to toggle from the server, seeing how quite a few things in ToS are client sided, but I think it's worth considering, even if it ends up only affecting some warps, NPCs, and maybe skills.
Beta Was this translation helpful? Give feedback.
All reactions