[The Mechanic]

In ye olde Build, when you had a wall with a hole in it i.e. had both an upper and lower section, you had to change the wall's orientation with the 'O' key for the auto-align to work. However this is busted in mapster.

The problem appears that when auto-aligned, the wall inherits some of the cstat flags from the start wall - kinda logical if you consider basic walls, however this knackers split walls

Commenting out (build.c, circa line 10906) :

                wall[w1b].cstat &= ~ALIGN_WALLS_CSTAT_MASK;
                wall[w1b].cstat |= cstat0;

proved the point as now it worked like ye olde build. It isn't of course a solution so instead I modified ALIGN_WALLS_CSTAT_MASK:

#define ALIGN_WALLS_CSTAT_MASK (8+256) // Originally (4+8+256)

Et voila, it works ! It seems to work regardless of whether the first wall is top or bottom aligned.

Perhaps a proper fix would be to see when a wall had both top and bottom parts visible and if so force cstat bit 2 to '1' regardless - but I haven't figured out how to detect if top and bottom walls both visible.

TTFN,
Jon

Attached thumbnail(s)

• 

[The Mechanic]

OK, after delving further - my head hurts! - I've simply added added the following code in build.c circa line 10900:

    wall[w1b].cstat &= ~ALIGN_WALLS_CSTAT_MASK;
    wall[w1b].cstat |= cstat0;
				
   // [JE]
   if( IS_DOUBLE_SIDED_WALL(w1b) )
   {
      wall[w1b].cstat |= 4;
   }
   // [/JE]

and

//[JE] Ref: GetWallBaseZ uses nextsctor=-1 to detect single sided walls
//    move to editor.h ?
#define IS_DOUBLE_SIDED_WALL(wall_num) (wall[wall_num].nextsector!=-1)
// [/JE]

Not sure if this has any other repurcussions (TROR for example), but seems to fix things for the standard use cases.

TTFN,
Jon

PS: Cool ! I think I've also spotted some residual code from stuff I did well over ten years ago.

[TerminX]

The Mechanic, on 05 August 2015 - 01:30 PM, said:

PS: Cool ! I think I've also spotted some residual code from stuff I did well over ten years ago.

?

[The Mechanic]

TerminX, on 05 August 2015 - 02:20 PM, said:

?

Yep. Many years ago - at least 10, I couldn't even be sure what derivative of Build it would have been - I added a facility to select tiles based on groups ('T' key whilst viewing tiles). It would, however, have had hard-coded groups at the time - the use of a tiles.cfg wouldn't have been me, though it is this config file that I've found makes this facility so useful.

The codebase has of course moved on considerably, but what makes me think "I was there!" in the current code base is illustrated by this (astub.c, circa line 3276) :

    //
    //	Await appropriate selection keypress.
    //

    bDone = 0;

    while (keystatus[KEYSC_ESC] == 0 && !bDone)
    {
        if (handleevents())
            quitevent = 0;

        idle_waitevent();

        //
        // Display the description strings for each available tile group
        //
        for (i = 0; i < tile_groups; i++)
        {

Specifically the multi-line comments, plus the use of spaces in expressions etc, even the variable naming (e.g. bDone, tile_groups) which is not the typical coding style of the main code but very much how I coded at w*rk .. at the turn of the century (god I feel old).

Another thing I do remember was the team were using some kind of version control even then which I was too dumb to be able to use, so I would have submitted code as a mix of a seperate file (new funcs) or comments "[JE]" where existing files were moded leaving the team member(s) to manually put my mods in - bet that was popular !

Happy days.

TTFN,
Jon

[TerminX]

The Mechanic, on 05 August 2015 - 11:28 PM, said:

Yep. Many years ago - at least 10, I couldn't even be sure what derivative of Build it would have been - I added a facility to select tiles based on groups ('T' key whilst viewing tiles). It would, however, have had hard-coded groups at the time - the use of a tiles.cfg wouldn't have been me, though it is this config file that I've found makes this facility so useful.

The codebase has of course moved on considerably, but what makes me think "I was there!" in the current code base is illustrated by this (astub.c, circa line 3276) :

    //
    //	Await appropriate selection keypress.
    //

    bDone = 0;

    while (keystatus[KEYSC_ESC] == 0 && !bDone)
    {
        if (handleevents())
            quitevent = 0;

        idle_waitevent();

        //
        // Display the description strings for each available tile group
        //
        for (i = 0; i < tile_groups; i++)
        {

Specifically the multi-line comments, plus the use of spaces in expressions etc, even the variable naming (e.g. bDone, tile_groups) which is not the typical coding style of the main code but very much how I coded at w*rk .. at the turn of the century (god I feel old).

Another thing I do remember was the team were using some kind of version control even then which I was too dumb to be able to use, so I would have submitted code as a mix of a seperate file (new funcs) or comments "[JE]" where existing files were moded leaving the team member(s) to manually put my mods in - bet that was popular !

Happy days.

TTFN,
Jon

Aha. I do remember accepting that as a patch a very long time ago. You used to post on the old 3DR forums, right?

[The Mechanic]

TerminX, on 06 August 2015 - 01:53 PM, said:

Aha. I do remember accepting that as a patch a very long time ago. You used to post on the old 3DR forums, right?

I'm afraid I can't remember, it is so long ago. It may well have just been via email ?

Out of curiosity, is there a pending list of bugs or feature requests for Mapster32 ?

Quite funny really, one of the other "bugs" I was going to fix was when using "save as", mapster didn't save the new map in the original map's directory. So, this morning I sat down and started single stepping through the code ... only to find it now worked ! Seems fixed in r5308 but it was bust in r5265 I'd been using. Bit of a coincidence as I'm guessing there is less than a month between the two builds?

TTFN,
Jon

[Helixhorned]

I agree with your general conclusion to prefer bottom-aligned walls for auto-alignment. Playing around with it in E1L1 a bit shows that it's ill-behaved for top-aligned walls. Actually, Mapster32 warns if the base wall is top-aligned (since r3396), but I guess that completely goes under in the course of editing. The change to carry over bit 1<<2 from the base wall to the auto-aligned ones goes back to r1882 -- in the course of TROR development -- so I guess it had a reason related to TROR. I think I recall similar reports from mappers, so if the current behavior is perceived as a big nuisance, I'd be happy to revert it. However, I'd like to find out the reason I did it this way first.

[The Mechanic]

Helixhorned, on 07 August 2015 - 12:02 PM, said:

I agree with your general conclusion to prefer bottom-aligned walls for auto-alignment. Playing around with it in E1L1 a bit shows that it's ill-behaved for top-aligned walls. Actually, Mapster32 warns if the base wall is top-aligned (since r3396), but I guess that completely goes under in the course of editing. The change to carry over bit 1<<2 from the base wall to the auto-aligned ones goes back to r1882 -- in the course of TROR development -- so I guess it had a reason related to TROR. I think I recall similar reports from mappers, so if the current behavior is perceived as a big nuisance, I'd be happy to revert it. However, I'd like to find out the reason I did it this way first.

I noticed the warning message (though not immediately) - but mis-interpreted it. At first I thought it was warning me about the two-sided wall that I just edited. Then I got to ignore it simply because if you start a brand new map, create a single box and do nothing else the warning still came up so thought maybe it was a bug. It didn't help that I incorrectly thought I needed to set top/bottom walls to swapped (the '2' key) for alignment to work in which case it never aligns even with my mod (or, indeed, in ye olde build.exe), but it's clear now that would only be an issue if someone wanted a different upper texture whilst keeping the lower the same as the preceding wall - an unlikely scenario.

Having tested further, one issue my mod would create is if you made a gap in a wall and made that into a door (ST20) - as might be the case for opening up a secret area - then my forcing the orientation on two sided walls would mean the texture didn't move as the "door" rises. I guess I should add code NOT to force bit 2 for walls attached to a zero-height sector?

The reason I asked about any pending list of bugs/feature requests for mapster32 is two fold. Firstly, of course, I have a list of things I'd like , but secondly perhaps I could have a bash at doing some of the easier ones ? I've discovered todo.txt in the downloaded source and I'd certainly like to up-vote "New walls being added in BUILD should NEVER be masked or blocking" and "Type tags in hex" (or better still a menu but that might be a bit too ambitious for now). As I go though the code I'm adding comments for my own benefit but maybe that documentation might be useful to feed back ?

TTFN,
Jon

PS Unlike the old days, I'm fully svn-ised now

[Hendricks266]

The Mechanic, on 08 August 2015 - 01:20 AM, said:

I've discovered todo.txt in the downloaded source

That, like the rest of build/doc/, is a historical document from Ken.

[The Mechanic]

Hendricks266, on 08 August 2015 - 12:03 PM, said:

That, like the rest of build/doc/, is a historical document from Ken.

Oh. So I guess there isn't a list of pending bug / features then ?

Anyhow, the offer is there, if you wan't me to tackle any of the easier / mundane mods while you all get on with the main ones them I'm willing to have a bash. I'm thinking specifically of Mapster32.

TTFN,
Jon