Help me make my new variant! (please!)

[will_asher]

How do I know if it's writing beyond the boundaries of an array?
and How do I know what the boundaries are?

When I first started making DaJAngband, I just discovered the txt files in the lib folder (the subfolder was called something other than gamedata at that point), and changed some things and added some new monsters. I posted about making changes in the txt files on here, and someone suggested I make my own variant. I said I can't do that I know only the barest basics of C, but they said something to the effect of Oh it isn't hard, you can probably figure a lot of things out by the comments. So I looked at the code, and the comments were so thorough in saying what the code was doing, that I could figure out how to customize a lot of stuff in the code. I'm a meddler, not a programmer, but I made my own variant before. I can do it again (with the help of the nice people here).

[Pete Mack]

Eeek! The stack is the program's active memory-- when you subroutine gets called, it takes more space on the stack. Its memory is released when the routine exits. It also means the current set of subroutines that are active.
The heap is the program's long-term memory. It gets created and released in arbitrary order with malloc() (memory allocate) and free(). Each allocation has a fixed size, and if you write beyond it, your program eventually gets borked. There are two ways this commonly happens: writing beyond the boundaries of an array, and writing too long a string.

[will_asher]

Heap corruption means you borked the memory allocator, either with a write to freed memory, or with a buffer overrun. That particular error message suggests the debug allocator detected a buffer overrun, where you allocated insufficient space for a data structure. What does the stack look like at the time?

You're speaking a language I don't know here. What's a stack in this context? and where do I find it to see what it looks like?
(I know what borked means at least. I definitely borked something.)

[Pete Mack]

Heap corruption means you borked the memory allocator, either with a write to freed memory, or with a buffer overrun. That particular error message suggests the debug allocator detected a buffer overrun, where you allocated insufficient space for a data structure. What does the stack look like at the time?

[will_asher]

thank you.

well.
I found almost that exact problem with the ampersands. So I fixed it, recompiled, and I'm still getting the same error popup...
(except the "at 0x..." number is different)

[Nick]

What does this mean? It sounds bad.
I added a couple things to savefiles in the player struct, but I thought I did it right...

It's hard to know for sure, but my starting point would be the savefile changes. Look at exactly what you've changed, and see whether the syntax matches existing code - for example, you may have done something like

rd_byte(tmp8u)

instead of

rd_byte(&tmp8u)

[will_asher]

I broke something somehow.

I went to open the game and test something, it compiles, it starts to run, then after character creation, I get this popup error window:
"Debug error
HEAP CORRUPTION DETECTED: after normal block (#213273) at 0x054BB1B8.
CRT detected that the application wrote to memory after end of heap buffer."

What does this mean? It sounds bad.
I added a couple things to savefiles in the player struct, but I thought I did it right...

[Nick]

Finding some kind of interesting things in the code I didn't know about before...

At the top of blow_effects.txt, it says:
"# eval - used for power evaluation in eval_blow_effect()"
But there is no eval_blow_effect(), and the eval appears to be unused.

Nice catch. That has been unused since we stopped calculating monster power in 4.0.

Also, in mon-blows.c, I noticed armor reduces damage only for attacks that HURT, SHATTER, and partially for elemental attacks, but not any other blow effect.

Why is this?

(Also, is this why several high-level giants and such HIT to CONFUSE instead of HURT?)

Tradition

I guess the original idea was that other blow effects are more about the effect than the damage. Clearly that principal is not universal any more - as you say, CONFUSE blows often do a lot of damage, as do some high level DISENCHANT blows.

[will_asher]

Finding some kind of interesting things in the code I didn't know about before...

At the top of blow_effects.txt, it says:
"# eval - used for power evaluation in eval_blow_effect()"
But there is no eval_blow_effect(), and the eval appears to be unused.

Also, in mon-blows.c, I noticed armor reduces damage only for attacks that HURT, SHATTER, and partially for elemental attacks, but not any other blow effect.

Why is this?

(Also, is this why several high-level giants and such HIT to CONFUSE instead of HURT?)

[will_asher]

Okay then. I can live with it. It just makes things a little harder for me.

[Pete Mack]

Will--
Putting data in configuration files is standard software practice. The types of spells (ball, beam, status effect, etc) are coded, but the spells themselves are not. This gets rid of enormous case blocks, which are not actually easy to read, and cut-and-paste programming, which is also a no-no. (Among other issues, it's a pain to test.)

[will_asher]

I want to add that changing some things, like adding new types monster spells, seems a lot more complicated now (at least for someone like me who isn't fluent in C) than it used to be before more things were put in the gamedata txt files.

EDIT: Also, I'm having a really hard time figuring out how to make pCONF a partial resist instead of completely immunity (only against CHAOS and a stronger confusion effect, won't be partial against the normal CONF spell or attack).

[Nick]

I already made a new player flag for it...

Right, that would also work.

[will_asher]

If you wanted to do this, you could mimic the way the code does it for shapes - add a modifiers entry to struct player_race, parse as in parse_shape_values(), copy the way calc_shapechange() handles modifiers into calc_bonuses(), probably add something in ui-entry.c for character sheet display. Or you could add it as another skill, like searching and digging.

I already made a new player flag for it...

[Nick]

the explanation at the top of p_race says:
# 'values' is for object modifiers which take a value that races possess
# innately.
But the code only reads "RES_" values, so if you want to make a player race with innate extra speed, you have to do it another way. ppfffflt.

If you wanted to do this, you could mimic the way the code does it for shapes - add a modifiers entry to struct player_race, parse as in parse_shape_values(), copy the way calc_shapechange() handles modifiers into calc_bonuses(), probably add something in ui-entry.c for character sheet display. Or you could add it as another skill, like searching and digging.