Implementing the restructure changes

[Carnivean]

No, because the txt files are tied to game core, not game preferences. You cannot let players choose core properties like object or monster flags, it would make no sense (player edits monster.txt, set Morgoth hp to 1...).

I should have been clearer, I meant just for the display properties that you were talking about.

[Nick]

Before the commit that nuked tval_to_attr, the default attr for inventory display was put into a pref file (font-xxx.prf), which clearly could be changed by the player. All other info bits, especially breakage chance and object flags, are clearly game core info and should NOT be changed by the player.

For my variant's perspective, the font-xxx.prf info was parsed on the client and transmitted to the server, which then used that info to display items in inventory for each player. The object_base.txt info was parsed on the server and therefore was used for all players.

I consider this a bug to be fixed - presumably by restoring font-xxx.prf and a function equivalent to tval_to_attr.

[PowerWyrm]

Currently implementing the removal of the FEAT_WALL constants in profit of SQUARE_WALL flags. Found a little error in mutate_cavern(): FEAT_WALL_SOLID was replaced by FEAT_GRANITE, but square_set_feat was not replaced by set_marked_granite, so the SQUARE_WALL_SOLID flag is never set. The code should probably be:

    for (y = 1; y < h - 1; y++)
    {
        for (x = 1; x < w - 1; x++)
        {
            if (temp[y * w + x] == FEAT_GRANITE)
                set_marked_granite(c, y, x, SQUARE_WALL_SOLID);
            else
                square_set_feat(c, y, x, temp[y * w + x]);
        }
    }

[PowerWyrm]

The draw_rectangle() method is badly written (and there's a nice typo), considering that generate_mark() already iterates on a rectangular area. It should be:

    for (y = y1; y <= y2; y++)
    {
        square_set_feat(c, y, x1, feat);
        square_set_feat(c, y, x2, feat);
    }
    if (flag)
    {
        generate_mark(c, y1, x1, y2, x1, flag);
        generate_mark(c, y1, x2, y2, x2, flag);
    }

    for (x = x1; x <= x2; x++)
    {
        square_set_feat(c, y1, x, feat);
        square_set_feat(c, y2, x, feat);
    }
    if (flag)
    {
        generate_mark(c, y1, x1, y1, x2, flag);
        generate_mark(c, y2, x1, y2, x2, flag);
    }

[Nick]

Thanks, done and done.

[PowerWyrm]

Finished implementing the SQUARE_WALL_INNER/OUTER/SOLID flags for dungeon generation. I need to check vs the old dungeon generator, but I think the method that builds the tunnels is broken with the new system. I've seen many times tunnels "eating" part of rooms, especially corners/outer walls. No idea what is the cause though...

[Nick]

Finished implementing the SQUARE_WALL_INNER/OUTER/SOLID flags for dungeon generation. I need to check vs the old dungeon generator, but I think the method that builds the tunnels is broken with the new system. I've seen many times tunnels "eating" part of rooms, especially corners/outer walls. No idea what is the cause though...

Have you got all the updates? IIRC I played with some different tunnel and layout generation before settling back to the original.

[PowerWyrm]

Nevermind. I've made more tests and the dungeon generator seems fine. There is just a small problem with some vaults that have no "outer" walls such as #6 (turnabout) and #8 (central), which are now disconnected from the rest of the level. Adding outer walls like for all other vaults fixes the problem.

[PowerWyrm]

Looking at the code, I think there's a problem with how the old PERM_INNER walls are now handled. PERM_INNER (permanent walls inside vaults) are treated like all other permanent walls and skipped when building a tunnel; this makes escaping a huge vault a challenge for the dungeon generator; fix: add a SQUARE_WALL_INNER flag to the wall and accept SQUARE_WALL_INNER permanent walls when building a tunnel.

[PowerWyrm]

Nevermind. I've made more tests and the dungeon generator seems fine. There is just a small problem with some vaults that have no "outer" walls such as #6 (turnabout) and #8 (central), which are now disconnected from the rest of the level. Adding outer walls like for all other vaults fixes the problem.

It would be probably a good thing to redraw all the rooms and vaults to allow outer walls only near the entrances of the vaults/rooms. Sometimes a huge vault has only one entrance made of granite and you have to dig 50+ squares to reach it because the tunnel was generated on the other side of the vault.

[PowerWyrm]

I've implemented everything up to the command framework rewrite. Now everything crashes during dungeon generation/deallocation.

1) Dungeon generation crashes when creating a trap due to bad comparison with z_info->l_max instead of cave->trap_max and using a non-standard way of allocating a new trap. Temporary fix: code a trap_pop() method similar to o_pop and mon_pop and use that instead. Fixed in recent V with linked list.

2) Dungeon deallocation crashes when there's a mimic (undiscovered) on the level due to the fact that the object linked to the mimic has already been wiped and we try to delete it again with a bad index. Temporary fix: call wipe_mon_list before wipe_o_list. Fixed in recent V (dunno how, but summoning a mimic and leaving the level didn't crash).

3) Dungeon generation crashes with labyrinths and caverns due to an assertion on cave->height/width because level is filled with permawalls after setting height and width. Temporary fix: fill the level before setting dimensions. Fixed in recent V with cave_new having height/width parameters.

This is really going slowly. Still more than a year of restructure changes to implement...

[Nick]

This is really going slowly. Still more than a year of restructure changes to implement...

Sorry. It gets better...

[AnonymousHero]

Sorry. It gets better...

QFT. (Lollerskates.) PowerWyrm, I'm sorry about the pain, but... yeah, it doesn't get much better from here.

[PowerWyrm]

Currently implementing the new dynamic cave generation... and at this point I'm suffering from the fact that my variant has an array of generated levels, and all generation routines have been modified to take a player pointer parameter instead of a cave pointer parameter.

Old code:

function foo_inner(player)
{
  cave = cave_get(player)
  play_with(player, cave)
}

function foo_generate(player)
{
  foo_inner(player)
}

With the new system, the "cave" pointers are generated "on the fly", so most of the generation functions take a "cave" parameter:

function foo_inner(player)
{
  cave = cave_get(player)
  play_with(player, cave)
}

function foo_generate(player, new_cave)
{
  foo_inner(player)
}

The problem here is that "new_cave", the newly generated cave, is the only pointer defined during cave generation. So the code in foo_inner() crashes because at this point, the "cave" pointer is NULL. So I need to browse all the code and add a "cave" parameter to all functions that need to access the cave array and that are called during cave generation:

function foo_inner(player, cave)
{
  play_with(player, cave)
}

function foo_generate(player, new_cave)
{
  foo_inner(player, new_cave)
}

I bet this is going to be fun...

[Nick]

Currently implementing the new dynamic cave generation... and at this point I'm suffering from the fact that my variant has an array of generated levels, and all generation routines have been modified to take a player pointer parameter instead of a cave pointer parameter.

Have you seen yet that V now has an array of generated levels too? It's called the chunk_list, and so far it only saves the town and restores it, but I imagine you could use it.

I don't think that helps with your current problem, though.