Alright, so this is in the Coding forum because it could apply to all the bases housed here. Now, down to business.

Affects in Smaug are are conglomeration of spaghetti, goo, probably some glue, and I wouldn't be surprised to see some twist-ties or zip-ties too. They're disgusting, bulky, and probably horribly, horribly expensive. I get a headache, and it kills my drive to work on my mud whenever I look at them. And sadly, I need to work on Affects. I need to update them to use std::bitset. Which is no easy task considering how entwined they are with everything in Smaug.

So I had this idea. What if.. instead of trying to decipher this pile of spaghetti/glue/goo/twist-ties/zip-ties.. it was ripped out, and rewritten from the ground up. Fantastic idea. But wait. If I don't know what all they do while they are entwined in all these other things. How do I rewrite them? Where do I begin? What do I do with them? Seriously. It quickly goes from daunting, to scary. So I figured if it's going to be done, it might as well be done with active community involvement. Much like the weather revision. The difference here is, I'm not going to do this solely by myself. We, as a community are going to develop this. How? I dunno, hadn't figured that part out yet. Sadly, I'll probably end up doing most of the work. But at least it will benefit most people. So. Here's the plan.

.
..
...

K. So isn't that a fantastic plan? Yeah, I thought so too. Huh? I didn't say anything. Oh, that's because I have no plan. I don't even know where to start. Seriously. Where do we need to start. I think the first step should be to compile a list of all the stuff that is currently part of the Affects system. And see if there's anything that is entirely not needed. (And yes, David, I know about your complaint about what they're called. ) Then we need to figure out what things should be being affected, what things shouldn't, how to handle it. We'll also need to hash out a plan to deal with spell affects.

And here's where I elicit a groan from all you hardcore C junkies. I refuse to contaminate this new system with bitvectors or extended bitvectors. If we do anything of that sort, we'll be using std::bitset. *pauses for groans* K, stuff a sock in the groaning. SmaugFUSS, SWRFUSS, SWFotEFUSS, and AFKMud all compile as C++. Why limit ourselves to 32, and 128. std::bitset is limitless with all regards to a MUD. That's probably not the wording I wanted. When it comes to a MUD, you're never going to reach the limit of a std::bitset. Yeah, that's what I meant. So why not? Any objections to this better have a damn good reason why we should be limited to 128, and why we shouldn't enjoy the fruits and ease of C++. Also, a viable alternative to std::bitset would be awesome as well. "I don't like C++" doesn't count as a good reason, btw. C++ is C with extras for making life easier. So if you don't like C++ you don't like an easy life. So.. Totally off topic. Anyway. Thoughts? Volunteers? I forgot what I wanted out of this. XD

.........................
Owner/Coder -- Malevolent Whispers -- Development Phase - Not accepting players
Coder -- Star Wars: The Sith Wars -- Open Alpha - Players Welcome - Full System Re-writes Imminent.

I3 Contact: Kayle@SithWars

Sounds like an ambitious project. What happens at the end of it? Will this be an 'affects snippet' or will this be SmaugFUSS 2.0?

I'm almost sorry I'm not a coder and can't contribute anything useful. Maybe I can offer advise here and there on use-ability from a players perspective or offer some project management skills.

(And this probably goes without saying but here's hoping this turns out a lot better than *ahem* certain projects on a certain other site) .........................
******************************
aka Hana Owner in Training: Fury of the Gods (in development)
laugh. dance. cure.

Over all theres not alot of stuff to deal with, although if you look at the code as a whole (considering where all affect information is checked, added, modified, and used) it can be a bit much lol. Most of that I'm sure you already know what it does. If you can give a little more info on what you would like to know though I'll answer the best I can.

I've found that you can sometimes come out better writing something from scratch and then there are times to just modify what you have. This would be one time where before you write something from scratch first of all you need to get a very good idea of what is being done and what you want to be done different. Like before you rip one out you might want to first combine it so its less of a mess (and trust me I've seen it enough to know it's messy as hell) so that you can have an easier time replacing it once you do decide what you want different. .........................
Remcon
Lands of Pabulum

Probably both. If the change is large enough, it may very well warrant our approach to 2.0. But it will definitely be a snippet, and will definitely go into SmaugFUSS.


I'm looking to understand it all. I don't really feel confident in my understanding of the affects at all. Even the simple things like checking, adding, modifying, and using. If I'm going to spearhead this revision, I'm going to need to be completely confident in the knowledge of how it works.

As for cleaning up the existing implementation, that sounds like a wonderful idea, until you start picking at it and trying, and get smacked with errors after errors because of the odd way the whole thing is implemented. For instance with characters. Sometimes it'll set just ch->affected.bits[0] and others it'll set just ch->affected. Why? To What end? Why does there have to be two separate ways to set something? I'm tired of seeing this stuff scattered through the base I've come to love. I want to see Smaug cleaned up and showing at least some semblance of intelligent design. I want to see it utilize more of the STL. (This was actually one of the reasons I restarted my own base from stock SmaugFUSS 1.9, so that I could update it to C++ but since then I've gotten so distracted and worked on so much other stuff that the original goal is long gone.)


Which project is this? MSSP? .........................
Owner/Coder -- Malevolent Whispers -- Development Phase - Not accepting players
Coder -- Star Wars: The Sith Wars -- Open Alpha - Players Welcome - Full System Re-writes Imminent.

I3 Contact: Kayle@SithWars

You know I recall seeing and changing that in LoP long ago lol I hated how that worked, and if I recall it was kind of buggy. I'll have to look at it some more real quick though to refresh my memory on what it was for. .........................
Remcon
Lands of Pabulum

I think the sad part here is that the current system is so deeply embedded and handled in so many different ways that it's impossible to properly understand how it works at present. Sure, there's code to add, modify, and remove affects. Great. But then when you look at it, there's 6 ways to do each one. It doesn't help at all that half the system uses xBV and half is still using normal BVs. So it seems to me at least that scrapping the entire hornet's nest first is desirable. Just look at the difference between the AFF_* and the APPLY_* flags and you'll understand the frustration. I made the mistake of powering through a conversion to std::bitset in AFKMud without really knowing what the hell was going on, and the system has bugs in it to this day I got sick of trying to fix.

Once that's done, some effort needs to be put into thinking of what sort of affects are wanted. The existing lists are fine, but there's no sane reason for them to be broken up into several blocks. If you want something to give a player +5 STR for a duration, don't shoehorn it. I suck at designing shit like this though. It's probably more accurate to say I'd be tempted to slap something together and hope for the best, but chances are it would turn out badly. .........................
PDNS-Admin | Sandbox | Arthmoor MUD Hosting Services | The Truth About Medievia: A Saga of Code Theft.

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984

That is the exact reason that APPLY_AFFECT uses like ch->affected_by.bits[0] and APPLY_REMOVE also used the ch->affected_by.bits[0]
and APPLY_EXT_AFFECT does the ch->affected_by

Well in mine I went with getting rid of the way using ch->affect_by.bits[0] since it was buggy as hell and caused problems lol but I do recall it being a pain in the ass over all to finally get working right. .........................
Remcon
Lands of Pabulum

[Changed the name of the topic so it's a little more obvious what's being discussed here.]

K. So. I think the first step toward figuring out a plan for this is to figure out what everything is used for. So first things first.

/*
 * An affect.
 *
 * So limited... so few fields... should we add more?
 */
struct affect_data
{
   AFFECT_DATA *next;
   AFFECT_DATA *prev;
   short type;
   int duration;
   short location;
   int modifier;
   EXT_BV bitvector;
};

/*
 * A SMAUG spell
 */
struct smaug_affect
{
   SMAUG_AFF *next;
   SMAUG_AFF *prev;
   const char *duration;
   short location;
   const char *modifier;
   int bitvector; /* this is the bit number */
};

Smaug_Affect seems to be only used where the OLC Skills/Spells are concerned, and it seems to just be an interface for spells/skills to modify affect_data.
Affect_data appears to be the main meat of the system. So here's my question. What are each of these values used for? Remcon, can you shed any light on this? Looking over the code is only resulting in headaches because it's so hard to tell which one is being used in all the millions of places any of them are used. However at least type is only in affect_data so that one is at least semi-easy to determine. Or so one would think.

From what I can tell affect_data->type is used to store skill numbers? I dunno though. So Remcon, have any light to shed? or am I going to have to continue poking around in the dark..? .........................
Owner/Coder -- Malevolent Whispers -- Development Phase - Not accepting players
Coder -- Star Wars: The Sith Wars -- Open Alpha - Players Welcome - Full System Re-writes Imminent.

I3 Contact: Kayle@SithWars

/*
 * An affect.
 *
 * So limited... so few fields... should we add more?
 */
struct affect_data
{
   AFFECT_DATA *next;
   AFFECT_DATA *prev;
   short type;
   int duration;
   short location;
   int modifier;
   EXT_BV bitvector;
};

Well the next and prev is for the double linked list handling. (I'm sure most know that )
type normaly is used for the gsn/sn.
duration is how long the affect has left.
location is the apply location
modifier is what is being modified (this is sometimes just a number like 5 for APPLY_STR and other times its like RIS_FIRE for APPLY_RESISTANT).
bitvector is used for applying a bitvector (APPLY_EXT_AFFECT for example).

/*
 * A SMAUG spell
 */
struct smaug_affect
{
   SMAUG_AFF *next;
   SMAUG_AFF *prev;
   const char *duration;
   short location;
   const char *modifier;
   int bitvector; /* this is the bit number */
};

You will notice that they are more or less the same aside from the char stuff being used here and the bitvector is an int here.
It uses a char for duration and modifier so it can use things like (L*5) etc... rd_parse if I recall right is used to get the numbers for it.
The bitvector is an int and not really sure why they did it as an int lol.

When a spell is cast it will take and copy the smaug_affect information over to a created affect and put it on the character. It uses lots of run around to handle this affect_modify, affect_to_char, affect_remove, affect_strip, affect_join, update_aris, aris_affect, spell_affectchar, spell_affect, .... But they all do have their needs lol

Hope that makes it a little easier to follow if not let me know what else you need to know .........................
Remcon
Lands of Pabulum

In the name of all things holy, if effects are overhauled, can we please spell it correctly and fix the mistake that was made more than a decade ago.

Now. The main problem with effects is that there is not a sane, unified interface to the system. You mess with effects in any number of ways, some of which are almost direct competitors.

It would be a major improvement to just expose a public interface for adding and removing effects to and from characters. The core of the effect system is relatively simple; what's complicated is the huge number of ways of dealing with them.

--

That said, there's something of a mission decision to think about here. What's being proposed is kind of like the RaM switch from Ice to Fire or whichever direction it was. This is certainly not a "bug fix"; we're talking a major internal overhaul that will make the codebase seriously incompatible with previous releases. Applying this patch won't be a simple matter of "go to line X, change to Y". Somebody asked if this would be SmaugFUSS 2.0 -- I think that that's a serious question, because the change will be considerable. .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

So what do you propose David? I don't think I have fully ever looked at the Effects system before.

I am not proficient in C++ but once we get a direction and once I see how things go then I could probably help some, but until then I don't think my input will be very valuable. .........................
Owner/Coder

Legends of Old
Currently in Development

The first thing I'd do is start differentiating between public and private data fields of the various structures. We don't have to do it all in one fell swoop -- in fact we shouldn't refactor more than we have to at a time -- but if we want to enforce interface, this is a great way to start.

"We" also need to figure out what all the various effect functions actually do, and see how to unify them. I haven't looked at them in long enough to remember the details, and besides most of my knowledge comes from my own codebase which is far enough removed that it might not be relevant anymore.

I don't have a full game plan, although I have a pretty good idea of the direction to head in. .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

I would actually consider this a bug fix. Yes, technically the system works as is. But it's not user friendly. Arguably this could be seen as an enhancement or a bug fix. It could also be viewed like the weather system. For that I just ripped out the old one and started from scratch. I was hoping to avoid that with this system, but the more I probe, the more it looks like a clean slate approach might be the easier path.

As for breaking compatibility with older patches, we technically already have. The const fix, already broke most snippets out there with the new need to have const char *argument instead of just char *argument. No, that's not really significant. But if done right, I think this could possibly be done without trashing compatibility too much. At least, that's my hope.

On the note of changing the name, Yes, technically it should be effects. But wouldn't that be more of a cosmetic change that could be handled by rewording the messages shown inside the game? These are enacting an effect on a character, so do they not Affect a character, while the actual effect given would be seen as an effect?

Between this and the traps overhaul, yes, we probably will reach the 2.0 milestone.

Still working on a plan for this. So, any input on direction to head, and any pseudo code people are willing to submit to help with this would be appreciated. Also, if anyone wants to try and document, everything the tentacles of this system are currently wrapped up in, any functions that work with these in a significant manner (don't mean setting one on a character, I mean actually interfacing with the guts of the structs themselves, something akin to affect_modify and the like), or any explanation of said functions that work with these in a significant manner would be appreciated, and I guess that's all I really have to offer as far as compensation... lol. .........................
Owner/Coder -- Malevolent Whispers -- Development Phase - Not accepting players
Coder -- Star Wars: The Sith Wars -- Open Alpha - Players Welcome - Full System Re-writes Imminent.

I3 Contact: Kayle@SithWars

So I was bored today and started an attempt at documenting (hopefully) relevant code from the source files of my clean SmaugFUSS 1.9.

Firstly, these are the functions found;

act.info.c:673:void show_visible_affects_to_char( CHAR_DATA * victim, CHAR_DATA * ch )

handler.c:988:void room_affect( ROOM_INDEX_DATA * pRoomIndex, AFFECT_DATA * paf, bool fAdd )
handler.c:1042:void affect_modify( CHAR_DATA * ch, AFFECT_DATA * paf, bool fAdd )
handler.c:1419:void affect_to_char( CHAR_DATA * ch, AFFECT_DATA * paf )
handler.c:1457:void affect_remove( CHAR_DATA * ch, AFFECT_DATA * paf )
handler.c:1482:void affect_strip( CHAR_DATA * ch, int sn )
handler.c:1519:void affect_join( CHAR_DATA * ch, AFFECT_DATA * paf )
handler.c:1543:void aris_affect( CHAR_DATA * ch, AFFECT_DATA * paf )
handler.c:4365:void showaffect( CHAR_DATA * ch, AFFECT_DATA * paf )

magic.c:29:ch_ret spell_affect( int sn, int level, CHAR_DATA * ch, void *vo );
magic.c:30:ch_ret spell_affectchar( int sn, int level, CHAR_DATA * ch, void *vo );
magic.c:5455:ch_ret spell_affectchar( int sn, int level, CHAR_DATA * ch, void *vo )
magic.c:5605:ch_ret spell_affect( int sn, int level, CHAR_DATA * ch, void *vo )

player.c:862:void do_affected( CHAR_DATA* ch, const char* argument)

save.c:51:void fwrite_fuss_affect( FILE * fp, AFFECT_DATA * paf );

Secondly, I grepped my little heart out to find instances of "affect*" or "AFF*" or "effect" (yes there are some!). To make it somewhat easier and readable I copied everything into text files per source file. I ended with a total of 31 files. Not sure what to do with them to share this information. Maybe we could make a spot in the repository for any of this project related stuff? Anyway, there's not much more I can do with them as I'm not a coder and it all looks greek to me Gathering info, sorting info, documenting info will be my contribution. .........................
******************************
aka Hana Owner in Training: Fury of the Gods (in development)
laugh. dance. cure.

File category created for uploading affects stuff. .........................
Owner/Coder -- Malevolent Whispers -- Development Phase - Not accepting players
Coder -- Star Wars: The Sith Wars -- Open Alpha - Players Welcome - Full System Re-writes Imminent.

I3 Contact: Kayle@SithWars

Effects, effects, effects .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

Does every mud have affects in them rather then effects? Can you think of any that has effects? .........................
Owner/Coder

Legends of Old
Currently in Development

Other than mine, no, I don't know of any, but that doesn't change the fact that everybody is making and/or perpetuating a spelling mistake
(Seriously, look it up in a dictionary: "affect" as a noun doesn't mean what people think it means) .........................
David Haley
Head Coder, Legends of the Darkstone
BabbleMUD Project
http://david.the-haleys.org

Got no beef with correcting the mistake, but obsessing over such a small thing in the code doesn't seem healthy to me .........................
PDNS-Admin | Sandbox | Arthmoor MUD Hosting Services | The Truth About Medievia: A Saga of Code Theft.

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984

I'm OCD about typing aff who and look in my mud. I don't know if I can switch to eff. haha. .........................
Owner/Coder

Legends of Old
Currently in Development