onefang bug fixes Was: [CF-Devel] Forgotten child

Sat Nov 1 23:18:41 CST 2003

I'm gonna respond to some of my own stuff as well as Mark's comments.

Executive summary - Don't worry about it, everything is fine.  Or, as we say 
here in Australia, "She'll be right mate."

On Mon, 27 Oct 2003 04:35 pm, Mark Wedel wrote:
>

      David Seikel wrote:

     >

      > BTW, I wasn't too sure about one of the inv checker bug fixes I

     >

      > submitted. (This is from memory, I am currently not at my own computer). 

I am now at my own computer, and I have plenty of time to look at source code.

>

      > As far as I can remember, inv checkers was a recomended way of stopping a

     >

      > particular race (player race or monster race) from going someplace.  In

Naturally, I cannot find that recomendation now, I read it in the docs 
somewhere, honest B-).  However, inv_checkers look like the only way of 
having a no_pass that is based on some condition.

>

        Well, looking at the code currently in CVS, the problem really seems to

     >

      be that the check_inv bails out if the triggerer is not a player.

check_inv() does bail if the triggerer is not a player, but the actual 
checking work is done by check_inv_recursive(), which is called from other 
places.  Notably check_inv_recursive() is called from blocked_link() in 
maps.c, and that does apply to monsters.

>

        However, I'm not sure how an inventory checker can be used to control the

     >

      trail of ants - the inventory checker doesn't limit where they can go,

     >

      other than being connected to some other object (say a gate or whatever)

     >

      which limits where they go.

inv_checker can have no_pass set, and this can be combined with match / no 
match to control access in a conditional way.  That is, pass only if the 
inv_checker matches, or pass only if the inv_checker doesn't match.

>

        I wouldn't really see why the order we are checking would make any

     >

      difference. And looking at the code right now, it seems to check the player

     >

      object before checking for matching objects in the inventory.

When I made the change oh so many moons ago, it wasn't that things where in 
the wrong order, it was that the player/monster object check wasn't done at 
all.  Looking at the CVS code right now, the change I made (checking the 
player/monster object) is in fact there.  One less bug for me to double check 
B-).  As for importance of order, I also doubt if it makes any difference, 
but since the general way it works is to check containers, then check the 
contents of the containers, and recurse down, I figured checking the 
player/monster first as the container of everything else was the obvious way 
to do it.

>

        so I'm not really sure what is trying to get fixed here/what is currently

     >

      broken, aside from perhaps the fact that the player check is still there.

This has turned out to be a storm in a tea cup.  The bug fix I was referring 
to had already made it into CVS, so I can cross that off my list of bug fixes 
to be double checked against CVS.

To summarise -

check_inv() and blocked_link() both use check_inv_recursive() to see if the 
inv_checker is triggered.

While check_inv() only applies to players, blocked_link() applies to monsters 
and players.

My bug fix (part of my initial bug fix package before I had CVS access) was to 
check_inv_recursive() and the patch had already been applied to CVS (complete 
with the comment I wrote) by someone else, probably you.

inv_checkers with no_pass set will block unless check_inv_recursive() returns 
a match.

inv_checkers with no_pass and last_sp set will block unless 
check_inv_recursive() returns no match.

Thus inv_checkers are the only reliable way I could see to have a conditional 
no_pass that didn't require a door.

I needed a reliable way to confine ants to a certain area of a map, while 
allowing all others to move around freely.  This was an open area, there are 
no walls I could put doors into.  I had seen a recomendation that 
inv_checkers are the way to do it, so I ringed my area with appropriate 
inv_checkers (no_pass if matching 'ant').  This didn't work, there were ants 
everywhere, I fixed it and it was included in my batch of patches.

To put it another way, if you cannot carry an ant with you across a place 
blocked by an inv_checker, then an ant itself should not be able to cross 
under it's own power.  To put it a third way (haven't tested this by the way) 
if you cannot carry an arrow across an inv_checker, you should not be able to 
throw / fire it across.

There where other bugs in inv_checkers, I fixed a bunch of them.  For 
instance, you are supposed to be able to setup an inv_checker that will 
remove the matched item, but random items where removed under some 
conditions.  Really upset me the first few times when I found that random 
items where going AWOL, including super powerful magic items I went to a lot 
of trouble to collect.  Lucky it was my test server and I had backups of all 
data files, so I restored the player file and went in search of the theif 
B-).

On the other hand, with the last CVS code I grabbed, the inv_checkers I use 
for testing crash the server.  My inv_checker bug fixes have not all been 
applied, or they ended up in the wrong place due to the massive code changes 
you mentioned, or there are new inv_checker bugs, or some evil combination of 
these things.  I should put together an inv_checker test plan and debugging 
map.

Back to the bug double checking...

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel