Some Axiom Progress
After 3 or 4 failed attempts at integrating Axiom into MV3D, I’ve finally got it working in a pretty good way I think. The only real issue I have currently is that my Items get pretty messy. As far as I can tell, if a parent class creates a member variable, in the child class (which is also a subclass of Item), you need to re-define that member variable as an axiom.attribute. This is a little annoying, because you’d expect to be able to define those member variables as axiom.attributes in the parent classes, but Axiom doesn’t like that. I found a way to hack it if you aren’t planning on persisting that variable, but it’s so messy that I prefer just listing out all the parent classes’ member variables in each child class. I’ve got the Account Service and Asset Service transformed to use Axiom (including all the types of Assets and AssetGroup). Each class has about 30 extra lines of defining parent member variables, but as far as I can tell, that’s the only way to do it.
Overall, I’m happy with the results, though. Next on the list is probably Directory Service, and then Realm Service. Realm Service will be fairly interesting because that’s where I’ll start to see physics stuff that needs to be initialized on load. The most fun will be with Simulation Service because not only is there physics stuff there, but the physics stuff can’t happen until the required Realm is loaded and its physics initialized.
I’m trying to decide if it’s worth it to partition up items in the simulation service. That way, you could have multiple stores and maybe use a binary tree based on the item ID to determine what store it goes in. Actually, directory service could really use this since it holds a listing of ALL realms / asset groups. Or maybe, the partitioning should be on which directory service you get your info from. Will have to look into that.