[ck3D]

So I understand Mapster isn't specifically a priority to keep refining right now, and in all actuality, the recent builds are excellent enough that most of the time one will get stumped is going to be due to their own fault (e.g.. not knowing about a documented feature, or only understanding the internals so much). But every now and then, little practical issues do come up, and I couldn't find a thread where mappers may bring them up. I am not talking 'how about a full interface revamp' mass hysteria but really just specific practical points.

For instance I looked on the Wiki and I could not find a shortcut that would exist to (possibly?) turn off visible sector highlighting. This is a problem when manipulating SOS/TROR as soon as too many layers overlap, because then 2D mode often looks like this and in such conditions, seeing exactly where you are moving the sector(s) to is impossible and so results in any number of failed blind attempts/undo's/reloads (unless one TROR joins a part to automatically shift the structure, but as a requirement to do would be convoluted):



Or maybe it should be made that the highlighting doesn't add up the way it presently does, I don't know, just there is this weird problem that exists.

Another important request mappers have been communicating for a while really should be incorporated into mainline Mapster32 would be oasiz's 3D mode sector selection script (at the very least out of all of oasiz's scripts), it is such an absolute game changer that in itself it would make the engine easier to approach and tame by newcomers, and of course it makes an experienced mapper all the more efficient too but most of them already have adopted the script. So it is regrettable that it is one download/install away from the main tool that it complements so fundamentally. It is the one manipulation I'm pretty sure no one gets why it wasn't a thing in DOS Build in the first place, surely.

Doctors hate him (maybe).

[ck3D]

Another small problem another thread just reminded me to relay (even if I do not expect an actual fix, it is valid to put out there): some documentation such as the Infosuite states that there is a limit of moving sectors per map, which technically is incorrect since it is the number of walls that actually matters (e.g.. break the limit by one wall and a map just won't run, but it will again if you delete that one wall although the sector count remains the same). That is just a clarification in case a mapper ever comes to need it, but now an actual inconvenience with the editor is it doesn't ever show a tally for keeping track anywhere, and so one has no way of knowing how close they may be to that limit of moving walls but by being familiar and going by feel. I remember oasiz once told me it mostly was the game side checking that and so on the editor side could be made to check but that may be difficult (perhaps could be some kind of sector motion SE/ST detection then addition of the walls of the corresponding sectors?). It isn't an important issue since that limit is so high, only the most ambitious maps possible ever hit it anyway, but some kind of indicator of it technically is something that is missing.

[oasiz]

select sectors (i.e. with script in 3D), CTRL + R will set the Z range (min/max floor-ceiling of selected)

Now here is the good one... press CTRL ALT R to remove greyout.

You're welcome!

[Mark]

A few years ago I noticed and reported that the Mapster F11 selector had undergone a change. It was horribly whitewashing the screen after the first 2 levels and was useless. After the "fix" it still just whitewashed the screen but not as badly. That control's behavior used to help bring up visibility in a way that it would actually let you see things in dark places in the maps. Now it acts like only the brightness level is adjusting and it really does nothing to help see the map. In older Mapsters it seemed like gamma, contrast or other combos were getting adjusted too and F11 was useful. After seeing this new thread I decided to install the latest eduke and mapster to see how things are going years later. F11 still operates that same whitewashing way. This is using Polymost or Polymer. I didn't check software mode.

OR...Maybe I'm senile and mis-remembering the old F11 behavior. Nobody else back then or it seems now has ever mentioned the problem.

[Mark]

A feature I would to see added is being able to view the hardcoded Polymer lighting from things like flames, not just the SE lighting. Since the light radius for flames relies on the flame sprite's set size in mapster I have to go back and forth between eduke and mapster a number of times to test while getting the size/radius correct.

[oasiz]

Would this only be for actors?
Not textures on geo

[oasiz]

Ok, got info from discord..

Bad news I'm afraid.
tsprite fuckery was what I tried first but the editor doesn't really check for anything else besides SE49 and SE50 when doing light preview routines.
It seems that the only polymer lighting there is on editor side are those two SEs.

EDITOR: Light preview is done at

ExtPreCheckKeys(void)

, where it manually sets up both SEs as needed by initializing

spritelightptr[i]

as needed and stores the needed data there from there on.
GAME: Light preview works somewhat similarly to this, except since it's needed for so many things besides just the SE, it has a helper function

G_AddGameLight(int spriteNum, int sectNum, vec3_t const &offset, int lightRange, int lightRadius, int lightHoriz, uint32_t lightColor, int lightPrio)

that does this initialization. I found bunch of code inside

actors.cpp

for switches and various other active things so that's clear now.

However I don't exactly feel comfortable doing this change..
Since the 3D prekeys event has this on editor side, it shouldn't be too hard to introduce a CON command wrapper for something similar as

G_AddGameLight

which would combine the editor logic as well.

Hopefully someone would be willing to take a tackle on this.

[oasiz]

ck3D, on 11 January 2026 - 03:41 PM, said:

Another small problem another thread just reminded me to relay (even if I do not expect an actual fix, it is valid to put out there): some documentation such as the Infosuite states that there is a limit of moving sectors per map, which technically is incorrect since it is the number of walls that actually matters (e.g.. break the limit by one wall and a map just won't run, but it will again if you delete that one wall although the sector count remains the same). That is just a clarification in case a mapper ever comes to need it, but now an actual inconvenience with the editor is it doesn't ever show a tally for keeping track anywhere, and so one has no way of knowing how close they may be to that limit of moving walls but by being familiar and going by feel. I remember oasiz once told me it mostly was the game side checking that and so on the editor side could be made to check but that may be difficult (perhaps could be some kind of sector motion SE/ST detection then addition of the walls of the corresponding sectors?). It isn't an important issue since that limit is so high, only the most ambitious maps possible ever hit it anyway, but some kind of indicator of it technically is something that is missing.

Any script you want this amended in?
I think I found the place in source.

It counts all wallpoints for sectors containing:

            case SE_11_SWINGING_DOOR:  // Pivitor rotater
            case SE_0_ROTATING_SECTOR:
            case SE_2_EARTHQUAKE:      // Earthquakemakers
            case SE_5:                 // Boss Creature
            case SE_6_SUBWAY:          // Subway
            case SE_14_SUBWAY_CAR:     // Caboos
            case SE_15_SLIDING_DOOR:   // Subwaytype sliding door
            case SE_16_REACTOR:        // That rotating blocker reactor thing
            case SE_26_ESCALATOR:      // ESCELATOR
            case SE_30_TWO_WAY_TRAIN:  // No rotational subways

Which should be trivial.

[ck3D]

oasiz, on 19 January 2026 - 09:04 AM, said:

Any script you want this amended in?
I think I found the place in source.

It counts all wallpoints for sectors containing:

            case SE_11_SWINGING_DOOR:  // Pivitor rotater
            case SE_0_ROTATING_SECTOR:
            case SE_2_EARTHQUAKE:      // Earthquakemakers
            case SE_5:                 // Boss Creature
            case SE_6_SUBWAY:          // Subway
            case SE_14_SUBWAY_CAR:     // Caboos
            case SE_15_SLIDING_DOOR:   // Subwaytype sliding door
            case SE_16_REACTOR:        // That rotating blocker reactor thing
            case SE_26_ESCALATOR:      // ESCELATOR
            case SE_30_TWO_WAY_TRAIN:  // No rotational subways

Which should be trivial.

I appreciate your consideration of this, honestly regarding exactly how to exactly implement it you might as well be asking your left hand but whatever is easy to even just have a possibility of running that search automatically (... or I could finally learn scripting). Could imagine it as one more option to possibly (?) add to the ' F 2D mode menu (for instance) if ever integrated to mainline Mapster where it would belong ideally, but for now would be cool to have really anything that can automatically check on the results. And yes I can confirm from experience this must be the bit of code, I can recognize most sector types I've seen affect my own maps in practice, and it's cool to see a confirmation that movement in just the z axis (so SE31, SE32, piston etc...) seems spared from counting towards the tally, since thus far I suspected otherwise.

[oasiz]

Hi,

Give this one a go:

As usual, include it and `do calcmove`

// Movement calculator script

gamevar i 0 0
gamevar u 0 0
gamevar temp 0 0
gamevar temp2 0 0
gamevar walls 0 0

definequote 1 placeholder

defstate calcmove
    set walls 0
    for i allsprites {
        ife sprite[i].picnum 1 {
            switch sprite[i].lotag
                case 0
                case 2
                case 5
                case 6
                case 11
                case 14
                case 15
                case 16
                case 26
                case 30
                    set temp sprite[i].sectnum
                    set temp2 0
                    for u wallsofsector temp add temp2 1
                    add walls temp2
                    break
            endswitch
        }
    }
    redefinequote 1 This many walls refuse to stay in place: %ld / 1024
    qsprintf 1 1 walls
    quote 1
ends

Also cool menu, I'll add that to the pile of stuff I haven't seen before.
The thing is that I kind of need a modal menu like that but also want it to work in 3D. This would only be accessible at source level unfortunately
So far the game refuses to let me do things like that so I'm stuck to hotkeys that can't overlap with other functions for now..
Trying to find ways around this.

Yeah, Z movers are stored usually in the sprite itself, sector movers can't really store this much data in the map format so it's stored externally at the game side.

[ck3D]

oasiz, on 19 January 2026 - 01:29 PM, said:

Hi,

Give this one a go:

As usual, include it and `do calcmove`

// Movement calculator script

gamevar i 0 0
gamevar u 0 0
gamevar temp 0 0
gamevar temp2 0 0
gamevar walls 0 0

definequote 1 placeholder

defstate calcmove
    set walls 0
    for i allsprites {
        ife sprite[i].picnum 1 {
            switch sprite[i].lotag
                case 0
                case 2
                case 5
                case 6
                case 11
                case 14
                case 15
                case 16
                case 26
                case 30
                    set temp sprite[i].sectnum
                    set temp2 0
                    for u wallsofsector temp add temp2 1
                    add walls temp2
                    break
            endswitch
        }
    }
    redefinequote 1 This many walls refuse to stay in place: %ld / 1024
    qsprintf 1 1 walls
    quote 1
ends

Also cool menu, I'll add that to the pile of stuff I haven't seen before.
The thing is that I kind of need a modal menu like that but also want it to work in 3D. This would only be accessible at source level unfortunately
So far the game refuses to let me do things like that so I'm stuck to hotkeys that can't overlap with other functions for now..
Trying to find ways around this.

Yeah, Z movers are stored usually in the sprite itself, sector movers can't really store this much data in the map format so it's stored externally at the game side.

Well thanks a whole lot, I'll definitely run this the next time I need to check rather than guesstimate, maybe rewatch your tutorial and who knows, perhaps I'll actually develop some focus for learning scripting. But Mapster already is such a timesink as is. If I ever allowed myself any further down the rabbit hole that is coding in general I just might surrender my life over to mathematics already. But I am well aware that there is a point where both meet.

Mindblowing to me that you didn't know about the special functions menu (but we all find out about 'new' stuff all the time, that is just how rich the editor is), I thought it was rather common knowledge. It is plenty useful, being all global map manipulation tools that really do complement the intrinsic possibilities of the more typical shortcuts quite well (instead of relying on selection, you alter fundamentals). But I guess it is nothing you could not achieve just as fast mastering scripting. The rescaling tool works completely differently from the mouse click and drag one since it engulfs all of the axes including Z, even the textures get compressed to fit (and that is one way of getting around some normal stretching minimal limits).

[ck3D]

oasiz, on 16 January 2026 - 10:56 AM, said:

select sectors (i.e. with script in 3D), CTRL + R will set the Z range (min/max floor-ceiling of selected)

Now here is the good one... press CTRL ALT R to remove greyout.

You're welcome!

I just have to explicitly thank you for this, in part because I actually knew of those shortcuts but was using them wrong, essentially had never gathered that one had to select specific sectors for precision and so used to think all the tool did was vaguely rearrange 'player' Z position when already juggling between more or less apparent layers using I think Ctrl Q/A (depending on keyboard) and/or PgUp/Down. But this makes SOS/TROR an absolute breeze, tricks as basic as juggling between different map files in order to craft separate floors to then stack are out of the window pretty much. Posting just in case (an)other mapper(s) would be making the same mistake as mine or similar.

[quakis]

I also get the most out of CTRL + R by creating dummy sectors matching the floorz / ceilingz range I want to group up, then selecting the range I need from those.