Master.c Now Loads Let's Celebrate
I’ve been coding again. I did what you’re not really supposed to do and started up a bunch of new features I didn’t finish, then committed a crapload of broken code that I’m now paying the price for. That’s okay, though, I like having a stack of stuff to work through as long as I can keep moving.
The first thing I had to do was fix master.c after I half-implemented a new sys include handler. It depends on the DomainTracker, this thing I wrote to keep track of managed branches of the filesystem. The /.include/ directory (more on the dot later) of your domain root is the thing that’s searched in sys includes, and /paths/ in sys includes are domain paths, not directory paths. A domain may be separated from its child domains by several directory levels, so ‘#include <../auto.h>’ will always include /.include/auto.h relative to your parent domain’s root directory. There’s also a platform sys include directory it checks if it doesn’t find anything in your domain. All that code was already done, though, I just needed to debug the interaction between the master ob and the domain tracker. Along the way I ran into an infinite recursion bug I never accounted for, because DomainTracker tries to log through LoggerFactory but LoggerFactory has sys includes that it needs DomainTracker to resolve. Now I’m more careful about preloading objects in the order I plan to use them and the master checks for whether or not the domain tracker has been loaded yet and acts accordingly.
Now that I got the master object humming along, I’m onto the login object. There were some bugs leftover from when I moved a bunch of stuff around, but the most of the work here is going to be flushing out the flavor concept. Right now the path to the avatar object is hardcoded, but the way it really should work is that login object will find out your start location in the game, figure out what flavor it’s running, and then clone the avatar object for that flavor. If you don’t have a start location, it should default to your workroom for now. If you don’t have a workroom, one will be provided to you from /etc/skel. The login object also needs to know a user’s home directory.
Also some stuff that’s on the roadmap but not yet critical is that your home directory only be able to run your personal flavor, to keep you from cheating up your chars out in other game flavors. Your personal flavor can, of course, inherit from another flavor. But it won’t have write to data outside of its own flavor. How exactly I’m going to accomplish that I have no idea, but that’s how it’s supposed to work. You also want to be able to inherit or sync data between flavors in some situations, so the solution needs to be dynamic.
Once login works, that’ll open up the avatar object and all its mixins, as well as any other flavor migration stuff I want to formalize. For instance, migrating into a new avatar in the main flavor I’m designing will dynamically write out different avatar programs for each species, so that your avatar object can inherit from your species object. Right now avatar.c just inherits from OrganismCode so it’s not really necessary, but it’ll need to happen before I can make the organism builder.
Right now I’m just trying to keep it simple and finish out the bare minimum I need for letting someone sign in, have a workroom, move around between rooms, and communicate with other players using the say command and the soul. And I want the GUI to work for all those things. That’s more than enough work to keep me busy and without all that stuff, there’s not much point to it all. It’s already forcing me to make some critical decisions along the way, even as basic as most of this stuff is. I got hung up for most of last weekend on the right path for my workroom and I’m still not totally happy with where I landed. But I’m done thinking about it so I’ll just cut this post off right there.