Implementing the restructure changes

[Nick]

On the question of INTERESTING vs NORMAL - do you think that either FLOOR or (less likely) EASY is capturing what you are after with NORMAL? I mean this regardless of where they're used incorrectly.

[AnonymousHero]

Two issues with that:

1. The diff will be so large (with so many filename changes) that it is unlikely to be useful
2. PowerWyrm is our most powerful debugging tool - please don't interrupt him while he's operating

Heh. I think it should be noted that, as long as the files remained mostly the same, git/GitHub will actually detect renamed+modified files, so it might be okay to just do a full diff. Then again, it might not.

[Nick]

Rather than going commit-by-commit and manually rebasing your variant off of Vanilla, you might have better luck looking at the diff of restruct Vanilla vs. pre-restruct Vanilla. That would save you from having to implement each bug and then each bug fix as separate tasks.

Two issues with that:

1. The diff will be so large (with so many filename changes) that it is unlikely to be useful
2. PowerWyrm is our most powerful debugging tool - please don't interrupt him while he's operating

PowerWyrm: Thanks for those. The bug tracker now has a milestone for 4.0 which we are using if you want to, but reporting in this thread is also good, it's up to you.

Am I correct in assuming that these errors are still in place in the current state of the code? Some things have been revisited later.

[Derakon]

Rather than going commit-by-commit and manually rebasing your variant off of Vanilla, you might have better luck looking at the diff of restruct Vanilla vs. pre-restruct Vanilla. That would save you from having to implement each bug and then each bug fix as separate tasks.

[PowerWyrm]

This week I decided to start implementing all the changes from the restructure to my variant. At this point, there are 35 pages of commits to browse, analyze and implement... and it took me already three days to tackle the first five commits. Needless to say it's gonna take ages...

Anyway, I'm going to post here all the oddities I find along the way. Please tell me if they have been fixed in the latest version of the code.

Commit f2cf3e5 (Implement trap layer):

* the minimum level of some traps has been changed: stat draining darts were minlevel 6, now 2; confusing gas traps were minlevel 1, now also 2; sounds like a copy/paste error

* rubble was not "BORING", it should probably be "INTERESTING"

* square_destroy_trap(): passing "c" as cave parameter, but using the static variable "cave" instead (see also: square_trap_specific)

* cave illumination/darkening has been completely broken when introducing the "INTERESTING" flag; before the restructure, there were two symmetrical bits of code, "feat > FEAT_INVIS" and "square_isinteresting"; this commit broke the symmetry by changing square_isinteresting() to features implementing the INTERESTING flag, which are completely different; this is particularly obvious for a variant that has other floor tiles (dirt, grass, water...) and non-floor tiles (trees, mountains...), which with the new code are memorized/forgotten incorrectly when lit/unlit; IMO there is a confusion between "interesting" and "normal" features here -- the "interesting" flag should be used for targeting code only (there's also a "square_isboring" function used there with a negation, which is completely pointless, "square_isinteresting" should be used instead), and the "normal" flag should be used everywhere else (for lighting/unlighting purposes)

In the code:
wiz_light(): uses "normal" flag (correct)
cave_illuminate(): uses "normal" flag (correct)
project_f(), GF_DARK effect: uses "interesting" flag (incorrect, should use "normal" flag)
map_area(): uses "interesting" flag (incorrect, should use "normal" flag)
cave_unlight(): uses "interesting" flag (incorrect, should use "normal" flag)
target_set_interactive_accept(): uses "interesting" flag (correct, but use "square_isinteresting" instead of the useless "square_isboring" function)