Topics created by Ashen-Shugar

@Ashen-Shugar I could hunt around and see if I still have any of the old logfiles from our AdminMUSH days.

@skew said in The Mush Hackathon:

So you just want me to start a new code project and see how badly I can break everything?

I would buy you a week's worth of coffee (er, one coffee a day for a week) to watch this beautiful trainwreck unfold.

This is rather neat. Thanks @Ashen-Shugar .

Also, I did fix that problem... was a simple /space/. Silly spaces messing up code...

We need open source code to make coding easier, like a MUSH version of Windows.

j/k

For the longest time, I've had issues where I wish there was a way to save information to a database like SQL, in some known format, and be able to query it. I don't just mean 'just use SQL', but I mean advanced features like... 'related topics', etc.

I basically wanted Graph based storage. I tried using oqgraph, since MariaDB gives access to that, and with MariaDB being binary compatible with MySQL, I could use it. But it isn't well maintained, and it tended to crash things. So I dropped that. (Read: Don't use OQGraph for SQL Graph Storage, it's a trap!)

I recently actually started work on this anew, and in doing so fixed a bug in PennMUSH's SQL handling that enabled single-return Stored Procedures -- creating Graph based functions in SQL. However, SQL isn't really made for this... with enormous tables, this'll get slow. (Read: Stored Procedures for SQL Graph Storage is the best option at the moment)

It's roughly detailed here:
http://mush-mercutio.tumblr.com/post/153345784737/pennmush-graph-framework

If I finish this, I may at some point rewrite SceneSys to use this kind of storage, and launch some basic things along with it, like a basic BBS and a basic Jobs system as a POC.

Being reflected on the MUSH and on SQL, would allow easy grabbing through websites, etc.

@Ashen-Shugar

One of the million things I have on the back burner is "SGP replacement".

My back burner is about the size of a house.

@Chime said in Dreams to Reality:

It's very pretty-- but it's a perfect example of what I was trying to avoid. I've been a UNIX person since 1995. I really do want just bare autoconf so that I can automate and do CI testing more easily.

Well, that's the brilliant part of it. It makes a dynamic file called 'custom.defs' in the src directory that has the Makefile variables. So you could use CLI and generate it in a batch or on the fly just fine. The menu is just an interface to generate the custom.defs file, that's it.

Unix guy here since 1985 (AT&T SYS3/SYSV on a 3B2), so I am all for the mighty CLI 😉

That said-- it is really nice to have all of those configurable features. Ideally they should become config options in the game conf file rather than compile-time features, but I understand quite well how big a pain that is.

Yup, we have a ton of customizations that way. All the mysql is in a rhost_mysql.conf, again, the Makefile menu interfaces with it.

The only compile times are those that make huge differences in the code itself, and again is just populated as DEFS's in the custom.defs file. So entirely CLI capable with batch processing. Yay is the UNIX.

Admittedly, a lot of my customizations to MUX were to remove a lot of #ifdefs for obsolete crap.

Take your MUX inc()/dec() option. What's the harm in having that always enabled?

Yea, some of these things we likely will re-visit to change from compile time to just conf parameters, most of it however was due to speed/performance considerations at the time.

[X] 26. SHA512 Passwords

I hope those are still salted?

Absolutely. 10 character randomized seeding per password encryption.
No rainbow table decryption for our baby 😉

strcat( %b %b, iter( lnum( 1, 23, 2 ), strcat( ljust( v( %i0 ), 2 ), ljust( v( inc( %i0 )), 2 ))), %b %b )

Okay, got it. Harder to change, not difficult to set up, more issue with iteration limits. C'est la vie.