04 Nov, 2008, kiasyn wrote in the 181st comment:
Votes: 0
Runter said:
First they stifled free speech.

Now they're water boarding people. ;)



…not cool.
04 Nov, 2008, Avaeryn wrote in the 182nd comment:
Votes: 0
DavidHaley said:
Ohhh… waterboarding. I thought it looked a little like somebody was strapped down and being zapped with a brainwashing machine. :lol:


I almost thought it was one of those anti-Ford bumper stickers. You know, the little boy with his back turned peeing on a Ford logo? :evil:
04 Nov, 2008, Avaeryn wrote in the 183rd comment:
Votes: 0
quixadhal said:
I cheated and just regex-replaced angle brackets. I know perl has a module for that, I just didn't feel like looking it up. :)

Waterboarding? Hmmmm, just because the board background is blue?

Oh yes, the bug list is now RAINBOW coloured, courtesy of Runter! :)

I opened a new port for plain http on port 8088, so let me know if it works (I don't have an external site to try it from myself).


Love the colored list :) Still reminds me of Skittles. :unclesam:
05 Nov, 2008, quixadhal wrote in the 184th comment:
Votes: 0
Ok, yanking us all the way back to the start of this thread for a moment. :)

In Bug #1, the complaint is that if obj_from_char(obj) removes strength (or any other prerequisite) from the character, AND the next item in their list (obj_next – formerly obj->next_content), then apparently obj_from_char(obj) will ALSO remove that second object from the character, putting it in the room's inventory.

THAT situation means our obj_next pointer is still valid (wherease obj->next_content will be now point to something else), but is now the room's content list.

Clearly, a potential bug.

However, I don't think the solution presented is the right one. I think obj_from_char() shouldn't EVER remove anything beyond the object requested for removal (and anything IT contains, if it's a container). If something can't be equipped anymore, it needs to be unequipped and either put into inventory or dropped as a seperate event (or in the update loop).

Opinions? Suggestions?
05 Nov, 2008, quixadhal wrote in the 185th comment:
Votes: 0
I've mucked with my script a little bit more, now the status is read from the actual bug file via a new Status line for each entry. That means I don't have to muck with my script as we fix things… I can just edit the bug list text and regenerate the html. Yeah, I could make it a cgi bin…

I've also started putting commentary at the bottom of the entries when their status changes. :)
05 Nov, 2008, Runter wrote in the 186th comment:
Votes: 0
Quote
Opinions? Suggestions?


Yeah. Use std::list and iterate it properly instead. :P
05 Nov, 2008, David Haley wrote in the 187th comment:
Votes: 0
I would be inclined to agree that obj_from_char should do nothing more than just unlink the object from the character's inventory.

I'm not convinced that this is really a question of proper lists vs. Diku-linked-lists, though.
05 Nov, 2008, quixadhal wrote in the 188th comment:
Votes: 0
Ok, working down the bug list…. the bug of being able to scan and see people through closed doors….

The suggested fix is:

if ( door != -1 && scan_room->exit[rev_dir[door]] != NULL
&& IS_SET(scan_room->exit[rev_dir[door]]->exit_info,EX_CLOSED) )
return;


My question: Why check the reverse exit? Yes, I know if ONE side of a door is closed, the other side SHOULD be too, but considering that rooms are not always euclidean, shouldn't we be checking the door on the side of the person doing the scan first, and the reverse one ONLY if it actuallys points back the same room you're standing in?

In other words, shouldn't THIS check be done first???

if ( door != -1 && ch->in_room->exit[door] != NULL
&& IS_SET(ch->in_room->exit[door]->exit_info.EX_CLOSED))
return;


and shouldn't the other one also check?
&& scan_room->exit[rev_door[door]]->u1.to_room == ch->in_room
05 Nov, 2008, Runter wrote in the 189th comment:
Votes: 0
DavidHaley said:
I would be inclined to agree that obj_from_char should do nothing more than just unlink the object from the character's inventory.

I'm not convinced that this is really a question of proper lists vs. Diku-linked-lists, though.


It's a question of intrusive lists vs proper lists. The problem is solved with a proper non-intrusive container class.
If you're running an iterator through a proper list and remove any element in the list at the same time you're safe to continue spanning your tree without fear of list corruption. (Which this really is.)
05 Nov, 2008, Runter wrote in the 190th comment:
Votes: 0
I think checking the exit and return linking is just bloating for no reason. First of all, it logically should never happen because the code fixes all the exits to have two doors regardless. In my opinion, that's just being paranoid. The code spends a lot of resources at boot time and OLC to ensure autonomously that closed doors always are closed on both sides.

Also if we are scanning and one side of the door is closed–Then it doesn't even matter if the other side is closed. If our side is closed the scan failed.

So are we going to check every reverse exit of every exit. Even ones that don't have doors?
05 Nov, 2008, David Haley wrote in the 191st comment:
Votes: 0
As a note, not all containers allow you to remove arbitrary elements during iteration. If you are claiming that the STL list is implemented in such a way as to let you remove arbitrary elements and preserve iterator state – I don't remember myself – that would indeed solve part of this issue. My understanding is that the issue is more complicated: there is also a design decision involved separate from container implementation: should calling for the removal of one object be able to effect the removal of another object? (As opposed to the question of how you handle that safely.)
05 Nov, 2008, Runter wrote in the 192nd comment:
Votes: 0
Well, all I have to say on the matter is when I read through the list of bugs many of them were associated with list corruption. Also, it's unintuitive to have to use holder next variables just in case you want to delete the current pointer. But if the list gets changed randomly during iteration you're screwed just the same. (Although it may happen without realizing it or with future code or just rarely.)


It may be something we want to talk about–The process for which it removes nested items and such–but my point is the list system probably should be revised. Not just for the sake of the bugs on the list, but the future bugs and unknown bugs it has already created.
05 Nov, 2008, David Haley wrote in the 193rd comment:
Votes: 0
Oh, I fully agree that the system should be revised. As you say, it's pretty unintuitive to have to store temporary pointers and all that. The list object should be separate from the objects in the list.

It might be worth asking Samson what he thinks about this w.r.t. all the work he did in AFKMud to use STL containers and to what extent it was worth it in the end.
05 Nov, 2008, Runter wrote in the 194th comment:
Votes: 0
Yeah, I may be wrong about the minor detail of iterators preserving the list during iteration. *innocent*

I'm currently investigating the issue.
05 Nov, 2008, David Haley wrote in the 195th comment:
Votes: 0
I know that Java lets you remove the element you just visited safely for basically all containers, but it gets really jittery about removing arbitrary elements. I frankly don't remember what the STL does; it probably depends a great deal on the container. I'm virtually certain that you can't remove arbitrary elements from sets and maps during iteration, for instance.
05 Nov, 2008, Runter wrote in the 196th comment:
Votes: 0
The implementation of the container should give you the new iterator value upon an operation that changes the list.

For example,

// erase this element if it is value 10.
if (*it = 10)
it = L.erase(it); // continue proper iteration.
05 Nov, 2008, Runter wrote in the 197th comment:
Votes: 0
This would produce the output 0 through 15 and exclude outputting 1 or 10.

list<int> L;
std::list<int>::iterator iter;

// Populate our list with 0 through 15
for(int i = 0;i < 16;++i)
L.push_back(i);

// Span our unary tree.
for(iter = L.begin();iter != L.end();++iter) {
if (*iter == 1 || *iter == 10) // remove the element without corrupting list.
iter = L.erase(iter);
cout << *iter << endl;
}


And removing elements other than the current one.
list<int> L;
std::list<int>::iterator iter;

// Populate our list with 0 through 15
for(int i = 0;i < 16;++i)
L.push_back(i);

// Span our unary tree.
for(iter = L.begin();iter != L.end();++iter) {
if (*iter == 1 || *iter == 10) // remove the next element without corrupting list.
L.remove(*iter + 1);
cout << *iter << endl;
}
05 Nov, 2008, quixadhal wrote in the 198th comment:
Votes: 0
Dunno if this applies to all iterators, but I found this:

Quote
When modifying the container itself while iterating over it, some containers (such as vector) require care that the iterator doesn't become invalidated, and end up pointing to an invalid element. For example, instead of:

for (i = v.begin(); i != v.end(); ++i) {

if (erase_required) {
v.erase(i);
}
}

Do:

for (i = v.begin(); i != v.end(); ) {

if (erase_required) {
i = v.erase(i);
} else {
++i;
}
}


The erase() member function returns the next valid iterator, or end(), thus ending the loop. Note that ++i is not executed when erase() has been called on an element.
05 Nov, 2008, Runter wrote in the 199th comment:
Votes: 0
I thought I would point out that this subforum, even though young, has nearly as many posts on it (490) as the rom main forum does. (650ish)

And this sub-forum has more than the totality of other codebases including their subforums.
06 Nov, 2008, Conner wrote in the 200th comment:
Votes: 0
Runter said:
And this sub-forum has more than the totality of other codebases including their subforums.

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? :wink:
180.0/267