16 Jan, 2009, Chris Bailey wrote in the 1st comment:
Votes: 0
I have a few enhancements for RocketMUD that I would like to include in the codebase. Just some basic additions to the color parser, a few tweaks here and there that I think improve performance. I don't want to just release "patches" or a whole new codebase to include these things. Would it be ok if I released a RocketMUD 0.3? Or is the project still ongoing elsewhere?
17 Jan, 2009, Chris Bailey wrote in the 2nd comment:
Shameless bump.
17 Jan, 2009, The_Fury wrote in the 3rd comment:
Shame on you.
17 Jan, 2009, Tyche wrote in the 4th comment:
You can find the RocketMud subversion repository at
http://sourcery.dyndns.org/svn/rocketmud
You can check it out with…
svn co http://sourcery.dyndns.org/svn/rocketmud
Make your changes and/or copy your changed files or new files
then run…
svn diff > mypatch.patch
Upload that mypatch.patch to ftp://sourcery.dyndns.org/incoming
The same goes for anyone wishing to contribute to any and all the projects I host which include…
coolmud, genesis, lpmud-2.4.5, pernmush, smug, tinymuck,
ubermud, diku-alfa, interlude, mesh, porting, teensymud,
tinymud-1.4.1, untermud, gag, lpmud-1.4.0, murk++, untermud,
rocketmud, teensyweb, tinymud-1.5.4, wingdbm
Some of the above are closed projects, but most aren't.
If you think commit access to any of the repositories would be more convenient, then just drop me a note with the
userid and password you'd like to use.
http://sourcery.dyndns.org/svn/rocketmud
You can check it out with…
svn co http://sourcery.dyndns.org/svn/rocketmud
Make your changes and/or copy your changed files or new files
then run…
svn diff > mypatch.patch
Upload that mypatch.patch to ftp://sourcery.dyndns.org/incoming
The same goes for anyone wishing to contribute to any and all the projects I host which include…
coolmud, genesis, lpmud-2.4.5, pernmush, smug, tinymuck,
ubermud, diku-alfa, interlude, mesh, porting, teensymud,
tinymud-1.4.1, untermud, gag, lpmud-1.4.0, murk++, untermud,
rocketmud, teensyweb, tinymud-1.5.4, wingdbm
Some of the above are closed projects, but most aren't.
If you think commit access to any of the repositories would be more convenient, then just drop me a note with the
userid and password you'd like to use.
18 Jan, 2009, Igabod wrote in the 5th comment:
Wow Tyche, I didn't realize you were such a busy man. That's a lot of different projects that I had no clue you were affiliated with. I knew you were responsible for rocketmud but didn't know about the others. You just impressed me.
18 Jan, 2009, Tyche wrote in the 6th comment:
Err…well most of those projects are just ports of old muds that I wasn't affiliated with in any way, except for genesis.
I've mostly been busy with fixing bugs in other people's non-mud projects. ;-P
I've mostly been busy with fixing bugs in other people's non-mud projects. ;-P
18 Jan, 2009, Igabod wrote in the 7th comment:
Still, that's a lot of work. I've got a few projects going myself but they look pathetic when compared to your list.
18 Jan, 2009, Chris Bailey wrote in the 8th comment:
First small patch uploaded ( Wanted to get an idea of how it was all working )
18 Jan, 2009, Tyche wrote in the 9th comment:
Well that sucks. Apparently svn diff doesn't have an option to include any new files you might have added.
If you could, just upload the new files, or if you have a real diff laying about use…
diff -urN old_code_dir new_code_dir > mypatch.patch
to create a new patch.
If you could, just upload the new files, or if you have a real diff laying about use…
diff -urN old_code_dir new_code_dir > mypatch.patch
to create a new patch.
18 Jan, 2009, Chris Bailey wrote in the 10th comment:
Ok sorry about that, I didn't even think of it lol. I uploaded the cmd_* files, but it wouldn't let me upload the commands directory. They all have to go in trunk/commands =)
18 Jan, 2009, Tyche wrote in the 11th comment:
I patched in socket config bug fix and something close to the color code change to head.
You might want to review load_commands and the context of where they are being defined.
It looks like the Main object, instead of Mobile.
You might want to review load_commands and the context of where they are being defined.
It looks like the Main object, instead of Mobile.
19 Jan, 2009, Chris Bailey wrote in the 12th comment:
Ah you are right about the load_commands. I didn't notice because it still worked that way, what would the effect be? I have it like that in a heavily modified version of the codebase with 50 commands or so. The changes I made in the color parser were due to A) Case has a bit more overhead than if/else due to an extra call to Kernel, and B) The byte comparisons were faster than converting to string and then comparing. It is an unnoticeable difference under normal use, but if you are parsing a large block of colored text like a big overland map, it bogged down pretty bad.
