search

fredi-68 / luswca

Remember to put full project title here
GNU General Public License v3.0
0 stars 0 forks source link

Use a custom loader for importing replica components instead of current implementation #46

Closed fredi-68 closed 5 years ago

fredi-68 commented 5 years ago

The current implementation is messy and bad. It consists of a bunch of import statements at the top of the file(s) and then manual arrangement in mappings in zone.py. Not only does this look bad and is very difficult to extend (which may be necessary as new components are discovered), it also fucks with our namespace, especially in the zone file.

Solution: Have a loader function in the objects package that (re)loads all components and possibly a ComponentRegistry class that manages component templates with some methods for retrieving components by name, ID, indices, stack index, etc...

fredi-68 commented 5 years ago

Just double checked and components already specify the component index and a list of indices. We should add a name class attribute as well. TODO: Find out if there are canonical names for the components in the client database and use those if possible

fredi-68 commented 5 years ago

This is turning out to be a much bigger rework than I thought it would be...

I looked at the replicaObject implementation again and realized that in order to ever get any sort of order into this chaos we NEED to couple component specific behavior to component classes. This is most likely also the way the original server did this. What this means for us is that we need to extract all game message / interaction handling that is specific to a certain type of replica component, extract it and put it into the component. For this to work, the Component ABC will have to expose methods for handling game messages, interaction requests and later other in world events such as collision. This also means that components need access to the server instance. All of this is pretty trivial, since we have access to all registered components as well as the server instance inside the replicaObject constructor and event handler methods. However, in order for the more sophisticated replica components to work properly we will need to pass level information from the scene loader to the components. In the end this comes down to standardizing the component instanciation / initialization procedure. Which was gonna happen eventually anyways.

I think this was actually the difference between indices and components in the original server. The indices are referring to the data structures used to store information (and possibly these were also the objects implementing serialize / deserializing code), while the components defined the behavior through a standardized interface.

fredi-68 commented 5 years ago

I've moved the components into a subpackage and reorganized the objects package to more clearly represent the class hierarchy. After some issues with how Python handles class equalities, I've got a system working that allows to retrieve component classes using their ID, name or stack index. I have also added methods for handling game messages and interactions inside of components and extracted all component specific logic from the ReplicaObject as a result. I have however noticed that with the new system, the way we handle object position is becoming rather inconvenient so that will be changed to only use one position/rotation value on the object that all other components refer to instead. Also left to do is fixing the zone component creation code to use the new interface for getting component classes as opposed to the horrible mapping at the top of the file.

fredi-68 commented 5 years ago

This refactor has been in testing for some time now and I believe it to be stable. I'll consider it done and move on to something else