Check out all of the details of this month's Patch Notes, featuring the 16th Anniversary and VIP Renewal Update! https://mabinogi.nexon.net/news/90098/16th-anniversary-and-vip-renewal-patch-notes-march-14th
[NEW MILLETIANS] Please note that all new forum users have to be approved before posting. This process can take up to 24 hours, and we appreciate your patience.
If this is your first visit, be sure to check out the Nexon Forums Code of Conduct. You have to register before you can post, so you can log in or create a forum name above to proceed. Thank you for your visit!

Name change blues

nikyahnikyah
Mabinogi Rep: 1,150
Posts: 92
Member
edited June 3, 2019 in General Chat
They should let the character that was created first keep their name.
Spareoh

Comments

  • HelsaHelsa
    Mabinogi Rep: 23,380
    Posts: 5,763
    Member
    It's too bad that they are gonna force "There can be only one" on folks who may have had the same name for years. On the other hand if they do implement allowing multiple name copies then it won't matter. So, sure, try to win the race but if you don't then, here on the forums, go into repeat calling for multi-name. I mean, it worked for server merge right?
  • DanievictriaDanievictria
    Mabinogi Rep: 3,695
    Posts: 313
    Member
    They really should have done what Wildstar did when they merged their servers. When they did, they introduced last names to character names, so players just had to add a unique last name to their character so they could keep their first names intact. That would cause a lot less drama and anxiety than the "+Server" method. Then again, maybe that was thought of but it turned out Mabi's aging code can't support a modification like that without breaking horribly, which is why we're getting the "+Server" thing.

    I'm sure there are lots of people who would like (or at least, not mind) a last name feature...
    Spareoh
  • ErikaErika
    Mabinogi Rep: 3,420
    Posts: 259
    Member
    I don't know if there's really a great way to handle this. Keep in mind that player characters, pets, and partners share the same name database.

    Say that a player on Mari created a pet named "Bob" during G2, and then an actual player named "Bob" was created on Ruairi during G9. Would that pet get priority over the player character?

    Or what if the person who created the name first quit long ago? And the second person who used the name was much more active? Would it still be fair to give priority to the person who created it first?

    My wife's character's name has been used by someone(s) else on the other three servers. Who knows if they're pets or partners, though. Or if those people even still play anymore. Whereas my wife and I still login (almost) every day. Would it be fair for her to lose her name to someone else who might not be active, or even a player character?
    Danievictria
  • nikyahnikyah
    Mabinogi Rep: 1,150
    Posts: 92
    Member
    edited June 4, 2019
    no talking about pets names don't care about those. I log in every day and have played since the start of mabi. Faithfull players should get name priority
  • HelsaHelsa
    Mabinogi Rep: 23,380
    Posts: 5,763
    Member
    Mmm Mmm Mmm Mnm Mmm Mmm

    I got da name change blues baby, done got mah name changed own me.
    I got da name change blues baby, done got mah name changed own me.
    Day done put an ugleh plus sign.
    An' iz ugleh ays cain be.

    Doan wan no ugleh ugleh plus sign, mmmmm thad juz woan do.
    Doan wan no ugleh ugleh plus sign, mmmmm thad juz woan do.
    Yuh done takes away mah dignity.
    An' nah ahm ow sad'n blue.

    Tell 'em ow 'bout ih y'all.
    <solo>

    I got da name change blues baby, an' nah ahm ow sad'n blue.
    I got da name change blues baby, an' nah ahm ow sad'n blue.
    Ah wan mah oh name back, OW.
    Wah cain't chew be true.

    Ah wan mah oh name back, 'n' thaz uh fack.
    Ah wan mah oh name back, 'n' thaz uh fack.
    Ah wan mah oh name back, 'n' thaz uh fack.
    Oh yeah, oh yeah, oh yeah.
    DanievictriaMaiaSaiTheDumbOne
  • nikyahnikyah
    Mabinogi Rep: 1,150
    Posts: 92
    Member
    lol cracking me up
  • GTCvActiumGTCvActium
    Mabinogi Rep: 7,125
    Posts: 661
    Member
    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).
    Danievictria
  • SaiSai
    Mabinogi Rep: 8,785
    Posts: 675
    Member
    Helsa wrote: »
    Mmm Mmm Mmm Mnm Mmm Mmm

    I got da name change blues baby, done got mah name changed own me.
    I got da name change blues baby, done got mah name changed own me.
    Day done put an ugleh plus sign.
    An' iz ugleh ays cain be.

    Doan wan no ugleh ugleh plus sign, mmmmm thad juz woan do.
    Doan wan no ugleh ugleh plus sign, mmmmm thad juz woan do.
    Yuh done takes away mah dignity.
    An' nah ahm ow sad'n blue.

    Tell 'em ow 'bout ih y'all.
    <solo>

    I got da name change blues baby, an' nah ahm ow sad'n blue.
    I got da name change blues baby, an' nah ahm ow sad'n blue.
    Ah wan mah oh name back, OW.
    Wah cain't chew be true.

    Ah wan mah oh name back, 'n' thaz uh fack.
    Ah wan mah oh name back, 'n' thaz uh fack.
    Ah wan mah oh name back, 'n' thaz uh fack.
    Oh yeah, oh yeah, oh yeah.

    I got da name change blues. cEtN9Od.png
  • HelsaHelsa
    Mabinogi Rep: 23,380
    Posts: 5,763
    Member
    GTCvActium wrote: »
    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.
  • GTCvActiumGTCvActium
    Mabinogi Rep: 7,125
    Posts: 661
    Member
    Helsa wrote: »
    GTCvActium wrote: »
    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.
  • HelsaHelsa
    Mabinogi Rep: 23,380
    Posts: 5,763
    Member
    GTCvActium wrote: »
    Helsa wrote: »
    GTCvActium wrote: »
    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.
  • GTCvActiumGTCvActium
    Mabinogi Rep: 7,125
    Posts: 661
    Member
    Helsa wrote: »
    GTCvActium wrote: »
    Helsa wrote: »
    GTCvActium wrote: »
    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.
    Spareoh
  • HelsaHelsa
    Mabinogi Rep: 23,380
    Posts: 5,763
    Member
    GTCvActium wrote: »
    Helsa wrote: »
    GTCvActium wrote: »
    Helsa wrote: »
    GTCvActium wrote: »
    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.

  • GTCvActiumGTCvActium
    Mabinogi Rep: 7,125
    Posts: 661
    Member
    Helsa wrote: »
    GTCvActium wrote: »
    Helsa wrote: »
    GTCvActium wrote: »
    Helsa wrote: »
    GTCvActium wrote: »
    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.

    The problem isn't that there wasn't planning. By my experience, the base product, the engine specifically had a road map and was designed by a team that was co-ordinated with goals and milestones in place. Again, this comes down to the fact that people join and leave the team. With the push for features to add, there is no way to plan for things several decades down the line. With the age of the game and the code theres layers upon layers of different coding styles, considerations, and challenges. The point I'm trying to make is that there was no "Final Product" planning. Unlike a console game of old where a game is completed with a list of features to be in the game (specially an actual target goal), an MMO like Mabi does not. Since the game is ever changing with different goals, ideas, and new system implemented, this means that the goals, design considerations, and even retroactive changes warp and alter over time.

    Let's look at a very basic example. Mabi version 1 was designed with a unique ID that is completely unique that its even unique across different publishers. A server merge at this point is very simple, the changing of the "server" field is all that's needed for a merge. Next is Version 2, a new feature is implemented that does not use this unique ID, instead since it deals primarily with the name tag so it instead uses the name tag instead of the unique ID as a key. A server merge at this point requires changing both the server field, and checking and handling collisions of player names. Version 3 builds a system on top of the feature created in Version 2, using Version's keys as their primary keys as well. A server merge at this point requires the server field to be changed, Version 2's name tags handled, and Version 3's keys to be handled. Fast forward to Version 20, the base product has since added many new features, some have used the unique ID, other used the name field. Other versions have built on top of original features that used the name field while others have references to both fields. There are entire data structures created and dependent on the naming field being unique in its case to operate. At this stage a server change requires the following, the server field to be changed, the names field handled, any keys referencing naming fields to be handled and any problem fields deleted.
    Spareoh
  • HelsaHelsa
    Mabinogi Rep: 23,380
    Posts: 5,763
    Member
    GTCvActium wrote: »
    Helsa wrote: »
    GTCvActium wrote: »
    Helsa wrote: »
    GTCvActium wrote: »
    Helsa wrote: »
    GTCvActium wrote: »
    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.

    The problem isn't that there wasn't planning. By my experience, the base product, the engine specifically had a road map and was designed by a team that was co-ordinated with goals and milestones in place. Again, this comes down to the fact that people join and leave the team. With the push for features to add, there is no way to plan for things several decades down the line. With the age of the game and the code theres layers upon layers of different coding styles, considerations, and challenges. The point I'm trying to make is that there was no "Final Product" planning. Unlike a console game of old where a game is completed with a list of features to be in the game (specially an actual target goal), an MMO like Mabi does not. Since the game is ever changing with different goals, ideas, and new system implemented, this means that the goals, design considerations, and even retroactive changes warp and alter over time.

    Let's look at a very basic example. Mabi version 1 was designed with a unique ID that is completely unique that its even unique across different publishers. A server merge at this point is very simple, the changing of the "server" field is all that's needed for a merge. Next is Version 2, a new feature is implemented that does not use this unique ID, instead since it deals primarily with the name tag so it instead uses the name tag instead of the unique ID as a key. A server merge at this point requires changing both the server field, and checking and handling collisions of player names. Version 3 builds a system on top of the feature created in Version 2, using Version's keys as their primary keys as well. A server merge at this point requires the server field to be changed, Version 2's name tags handled, and Version 3's keys to be handled. Fast forward to Version 20, the base product has since added many new features, some have used the unique ID, other used the name field. Other versions have built on top of original features that used the name field while others have references to both fields. There are entire data structures created and dependent on the naming field being unique in its case to operate. At this stage a server change requires the following, the server field to be changed, the names field handled, any keys referencing naming fields to be handled and any problem fields deleted.

    It may very well be just like that. That this merge went relatively smoothly with respect to redefining the server of residence, could have been because all that was required was to repopulate that field with new data or it could have been a much more complicated affair as you suspected. As for the issues with the renaming kludge, twenty-ish years ago when the game was initially designed the issues of today we're very likely not foreseen, but it's still a pity it wasn't done the way that I have lamented. Unfortunately, like so many things in life, this was learned the hard way. Moving forward new games, learning from the example here, may choose to have a more independent field do the job, to cover unforeseen developments in the future.