fredi-68
commented
5 years ago seriously though, aside from the technical implementation, how are we going to handle properties? They are handled as individual instances so we need to spawn world server instances each time a player wants to visit a certain property. Since we also need to initialize this instance with the data from the user generated content, the easiest way to store player properties would be as separate zones. All of them would share the same zone.json meta data, but have an additional folder for user generated objects. We could load those using a script, perhaps by attaching it to the zone controller. Alternatively we could just use the world script once that is implemented. This means we'd have to save both the original brick by brick model as well as a file containing information about the object (such as attached behaviors). For the model the most logical idea would be to use lxfml files as the original server did. We will probably need to both parse and write LDD data at some point during property building anyways so we'll have an implementation of the file format. This means, once a player requests access to a property, the server would have to look up the corresponding zone and load it, query all user objects, initialize them, parse the lxfml data and somehow send all of that to the client. Another issue occurs if we are managing multiple property servers. In this case, the zone has to be loaded from some sort of central data server, which means we'd have to make the zones use some easily downloadable format. Just using a ZIP archive should work well here. This however means that we will have to support loading a zone from a ZIP archive in the zone loader, so the respective code will have to be slightly changed.
haHAa
gud mem