[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!
Comments
4-this could definitely be a problem and as a solution I will join alexina to cash in on all the discounted gear from "quitting/transfering sales". Alexina is looking a lot brighter with me there.
If you work extensively with databases with complex referencing and foreign keys you would understand that accessing and changing values are a very easy thing, but whether or not the program will run fine after is different issue all together. One big issue I've seen when merging of database is when PKs of FKs are improperly ported over, or even just an small over sight, could result is catastrophic errors to occur. For instance a reference is suppose to point to a unique object, but thanks to a database merge, or an appending of another database, could cause this reference to now point to two or more objects. This has several effects, the more benign one is that it just defaults to the first instance, ignoring the other entries. More damaging effects are if the reference points to further tables and entries which in turn could cascade into corruption of other data which can be extremely difficult to fix. Assuming this only affects a tiny minority, there's the risk that someone could see their account lost for days or weeks at a time while NA considers the merge a success. As a game, the cross references, FKs and other things are bound to be extensive. We are also unsure of the data structure which could mean very well that PKs will have to be done and adjusted for during the actual merge. For example certain aspects might be kept as separate databases with identical tables. A merge of such databases would need mean that any PKs will almost certainly have duplicates in the other databases. Now you may think that just changing these are a simple matter, however when changing these, you must also be weary of also changing FKs of other entries. Missing any of these entries could result in displaced or lost items or corruption of other data.
The Q/A from the developers a number of years ago have explicitly named them as blackboxes and the reason why they were weary of doing updates to specific content. They may have since researched into them to remove their blackbox status, but it does not change the fact that any function with in the code that is poorly understood are called blackboxes. When working with databases, it is paramount to understand how the code interacts with the database. If an invalid entry is made it WILL lead to further issues. The fact is that money and man power is needed to research it, and how much money from the budget will be devoted to doing it. If you believe that editting a database outside of the program's normal operation does not involve the code, you will be in for a rude awakening if you apply that logic.
If you have a copy of the database I would love to see it since I'm curious about how the data structures are organized. I can almost say for certain that the data structures are far more complex and entwined than you think they are and this goes far beyond just "editing" values. I can almost say for certain that databases will have to be merged given how much time and effort they put into this. If the issue was something simple like "editing" values, this would not be a big deal that took so long to do.
At the end of the day I believe that you assume that the data structures and the merge are a simpe affair and that the merge itself is accomplished with the simple edits of just a few fields. As someone that deals extensively with databases on a daily basis, I can tell you for certain that there are matters that absolutely complicates this. Otherwise it wouldn't have taken them this long to even try something like this.
I think we're at the point of talking in circles, so I'll just summarize as best I can:
- For me "Black Boxes" are files of executable code that have no corresponding source code and are only available during the linking portion of the build. If there is source code, it's not a Black Box, although it may be a challenge to work with.
- I don't think this merge will require changes to the code, and will be accomplished strictly with database manipulation, specifically editing of fields. So any talk of Black Boxes, here I think, is irrelevant.
- If I understood you correctly the work on the database for this undertaking will very likely involve more than simply editing server name fields, at least with respect to issues where server of residence must be known. I believe that they will literally just change every data instance of "Tarlach" "Ruari" and "Mari" to "Nao" and that understanding what is said in any Black Box, won't be necessary, at least with respect to issues where server of residence must be known.
On these then, I think we're just going to disagree. I will grant you though, that should the merge actually go smoothly, I could not, in good conscience, consider that as proof of my position, as I recognize that it could be that you were right all along and that Nex-er-the-relevant-party-performing-the-merge either dodged a very big bullet or managed to be sufficiently diligent for this undertaking. I think perhaps we can both agree that issues arising from renaming objects such as characters and homesteads is high likely to be problematic.
You really contradict yourself on these forums.
DISCLAIMER: since the following post is not made by an employee of Nexon or any of it's affiliates or partners, what is contained therein is ultimately speculation. Until Nexon or any of its affiliates or partners has spoken definitively on the matters to be discussed, do not take them as granted, even if the language used happens to make it seem so.