06 Nov, 2008, Runter wrote in the 201st comment:
Votes: 0
Quote
Runter, do you suppose the fact that most of the other codebases represented here also have their own separate forum sites might have a slight impact on the reason for such numbers?


I'm a liberal. I conveniently leave little facts like that out when representing my case.
06 Nov, 2008, Conner wrote in the 202nd comment:
Votes: 0
Ah, didn't mean to cramp your political style, was just trying to help point out the most obvious causality for your observation. :lol:
06 Nov, 2008, Runter wrote in the 203rd comment:
Votes: 0
Some day ram will have its own forum, Mr. Fancy Pants.
06 Nov, 2008, Conner wrote in the 204th comment:
Votes: 0
Hmm, is that a threat or a promise? :tongue:
06 Nov, 2008, David Haley wrote in the 205th comment:
Votes: 0
Runter said:
I'm a liberal. I conveniently leave little facts like that out when representing my case.

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.
06 Nov, 2008, Avaeryn wrote in the 206th comment:
Votes: 0
Runter said:
Some day ram will have its own forum, Mr. Fancy Pants.


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

I just thought that was too cute to resist! Love ya Conner! Mean it! :biggrin:
06 Nov, 2008, quixadhal wrote in the 207th comment:
Votes: 0
*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:
07 Nov, 2008, Runter wrote in the 208th comment:
Votes: 0
Is there any way to see a list of the revisions and what the changes were in each revision?
07 Nov, 2008, Runter wrote in the 209th comment:
Votes: 0
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.)
07 Nov, 2008, quixadhal wrote in the 210th comment:
Votes: 0
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.
07 Nov, 2008, quixadhal wrote in the 211th comment:
Votes: 0
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.
07 Nov, 2008, Runter wrote in the 212th comment:
Votes: 0
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.
07 Nov, 2008, Runter wrote in the 213th comment:
Votes: 0
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().
07 Nov, 2008, quixadhal wrote in the 214th comment:
Votes: 0
Runter said:
for ( vch = ch->in_room->people; vch; vch = vch->next )


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.
07 Nov, 2008, David Haley wrote in the 215th comment:
Votes: 0
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…
07 Nov, 2008, Runter wrote in the 216th comment:
Votes: 0
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.)
07 Nov, 2008, Runter wrote in the 217th comment:
Votes: 0
*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:
07 Nov, 2008, David Haley wrote in the 218th comment:
Votes: 0
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.
07 Nov, 2008, quixadhal wrote in the 219th comment:
Votes: 0
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
Quote
int olevel = 0;
int i = 0;
int j = 0;

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. :)
07 Nov, 2008, Runter wrote in the 220th comment:
Votes: 0
I love that the compiler just lets you declare the variable any old place. Like
Quote
for(int i = 0;i < 10;++i)
;
200.0/267