Answer soon because site staff has been deleting things like this. I'm gonna guess:
Tarlach 13%ishEralea wrote:If that is the case, then it will ironic as the server that most supports a merge didn't get the merge.
I think I may have misunderstood the question, what exactly are you asking?
Let me rephrase that then, "it would ironic that the server with the most people that wanted a merge didn't get the merge."
Personally, I know more people on Alexina who didn't want a merge over those who wanted a merge.
I also know that the pro-merge people would have loved to argue all day with the anti-merge people, but the anti-merge people never felt the need to go out of their way to squabble about it because they were already satisfied with the no merge decision for Alexina.
Which is the attitude I need to take, to be honest. There's no need for me to posit anti-merge opinions. My "side" already "won" from the start.
But don't assume we don't exist. The pro-merge people are just more visible because you're all voicing unopposed complaints. There is a large anti-merge group that isn't engaging with you. At this point I'm just rolling my eyes whenever I see surveys that only pro-merge people will vote in, and discussions that only pro-merge people will weigh in on. It's like you guys don't even realise you're in a biased echo chamber.
I just might server change to Alexina if it'll be emptier. Y'all are lucky.
The old servers were small enough that they were merged together, while Alexina was considered big enough to not be merged. What you are experiencing now is nothing new for us. Still it must be coming as a shock to you; that's understandable. Marians are on a twice as big server, Ruairians three times, and Tarlachites four times. It may not be easy to see right now, but you will get used to it and adapt; you all will. Consider this, all that you are now experiencing is nothing new to the folks on Alexina, yet in spite of all that, we'd all like to be merged too.
A merge isn't a real solution to dwindling player numbers, its a response to the company's lack of confidence in being able to draw in new players. There's also a problem now of people who previous wanted to get away from players in those servers are now stuck with them or throw away everything they've invested to maybe keep away from those people until the next time they do a final merge into 1 server. While players will have to adapt to continue enjoying the game, this was an unnecessary change that was imposed on many players that did not want the merge to take place. They should've implemented server transfer only and let players choose if they want to migrate to a more populated server or to a less populated one. The choice now has also been taken away as we now only have 2 highly populated servers.
That could very well be but the dwindling player base may have been a result of the small servers, or rather too may of them. Apparently, the Korean servers have 20 channels; we never did. If we had then we might've only needed two servers all along, each with 20 channels. Such a set-up from day one might've kept the population sufficiently concentrated to have kept some folks from quitting.
Choosing between people who want to be away from other people and people who want to be near people is a zero-sum game. I suspect inclusion is the much more popular desire.
The biggest problem with Mabingoi is the same as it is for all games: they are funner for new to mid-level players, but not so much for highest-end players. Most of the folks that are jaded by Mabinogi now are these high-end players. You can see they've tried to make new content interesting for them, but then weak players complain that they are shut out until they are strong enough so for them there essentially is no new content. And when they make new content for the newer to mid-level players then the high-end player complain that it's not challenging and that they are still bored. Shadow missions attempted to address this by allowing freely chosen difficulty level, and what do active non-AFK/chatting high-end players do? Difficulty selectable content. But I digress.
It's most likely a limitation of the game engine itself. Remember, given the amount of problems we're seeing, a server merge was never envisioned, and the data was not designed to be merged like this. If I had to explain it, the game probably requires a fixed user name as reference for some of its code so if it detects a collision, its not designed to handle it by renaming. From my understanding it seems like even the name change isn't a real time service, its a request, as in they have to turn the servers off to change the name in the database (with massive limitations) at set intervals (server maint).
The +server tag solution is clearly a kludge. I bet it was as obvious to you as it was to me that it was so. It's too bad that they use the name as the key field as we now see the consequences of that. I've called for them to use another field in this roll to free up the name field for variation. I suspect the problems we are seeing are by inconsistent applications of this name field in other objects. In some cases, they seem to be populating a reference field with the data copied over from the name field while in others it holds a kind of pointer. Those used as pointers ideally should handle name changes without a second thought, whereas the ones populated directly with text will be the ones that can be accidentally overlooked. I think you're right that name changes would have to be done during maintenances as they are, in a sense, mini-versions of the server merge that happened just now.
While I understand you have a good idea on how to avoid it, understand that different people have worked on the game code itself. From my experience in the industry another programmer on the team might be writing code for a different feature and used the character naming field as a key since the thought process at the time was "These will serve as unique identifiers" in which a server merge was not even considered possible. Then compound all of these over time where newer programmers on the project do not have time or the resources to investigate code written by an older programmer and use different fields in the database for their features since at the time, they were unique keys within their own servers. This is the result, a machine so complex that many of the parts are black boxes, working away fine but a small change or misalignment will cause failure and damage. The merger was not elegant, they had to delete problem items (I'm still getting them to look into a bunch of issues I have), the web shop is broken for a server, the auction house was broken from the get-go, as well as a magnitude of account/character specific problems.
This is not including some of the social and economical issues this has introduced. But that's another thing entirely.
Of course making something new in game, with staff turn-over, and the industry practice of not commenting the source code sufficiently produces the issues you describe here. Of the term "black box" were just gonna disagree about its definition. Overseas they have the server change options, this merge was an application of just that but on the largest possible scale. The issues we are experiencing are due to either name change, or issues with items that were not cleared out of places that they should have been.
But anyway the merge is in the past now. Having the key field not be based on the name, if accomplished, I think you'll agree is a good idea. Will it be work? Of course but so is adding a new generation, or in the past when they changed the combat system. The conditions that the dev teams may have to work under is pretty much how things are in the industry, they'll work on it, and they'll get it done.
Good talk BTW. If we can identify and propose solutions to potential issues they may be experiencing then I can't see that hurting them.
There is of course the flip side in that there IS a unique identifier that they have not bothered to use. In the industry I have noticed that there are actually designs and considerations made when designing the original product to account for a specific functionality that a future team may face. The problem is that the original base product will take to these changes fine, its the new stuff that has now been such integral part of the program that it is no longer an option. The sad fact is that the time investment in changing it for the better is just simply not worth the resources invested in in most cases. While your suggestion will handle the issue we saw, the problem how much it cost to apply a decade old product with numerous revisions and updates. The network of keys and interconnecting parts means that a small change will cascade. From people I've spoken to, some people do have actual character data corruption as a result of the merge. In all honesty to implement your solution will probably require the system to be completely rebuilt from the ground up. If anything I think the current method they have is the best solution that uses up the least amount of resources. Namely brute force the name changes and delete any possible problem collisions.
I suspect there is such a field, sort of. There does seem to be a "record number" at least for characters and pets; I don't know about Homesteads though. A modder told me that with a mod they are using that you can actually read a characters record number. Apparently, it is combined for characters and pets, but it seems to be old server based. But then this is the word of a modder so who knows.
Of course in planning any project, it comes down to the bottom line: is it worth it? Only Nex-er-whoever-it-is knows. It's really a shame though that they didn't design the database, from the get-go, so that the key field was independent of the name.