Support for ACE-World 0.2.0+ #499
Conversation
| DROP TABLE IF EXISTS `ace_landblock`; | ||
| /*!40101 SET @saved_cs_client = @@character_set_client */; | ||
| /*!40101 SET character_set_client = utf8 */; | ||
| CREATE TABLE `ace_landblock` ( |
There was a problem hiding this comment.
Is this new or just consolidating what was already done? If the former, why are we re-denormalizing this data again? We had solutions for this already. I get the point about only storing the weenie data instead of the instanced data for NPCs - I agree that makes sense. I'd rather have a flag in ace_object for "load_from_weenie" or something, allowing us to only store the location, preassigned Guid, and that flag for the instance.
There was a problem hiding this comment.
there are far too many gaps in the data coverage for full object instancing to work at this time in development for the world database side of things. For every object instance we have in ACE, it had to be seen, assessed, and used to make up the "complete" object, which doesn't include the properties we don't know about. For every property sent to the client about a single instance there are at least two more that weren't. Given that, even ACE "complete" instances lack numerous important properties. On top of that due to the instancing, the "completeness" of the same weenie from one object to the next wildly varies.
The instance system this PR makes use of vastly improves the ACE "completeness" of every object we know about it and makes it very easy to continue to correct and augment going forward. The current system has object instances in varying degrees of ACE "completeness" and wastes multiple resources due to ignoring the nature of how weenies worked.
There was a problem hiding this comment.
This PR could have easily addressed the instance/weenie problem without any new database models, which was my point. You're conflating the problem that needs addressing (which we agree on) with our complaints about the implementation.
There was a problem hiding this comment.
It didn't/doesn't make much sense to me to mix partial objects with complete objects within the ace_object table. I'm sure it can be done with the right setup in landblock.cs and some hackery to let it know when an object is a partial vs complete but I don't see the benefit of bending ace_object+ace_position to fit that kind of dynamic. I like the clear split of using a separate table/object for instances within the world db and I'm confident that at this time its the better of iteration of the two systems and have tested it to effectively replicate what was going on before in the database at runtime instead.
|
I posted my concerns about this update over in discord. |
Download and import ACE-World v0.2.0 prior to starting up ACE.
This shifts the world database away from ace_object instances to a more easily managed instance generated by weenies system.
Each time the server is started and when the landblock is first loaded it will generate new instances based on the weenies in the database.
This new structure reduces database size and import times as well as makes it significantly easier to correct the flaws introduced by pulling weenies out of PCAP data.
This does not change the structure for objects stored in the shard database. Those objects should always remain copies of weenies saved in ace_object as a unique, complete instance.