I guess that one could perhaps think there is some educational value to applying the fixes by hand, but frankly I think there are better ways to learn the code. Still, this is not really choosing stock over SmaugFUSS, because the end result is still the FUSS version. I'm still wondering why somebody would want the stock version without all the fixes.

Applying the bugfixes from the FUSS forums wouldn't allow you to end up with the same thing as stock SmaugFUSS. You wouldn't have the weather system, the converted pfiles, or any of the stuff brought over from Smaug 1.8. You'd also have to manually apply the const fix.

I agree with this sentiment, though the implementation
is likely subject to endless, possibly passionate,
debate. For example Why would someone who only knows
the name "Circle" navigate into a TBA directory?
It wouldn't be enough to have a dir named TBA with
a subdir named Circle. You'd want something like
Circle-TBA as a directory name. Or do you? Is it more
correct that there be a Circle dir with TBA under it?

You could go around in TBA's all day debating this, I bet.

I don't necessarily have a solution but I do have
anecdotal corroboration…on occasion I've seen someone
try to use the Nightmare lib because of some vestigial
memory of it being "better" than Dead Souls, and hard
to find. Never mind that NM IV and DS 1 are almost exactly
the same in terms of code, and that DS has been fixed
up and improved on since then. It takes time and effort
to explain this stuff to people who fixated on the
old brand. And this is a vestigial echo of a brand switch
from TEN years ago.

I just thank my muse that it never seriously occurred to
me to rebrand Dead Souls when I picked up maintainership. I
bet that a non-trivial amount of my time would be spent
just explaining this stuff.




I can't speak for those specific codebases, but maybe
my experiences with mine are helpful. The codebase I
maintain has all sorts of awesome stuff that wasn't
there when I picked up maintainership. A quick-creation
system (sort of like OLC), vehicles, web editing, blah
blah yadda, really great stuff, imo. Not to mention tons
of fixes. As far as I'm concerned, it is vastly superior.

For some folks, though, it's "too much". Even though you
can turn off features, or just, you know, not use them.
Somehow the fact that they are there is just…not desired.
They want a "simple", clean slate they know. It may be
more work, perhaps, but maybe they didn't want to follow
the dev direction taken by me.

I think that's logical, even if I don't agree with it.
That's why I make available the version of DS that I
cleaned up *juuust enough* so that it runs. So that such
people can follow their own dreams. Peace be with them.


Another logical reason could be that people want to analyze
older versions and compare to newer versions not necessarily
to reinvent the wheel, or necessarily "learn code", but for
reasons of general investigation of dev philosophies or
even authorship. You know…general research. This reason
doesn't involve starting a mud, obviously, but people download
code for reasons other than starting a mud, and we *are*
talking about repository organization for download, not
proselytizing for new muds, right?

This thread seems to be about why a new mud would start
with X instead of its "better" derivative Y, which is fine, right,
you guys talk about whatever suits you. But I understood the
OP to be about the organization of the downloads, which should
not assume that mud-starting is the point of accessing the repository,
in my opinion.



Lol wut


-Crat
http://lpmuds.net

That's probably closer to CWG or AFKMUD than tba or FUSS simply because both of the latter two didn't do that much to add to the original so much as polished it up and fixed numerous bugs that were in the original whereas the former two added numerous additions to them to make them heavily modified versions of the original. I know at least with tba, and likely with FUSS, that we aimed to only add features that we felt were sufficiently theme independent and were something that in general no one would rather not have. (Note the in general, I know there may be some oddballs that don't like OLC, and maybe they like having to log into the shell to change their greetings screen, etc.)

Would you be as opposed to something more concrete and less biased then, like say a date of latest development:

CircleMUD-3.1: Last Developed November 2002
tbaMUD-3.57: Last Developed: Current

I think that tbaMUD suffers from a branding problem. Without having seen the names come up in the forums, or without having done a little looking around, I'd have had no idea it was a continuation or even vaguely related to Circle…

I agree, we had wanted to continue naming it CircleMUD but Jeremy Elson specifically asked us not to.

Yeah, as I recall, the folks at tbaMUD tried to jump in and take the mantle of CircleMUD 3.5 when the Circle development team pretty much said they were done. The community didn't go for that, and while Jeremy Elson made some comments that sounded like he might approve such a thing, I think he decided they were adding too many features, and since the community wasn't happy, they changed the name.

It might have been better to call it TBACircle or something. The Builders' Academy doesn't imply that it's Circle related, at least by name. SmaugFUSS is pretty clearly Smaug-derived.

Personally, I like the current organization that puts tba into DikuMUD/Circle/tbaMUD. I would like to be able to see the development date though. I could see a sort option on the search page to sort by date being quite handy.

Did you consider similar or synonymous words, like OvalMUD or RoundMUD? Does "tba" stand for something other than "The Builder Academy"?

You know, everyone would have loved you if you'd called it PieMUD. Pie > All. :cyclops:

I'd go for PiMUD, seeing as it's a better joke on Circle relevancy.

Well, IMO it's more important to make the relation obvious instead of having a clever play on words. PiMUD is pretty clever but not an obvious relative to Circle (until it's pointed out of course).

SphereMUD would get clever and symbolic at the same time. :thinking:

Ah, clearly you either missed Kayle's post earlier about SmaugFUSS and/or just haven't checked it out at all. SmaugFUSS' latest version includes Kayle's Weather System, converted Area files (to KEY format), vassign instead of rassign/oassign/massign, and various other changes. Many of these are very much changes for the betterment of the codebase, but they are also added features that some might not want, and converting back from them would be far from simply disabling a flag at compile time.


I can't speak for Lobotomy, but I think including a last developed date in the file's description would be great, though I don't know that each person uploading new code would always comply with that inclusion unless it were an additional separate field… but I don't think it'd be right to alter the name of each codebase by adding that field to it..

Sounds like the naming of tbaMUD just got caught on the wrong side of community sentiment. For SmaugFUSS, we got lucky really. The community took to the name immediately and there was never any protest about it. It was an unofficial name before I got a hold of Thoric personally and he said there was no problem with the name or with us continuing work on the public code in a semi-official capacity. So we got the developer's blessing as well. I think that may help somewhat but in the end I don't think the name does much more than remind people it's a Smaug.

Also, SmaugFUSS is no longer strictly about bugfixes and hasn't been for some time now. It just doesn't come across that way. We don't just pile on stuff at random though. Things like hotboot, dlsym command tables, MCCP, Kayle's weather code, the area format changes, they were all very commonly asked for things. In fact I can recall a time when people asked repeatedly about problems getting hotboot and/or dlsym working than they were spending on more productive things. There have been other lesser improvements like the vassign command Conner mentioned. But none of it has been adding features just for the sake of it, or for spinning off another full blow derivative like AFKMud, and certainly not stuff that the vast majority of people don't want.

As far as a "last touched by developers" type of tag, I think that would require a great deal of work considering the amount of stuff we have available here now. Maybe there's some kind of automated or semi-automated way to look at the source code in the archive and find the most recent file date in there from a C or H file?

Exactly, these have all been features that were highly in demand, if not chosen as the best approach to fixing an existing problem, but I can understand if someone were to opt to manually do all the bug fixes from the original stock code rather than try to reverse engineer these things back out if they simply didn't want them on their mud because some of these changes are pretty extensive.


You'd think there really ought to be some way to automate such a thing using the same methodology that y'all are already using to display the contents of the files in the repositories. Maybe have it scan the file list for the most recent dated source file and use that date?

Obviously, we'd want a little more clever script that this, but here's one line for normal C language games using .tar.bz2 files:

tar -jtvf wileymud3_050101.tar.bz2 | grep '\.[ch]$' | awk '{print $4" "$5}' | sort -r | uniq | head -1

2004-11-10 06:38

Aye sounds like roughly the same idea as what was and wasn't added as tbaMUD uses. tbaMUD has OLC, DG, copyover, cedit (configuration editor), tedit (text editor, used for editing greetings, motd, etc. in-game), checkload (checkload mob 500 shows what rooms the mob has resets in) etc. We haven't shied from admin tools but have shied from adding player-side changes (at least to the code, the world itself isn't circle's and includes a few zones filled with examples of DG Scripts that the helpfiles for DG reference).

Well Conner, apparently quixadhal has something that looks like it would work. Converted to a numerical timestamp that can be stored in the file DB this would be a reasonably good solution to employ when a code archive is first loaded. The only real problem is how do we establish any sort of standard method for finding the right files to test dates on? Just scan the whole package for the newest C or H file? Suppose the package hasn't got any? :)

It's funny you should say that, my first thought when I saw his one liner there was "what if the source code uses .c++ or .py files?" :lol:
I suppose, ultimately it'd be a matter of coming up with a script that would check for all known source file extensions, or maybe just go through the files list in the src|source|?? folder, but I agree that for a quick & dirty solution for C based codebases, his way looks pretty good.