[lllllllllllllll]

I made a diagonal slide door on the grid and it stops short of the distance it is set to and returns to a position offset by that shorted amount. Each full open/close adds the same amount of offset.
It has the same wall length as another normal slide door I made with the same speed setting.
Is this because the effector is drifting out of the door volume or is diagonal movement outright not supported for slide/bridge types?

[Forge]

diagonal movement doesn't play well with the engine.
even if you made it perfect / on a straight grid & then rotated it diagonal, it would still drift. I'm going to guess it's due to the effector sprite 'aiming' angles.
Rotating doors do the same thing.

i'm too lazy to figure out how to keep it from drifting, I just take the path of least resistance and fiddle with masterswitches and whatnot to make the sector move only once and never again.

[ck3D]

Can confirm that's always been an issue with diagonally moving structures, for a while I remember I considered repurposing the shifting sliding door thing into an object pushing mechanic except of course as long as the player can activate the door they can push it through both non-solid (sector boundaries) and solid (map boundaries) walls, which kills most of the practical possibilities for such an effect.

It's probably just due to the way the movement mechanics of those doors are hardcoded, I always imagined something somewhere was rounding up in order to calculate the door's next position instead of keeping track of its default coordinates and dragging the wall points back there, instead it just improvises some bullshit that's only meant to look like it does what it's really supposed to be doing. One good way of observing what I mean there is by trying and making a diagonal four-way Star Trek door or whatever those are called, the engine completely loses track of the default position as soon as the first activation, assumes the wall point movement should be straight regardless of the actual wall geometry and basically starts pulling into itself.

[lllllllllllllll]

Making it single use was a good solution

For pushable slidedoors you can prevent the player from interacting with it by putting the white wall facing away from a hole for the object to be moved into (kind of like blocks in Zelda). It would have to all be 1 sector though- room and hole.

[Aleks]

lllllllllllllll, on 18 April 2023 - 06:28 PM, said:

Making it single use was a good solution

For pushable slidedoors you can prevent the player from interacting with it by putting the white wall facing away from a hole for the object to be moved into (kind of like blocks in Zelda). It would have to all be 1 sector though- room and hole.

If you have a slide door made of multiple sectors, you can tag only one of them with ST25 and just add SE15 with matching hitags in the others, so that they will all move together - this way, the door will only operate when you press "use" on the ST25 sector, which can be e.g. concealed inside the wall to prevent from more than a single operation. Another idea is, if the door is textured with one of the tiles marked as "doortile##", then you can add a wall lotag matching the activator in the door sector, so this wall will act like a switch (doortiles also can work as switches when used as sprites BTW). It's a good idea for pushable objects when you want to mimick the fact Duke has to push them from a specific side for operation - as you mentioned the Zelda puzzle, you might check how I've done this in Back in Business 4th level (Piggish Prison), where at one point you have to push around a stack of furniture in the proper order so that they don't "overlap" to make your way to the door.

[Forge]

my lazy method
an activator sprite and a masterswitch sprite
one time activation & no manual usage afterwards



has to be switch or touchplate activated for the first and only use. Using the switch again, or manually pushing on it at any time won't do anything.

this could probably be exploited if a multi-use touchplate activated something else repeatedly, but you wanted a sector to move and stay put on the same tag

[Mike Norvak]

My mapping question is:

Will I map again?

🤔

[Aleks]

Mike Norvak, on 19 April 2023 - 02:59 PM, said:

My mapping question is:

Will I map again?

🤔

There's a very simple block diagram to answer this question:

Have you every mapped before?
Yes. -> You will eventually map again.
No. -> You may or may not map in the future.

[Forge]

Mike Norvak, on 19 April 2023 - 02:59 PM, said:

My mapping question is:

Will I map again?

🤔

you could. against your will, but i currently respect your wishes.

[ck3D]

To Build or not to Build, that is the question.

[Forge]

Imagine mapping again.
that's crazy talk

[zazo]

Hi ,
I would like to know if it is normal that the aspects of the sprites' propotions in mapster32 (and ingame) are different depending on whether they are flat or not?
Here is a screenshot with a basic example with a square sprite (64*64 pix): on the right it is flat (pasted on the wall) and looks square, and on the left it is not flat and looks not square.
Before doing this test, i reset the mapster32 config (by deleting the mapster32.cfg and restarting mapster32).
Thanks in advance

Attached thumbnail(s)

• 

[Forge]

zazo, on 05 June 2023 - 07:31 AM, said:

I would like to know if it is normal that the aspects of the sprites' propotions in mapster32 (and ingame) are different depending on whether they are flat or not?

it's been like that for a very long time. As long as I can remember at least.
the only thing i would suggest checking is to see if it was like that back in the original dos build.exe

[zazo]

Forge, on 05 June 2023 - 07:56 AM, said:

it's been like that for a very long time. As long as I can remember at least.
the only thing i would suggest checking is to see if it was like that back in the original dos build.exe

OK, i thought I had a configuration problem with the graphics card... so, if you want to have a sauare pixels aspect with non-flat sprite, you have to adjust the values of sizeat, sizeto, xrepeat, etc.... in a non-homothetic way (for example : sizeat 64 48 )

[Forge]

I can only speculate that it is the way it is because of crt monitors & resolutions back in 1996 and the current prominent use of widescreens today, but i'm probably wrong

[VGames]

I recently added some decorations to E1L1 and I noticed that the FIRE and FIRE2 actors that I added sometimes don’t show up in game like they should. And sometimes they get removed while playing the map. Is there a reason for this? Is there a setting for the fire actors that I need to make sure is enabled? The fire actors that were placed in the vanilla version of the map remain as they should no matter what.

[ck3D]

VGames, on 21 June 2023 - 04:42 AM, said:

I recently added some decorations to E1L1 and I noticed that the FIRE and FIRE2 actors that I added sometimes don’t show up in game like they should. And sometimes they get removed while playing the map. Is there a reason for this? Is there a setting for the fire actors that I need to make sure is enabled? The fire actors that were placed in the vanilla version of the map remain as they should no matter what.

Double check that you're not confusing FIRE with BURNING just in case (one of them is coded to instantly expire, the other one stays, forgot which is which), and another general rule is the sprites shouldn't be blocked or hittable in the map itself or else they will disappear when shot/hit.

[VGames]

ck3D, on 21 June 2023 - 05:29 AM, said:

Double check that you're not confusing FIRE with BURNING just in case (one of them is coded to instantly expire, the other one stays, forgot which is which), and another general rule is the sprites shouldn't be blocked or hittable in the map itself or else they will disappear when shot/hit.

Yeah I’m using fire and not burning. I understand the difference between them. But I think u hit the nail on the head. I don’t recall disabling their hitscan flag. I did remove their blocking abilities but not their hitscan flags. I’ll double check that. Thanks for the tip.

[zazo]

Hello,
I have a question about coding:
i'm trying to change the player coordinates (x,y,z), specialy to the coordinates of another actor, but the player remains stuck following this change (you can no longer move in x, y, z only turn on yourself).
The code I wrote is simply this:
inside an actor code :

if (condition to replace the player) ife removeplayer 0
{
geta[].x temp setplayer[THISACTOR].posx temp
geta[].y temp setplayer[THISACTOR].posy temp
geta[].z temp setplayer[THISACTOR].posz temp
set removeplayer 1 // done
}

Do you know another way to assign a new coordinate x,y,z, to the player in the map, without a blockage ?
Thanks in advance

[lllllllllllllll]

If there is a condition to set 'removeplayer' to 0 and it's being met at the same time as your other condition you'll be set to those coords for the rest of eternity.
If the actor you are porting to is blocked you might be getting stuck in it.
If the actor you are porting to has its Z inside world geometry you could get stuck too. Or a sloped surface with it's first wall higher than the spot you're popping up at.

You might try to also set the player's sector to the actor's sector.

[zazo]

lllllllllllllll, on 20 October 2023 - 10:50 AM, said:

If there is a condition to set 'removeplayer' to 0 and it's being met at the same time as your other condition you'll be set to those coords for the rest of eternity.
If the actor you are porting to is blocked you might be getting stuck in it.
If the actor you are porting to has its Z inside world geometry you could get stuck too. Or a sloped surface with it's first wall higher than the spot you're popping up at.

You might try to also set the player's sector to the actor's sector.

I may be the solution... But is there any piece of code to make a proper teleport sprite... ?

[lllllllllllllll]

Have you ever heard of maps being modified by running them once? I had back-to-back mirrors with a buffer sector between them with two vertex(s) of their behind-the-mirror sectors overlapping, and then test what it looks like ingame and of course it's glitchy looking as hell so I go to rearrange it only to find the points on one side have been merged. I think what a retard I was not to notice accidentally merging points, spend a few minutes untangling the mess this merge created, and run the map again only for the exact same thing to happen. I chalked it up to another user error and arranged the points to be the smallest amount of units apart and run the map, and that too results in the points of one side becoming merged into one.

So I undo the mess this has made again and this time have the mirrors as entirely unconnected sectors with white lines, only this time their vertex(s) for the face of the mirror overlap on the grid. Running this one causes these completely unconnected sectors to have the vertex(s) on both ends fused together.

[ck3D]

I suspect that may be the same automatic 'fix' that I've heard ruins replicating the Billy Boy one-way window trick/bug in Mapster builds of the last few years (meaning that opening Billy Boy's maps in the editor these days probably destroys them too). Has to do with corruption detection and may or may not be dodgeable by opening a dummy map, enabling master mode or whatever it is called again the option that allows the joining of non adjacent sectors, and only then opening the desired map (wouldn't be surprised if even that didn't work). Perhaps is completely unrelated but on paper sounds very similar. I think I remember Aleks used to have to juggle with similar stuff back when working on Back in Business due to a one-way window in Piggish Prison.

[Aleks]

Yeah I think this might not be caused by testing the map per se, but by some auto-fix that happens at some point, probably even when saving the map or going between 2D and 3D mode - maybe check if doing only that also modifies your map and - if not - try just running the map not from the editor testing mode, but from the regular eduke32.exe. You might also want to disable some automatic fixes in mapster32.cfg, maybe something helps - here are my current settings for that:

; Auto corruption check interval (seconds)
autocorruptchecksec = 0

; Ignore 'already referenced wall' warnings
corruptcheck_noalreadyrefd = 0

; Flag Duke3D issues
corruptcheck_game_duke3d = 0

; Auto-correct inconsistent ceilingstat/floorstat bit 2 and .heinum?
; Set to 2, also warn on 'corruptcheck'.
corruptcheck_heinum = 2

; Fix sprite sectnums when saving a map or entering 3D mode
fixmaponsave_sprites = 0

Also, you might want to run the command

script_expertmode 1

in the console (can also be set up in m32_autoexec.cfg).

As for what ck3d pointed, that indeed happens with BillyBoy window trick, which is a deliberate abuse of wall corruption - but it can be pasted into new editors and with autofixes disabled, Mapster won't screw it up, as long as you don't touch any affected vertices. So I just edit the necessary part in an older Build and paste it back into the new one when ready.

[William Gee]

Some of the walls in my WGSpace doors all got broken in recent years, I'm guessing it was this auto fix thing you mentioned as I never understood what caused the breakage.

[Aleks]

Just a new find that might be interesting regarding the recon patrol vehicles and locators: while the subways will follow the locators in their parent sectors so you can have more than 1 path set for them, RPVs follow any path and they can be interfered with subways and/or 2-way trains. This resulted in the idea that it's not possible to have both subways and RPVs in a single map, unless both would follow the same path of course. However, I've just noticed that in the case of there being more than 1 locator with the same lotag (which would usually be lotag 0 or 1, as these are used by 2-way trains), RPV will choose the locator with higher spritenum for its path (so e.g. if the RPVs bug out because of adding a 2-way train in the map, just copy the locators with tags 0 and 1 from the RPV's path and delete the older ones to keep only the ones with higher spritenum). Didn't really test this in-depth, but I assume working like that could allow to have both subways and RPVs in the same map and using different paths.

BTW, spritenums are also dictating the order in which viewscreens show the image from the linked cameras, starting from the camera with the highest spritenum and going down in a descending order.

[ck3D]

This is just a very basic tutorial/demo of how to best fix long distance rendering bugs in Mapster32 when working with large spaces, basically just addresses a common beginner mistake but one that isn't very accessible to understand even exists since there are no visual clues of such operations but the glitches happening or not. Simple logic to master once familiar but can use some guidance at first, I know I spent a long time with trial and error with such issues back when working on some Blast Radius maps.

Before:

3D mode glitch (right): https://cdn.discorda...16/capt1344.png
Automap (glitchy map state): https://cdn.discorda...22/capt1343.png

The engine is trying to render too much stuff at once at the same time but can be mitigated by adding splits/drawing walls if necessary.

Wall/split length seems to matter, with trial and error I've found 8193 max length seems the safest max to me, but might depend on level geo habits.

Long walls that are bound to be visible from afar I always split every 8193 units for that reason, e.g.. the splits on the red walls already were there but work as a different safeguard portal.
Drawing walls with splits to fix: https://cdn.discorda...55/capt1347.png

After (glitch free):

3D mode: https://cdn.discorda...98/capt1346.png
Automap (fixed map state): https://cdn.discorda...02/capt1345.png

Sometimes the problematic area/angle to rework isn't so clear cut. In those cases what I usually do is point at the glitchy sector/texture in 3D mode and temporarily mark it as ill with palette 6. Then once it's easy to locate, with the player camera back to the glitchy viewpoint start drawing a straight line from there to the center of the ill sector, and see if it cuts any massive line or space, I've been in situations where sometimes it would be just a single wall that's longer than 8193. Try splitting that/those wall(s).

[Aleks]

I remember someone (IIRC Graphics) bringing up 8193 as the max size for walls, but personally never found the limit to be so low - I usually just watch to keep the wall length around the boundaries below ~40k units when it becomes "blue". Simpler Times had a lot of walls of about 24k length, even the curbs around the pavements in the player area, but mostly boundaries (IIRC the water sector with the boat on it stretches so much that its walls become blue as well, but there's nothing to be done about it and works fine).

Not really sure what's going on in your screenshots TBH, I would probably pin this thing on something wrong with parallaxed skies or slopes (I've just noticed slopes can be a bitch for rendering in particular, having more glitches in my current map with them than with super-complex TROR).

ck3D, on 24 January 2024 - 08:02 PM, said:

In those cases what I usually do is point at the glitchy sector/texture in 3D mode and temporarily mark it as ill with palette 6. Then once it's easy to locate, with the player camera back to the glitchy viewpoint start drawing a straight line from there to the center of the ill sector, and see if it cuts any massive line or space, I've been in situations where sometimes it would be just a single wall that's longer than 8193. Try splitting that/those wall(s).

That's a great tip though, I also do that temporary coloring on glitchy stuff, especially when making some tricky SOS effects, "painting" every floor and ceiling differently to see which one bugs out.

[ck3D]

No no in specific cases that value seems tried and true, I've fixed dozens of instances of the bug with that value seeming to be the fix/threshold, but you only get to be this precise in extreme circumstances. Good on you if you're not familiar with those glitches, like I was saying it must have to do with habits in level geo. You're likely to run into them in really giant open spaces, especially if there is contrast in the concentration of the resources and it's a shitload of walls that need to be rendered in front of one long wall at once. Each wall is a portal and not breaking things up sometimes you get weird overflow where the sector in the background seems to spill into the one in the foreground (but I also like splits to make sure to prevent collision bugs when shooting). The visual effect indeed is the same as bad slopes but can happen with flat sectors. I'd suspect you're not too familiar with those glitches because your style frequently involves spending most of a map's walls indoors and so you have less opportunities with bad portals, whereas long walls do not matter until they clash with one. Post is a bit of a simplification but I would have appreciated to be able to read it somewhere some years ago.

[jimbob]

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.