
Mapping questions thread
#631 Posted 13 January 2022 - 05:04 AM
#632 Posted 17 January 2022 - 10:40 AM
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:
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
It's basically pushing the rear so that the textures on the side will stay intact.
#635 Posted 30 January 2022 - 03:05 PM
#636 Posted 30 January 2022 - 03:26 PM
"; 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
#639 Posted 01 February 2022 - 05:22 AM
Mister Sinister, on 30 January 2022 - 03:26 PM, said:
"; Grid limits
editorgridextent = 131072"
awesome

#640 Posted 17 April 2022 - 12:14 PM
[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
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
#643 Posted 02 July 2022 - 05:59 AM
#644 Posted 08 July 2022 - 11:23 AM
Has anyone else had these problems and if so are there any known solutions?
#645 Posted 09 July 2022 - 12:57 AM
#646 Posted 09 July 2022 - 01:35 AM
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
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
#649 Posted 07 September 2022 - 01:40 PM
#650 Posted 07 September 2022 - 02:31 PM
dandouglas, on 24 June 2022 - 10:36 AM, said:
you can preview effects with X ? :/ never knew that
#651 Posted 04 March 2023 - 11:56 PM
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
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
#654 Posted 07 March 2023 - 05:03 AM
#655 Posted 07 March 2023 - 06:03 PM
#658 Posted 15 March 2023 - 12:08 PM
lllllllllllllll, on 04 March 2023 - 11:56 PM, said:
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:
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.