[Mike Norvak]

jimbob, on 26 January 2024 - 01:48 PM, said:

would there be a way, a easy way to spawn enemies after a delay? i think the two way train method could work, but i need to spawn 5 small waves and making 5 trains is just too much really.

There was an easy way involving using the delay bit in a gate sector with an activator triggering the respawn

https://infosuite.du...ae_doors_nomap1

I don't exactly remember the details or who came with the idea sorry. I remember using it in my map, you can check the effect there. It's some big triangles outside the playable zone, you'll figure it out, is really easy to set up.

https://dnr.duke4.ne...shade_Army.html

[lllllllllllllll]

Sometimes (or maybe just this time) splitting a giant sector makes things worse.
Doing it on the map I'm working on introduced more visual glitches in sectors that were fine before and fixed none. But merging them back together after the split fixed both the new glitches and the first set.

That sector is the big one wrapping around one end of the ship here like a square 'A' inside the perimeter of giant trapezoids. With no changes to the walls or vertices and merely splitting this sector into 3 it caused the center area of the ship to become visually unstable ingame. Merging those 3 sectors back into 1 resolved all the visual errors ingame even though they were still visible in mapster until closing it. [Joining, not Undo]

It may just be a consequence of that huge sector in turn being surrounded by huge sectors with blue walls though.

[Aleks]

jimbob, on 26 January 2024 - 01:48 PM, said:

would there be a way, a easy way to spawn enemies after a delay? i think the two way train method could work, but i need to spawn 5 small waves and making 5 trains is just too much really.

Use targets/shooters - the touchplate/switch whatever you want to trigger the wave activated a delayed masterswitch in an "out of bounds" sector which after the delay activates a shooter shooting a shrinker projectile at a target, which activates the respawns. You can check the out of bounds stuff in the bottom left corner of Simpler Times, requires just 3 walls really since you can virtually set the sectnum of masterswitches and shooters in any other sector (providing it has a low enough floor/high enough ceiling) and have it work in the "dummy" sector.

[lllllllllllllll]

Another visual glitch I ran into related to huge sectors is the walls splitting groups of smaller sloping sectors within appear to flicker into view even though they are not actually visible.
A wall being just barely visible because of a sloping sector is easy to hide by applying a corresponding texture & shade to where it is showing up, but with seam brought on by the presence of the huge sector it is not the wall splitting the smaller sectors that is being seen. It is the wall(s) of the huge sector. Shading & texturing that huge sector's walls resolves the problem.

[ck3D]

lllllllllllllll, on 27 January 2024 - 12:13 PM, said:

Sometimes (or maybe just this time) splitting a giant sector makes things worse.
Doing it on the map I'm working on introduced more visual glitches in sectors that were fine before and fixed none. But merging them back together after the split fixed both the new glitches and the first set.

That sector is the big one wrapping around one end of the ship here like a square 'A' inside the perimeter of giant trapezoids. With no changes to the walls or vertices and merely splitting this sector into 3 it caused the center area of the ship to become visually unstable ingame. Merging those 3 sectors back into 1 resolved all the visual errors ingame even though they were still visible in mapster until closing it. [Joining, not Undo]

It may just be a consequence of that huge sector in turn being surrounded by huge sectors with blue walls though.

That is true, I forgot to mention as it's happened to me a lot less but I've also fixed issues by deleting sector splits before, map boundaries in particular seem a lot less prone to glitching out when it's just one giant sector containing the whole of the map (surprised me too at first, but I guess that's because then the player technically can't view the bulk from outside in). I still insert my 'preemptive' vertices all along so while the sector itself ends up gigantic, every single of its walls technically is relatively short.

The bug from your example is something I run into a lot, at this point it's basically trial and error, sometimes the engine prefers broken up sectors, sometimes it prefers the same structure(s) wrapped up in a whole block, seems dependent on the construction itself but that also means the quirks of the level and what's possible to go wrong in possible views and angles. Usually in such cases feels like it's the ability of the engine to render around a structure all the while encountering splits vs. not that struggles and when one scenario doesn't work then the other one will. In general I feel like Build needs clean breathing space whenever it's supposed to show the back of/around/behind encapsulated blocks of maps, usually those are the zones to rework, but sometimes is a wrong portal that's inside.

Then there also is the different problem that isn't just visual (but of course also is) of the engine suddenly failing to detect certain loops after manipulating/creating sectors or loops and so then depending on angle it will either show the sector bulk correctly as belonging to its parent, or not at all as if it always had been dissociated independent space that isn't meant to appear there, so practically flickers in and out (feels like the embryo stage of the 'inverted sectors' bug). In most of those situations, connecting the spaces again with new red lines will recreate/check/force the proper loops, and then those new splits usually are free to go again once the order has been reestablished and the map saved.

Slope behavior info could be extremely useful to know, thanks for pointing that out. I don't know if I ever would have even considered something like that by myself whilst debugging but makes sense now that you say it.

[Šneček]

I was wondering if any of you have a new type of laptop and it is missing the scroll lock key, how does it handle setting the start position in mapster or build? Has anyone encountered such a problem?

[Forge]

Šneček, on 04 February 2024 - 07:12 AM, said:

I was wondering if any of you have a new type of laptop and it is missing the scroll lock key, how does it handle setting the start position in mapster or build? Has anyone encountered such a problem?

go to the bottom of the mapster32.cfg file and remap the key

[zazo]

Hello everyone,

My question concerns an ergonomic problem under mapster 32: in particular when working on wide open areas with high definition textures, there is a lot of lag and slowdown in the navigation in the 3d view, as well as a long switching time from the 2d view to the 3d view ("enter" key): it seems that mapster32 is struggling to recalculate or recache textures ?...
Is it possible to configure mapster32 to reduce all these lag / delay ?
Thank you a lot !

[Mark]

I ran across this problem years ago. It was caused by me naming the folder of my hi res content "textures" ( without the quotes )
This confused mapster and so it didn't produce a textures cache file to speed up loading times.

[zazo]

Mark, on 23 April 2024 - 08:30 AM, said:

I ran across this problem years ago. It was caused by me naming the folder of my hi res content "textures" ( without the quotes )
This confused mapster and so it didn't produce a textures cache file to speed up loading times.

Hmmm, it seems my mapster don't create a textures cache...
My eduke3d create such a file when loading map, but when i erase the cahce file, and then use mapster and close it, i don't see any renewed textures cache file...
how could i enable the cache for mapster to speed up the thing ?
(Also, i tried to rename the "textures" folder, but the problem remains...)

[Mark]

I'm not real smart about this stuff but check in the mapster.cfg file if there is a line for texture cache= ?

[lllllllllllllll]

Spawning sprites with certain floor aligned textures targeted can make them pop up inside nullspace in a wall outside of the current grid & 3d views and without realizing this I kept thinking I was hitting the wrong key. Luckily I caught it in orthographic view.
I was wondering if you can jump to sprites that are not inside playable space? It did not make any corruption warnings.

zazo, on 23 April 2024 - 09:01 AM, said:

Hmmm, it seems my mapster don't create a textures cache...
My eduke3d create such a file when loading map, but when i erase the cahce file, and then use mapster and close it, i don't see any renewed textures cache file...
how could i enable the cache for mapster to speed up the thing ?
(Also, i tried to rename the "textures" folder, but the problem remains...)

Cachesize too small?

[Forge]

zazo, on 23 April 2024 - 09:01 AM, said:

Hmmm, it seems my mapster don't create a textures cache...

it won't make a texturecache, or texturecache.index file if you're running it in software mode.

now i want to see the mapster32.log file contents and check how old the abacus is that you're running the program on, if you're getting lag in 8bit

[lllllllllllllll]

Beware there's a bug with shade preview (in versions up to 2023 at least) that can change floor+ceiling+sprites shades to the light effector's shade after it is toggled off. It reset the pal of battlelord sentries to 0 in the affected sectors so that was a fun trip too.

Light Switch with 16 light / 20 shade --> 16 shade pal0
Random Lights After Shot Out with 25 light / 8 shade --> 25 shade

[ck3D]

lllllllllllllll, on 23 June 2025 - 07:13 PM, said:

Beware there's a bug with shade preview (in versions up to 2023 at least) that can change floor+ceiling+sprites shades to the light effector's shade after it is toggled off. It reset the pal of battlelord sentries to 0 in the affected sectors so that was a fun trip too.

Light Switch with 16 light / 20 shade --> 16 shade pal0
Random Lights After Shot Out with 25 light / 8 shade --> 25 shade

I've noticed and reported this too - oasiz has said they were aware and it's an oversight. In my case it only would affect one sector in the map where I detected it - sector 272 (so I imagine it must be some bitfield madness since that's 256 + 16). Is that the case in your map too, if it happened to be consistent like that then at least would mean it easily can be checked on and shading in that specific sector should be saved for the map finalization stage.

[lllllllllllllll]

It's the same each time. I still think the shade of the effector is a culprit in some way. A cluster of sectors 823-833 with their shade/light inverted are getting affected by it. The other lone sector was 573 (512+32+16+8+4+1) and even though it is in a cluster of similarly lit sectors they were not touched.
But other sectors aren't safe if you delete or merge older sectors.

welp spoke too soon

Spoiler

823 512+256+32+16+4+2+1
824 512+256+32+16+8
825 512+256+32+16+8+1
826 512+256+32+16+8+2
827 512+256+32+16+8+2+1
828 512+256+32+16+8+4
829 512+256+32+16+8+4+1
830 512+256+32+16+8+4+2
831 512+256+32+16+8+4+2+1
832 512+256+64
833 512+256+64+1

[ck3D]

Bug is way worse than I thought if so many sectors can get affected. It was only that one sector/sectnum in my map of reference and so I was assuming a steady one-off. I'm never using ' X again until this gets fixed now (if any time). Shade of the effector does seem to be at play, in my case I was getting sector 272 with sector shade 18 bearing shade 0 lightswitch SE consistently reset back to sector shade 0. I think it's a problem of loaded temporary data that gets unloaded wrong. Using oasiz's 3D mode sector selection tool that temporarily turns highlighted sectors pal 6 as a visualizer (only if shade preview is on), I've run into palette conflicts before where some of the sprites inside of the selection actually got set to pal 6 once the sector deselected, which sounds similar/related to the incorrect unloading.

[oasiz]

Yeah, m32 has a "selection preview in 3D" when shade preview is enabled and it's a one-off function that I have no access to from scripts.
What my scripts do is that it simply lets you to select/de-select those sectors in 3D, unfortunately it would need an additional check here..
In Fury this is much less of an issue due to us not using stock duke SE lights.
But since SE lights are previewed and also the selection does it's own things, there is a logic error where it will restore wrong data.
I documented the following steps earlier:

Repro steps:
- Load an area
- Select a sector
- In 3D mode, toggle light preview on (quote + x)
- Go back to 2D, de-select
- Go back to 3D, you'll notice that the texture has changed to PAL6, but it previews with whatever "correct pal" you have due to SE light preview still overriding it
- If you disable light preview, it will remain PAL6 and no way to undo naturally unless you have a previous state in memory

IIRC this was something that helix added if I recall correctly from code comments so it's probably quite old code by now.

EDIT: Btw, you can use the selection scripts just fine as long as you don't have light preview enabled..
One idea i've had is to implement a temporary dummy sprite to show a selected sector but you all know what issues those tend to entail..

[ck3D]

oasiz, on 24 June 2025 - 01:24 PM, said:

EDIT: Btw, you can use the selection scripts just fine as long as you don't have light preview enabled..

Yeah, that is what I've been doing most of the time since I found out about the bug, and will keep doing all of the time now that I know it can affect just about any sector. Seeing as selected sectors (unlike sprites) remain selected during shifts between 2D/3D mode, that works as a visualizer when you need one (and if you're the map designer you tend to know how the areas you're editing are structured anyway, and probably have mastered 3D mode mouse pointing). I really hope your tool gets integrated as a proper Mapster32 feature at some point, it's so convenient and powerful and saves tons of time.

[oasiz]

I think I got this fixed but since I haven't really contributed actual code before, there might be changes that are needed..

It's a bit of a logic error in the editor code where it first saves the selected sector's original pal and proceeds to do SE lights after.
Issue is simple, it reads the sector data for SE _after_ this selection logic, which means that it will be PAL6 and overwrites the saved original palette for floor/ceiling.

Upon restoration it just blindly restores whatever was saved, which in this case is PAL6 and you end up with that.
https://voidpoint.io...70e?view=inline
For anyone who is curious or wants to build their own binary..
Ask me if you need the binary meanwhile..

[ck3D]

lllllllllllllll, on 24 June 2025 - 12:19 PM, said:

It's the same each time. I still think the shade of the effector is a culprit in some way. A cluster of sectors 823-833 with their shade/light inverted are getting affected by it. The other lone sector was 573 (512+32+16+8+4+1) and even though it is in a cluster of similarly lit sectors they were not touched.
But other sectors aren't safe if you delete or merge older sectors.

welp spoke too soon

Spoiler

823 512+256+32+16+4+2+1
824 512+256+32+16+8
825 512+256+32+16+8+1
826 512+256+32+16+8+2
827 512+256+32+16+8+2+1
828 512+256+32+16+8+4
829 512+256+32+16+8+4+1
830 512+256+32+16+8+4+2
831 512+256+32+16+8+4+2+1
832 512+256+64
833 512+256+64+1

So according to oasiz who just looked into my case, apparently (in my case mistakingly) having two SE's in the same sector is one thing that could cause the bug, just in case that sounds like something you might have going on. I'd say you should feel free to contact oasiz with example files in their broken state as well, especially if your situation is different.

[lllllllllllllll]

Well if it's not just me using an old version of mapster the bug is present in all versions of Incubator I posted. The pal-wiped battlelords are in the "vault" looking room and the dark SE blinking lights are in a room near them that has 2 closet-sized rooms joined to it. Toggling shade preview on then off will turn the battlelords to pal0, and make the floors of those dark SE's pitch black. Some of the sectors do have a SE explosive in them but most don't. The battlelord room has extra SE for floorz in all the light sectors but only the single sector with battlelords in it gets affected.

[oasiz]

I'm stupid and I'm going to need an exact shot/spot/map file

[oasiz]

Thanks for sharing this!
I checked that in both instances you have two or more light sprites in the same sector.
SE12, SE3 SE4 are all applied in code with the exact same logic.
This is the same root cause which ck3d had.

What happens is that the preview quickly modifies the map JUST before it draws the 3D elements and restores the state RIGHT after.
The saving is sort of:

-> ONE BY ONE do this (by running through all map sprites with SE texture)
- Check if it's 12, 3 or 4 lotag (A light preview needed)
- If so, let's do preview for this sector!
----> Save floor/ceiling/wall/sprite pals and shade to a dedicated slot for this sector and it's walls (One slot for each Sector ID and Wall ID)
----> Set all of the sector's floor/wall/ceiling/sprites to whatever the SE sprite is shaded/pal'd as
DONE! Check if we have more SE sprites in the map that need to be checked for preview

<< DRAW THE FRAME >>

- Restore floor/ceiling/wall/sprite pals/shade which was saved
DONE!

The problem here are these "dedicated slots" which only account for ONE run of this logic.
So if you check the SE sprites again and find another light sprite in the same sector, it will just blindly save the current preview state over the saved shade/pals we had and re-applies it's contents there.
The reason why you don't get double shading is that the sprite was just changed to a matching shade/pal of the first light SE.
But this means that the original data was just lost!

I've made a MR with this fixed in: https://voidpoint.io...ge_requests/348
In this one it will mark if a sector has already been previewed once for this draw loop, skipping subsequent applications of SE.

For the time being you can use this temporary build of mapster32 which has this commit built in: https://lerppu.net/e...2/mapster32.exe

[oasiz]

The fixes are now in mainline, latest eduke32/mapster32 binaries!

[jimbob]

Aleks, on 27 January 2024 - 12:38 PM, said:

Use targets/shooters - the touchplate/switch whatever you want to trigger the wave activated a delayed masterswitch in an "out of bounds" sector which after the delay activates a shooter shooting a shrinker projectile at a target, which activates the respawns. You can check the out of bounds stuff in the bottom left corner of Simpler Times, requires just 3 walls really since you can virtually set the sectnum of masterswitches and shooters in any other sector (providing it has a low enough floor/high enough ceiling) and have it work in the "dummy" sector.

thats actually a really elegant solution i think