
Mapping questions thread
#631 Posted 13 January 2022 - 05:04 AM
Anyone would happen to remember the quickest way to flip a map upside down on the Z axis (e.g.. invert everything so that the sky is at the bottom) by chance? I remember reading a post about a shortcut or console command a while back but can't track it down because only flipping sectors on the other axises insists on showing up in my searches (since that's a lot more common). Or was that a script someone made? Thanks.
#632 Posted 17 January 2022 - 10:40 AM
Hi, I am recreating the effect of arriving train that is in Blood E1M2 - a map which I am converting to Duke. I use slide door as the train, but it's slow as hell. Is there any way how to speed up the slide door? Or do I have to use a 2-way train instead?
Duke Nukem effects are fairly limited in comparison with Blood. I guess there is also no way how to move flat sprites in Duke3D for moving sprite bridges, etc. I saw that flat sprites can move up or down together with sectors. The only way I found how to sort of have moving flat sprites is to use maskwalls. Is that correct?
Thank you!
Duke Nukem effects are fairly limited in comparison with Blood. I guess there is also no way how to move flat sprites in Duke3D for moving sprite bridges, etc. I saw that flat sprites can move up or down together with sectors. The only way I found how to sort of have moving flat sprites is to use maskwalls. Is that correct?
Thank you!
#633 Posted 17 January 2022 - 11:35 AM
MissingNO, on 17 January 2022 - 10:40 AM, said:
Hi, I am recreating the effect of arriving train that is in Blood E1M2 - a map which I am converting to Duke. I use slide door as the train, but it's slow as hell. Is there any way how to speed up the slide door? Or do I have to use a 2-way train instead?
Duke Nukem effects are fairly limited in comparison with Blood. I guess there is also no way how to move flat sprites in Duke3D for moving sprite bridges, etc. I saw that flat sprites can move up or down together with sectors. The only way I found how to sort of have moving flat sprites is to use maskwalls. Is that correct?
Thank you!
Duke Nukem effects are fairly limited in comparison with Blood. I guess there is also no way how to move flat sprites in Duke3D for moving sprite bridges, etc. I saw that flat sprites can move up or down together with sectors. The only way I found how to sort of have moving flat sprites is to use maskwalls. Is that correct?
Thank you!
Slide doors are indeed slow and cannot move faster, they also don't carry sprites. 2-way trains always worked for moving any sprites over the horizontal plane. Other effects that work would be bridge (I don't use that at all due to how limited it usually is as well, also even slower than slide doors), "rotate rise bridge" (ST30 with SE0 and SE1), if SE0 is put at the same height as sector floor it won't move up/down - however it goes over a circular track, if you want "straight" movement, then won't be any good unless you make some super large radius. You can also use conveyor belts either to move sprites or to simulate the movement of a train - see how it was done in e.g. Red 4, West Alien Train, Vlak and that train map in Metropolitan Mayhem. There's also the subway effect, but it goes over a loop.
I haven't played Blood yet though, so not sure how this should look like

#634 Posted 17 January 2022 - 11:52 AM
You can at least make it slower by using two stacked stretcy bridge effects as it's mostly just a wallpoint dragger. Have another one at the end of the "door sector" and place it out of vision and you have something that looks like a really slow slidedoor that can also carry sprites.
It's basically pushing the rear so that the textures on the side will stay intact.
It's basically pushing the rear so that the textures on the side will stay intact.
#635 Posted 30 January 2022 - 03:05 PM
is there a way to expand the usable grid in build? or am i limited to creating it in the available space and selecting/dragging it out of the grid?
#636 Posted 30 January 2022 - 03:26 PM
IIRC you can change grid size by editing this line in mapster32.cfg
"; Grid limits
editorgridextent = 131072"
"; Grid limits
editorgridextent = 131072"
This post has been edited by Mister Sinister: 30 January 2022 - 03:26 PM
#638 Posted 31 January 2022 - 08:37 AM
Just put "9999999999" and the config file will do the rest ๐คฃ
#639 Posted 01 February 2022 - 05:22 AM
Mister Sinister, on 30 January 2022 - 03:26 PM, said:
IIRC you can change grid size by editing this line in mapster32.cfg
"; Grid limits
editorgridextent = 131072"
"; Grid limits
editorgridextent = 131072"
awesome

#640 Posted 17 April 2022 - 12:14 PM
my videocard died the other day, so i installed a new one, but due to the issues i might have panicked and changed some settings in mapster, now it wont load anymore, it says 'warning no active cache' if i set cache to 0 or 1 it works, but the next time i load it it gives me the same error again.
[edit] deleting my mapster settings.cfg file seems to work.
[edit] deleting my mapster settings.cfg file seems to work.
This post has been edited by jimbob: 17 April 2022 - 12:41 PM
#641 Posted 24 June 2022 - 04:17 AM
Bit of a strange question - I have an SE12 light switch effect in one of my maps which keeps breaking when I make new additions elsewhere. As a workaround I keep deleting the offending sectors, copying identical ones from a previous iteration of the map, and then it all works fine for a while until some unspecified change I make breaks the effect again.
Can anyone think of a way to track down what might be causing this, or is it just one of those weird Mapster quirks?
Can anyone think of a way to track down what might be causing this, or is it just one of those weird Mapster quirks?
#642 Posted 24 June 2022 - 10:36 AM
^ okay I think I've pinned the issue down, the effect seems to break every time I use 'X to toggle the sprite shade and SE light effect preview. Very strange!
#643 Posted 02 July 2022 - 05:59 AM
Spend enough time with Mapster and you'll find a number of "odd things". Like a swing door or polymer light in a part of the map you haven't touched in months stops working. And it wasn't because of a newly added duplicate tag number elsewhere. So I just delete the SE, put another one exactly like it back in and it works fine.
#644 Posted 08 July 2022 - 11:23 AM
I have been working on lighting a map recently using the Polymer sectoreffector values and I have discovered what appears to be a limit to the number of lights that can be used within a sector or area before problems start occuring. It seems that other lights in the area will turn off if there are two many. I have also discovered that the lighting effects tends to leak through walls as well and can impact the lighting effects in other parts of the map.
Has anyone else had these problems and if so are there any known solutions?
Has anyone else had these problems and if so are there any known solutions?
#645 Posted 09 July 2022 - 12:57 AM
there should be a couple of sliders to adjust in the menu concerning lights and shadows. Leaking problem is one of the handful of bugs with Polymer. Not much you can do.
#646 Posted 09 July 2022 - 01:35 AM
Re: leaking through walls - if that means what I think it means, remember 1/ giving a wall a Hitag of 1 will exclude it from light effects although in some particular cases that still will not look as intended (if it will even function) and 2/ each red wall actually has two sides that can each bear different tags (which isn't exactly explicit in Mapster), which means one should always make sure it's the correct side(s) of the wall that is (are) tagged, and that's something easily overlooked with how tags look in the editor.
Like I was just saying, sometimes weird inconsistencies in lighting/shading logic seem to happen with things correctly set up in-editor but insisting on behaving funny in-game, in a lot of those situations for me drawing a very thin (barely noticeable) sector to separate the problematic walls from the next sector (usually but not always the ones with the effectors) and isolate them fixes the aesthetics.
edit - ah it's still early here and I just realized we're not talking classic lights. Whatever, still good information.
Like I was just saying, sometimes weird inconsistencies in lighting/shading logic seem to happen with things correctly set up in-editor but insisting on behaving funny in-game, in a lot of those situations for me drawing a very thin (barely noticeable) sector to separate the problematic walls from the next sector (usually but not always the ones with the effectors) and isolate them fixes the aesthetics.
edit - ah it's still early here and I just realized we're not talking classic lights. Whatever, still good information.
This post has been edited by ck3D: 09 July 2022 - 01:36 AM
#647 Posted 07 September 2022 - 04:23 AM
Hello,
Don't know where to post my request, but i think it's the place:
I'm searching for library and tutorials to put 3D models (ex: cars, trees, etc) in maps...
Do you know:
1 - where i can download nice 3dmodels ?
2 - how to edit the duke3d.def to implement them correcly ?
for exemple, then model declaration lines looks like this:
model "models/br_gascan/br_gascan1.md3"
{
scale 1.0 shade 11
skin { pal 0 SURFACE 0 file "models/br_gascan/br_gascan1.jpg" }
anim { frame0 "idle01" frame1 "idle01" fps 0 flags 0 }
frame { name "idle01" tile0 3408 tile1 3408 }
}
... how do we find the names of the frames ?
Don't know where to post my request, but i think it's the place:
I'm searching for library and tutorials to put 3D models (ex: cars, trees, etc) in maps...
Do you know:
1 - where i can download nice 3dmodels ?
2 - how to edit the duke3d.def to implement them correcly ?
for exemple, then model declaration lines looks like this:
model "models/br_gascan/br_gascan1.md3"
{
scale 1.0 shade 11
skin { pal 0 SURFACE 0 file "models/br_gascan/br_gascan1.jpg" }
anim { frame0 "idle01" frame1 "idle01" fps 0 flags 0 }
frame { name "idle01" tile0 3408 tile1 3408 }
}
... how do we find the names of the frames ?
#648 Posted 07 September 2022 - 09:14 AM
there is a program called Npherno 3D. Load the model into there. Make sure you have the program window maximized. It will show the frame name towards the bottom of the screen.
#649 Posted 07 September 2022 - 01:40 PM
Or if you load the md3 file into a hex editor the frame names are right near the start of the file.
#650 Posted 07 September 2022 - 02:31 PM
dandouglas, on 24 June 2022 - 10:36 AM, said:
^ okay I think I've pinned the issue down, the effect seems to break every time I use 'X to toggle the sprite shade and SE light effect preview. Very strange!
you can preview effects with X ? :/ never knew that
#651 Posted 04 March 2023 - 11:56 PM
Some maps like Lunatic Fringe have sectors that are not connected directly but share the same volume. When you wake enemies in the first set of sectors and move to the second set of sectors those enemies will occasionally flicker in and out of existence.
My question is whether the listed z of ceiling/floor is going to cause problems even though it is sloped in a manner where it does not meet another sector's volume. Things like having to set Triggers at the true z of a sloped floor to prevent floor rise/drop make me think it will be trouble.
(numbers for example's sake; note negative z is higher elevation)
a sector first wall set to 2048 z, a sloped ceiling of 1024, and the opposite wall reaches 4096 z
vs
that same sector's first wall set to 4096 z, a sloped ceiling of -1024, and the opposite wall reaches 2048z
These are visually identical with the exact same limits on volume with the difference being the z of the ceiling.
Now with 2 separate sectors sharing the same area:
Sector A has its first wall set to 4096 z, a sloped floor of -1024, and the opposite wall reaches 2048 z (/)
Sector B has its fist wall set to 3072 z, a sloped ceiling of 1024, and the opposite wall reaches 5012 z (\)
The first walls are mirrored to slope in the same direction / / parallel so even though their volumes do not overlap at all their z values extend into the other's slope.
Are these sectors going to be treated as if they occupy the same volume?
My question is whether the listed z of ceiling/floor is going to cause problems even though it is sloped in a manner where it does not meet another sector's volume. Things like having to set Triggers at the true z of a sloped floor to prevent floor rise/drop make me think it will be trouble.
(numbers for example's sake; note negative z is higher elevation)
a sector first wall set to 2048 z, a sloped ceiling of 1024, and the opposite wall reaches 4096 z
vs
that same sector's first wall set to 4096 z, a sloped ceiling of -1024, and the opposite wall reaches 2048z
These are visually identical with the exact same limits on volume with the difference being the z of the ceiling.
Now with 2 separate sectors sharing the same area:
Sector A has its first wall set to 4096 z, a sloped floor of -1024, and the opposite wall reaches 2048 z (/)
Sector B has its fist wall set to 3072 z, a sloped ceiling of 1024, and the opposite wall reaches 5012 z (\)
The first walls are mirrored to slope in the same direction / / parallel so even though their volumes do not overlap at all their z values extend into the other's slope.
Are these sectors going to be treated as if they occupy the same volume?
#652 Posted 05 March 2023 - 03:42 AM
I didn't study the case very closely but have practically ran into similar issues to differently acute extents in a couple of different maps with different sector over sector set-ups. My general experience so far has been that what the game considers as player space altogether is what seems to matter; sectors that overlap but otherwise share zero volume in terms of player space usually are safe, but the more leeway you introduce including via slopes the more conflicts, I guess due to how coords are generally handled (and so clipping into invalid space altogether seems to be the check, including on the z axis). I didn't go as far as checking first walls (but you made me realize that maybe I should), but in one map in particular I could clip from an underwater layer of my level to the above water layer/overlapping sector when the only protruding offset in volume was, just partially, a big slope. If I ever try changing first walls there or even just altering the general set-up for experimentation purposes I might report back.
Oh and yeah, that means clipping through the layers can happen to enemies but to the player as well. Build actually is very fragile in those regards and a lot of the clipping behavior rarely breaks in practice thanks to appropriate map design, otherwise by overlapping sectors and walls all over the place it's stupidly easy to have it go nuts. To a degree that seems very Eduke build dependent, too (I think I remember most of collision was revamped a while back).
That is all assuming you're talking about enemies actually clipping through the sector over sector layers. If the effect is just visual then that is more likely to have something to do with their current sectnum being or not being currently visible, regardless of which layer is being rendered (they're rare but I think I've seen a few funny conflicts of the sort; off the top of my head, maybe in 2BIZARRE.MAP).
Oh and yeah, that means clipping through the layers can happen to enemies but to the player as well. Build actually is very fragile in those regards and a lot of the clipping behavior rarely breaks in practice thanks to appropriate map design, otherwise by overlapping sectors and walls all over the place it's stupidly easy to have it go nuts. To a degree that seems very Eduke build dependent, too (I think I remember most of collision was revamped a while back).
That is all assuming you're talking about enemies actually clipping through the sector over sector layers. If the effect is just visual then that is more likely to have something to do with their current sectnum being or not being currently visible, regardless of which layer is being rendered (they're rare but I think I've seen a few funny conflicts of the sort; off the top of my head, maybe in 2BIZARRE.MAP).
This post has been edited by ck3D: 05 March 2023 - 04:02 AM
#653 Posted 05 March 2023 - 02:45 PM
Ok so I was putting together a new episode with custom slaughter maps. For some reason I can't get the second map to start after the first map is completed. It just plays the first map again. But if I play through the first map the second time it's loaded up it will continue on to the second map like it should have done the first time. Has anybody had this issue? I know I have everything set up properly in the USER.CON file. I have named the maps E5L1, E5L2, E5L3, etc. This also happens when I skip to the first map of the new episode. What could be causing this?
#654 Posted 07 March 2023 - 05:03 AM
do you play it starting from the user map option? afaik this seems to take you back to the main menu everytime you finish a map. or did you load them all in the user.con?
#655 Posted 07 March 2023 - 06:03 PM
I figured it out. The map in question was using the MP version of the nuke button because itโs palette was set to 1.
#658 Posted 15 March 2023 - 12:08 PM
lllllllllllllll, on 04 March 2023 - 11:56 PM, said:
Some maps like Lunatic Fringe have sectors that are not connected directly but share the same volume. When you wake enemies in the first set of sectors and move to the second set of sectors those enemies will occasionally flicker in and out of existence.
My question is whether the listed z of ceiling/floor is going to cause problems even though it is sloped in a manner where it does not meet another sector's volume. Things like having to set Triggers at the true z of a sloped floor to prevent floor rise/drop make me think it will be trouble.
(numbers for example's sake; note negative z is higher elevation)
a sector first wall set to 2048 z, a sloped ceiling of 1024, and the opposite wall reaches 4096 z
vs
that same sector's first wall set to 4096 z, a sloped ceiling of -1024, and the opposite wall reaches 2048z
These are visually identical with the exact same limits on volume with the difference being the z of the ceiling.
Now with 2 separate sectors sharing the same area:
Sector A has its first wall set to 4096 z, a sloped floor of -1024, and the opposite wall reaches 2048 z (/)
Sector B has its fist wall set to 3072 z, a sloped ceiling of 1024, and the opposite wall reaches 5012 z (\)
The first walls are mirrored to slope in the same direction / / parallel so even though their volumes do not overlap at all their z values extend into the other's slope.
Are these sectors going to be treated as if they occupy the same volume?
My question is whether the listed z of ceiling/floor is going to cause problems even though it is sloped in a manner where it does not meet another sector's volume. Things like having to set Triggers at the true z of a sloped floor to prevent floor rise/drop make me think it will be trouble.
(numbers for example's sake; note negative z is higher elevation)
a sector first wall set to 2048 z, a sloped ceiling of 1024, and the opposite wall reaches 4096 z
vs
that same sector's first wall set to 4096 z, a sloped ceiling of -1024, and the opposite wall reaches 2048z
These are visually identical with the exact same limits on volume with the difference being the z of the ceiling.
Now with 2 separate sectors sharing the same area:
Sector A has its first wall set to 4096 z, a sloped floor of -1024, and the opposite wall reaches 2048 z (/)
Sector B has its fist wall set to 3072 z, a sloped ceiling of 1024, and the opposite wall reaches 5012 z (\)
The first walls are mirrored to slope in the same direction / / parallel so even though their volumes do not overlap at all their z values extend into the other's slope.
Are these sectors going to be treated as if they occupy the same volume?
A bit later to the party... Anyway:
Remember that the slopes that go "below" the floor level or "above" the ceiling level will cause problems with rendering sprites, effectively "cutting" and not rendering any part of the sprite that is below the floor height or above the ceiling height. This happens even without any kind of SOS.
As for your problem - you should try building this setup and see, but I highly doubt it would cause any problems, pretty sure I've done more insane SOS stuff regarding staircases etc. without any problems.
#659 Posted 17 March 2023 - 10:29 PM
Aleks, on 15 March 2023 - 12:08 PM, said:
Remember that the slopes that go "below" the floor level or "above" the ceiling level will cause problems with rendering sprites, effectively "cutting" and not rendering any part of the sprite that is below the floor height or above the ceiling height. This happens even without any kind of SOS.
Funnily enough that cutting behavior prevents the issue of sprites blinking into sectors they don't belong inside of for this setup.
Due to the corner sectors being triangles I had to include 2 spots of overlapping listed z's but they don't have any obvious problems in Polymost. Duke wasn't hopping through floors or ceilings at least.
Beyond that convenience having the sprites' legs chopped off is very ugly.
#660 Posted 22 March 2023 - 08:46 PM
Since the player has to be in playerspace to alt+s a sector does the particular sector you have it in change anything about the new sector being made?