Speaking of snippets. There is one snippet that would be nice to add into SWR/FotE, and that is the Replacement Shuttle System. It does not change the gameplay, but it makes creating and updating shuttles and turbocars much nicer for the imms by making them OLC'ed instead of hardcoded.

A few other things that would be nice:
OLC Liquids,
OLC Races,
OLC Classes

None of which are hard to do, I've done them on my MUD. But it would be nice for it to be actually released.

Keirath said:

None of which are hard to do, I've done them on my MUD. But it would be nice for it to be actually released.

And yet, no one's stepped up and offered to do it.

This is my biggest issue with working on the Star Wars bases. Everyone wants to see a lot of stuff done to them, but no one's ever offered to do it. Aside from Caius, who applied the const fix for SWRFUSS. And this is something I've noticed as a sortof trend in the entire Star Wars Mud community, or lack thereof. I don't know the Star Wars bases. I can't be expected to do all the work on something I don't use, don't know, and never really have. I need input from people who really use these bases, instead of everyone expecting me to do everything.

As I stated previously, I'd be more than happy to get more involved. In fact, if its desired, I'll add OLC shuttles and liquids. OLC races and classes change the base a bit the way I do it. So, I'm not sure I'd be best for that. I know the nanny.c update needs to be applied, which is no problem and I am willing to do.

I would also be willing to apply extended_bitvectors to room_flags and whatever else is necessary.



One thing that might be nice to see added is the AFK board snippet. I'm not sure if many people have played with it, but I installed it in a stock SWRFUSS recently and I am quite impressed.

Also, if we could compile a list of useless structures and data that still remain in SWR, I'd be more than happy to go through and clean it up.

Oh, also, I'm definitely interested in LUA-in-SMAUG. Though, I have NO earthly idea how to go about it
So take that as one vote from me.

I went through last night and made a list of things that I'd be willing to do this week for SWRFUSS

Nanny replacement
Remove senate_data (this struct and accompanying data is completely unused/incomplete)
Add in ship->description supporting information (Ayuri posted something about this here
Remove magic spells that are not in use
OLC Liquids
OLC Shuttles
Add Extended Bitvector support
Convert Room Flags, Languages to Extended Bitvectors (Also could do other flags, depending on what people want)
OLC Races
OLC Classes


Other ideas that I could do, if wanted:
On the Swfote Sourceforge site there is a configurable compass snippet. This is rather a nice addition, and its configurable. I thought this might be a nice addition.
AFK Board Snippet - In my opinion this is a huge improvement to the board system.

What is the general opinion on these things?

It might be worth consolidating the branches somehow. I'm not wholly sure how one would do this without making an awful lot of work. But it seems odd that every piece of work needs to be done in duplicate or even triplicate.

For example, while adding Lua to SmaugFUSS makes a lot of sense, it would be annoying to have to do the same thing all over again for the SW bases.

The practical consequence of this would be adding SW stuff to the core SMAUG base, while somehow preserving the separation of game spaces. In an ideal world there would only be one core project, with "game modules" that implement either fantasy or SW. (When you think about it, a huge number of the core mechanics are all the same.)
But this might be more trouble than it's worth considering the general state of things.

I would agree that this could be very useful. However, I'm not sure how we could go about and do this. SWRFUSS/SWFOTEFUSS are quite different than SMAUG FUSS on even a basic level. (skill system works differently, all sorts of stuff).

It definitely would save time and work.

On the topic of Lua, David, are you thinking about moving forward with Lua in SMAUG. It's something I am quite anxious to see. Even if you just did it for SMAUG FUSS, it might help a few of us get it running in SWR so you didn't have to do the work there.

Well, at this point I will say that I am very seriously considering doing it. As I mentioned, I've been doing this on and off for my own codebase for some time, so have a fairly good idea of what is involved. The main problem is that I've already got an awful lot on my plate what with work and another commitment, so I don't have a realistic idea of a time estimate at this point. It's the kind of thing where I know pretty clearly what needs to happen, I just need to go forward and do it.

FWIW I wouldn't be just adding Lua, but also starting the conversion to C++ with constructors and destructors for various objects, in particular the character objects. I don't think this really matters but I thought I'd mention it. (Well, it does matter in the sense that I won't add Lua unless I can make this kind of change here and there, because it's too much of a hassle for me to back-port everything I have to straight C. I also happen to think that it's a Good Thing for the codebase in general.)

I'd love to see it. I understand the time commitment. I was looking at what Nick Gammon did, but it doesn't seem near as in depth as what you have mentioned doing

David Haley said:

FWIW I wouldn't be just adding Lua, but also starting the conversion to C++ with constructors and destructors for various objects, in particular the character objects. I don't think this really matters but I thought I'd mention it. (Well, it does matter in the sense that I won't add Lua unless I can make this kind of change here and there, because it's too much of a hassle for me to back-port everything I have to straight C. I also happen to think that it's a Good Thing for the codebase in general.)

This looks like a good plan to me. SmaugFUSS has been sitting on the C++ fence for quite some time now. Making these changes to the structure can only be a good thing. It's the sort of first step I did with AFKMud back in the day, but I'm pretty sure I went about it in a bad way that shouldn't necessarily be repeated

How hard is the transition from C to C++. I learned C through mud programming and am very interested in learning C++. The idea of an object oriented language is something I'm very interested in. I just have NO idea how to go about learning it from here.

That's kind of a long question. There is a syntactical transition you must make, and a conceptual one. Funnily enough, contrary to what many people believe, you can already do OOP-like stuff in C. As soon as you have functions of the form:
extract_char(Character* ch, ) { ... }
then you have a "method" called "extract_char" that takes characters as objects.

Moving to C++ just enforces this constraint and organizes methods into a single location. There's more stuff too, but I have to cut this short unfortunately. Will write more later...

o u gaiz.

Here you go

This is my Lua work on FUSS so far. Enjoy.

Thanks Daniel. I appreciate it. Looking forward to learning more about it.

I mentioned earlier doing extended bitvectors, but I thought about it and remember most people before std::bitset instead. I am guessing that would be the route to go anyways, especially if we begin the conversion to C++.

Kiasyn, your archive appears to be corrupted.
But I guess this gives me an incentive to do this quickly, because there are likely things that I will want to change.

Keirath said:

I mentioned earlier doing extended bitvectors, but I thought about it and remember most people before std::bitset instead. I am guessing that would be the route to go anyways, especially if we begin the conversion to C++.

I don't like using std::bitset because I don't really care for its external interface. But yes, it would be far better to use a sane interface like that rather than the mess of bitvectors in SMAUG.

I personally don't know std::bitset so can't speak much about it.
However, I can't say I'm fond of the stock bitvector system.
Extended Bitvectors aren't much better, but at least they're not AS limited.

So really, I'm unsure where to go from there.

David Haley said:

Kiasyn, your archive appears to be corrupted.
But I guess this gives me an incentive to do this quickly, because there are likely things that I will want to change.

Keirath said:

I mentioned earlier doing extended bitvectors, but I thought about it and remember most people before std::bitset instead. I am guessing that would be the route to go anyways, especially if we begin the conversion to C++.

I don't like using std::bitset because I don't really care for its external interface. But yes, it would be far better to use a sane interface like that rather than the mess of bitvectors in SMAUG.

i checked it, and it seems fine

IT's definitely corrupted.

Tried again from work, it failed again. Maybe the upload to your blog got interrupted or something.

std::bitset is definitely where I'd like to see things go with a C++ conversion.

@Kiasyn: The .tar file inside the .tgz file is definitely corrupted.