I'm a liberal. I conveniently leave little facts like that out when representing my case.

Ah, didn't mean to cramp your political style, was just trying to help point out the most obvious causality for your observation. :lol:

Some day ram will have its own forum, Mr. Fancy Pants.

Hmm, is that a threat or a promise? :tongue:

Somebody's in for a whole lot of angst in the years to come… :rolleyes:

Basically it comes down to the fact that design discussion is occurring here whereas the other codebase forums are used mainly for question/answer type things. Which is more or less the consequence of what Conner said.

Yes! It will! Long live RaM!!!!! :tongue:

I just thought that was too cute to resist! Love ya Conner! Mean it! :biggrin:

*smirk*

Hey you slackers…. revision 39 brings more bug fixes from Ye Olde List....

Pass 1 got all the easy ones, the rest either may not apply yet, or require me to take precious time away from Fallout 3. *grin*

I think we have to officially accept the name "Repressed Anger MUD" before we get our own sub-forum. Can't have a sub-forum without an actual name, can we? :evil:

Is there any way to see a list of the revisions and what the changes were in each revision?

Btw, I'd just leave any of the bugs alone associated with list corruption because of the linked list code.

It's going to be fixed as soon as the new style lists are merged in anyways. (Along with a lot of bugs that probably have went unreported.)

Yep, there are a few commands that are useful.

svn log -r40:42 .

That would show the log messages you (or I) provided when we did a checkin, for revisions 40, 41, and 42.

You can also generate diffs via: svn diff -r40:41 foo.c
I think you can generate annotated diffs (which have the revision of the lines changes), but I've never bothered to try.

I'm currently rearranging code a bit more (trying to get rid of recycle.c) and poking at bug #12. On the TODO list will be an entry to add a LAW property to an area to cover the entire area. I'd actually suggest allowing such global properties for many of the room flags (dark, indoors/outdoors, nosummon, etc)… it would save a lot of hassle.

If I'm building an underground cavern, I'm pretty sure 99% of the room will be underground, indoors, and dark. To make exceptions though, one needs to have reverse bits (or confusingly allow them to be reversed, even though they aren't renamed). IE: if dark is set at the zone level, setting dark on a room XOR's it and makes it not dark. As long as that's clearly documented and supported in OLC via changing the names to LIGHT, it'd be easy to implement.

Perhaps for consistency I would say have a similar system for setting flags on all mobs in a certain area. Or perhaps objects.

I could see perhaps wanted to have all or almost all of the mobiles in the area load blind or some other flag if it made sense.

Hrm. I stumbled across a bug. I don't remember it being on the big list 'o bugs so you might want to check out this code in check_assist()

Down near the middle or bottom is this.

{
                    CHAR_DATA              *vch;
                    CHAR_DATA              *target;
                    int                     number;

                    if ( number_bits( 1 ) == 0 )
                        continue;

                    target = NULL;
                    number = 0;
                    for ( vch = ch->in_room->people; vch; vch = vch->next )
                    {
                        if ( can_see( rch, vch )
                             && is_same_group( vch, victim )
                             && number_range( 0, number ) == 0 )
                        {
                            target = vch;
                            number++;
                        }
                    }

                    if ( target != NULL )
                    {
                        do_function( rch, &do_emote, "screams and attacks!" );
                        multi_hit( rch, target, TYPE_UNDEFINED );
                    }
                }

Notice how the loop runs through all of the people in the room but uses the next variable.
That was supposed to be ch->next_in_room. That code as it stands is a good example of how
a simple logic error can corrupt a list. Since next is used in only two places in stock rom, the main character list,
and the list of recently freed data—you could have freed pointers dereferenced or just people not in the same room checked against, randomly.

However, the new list system would fix this naturally anyways.

edit: Found the same thing happening in mob_hit().

Hmmm, so this is what happens when friends let friends code drunk? :)

I assume then, that the Diku people decided to embed several different sets of list traversal pointers in each object, rather than properly manage lists externally with pointers to the nodes…. no wonder "threading a link" is such a pain.

Somebody probably did it when there was just one list, which is "kind of" (read: not really at all [1]) reasonable, and then the next person came along wanting to do a list, and they said hey: we've already got this link, so let's add another one… and then nobody ever got around to fixing it, in part probably because few people realized how dangerous it was, or felt confident enough to be able to fix it without breaking a lot of stuff.

EDIT:
[1] it's reasonable in very few circumstances, but in this case it should have been predictable that you'd have many different lists of characters – furthermore, the character object is not very lightweight; embedding the list directly makes some sense for very lightweight objects when the overhead of the extra pointers is more than the object itself. But anyhow…

I think it's just an example of how easy it is to mess up with what they were doing.

ch->next was always intended to only be used in the list for all valid character data.
Whereas, ch->next_in_room was always intended for linking players in the room together.

It's just a slip. I think anyone who was coding something quickly could do it by accident.

But then again, the system just lends itself to accidents that like which aren't obvious even at runtime. (And potentially can corrupt data.)

*wonders if indent really did a good job*

if ( mob->pIndexData->pShop != NULL )
                {
                    int                     olevel = 0,
                        i,
                        j;

                    if ( !pObjIndex->new_format )
                        switch ( pObjIndex->item_type )
                        {
                            case ITEM_PILL:

That looks quite correct to me. Not pretty, but correct.


EDIT: unless you were referring to the newlines in the variable declaration, in which case you'd have to go look if those were there before indent ran.

Yes, that's one of the many places K&R/ANSI C and I differ in opinion. I can't stand declaring multiple variables in one statement, because it makes a huge mess if you decide you move them around later. I generally fix those when I see them, so they become

It doesn't help that ROM is full of variables that are declared inside brace scope pairs, instead of at the top of the function like a good K&R programmer would do. :)

I love that the compiler just lets you declare the variable any old place. Like