Posts made by Loki

@mails are not voluntary forms of torture! Our storytellers were just sadistic bastards.

snakes and hemipenes. Thanks for the reminder, Then.

Heyo, what can I do for you?

I rather got the impression that @Glitch was suggesting we should develop something along the lines of roll20/Storium, rather than saying we should use those specific projects. I am pretty sure what he was suggesting is that there are a lot of features which could be made available with a client update, and that I should focus my efforts in those directions.

I think he's correct, but I'm not a client developer, so I'm not gonna do it. The suggestion of rich text and media was a darned good one (although media would be difficult since that introduces the ability to send porn unsolicited, if you're not careful).

Either way, I believe this forum is "Mildly Constructive" so can we move off the client code discussion and back to the constructive topic I asked for? You wanna fight about client codes, go somewhere else. I am still interested in hearing more responses like @Misadventure's.

So converting Anom Jobs to MySQL permanently is a bigger undertaking than I wanted to take on, so I decided to start on a new Anom Jobs replacement from scratch. I'm not done, but it's about 80% usable at this point; just needs things like assigning and such.

I encourage anyone interested to make pull requests against it and I'll approve them; I likely won't be finishing it until post-August (if I get back to it at all; depends on whether I decide to work more on Jasmine or go back to MUX).

Anywho, codebase is here: https://github.com/kkragenbrink/mush-issue-tracker

Have fun.

@Glitch Jasmine uses JSON objects, but I've restarted it so many times and it's just not in a working state. I'm restarting it again in ES6 and I like where it's going right now. But yeah, it's JSON, and your example would work fine if the API was designed to handle it. That's all in implementation details, and not hard to support.

@Misadventure What if there was a multidescer already in place? Would that satisfy?

Dreaded Double Post: I say it can be done while still using telnet, but I feel it's important to clarify that I think it can be done alongside telnet. Not necessarily over telnet. Increasing features based on the type of client connecting is a positive trait; or more specifically, degrading features based on the capabilities of the client is a positive trait. It's something most web developers are quite accustomed to (anyone else have to support IE6 long after IE9 became available? I did.)

Actually, automatic log-posting is a feature I consider mandatory for any new game, and not a difficult feature to implement. Most of the games I'm on now have it.

Ignoring that, I think Glitch has a good point, but I learned about two years ago that "client code" is not my thing. I absolutely encourage SOMEONE to make a good client code. Good client code should drive good server code. And in my dream grand new codebase, I would gladly accept requests for new features such as "rich text". I think that is a fantastic example of a place where MUSHes could improve. This can be done while still using the telnet protocol, though; in fact, MXP attempted to do just that (but it was arguably a failure).

To Glitch's question, however,

@Glitch said:

So I ask this with no hostility toward the idea, but without finding any pros myself, why shuffle the back-end only to leave the front-end experience the same?

Because I am a services-oriented software developer, and this is where I am personally able to make an impact. But I will gladly work with someone who wants to make a new client, and ensure that my backend service can meet any needs of the frontend client, so long as I think those needs can justifiably improve the experience for my target audience.

Thanks for the feedback, Chime!

I do note, however, that Sandboxes are a little different from full games. People tend to be more forgiving of little weirdnesses on a sandbox, because they aren't regularly trying to find RP, interact with staff, or navigate a grid on them.

So everyone's heard their coder talk about how much shit the MU* codebases all are. Sure, we make them sing and dance and turn backflips, but at the end of the day, as a Software Engineer by Profession, I find MU codebases to be frustrating, limited, and aggravating.

I have toyed with the idea of writing my own codebase in a language like Python or NodeJS for many years. I recently found Evennia, which is a really fantastic codebase ...

Evennia, and my own Jasmine (which is a NodeJS equivalent) aren't really production ready, but working with them over the past few months, I've had a nagging question in the back of my mind: will MUSH players care that it isn't Penn/Tiny/MUX/Rhost?

Obviously the immediate answer is "Of course not, as long as it behaves similarly I won't notice the difference and won't care."

But that leaves a big question: what is the definition of "behaves similarly" in this context?

So, ultimately, what I am asking is: can MUSHers live without access to SoftCode? I'm talking about things like time(), elock(), and similar.

What do you guys think? If the COMMANDS you use for everyday roleplay were available, but you could not do any evaluation other than the occasional %-substitution, would you even notice?

I would, but I'm a coder. What about the rest of you?

I have not tested these in a very long time, but these were taken from a decompile on Haunted Memories.

https://github.com/kkragenbrink/mush-sqlbb

Please feel free to use them. I will try and get some time to test them and make sure all features are working as intended. In use, players should never realise they aren't using Myrddin's Bulletin Boards, although some minor differences (specifically in how board locks are set up) do exist from an Admin perspective.

Please feel free to submit bugs or pull requests and I will try to get to them when I have a chance.

So I'm in the process of cleaning up my SQL Bulletin Boards, but while I was at it I remembered that HM had a lot of custom AJobs modifications that people really seemed to quite like. Almost all of those modifications were stored on one object (#49) which was stored in the Master Room and @parented to the actual Anomaly Jobs Command Object. In turn, the Anomaly Jobs Command Object was stored in that object's inventory, thus allowing us to modify the heck out of AJobs without ever modifying the underlying sourcecode. This made upgrades really seamless.

This code is Unlicensed. Please enjoy.

https://github.com/kkragenbrink/haunted-memories-ajobs-customization

@Thenomain Found it. Will publish to GitHub after I've cleaned it up and retested it. Should be tomorrow or Sunday. Note that there's one small piece of Myrddin's that I never did quite get right related to board locks. There's some room for improvement, there.

@Thenomain I got Myrd's BB into MySQL. Let me see if I can dig it back up and put it somewhere. HM's bboards were not stored on objects.

I am interested in this project, and might be willing to make some pull requests to it. I'll poke my nose at it when I have some free time and inspiration. I desperately want to never use Anomaly Jobs in Object form again.

This is probably the purest way to do backups, and what I always wanted to set up for Jobs on HM but never had the time for. My long term goal was to move the entire Database into MySQL and skip the stupid Objects thing. Then the concept of "archival" would be "is the job in a visible status" or "is the job in an archived status" and we wouldn't need these silly post-hook triggers which are prone to failure.

Chime, I sympathize greatly with you in this conversation, and with your client. It's not a very good situation for either of you, and I'm sorry it happened. I don't have a lot of time, either, these days; however, if you want a backup on support maybe I can give you a hand now and then as needed. I'm happy to help your customers out under the same conditions which you are: when I have time.