New Start Databases
-
Something I've been considering more and more and think may be helpful is for those people who want to start up new mushes to have base-code already in a mush db.
What would be nice is getting together, as a group, and get a standard start db for MUX, Penn, and Rhost so regardless of the starting mush engine someone decides on, the base core of utilities and functions that someone would expect would be available.
This would, of course, require some planning and cross-porting various softcode between the various engines (where possible).
It this just shooting at stars? Does anyone see any use for this?
It also would be requiring consistently keeping code updated whenever updates or patches were done to the softcode packages.
Just something snoogling in the back of my mind.
-
I've had this for awhile with my FS3 codebase for folks wanting something for PennMUSH. Even if you don't like the FS3 skills system, you can just uninstall that module and keep the rest of the globals and stuff. I know several people have used it, so I'm sure starter DBs for other platforms would get some mileage.
-
I've debated doing something along this line for Evennia. In the past, I saw people interested in doing this. I think it is a great idea and might even help others get past the fear of building a MUSH/MUX/Whatever.
-
I've been begged to put the CoD (WoD) system in a startup db for a while. At the speed in which this game line changes and I improve it, tho, I don't think it's quite possible without more dedication than I have the time for. I'm actually quite a bit saddened for it.
TinyMUSH has Ambryl's latest softcode-starter in it.
TinyMUX has the dated yet still functional SMP (SPM? SFM? I can't remember).
Penn apparently has a Faraday bundle (so good).
I suppose it'd only be fitting if Rhost had an option too. -
My next "big" project... when I finish all the other big projects... is to purchase a Digital Oceans droplet, install a clean version of TinyMUX, and then install Thenomain's base Chronicles of Darkness suite on it. Once that's all functional, we'll get WikiMedia installed as well, in the very base version, and ensure everything is operational in a basic format.
Once that is all done, I'll go back in to clear passwords and ensure all my data is off it. At that point, Digital Ocean allows you to clone droplets and send them to other Digital Ocean users. I'll have a fully functional base-level CofD MUX server that I can essentially hand out to anyone who wants it. At that point, Thenomain has been diligent enough with his github code to make it basically copy+paste into Muxify, then copy+paste into game, and it all loads correctly.
So, people will not only be able to get a basic package... but a nearly ready-to-play game.
Edit: You'll still need to build a map, configure your boards, channels, blah blah blah. So, not ready-to-play. But close-ish!
-
@Thenomain said in New Start Databases:
I've been begged to put the CoD (WoD) system in a startup db for a while. At the speed in which this game line changes and I improve it, tho, I don't think it's quite possible without more dedication than I have the time for. I'm actually quite a bit saddened for it.
TinyMUSH has Ambryl's latest softcode-starter in it.
TinyMUX has the dated yet still functional SMP (SPM? SFM? I can't remember).
Penn apparently has a Faraday bundle (so good).
I suppose it'd only be fitting if Rhost had an option too.Theno,
I'd be very curious how much your CoD package would work out of the box on Rhost.
I played a bit with getting F3 working on Rhost but there's some discrepencies in how the parser works that'll be annoying.
- Non-penn parsers require extra escaping of \ characters.
- Penn's parser does not require ending parenthesis, bracets, and brackets, no matter how many levels deep you are. Which... I never figured why, but makes for lazy code that is non-cross portable
- Penn's parser doesn't handle a large number of ('s, {'s or ['s in raw string format to any command, so anyone who uses a lot of them for something as simple as ascii art will be SOL.
- ansi is handled differently
- search/lsearch is handled differently
- align() vs printf() vs columns()
I'd say Rhost is the most compatible with MUX without being a MUX. It's also the most compatible with Penn without being a Penn. It has a ton of unique features that neither have as well. So it's a unique choice, but if you use the unique codepoints of each codebase, which make sense if you plan to code for those platforms, it starts to remove the ease of porting that code to another system.
Faraday, I do plan to work again on getting your code ported to Rhost, but one of the things I need to fix is the ending parenthesis, braces, and bracket issue. The other is convert all the lsearch()'s to search() and any use of align() to do printf()
Those are the big telling points. After that things will start to mesh a bit.
Theno, I've not looked at your package so I don't know how easy (hard?) it will be to port, but I think much easier as frankly MUX doesn't have the wider functionality that Penn does, nor the wider differences Penn and Rhost have to each other.
Would be a curious project to take on.
For those who want a place to play around with Rhost features, I have a game set up that anyone who connects will be automatically set wizard.
So you can use it to test packages, play with code, etc.
Some things (like @shutdown, @reboot, etc) were locked off, but pretty much everything you'd expect a wizard to have access to will be accessable.
Keep in mind help in Rhost follows the old mud standard where 'help' and 'wizhelp' are separate commands.
If you want to play, site is rhostmush.com 1066.
If anyone manages to crash and/or bring the place down, just let me know and I'll restart it up, no worries.
-
@Thenomain said in New Start Databases:
TinyMUSH has Ambryl's latest softcode-starter in it.
Actually, TinyMUSH doesn't come with a starter db anymore. It used to come with Amberyl's MUSHCore but the links to that went dark years ago and I have not yet been able to find a copy anywhere. Most of the best features from that are extant in MUXcore, which works very well with TinyMUSH. You will, however, have to change certain bits of code that use MUX's @if command, to use @switch instead since TM3 lacks @if (I do have a module that adds @if and a few other missing things, if anyone is interested).
-
@Ashen-Shugar said in New Start Databases:
- Penn's parser does not require ending parenthesis, bracets, and brackets, no matter how many levels deep you are. Which... I never figured why, but makes for lazy code that is non-cross portable...
Well I can't speak for the original code devs' intentions, but I think when you consider the state of MUSHcode back when it was first developed, and the simplicity or what folks were doing with it (falcon controllers and the like), it simply wasn't a big deal. It was actually convenient, because you could make a mistake in your paren matching and the parser wouldn't care. And then of course once they had made that original design, they then had a body of code that would've been broken if they ever changed it.
Also, cross-portability wasn't really a big thing. TinyMUX was way different than Penn back then, but now they've sort of come together compatibility-wise and people are more apt to want to bring stuff across.
Anyway, you're now the third person to have tried to port my codebase over to another platform and given because it was too much of a pain. I'm pretty much declaring it a lost cause at this point And with all my efforts focused on AresMUSH, I'm not terribly concerned if it ever makes it to the RHost or MUX platforms. But thanks for trying.
-
@faraday said in New Start Databases:
Anyway, you're now the third person to have tried to port my codebase over to another platform and given because it was too much of a pain. I'm pretty much declaring it a lost cause at this point And with all my efforts focused on AresMUSH, I'm not terribly concerned if it ever makes it to the RHost or MUX platforms. But thanks for trying.
I've made two attempts also, with the same result.
-
@RnMissionRun Four then. It's totally possible, technically-speaking, but is anyone really that desperate for FS3 + MUX that they need to suffer? Spare yourself the pain
-
@faraday said in New Start Databases:
@RnMissionRun Four then. It's totally possible, technically-speaking, but is anyone really that desperate for FS3 + MUX that they need to suffer? Spare yourself the pain
I saw it as an established, fairly well-known and -working- system suitable for use with a wide variety of games. It seemed a better use of time to port it (since I really, really did not want to use PennMUSH for my project), than doing something from scratch.
I was wrong
-
I tried porting the system to Mux before. Without regedit(), forget it.
-
@Thenomain said in New Start Databases:
I tried porting the system to Mux before. Without regedit(), forget it.
regedit() is only used in a handful of places though, and at a glance they all seem pretty non-essential (like printing MUSH code to a wiki format for archiving bbposts). The paren-matching and comm-escaping issues @Ashen-Shugar mentioned were the biggest headache for me because they're freaking everywhere. That and there were subtle differences with permissions/ownership and stuff like that.
Kinda feel like this is veering off topic of the original idea of a starter DB, but since the OP mentioned portable code maybe it's still relevant.
-
@Ashen-Shugar I honestly feel that we have enough choices already. Penn users have Volund's code suite, Talvo (Mike's) code suite and Faraday's starter DB, in addition to a handful of publicly avaliable DBs such as Rince's WCRH db. MUX has SGP and MUXcore, plus various (mostly) WoD-centric dbs. TinyMUSH can use any of the MUX starter dbs (with minimal modification required). Rhost has Volund's and SGP.
Either of these will give you a decent (if not great) set of basic globals that you can easily extend and customize. What would you include with a "standard starter db" that isn't in one of these, that isn't very game specific?
I feel that starter DBs should be specific to a codebase. I feel they should be designed in such a way as to take full advantage of the unique features of their target codebase and to demonstrate "best practice" for same. You simply can't get that with a generic codesuite.
-
@RnMissionRun said in New Start Databases:
MUX has SGP and MUXcore
Nnnnnnnnnggghhhhhhhkkkiiiiiinnnnnnnnnnnda? I've yet to see a Mux project where someone hasn't essentially wanted to throw SGP to the curb, and I keep forgetting that Muxcore exists which just a slightly cleaned up version of same. SGP is absolutely better than nothing, but that's about all I can say about it.
-
Respectfully, I believe you are missing the point. The goal with this sort of project is to make things more accessible, and perfect is the enemy of good.
-
@Sunny said in New Start Databases:
Respectfully, I believe you are missing the point. The goal with this sort of project is to make things more accessible, and perfect is the enemy of good.
I'm not asking for perfection
I'm merely suggesting that it be done well, so that a few years from now, experienced MUSHers won't log on to a new game, see they're running a stock "Ash's Starter DB", groan and disconnect because they think it's bloody awful.
-
Nobody sets out to do a project wrong. Not when it's something they want to see done. I would love to see new effort in this arena -- I am precisely the sort of person that would benefit a whole lot from it.
-
@Thenomain said in New Start Databases:
@RnMissionRun said in New Start Databases:
MUX has SGP and MUXcore
Nnnnnnnnnggghhhhhhhkkkiiiiiinnnnnnnnnnnda? I've yet to see a Mux project where someone hasn't essentially wanted to throw SGP to the curb, and I keep forgetting that Muxcore exists which just a slightly cleaned up version of same. SGP is absolutely better than nothing, but that's about all I can say about it.
I have to admit, never have I seen a SGP/Muxcore survive the coder joining and starting to build. Non-coder mu* owners install it to get themselves started, or to tinker, and then realize just how complex some MU code can be, and then redouble their efforts in finding a coder.
Coders just rip that crap out anyway. And I say that because I feel that every coder out there worth their salt want things done Their Way, not that the SGP/Muxcore package is 'crap', just that it is from the standpoint of some of us arrogant coder types... if that makes sense?
-
@Rook said in New Start Databases:
I have to admit, never have I seen a SGP/Muxcore survive the coder joining and starting to build.
Maybe those ones don't (I'm not too familiar with them myself), but I think the larger code suites like FS3/Theno/Volund do. If someone wanted to start from scratch, they would start from scratch and not use one of those in the first place.
So it comes down to what value is being provided by your "starter DB". Are you going for just a tinkering platform or more of a "game in a box"?