LPMuds.net Forums => Drivers => Topic started by: silenus on August 29, 2017, 08:55:49 AM

Title: new driver development.
Post by: silenus on August 29, 2017, 08:55:49 AM

Given that FallenTree is reluctant to add support for the old mudlibs with the 3.0 release I was wondering if anyone might be interested in working on a new driver. This is kind of a project I have been thinking about on and off for sometime. My current idea is to write it in either Java or Node.js. My main reason for selecting Node.js is because I would like to learn the language (or typescript) but Java has a concurrency model that could potentially support more features in future (such as the STM like stuff they have in Hydra). The idea is to be fully compatible with the FluffOS 2.xx line.

I have some reasonably detailed plans that I have outline over the years and now have perhaps a few months to work on it. I suspect given that I can combine and clone the actual grammar with the ANTLR grammar in the code vault it might be possible to get lillib to compile and run. If anyone is interested in helping out a little bit let me know. I think it would be fun.


Title: Re: new driver development.
Post by: silenus on August 29, 2017, 09:11:05 AM
I think is also room for new ideas in how a programmable system like an lpmud driver should run nowadays. I have recently become interested in probably somewhat old stuff to most people- cloud computing via AWS and NoSQL style databases like Cassandra. So I have been wondering if a mud could be backed by some of these kinds of systems and be distributed over multiple machines for robustness.
Title: Re: new driver development.
Post by: Adam on August 30, 2017, 07:10:48 AM
A new driver would be great but remember mud admins are lazy easily spooked creatures of habit.  basically, unless you spoon feed them... "Make it really really easy" for them to change they simply won't because they consider the driver they are running on stable.

From memory, most muds changed to fluffos around the time cratylus changed deadsouls to use it and discworld was using it in prime time for quite some time, so from that most thought, it was trust worthy and stable.

So I see this being an issue unless you can get a large mud to use it and stand by it not many will make the change. hence why fluffosv3 is a big waste of time. as its too much effort to make the transition, No English Muds are using it and it's bloatware which is a big turn off for older mud admins.

Personally, I think time would be better spent maintaining the version 2 branch of fluffos with patches as things change but that's just me if I had the time I would do it ;)
Title: Re: new driver development.
Post by: silenus on August 30, 2017, 09:51:26 AM
I think that FallenTree's stuff has a lot going for it and probably it is being used in situations where there is more active development (chinese muds). I think perhaps the english speaking community has grown too small for him to feel that it's worth the effort to support even though it isn't that much work really IMHO. It just requires setting up some integration testing system where one at least can boot the existing mudlibs with various different compile options.

I talked to him via email and it seems he is not willing to do it so I am not sure if I will help out in his efforts to further improve the system.

Writing a driver is a much easier task than it use to be given that we now have many vm based languages supporting features such as dynamic loading. One can basically write a LPC->lang of choice transform with instrumentation for dynamic checks need for security etc. and have all the code run directly on the vm without having to write your own.

It would be nice to have some help once I have the basics taken care of (language transformer and lightweight runtime). Since there are certain portions of the conversion process which requires a lot of grunt work and might take sometime unless there are a sets of hands doing it at the same time such as reimplementing the various efun packages and perhaps the language parser for dead-souls which i don't really understand that well.
Title: Re: new driver development.
Post by: FallenTree on September 05, 2017, 01:11:47 AM
TBH, I didn't say I won't add support for older libs in FluffOS3, In fact, all compatibility issues that ever been raised on GITHUB already has a solution, I'm not sure what the exact issue is.

All in all the driver is generally going towards an configuration based instead of compile options based system, which make it possible for people to pair an generic driver with some runtime config and run all the old mud.  If there are some specific active MUDs that want to try to transit to FluffOS 3 , I'm willing to work with you and support them. 

Please submit your question with specifics on the github, instead of just say, stuff doesn't work.
Title: Re: new driver development.
Post by: silenus on September 06, 2017, 09:45:46 AM
This is kind of off topic but I suspect the problem is many of these libs aren't on running muds as of today but still represent a significant body of work and people interested or playing with english language muds and mudlibs might still have some interest in them- so some system perhaps is needed to perhaps at least boot up and test some of these muds and make sure they still work when driver modifications are made.

There are some changes besides the removal of the discworld extensions that make me a bit uncomfortable since I am unsure of what was accomplished. One of these is the change to the sort algorithm which I haven't really looked at. The old one is a bit odd because it is designed not to behave badly even if someone passes in a strange function to determine the sequence order. Is this still the case with the new function?

The other two i noticed i posted on the github already. I probably (back on topic) will be working on a new driver over the next month to see how difficult it is with modern tools.
Title: Re: new driver development.
Post by: silenus on September 11, 2017, 09:21:40 PM
I posted a slightly buggy version of a stripped fluffos grammar with just the context free grammar portion of the rules. I say buggy since i by mistake deleted some portions of the alternations when stripping the file by hand. I will try to test and post an updated grammar for fluffos in antlr4 soon.