Angband Forums

Angband Forums (http://angband.oook.cz/forum/index.php)
-   Variants (http://angband.oook.cz/forum/forumdisplay.php?f=4)
-   -   Angband coding question (http://angband.oook.cz/forum/showthread.php?t=928)

will_asher August 29, 2008 05:58

Angband coding question
 
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 August 29, 2008 06:24

Quote:

Originally Posted by will_asher (Post 9762)
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 August 30, 2008 01:52

thanks, that's what I needed to know

will_asher August 31, 2008 06:51

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 August 31, 2008 07:00

Quote:

Originally Posted by will_asher (Post 9827)
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 August 31, 2008 07:49

Quote:

Originally Posted by Mangojuice (Post 9829)
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):
Code:

* 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 August 31, 2008 14:06

Quote:

Originally Posted by roustk (Post 9834)
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 September 2, 2008 06:27

Quote:

Originally Posted by roustk (Post 9834)
It is a *documented* feature. The comments before the Rand_div() function include, at about line 117 (in 3.0.9b):
Code:

* 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 September 2, 2008 06:35

Quote:

Originally Posted by will_asher (Post 9886)
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 September 2, 2008 07:06

Quote:

Originally Posted by will_asher (Post 9886)
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.


All times are GMT +1. The time now is 10:45.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.