Angband coding question

[will_asher]

I'm back after being mostly AWOL for the last couple months, but I'm back and DaJAngband is not dead (but it'll still be pretty slow moving). On that note, I have a question for people who know the code.

In monster.txt, the third entry in the W: line is unused and always set at zero. I would like to use this spot for something, but in the code it seems to assign it to r_ptr->power and actually do something with it. Does it actually do anything? Would it have any unwanted effects if I assigned the unused spot to something besides r_ptr->power and used it for something?

In the meantime, I'm going to make yet another copy of everything as a backup and go ahead and try it.


PS After being gone for awhile, I thought the official vanilla 3.1.0 would be out when I came back. oh well.

[andrewdoull]

I'm back after being mostly AWOL for the last couple months, but I'm back and DaJAngband is not dead (but it'll still be pretty slow moving). On that note, I have a question for people who know the code.

In monster.txt, the third entry in the W: line is unused and always set at zero. I would like to use this spot for something, but in the code it seems to assign it to r_ptr->power and actually do something with it. Does it actually do anything? Would it have any unwanted effects if I assigned the unused spot to something besides r_ptr->power and used it for something?

Its currently used in commented out code in init1.c. However, that is generated, and not read in from the file - so you could safely read that particular string into another value e.g. r_ptr->not_power instead.

[will_asher]

thanks, that's what I needed to know

[will_asher]

Another question:

I compiled and tested my latest change beginning to implement monster stealth. The game crashed so I tried playing the game on the debug mode in the compiler. When the game crashes, the compiler brings me to the following place in z-rand.c which I never touched. Could anyone help figure out what's wrong?

<code>
/* Hack -- extract a 28-bit "random" number */
r = ((r >> 4) & 0x0FFFFFFF) / n;
</code>


thanks ahead of time

[Mangojuice]

Another question:

I compiled and tested my latest change beginning to implement monster stealth. The game crashed so I tried playing the game on the debug mode in the compiler. When the game crashes, the compiler brings me to the following place in z-rand.c which I never touched. Could anyone help figure out what's wrong?

<code>
/* Hack -- extract a 28-bit "random" number */
r = ((r >> 4) & 0x0FFFFFFF) / n;
</code>


thanks ahead of time

I think I know! This is a division by 0 error, so n would have to be 0 for this to cause a crash. If I'm looking at the right function, n is set to be 0x10000000 / m where m is the input. But m is a u32b value! So if m is larger than 0x10000000, n ends up being 0 and you get a crash. So I bet you are calling for a random number with an extremely large range somewhere.

This is, in fact, a "bug" in the random number generator code, but it's one that's avoided by an unwritten coding practice you must have violated.

[roustk]

This is, in fact, a "bug" in the random number generator code, but it's one that's avoided by an unwritten coding practice you must have violated.

It is a *documented* feature. The comments before the Rand_div() function include, at about line 117 (in 3.0.9b):

 * Note that "m" must not be greater than 0x1000000, or division
 * by zero will result.

It would probably behoove Will to check why his code is asking for a uniform draw from more than a quarter-billion values (28 bits)...

[Mangojuice]

It is a *documented* feature. The comments before the Rand_div() function include, at about line 117 (in 3.0.9b):

Ok, that's true. Of course, though, the code never calls Rand_div directly. The calls are all through calls to randint0 or rand_range, and their documentation doesn't mention this, or take steps to avoid the problem.

[will_asher]

It is a *documented* feature. The comments before the Rand_div() function include, at about line 117 (in 3.0.9b):

 * Note that "m" must not be greater than 0x1000000, or division
 * by zero will result.

It would probably behoove Will to check why his code is asking for a uniform draw from more than a quarter-billion values (28 bits)...

how would this happen? I certainly didn't put any randint(100000000) in there anywhere.

[Nick]

how would this happen? I certainly didn't put any randint(100000000) in there anywhere.

You should be able to do a backtrace in your debugger to find where the to the RNG is coming from.

[Mangojuice]

how would this happen? I certainly didn't put any randint(100000000) in there anywhere.

My guess is that either you used an uninitialized variable, or somehow you called the RNG with a negative value that wrapped around.

[will_asher]

Thank you, it appears to work now. The problem was a negative number.