Help me make my new variant! (please!)

[will_asher]

You didn't deliberately change it, but you did in fact change it. In fact you accidentally changed a whole bunch of files no doubt, take a look at the file list in this commit:

https://github.com/will2asher/RubberBand/commit/820fbec145a3926edc7c43fb5271eef4255a0a49#diff-1ee747d08cd0541b263a7a0c4dcd7a2e230a5fdf7d59db57d55ab654b8bf0c2e

As far as I can see you've:

downloaded a copy of angband
Nick has updated dungeon_profile.txt
you've uploaded the older version of dungeon_profile.txt

So is there an easy way to get the changes Nick made added to my fork? or do I have to do it manually from the diff?
EDIT: Well, I guess I can just download the newer dungeon_profile.txt. I'll try that.

For that matter, how did my fork get the changes Nick made (that require an updated dungeon_profile.txt) without getting the updated dungeon_profile.txt?

Also, how do you make a diff like that between two files on github?

EDIT: It runs now, yay!
thanks for your help

EDIT2/PS: Is old_class.txt still used/needed?

[wobbly]

For that matter, how did my fork get the changes Nick made (that require an updated dungeon_profile.txt) without getting the updated dungeon_profile.txt?
thanks for your help

So while its hard for me to tell exactly what went wrong, when I look at the last commit to dungeon_profile.txt in angband-master and compare it to your commit on ruberband, I can see that you accidentally reversed Nick's changes. This suggests to me that the version you are working with on your PC is older then the version you forked on github. Either its an older copy of angband-master or its a copy of angband 4.2-release.

As to how Nick's changes got there, you forked angband-master on github a month ago and the changes have been in master for 4 months.

[will_asher]

Huh. I thought I had cloned the angband-master when I made a fork on github. I guess not. Is there a relatively easy way to get Nick's changes into the code on my computer?

EDIT/PS: I'm currently playing my pre-alpha build, and it's acting like there's a movement delay even though I made sure movement delay and base delay factor were set to zero. Can anyone guess why that is?

Also, will it break anything if I increase the backpack slots in constants.txt by 1? (I'm guessing it'll likely break savefiles, so I'll finish my current game before I try it.)

[backwardsEric]

Also, will it break anything if I increase the backpack slots in constants.txt by 1? (I'm guessing it'll likely break savefiles, so I'll finish my current game before I try it.)

Besides the save file (loading one generated with a larger pack limit should be okay, but the load code isn't set up to explicitly handle the pack overflow that could happen), there's how the pack is presented in the user interface: the current limit is one less than the minimum expected height for the main window, 24 rows. With the main window at the minimum height and a full pack of 24 items, displaying the inventory won't show the last item in the pack.

[will_asher]

Besides the save file (loading one generated with a larger pack limit should be okay, but the load code isn't set up to explicitly handle the pack overflow that could happen), there's how the pack is presented in the user interface: the current limit is one less than the minimum expected height for the main window, 24 rows. With the main window at the minimum height and a full pack of 24 items, displaying the inventory won't show the last item in the pack.

I could just increment the minimum height of the main window to match.

[will_asher]

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.

Anyway, I've been busy on Rubberband development. I'll probably make a release sometime soon. currently in the process of adding a couple new player races.

[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.

[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]

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

Right, that would also work.

[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).

[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]

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

[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?)

[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]

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...