[DGD] Simul-kfuns

Raymond Jennings shentino at gmail.com
Mon May 7 10:54:19 CEST 2018


On Mon, May 7, 2018 at 1:43 AM, Felix A. Croes <felix at dworkin.nl> wrote:
> Larry Moore <cylis at mts.net> wrote:
>
>> My issue is, that I didn’t want to bloat the auto object with all of the simul-kfuns. However, having a simul-kfun file included in the auto object doesn’t allow you to compile the individual simul-kfun file, since it is in the auto object and the auto object is in all objects so you end up with an endless loop,
>
> The best way to get rid of simul-efun bloat is to remove all non-essential
> simul-efuns, or to move them to other objects that can be explicitly
> inherited.  Functionality which really has to be available to every
> object in the game should be in the auto object, bloat or not.  Updating
> a simul-efun then requires a recompilation of the auto object.

Just to be clear, recompiling the auto object works the same way as
recompiling any other inheritable when it comes to recompiling its
inheritors down the tree, right?  A full branch purge and a leaf
recompile being required to fully switch over?

>> so you can only compile the auto object to find out if your simul-kfun file has an error in it. I suppose my issue is that I have been coding in MudOS so long, and our plan is to convert our MUD that has been running for 20 some odd years from MudOS to DGD, and I wanted to make the transition as easy as possible for my staff. If I have to code the simul-kfuns in the auto object, then I can do that, I was just wondering if there was any other way.

May I also suggest MudOS4DGD?

I think VikingMUD used something like that to great effect to migrate
their own codebase to DGD.

> I don't want to discourage a conversion, but you are going to need at
> least one capable person who is familiar with DGD on your team to succeed.
>
> Regards,
> Felix Croes
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd




More information about the DGD mailing list