[ck3D]

Unless it was a one-off bug which sometimes tends to happen to me with quick newboard.maps I start on the fly as test maps, I just ran into a Mapster bug I've never seen before I thought I would point out because it may be interesting, I'm sure it's normal engine behavior too and eDuke32 devs are aware since an error message about invalid... coordinates? (the specificity of the message I already forgot) does display (note that I'm not using the latest version of Mapster either; that build is about a year old). But basically, I started a new map and just made a large triangular sector real quick that was all blue walls, because I was already so zoomed out - which I didn't think would matter for an ephemeral test map but I guess turned out to, since I assume it caused an overflow. That resulted in a fully invalid sector which couldn't be explored in 3D mode and would basically render nothing but base pitch black and infinite HOM. I didn't experiment at all so I have no idea if it's reproducible or a one-off (but it would make sense if it were consistent), I have no idea if the entirety of the map has to be 'invalid' to generate such results (in my case it was, now I wonder if isolated sectors in a level with valid space would also behave the same), I didn't even try to see if it killed the player. But I thought it was a bit particular and odd, and while I don't know shit about how magnets are wired there myself I seem to understand that HOM can be tied to funky rendering tricks and so perhaps this could be relevant info to someone.

[ck3D]

Want to see another weird one I've been getting? Pretty sure I've mentioned it before on here; the infinite letter sprite column. I've since narrowed the causes down to... weird stuff going on upon opening some old maps, which were made in older versions of Mapster, in more recent Mapsters (well this build here is about a year old), and either running corruptcheck tryfix or sometimes just letting Mapster run its base, default corruption checks. Apparently, it's finding stray or corrupted sprites around the map, moving several if not all of them to the same exact coordinate (if there's ROR, that's sometimes outside of playable space when floors don't align), sometimes giving them absurd tags, and while the sprites don't show in editor most of the time (if ever?), in game generates a giant ass column of them that disappears ad infinitum into the parallaxed sky. (edit - just double checked and no, it actually stops at top sky height)



From the mapper's perspective, it's very easy to address the issue since locating then deleting the sprite(s, because sometimes it seems to be just one) successfully forever deletes the column. So this is not an issue I'm having. I'm just really curious as to what exactly could cause a sprite to do this and is it even possible to manipulate? Looks like a maskwall but isn't, acts solid like a white wall but isn't, seems to be one-way whenever the sprite is, tile of the sprite glitches out in funky ways (similar to floor-aligned sprites from a distance) with how close or far the player gets. I don't know much about cstats, maybe it's related? I assumed random corruption the first time it happened to me, but since then I've gotten this maybe half a dozen times on different maps (but all with the same background of having been made on the same outdated Mapster originally, then ported over to newer).

[dnskill]

At least part of what I'm about to post was mentioned here

Shaq Fu, on 09 October 2016 - 08:55 PM, said:

More images of this place can be seen here: http://imgur.com/a/DdQqH

and I'm pretty sure this was discussed in the past elsewhere on this forum, but I felt it may be worth adding a bit more info to this because it seems not many people are actually aware of these small differences in v0.99:

First off, as Shaq Fu posted about in 2016, E1L2 in v0.99 includes a section of the level that appears to be a concept for a more involved starting area for this level. It seems at some point the plan was to have Duke go down the elevator, but it would lead him to a parking garage. From, there, he would find armor in a storage closet and a switch near the garage doors to raise the garage doors with. He'd also have to deal with a pig cop and assault trooper in here.

Spoiler

From there, it seems the plan was to have this connect with the rest of the level, so you'd exit the garage with the erotica store to your left (to the right of this image below), and the rest of the level likely would've played out exactly the same.

Spoiler

Curiously, there is another small room that appears it would've been the inside of a building that would likely have gone off from an earth quake or some other sort of trigger and leave a hole in the wall for Duke to enter here. My best guess is it is meant to be part of the building that leads to the yellow access card door, sort of like in Nuclear Winter. It seems it is possible this could've been used to show a bunch of gibs flying out from an explosion, as I doubt the troopers inside would survive.

Spoiler

Furthermore, there is a secret Easter Egg found in v0.99 that was removed before v1.0 and you can see how to trigger it here. The way this worked was by using the security cam feature but disguising it as a magazine.

Spoiler

There's another unused room that appears like it too was some sort of page in a magazine, but there's nothing to trigger it. It could be just another Allen Blum hidden message sort of thing, or maybe it was initially a part of this same thing here.

Spoiler

Another cut "Easter Egg" is in the bathroom payphone booth, which played the sound PIGWRN.VOC instead of the dial-tone. You can see this here. This sound was also used for the ending to E1L2 in this beta before being replaced with !PIG.VOC in v1.0. This makes me wonder if PIGWRN was only used as a placeholder for the ending message, and was intended to be heard only through the phone, but ultimately went unused. I'm pretty sure it's saying "Prepare to die, human!" as pigs squeal in the background.

Oh, and in the Abyss in v0.99 there is a hidden message I just noticed:

Spoiler

It can be found in a tunnel area that is absent from the final version of the game near where the fire pit is, right before you jump down in there if you go the the left there's a small hole you can get into that leads into this tunnel. Without the goggles, it is pitch black, but you can peak into where the room with the octabrains and bloody hand switches are for the shrinker puzzle you need to do in order for the lava area to explode for you to get to the rest of the level.

[oasiz]

Probably known to some but I discovered this today and doesn't seem that well documented..
Typically SE17 transport elevators are documented as requiring HITAG 0 & HITAG 1 pairs for lower/higher floors.
While writing documentation for m32 scripts I found it strange that it's explicitly 0/1 and not simply "greater than zero / not zero" as this is not seen much in the code.

It turns out that if I modify _SE.MAP to have tags 665 and 666 it still works fine, hinting that It's just +1 that it cares about for a higher floor.
However If I copypaste the higher floor and shift it even higher and give it a 667, surprise surprise, it still works!

This means that the multi-floor capability for transport elevators is still in the game but with one limitation: You can't determine the direction when inside the elevator.
You can however call the elevator just fine on the top floor and have it reach you. As you use it, it will go lower and lower until you're at the bottom.

Digging through the code it seems that the function in question and it does have "WarpDir" quite well supported.
Slightly below you have the ST code itself that has two separate blocks "Player inside sector" and "Player outside sector".
When inside, it simply calls 1 or -1 depending on the current floor, however if you are outside it will keep climbing as long as the Z differs.
What's more, the RGAME.H I posted above has a player struct member "select_dir" which is possibly what was used to store this value, it's possible that the earlier code was as simple as looking at this value and picking 1 or -1 to pass for warpDir.
The "Outside of elevator" code could've been simpler already if it was just two floors so I think it was just quickly modified to remove the need for this variable.

Long story shorter:
- Warp elevator hitag doesn't have to be 0/1, just a sequence.
- Multiple floors are still supported just like lameduke
- Only the "pick a floor" functionality is broken when inside the elevator but otherwise it's all still there.

Maybe with some workarounds this could be made to work better?

[oasiz]

This only changed one if statement to check for "SK_CROUCH" and removed one line of code after that.
The routine already does the checking of "Is anything really above/below" for you.

[Jblade]

that's really awesome, nice find!

[Shadow_Wulfe]

What is the syntax of the eduke32 "Give" command?

I can only seem to get it to spit out a line telling me it COULD give "requested item".

[Jblade]

Shadow_Wulfe, on 09 October 2022 - 06:37 PM, said:

What is the syntax of the eduke32 "Give" command?

I can only seem to get it to spit out a line telling me it COULD give "requested item".

it takes either a tilenumber or the full name of the actor.

[NNC]

I was toying with Mapster today, and noticed that one of the Babe Land carts (the blue one) gets glitchy as soon as you open the map (it's not like those old Mapster/Build SOS related glitches which became problematic when you make the first change in the level). It's sprite #303 which is the cause of the glitch, it's a rotated sector put on the edge of two sectors. It's functional in the original game, but isn't with a maphack. Weird stuff.

[oasiz]

Yeah, I think this was last brought up a few years back. IIRC It's just a mapping mistake and it's just the editor auto-correcting the sector number of the sprite.
Rarely an issue but it can cause interesting things with rotation sprites for example.

Try opening the map with script_expertmode 1 enabled and see if the disabled correction lets it remain "wrong"

[NNC]

oasiz, on 26 November 2022 - 01:00 PM, said:

Yeah, I think this was last brought up a few years back. IIRC It's just a mapping mistake and it's just the editor auto-correcting the sector number of the sprite.
Rarely an issue but it can cause interesting things with rotation sprites for example.

Try opening the map with script_expertmode 1 enabled and see if the disabled correction lets it remain "wrong"

Weird stuff. I checked some maps, and this autocorrection thing happens a few times. For example one pigcop respawn is modified from one sector to another in Hotel Hell too. How the engine do these things? How can it detect what's wrong and what isn't?

Also, what's this expertmode doing? What's the difference between it and normalmode?

[Aleks]

The Watchtower, on 27 November 2022 - 03:55 AM, said:

Weird stuff. I checked some maps, and this autocorrection thing happens a few times. For example one pigcop respawn is modified from one sector to another in Hotel Hell too. How the engine do these things? How can it detect what's wrong and what isn't?

Also, what's this expertmode doing? What's the difference between it and normalmode?

Original Build didn't check if the sprites have "correct" sectnums, but then I don't think it was possible to purposely edit this and could only happen through a glitch I suppose. Mapster automatically fixes sectnums in "non-expert mode" (so that the sprite have the sectnum corresponding to their geometrical coordinates/physical location) and doesn't in expert mode, which can be used for various tricks. Also, expert mode allows for joining non-adjacent sectors, which was also possible casually in original Build.

[NNC]

During my Blast Radius playtesting, ck and me were talking about palette respawns once again, and how it doesn't work bosses aside in the vanilla game, despite the several uses of pal21 respawn troops especially in the first 3 episodes.

Now I'm thinking again, basically all those red liztroop spawns in the game are "straight in your face" ones, where you can clearly see the same flashy animation that is also used by the red troop's teleport. For example in Hollywood, that weird respawn in the cinema chairs look like some kind of introduction for the red troop, similarly to the one at the backdoor. Then there is a second one from both routes in the main lobby before you can get the shotgun. I mean, the troop spawns in flashy style, and can use the same flash later on.

Similarly, the straight into your face respawn troops in Red Light District (in the bar shooting the girls), Death Row (in the church), Launch Facility (at the start), The Abyss (near at the end with the deep abyss), and several others in Incubator, Warp Factor do the same. The most common respawns are not straight into your face, and none one them are using palettes. I didn't check beyond mid-episode 2, I guess this whole concept had been lifted later on, but this is a trend that is not a coincidence.

[Reaper_Man]

FWIW looking in the source code, the lack of palette transfer from RESPAWN to the enemy it spawns is intentional. In the case of the Liztroop, the palette is always forced to 22 if it isn't already set. However for all enemies, it doesn't check for the palette of the spawning RESPAWN and apply it first, so the Liztroop sees a default 0 palette. This is not the case for bosses, which does check if it was spawned by a RESPAWN and if so, transfers its palette to the boss. Because this behavior was never changed between 1.3 and 1.5, we have to assume they wanted to enforce this behavior, and because EDuke tries to maintain compatibility, that's why this behavior persists. Thankfully you can work around this using Events

As for the Liztroop Captains, I would guess the opposite - RESPAWNs were already using the TRANSPORTERSTAR effect, and they added in the Captains after having the "in your face" spawns as a way to change up gameplay dynamically.

[ck3D]

Reaper_Man, on 18 February 2023 - 08:08 AM, said:

In the case of the Liztroop, the palette is always forced to 22 if it isn't already set.

Oh no way, so that explains the whole blue uniform in the base .art and editor, green uniform in the game pseudo-mystery. I'm trying to remember how the troopers looked in every possible port now, off the top of my head Duke Nukem 64 still had the blue ones even in game. Now I can imagine that they only gave the Liztroop base sprites a blue uniform so that it would be palette friendly and wonder if that means they ever actually had plans for the blue ones (or other colors), but realistically the green swap sounds more like a quick afterthought to help convey 'trooper' in the enemy's aesthetic (and also completely polarize them in reference to the red ones on the color wheel).

[MrFlibble]

ck3D, on 18 February 2023 - 10:33 PM, said:

wonder if that means they ever actually had plans for the blue ones (or other colors)

It was quite a widespread practice for sprites with swappable palettes to use some kind of default "neutral" colour in the data files, which might not coincide with any colour seen in-game for those sprites.

For example, in StarCraft the remappable areas of units and buildings are in gradients of some pink-purplish colour in the game data, which is never used in any player colour scheme.

In Red Alert, all units and structures have the gold colour in the game data, like GDI in C&C, even though this is not the default colour scheme for any side in the single-player campaign.

in Daggerfall, all player paperdoll clothes that have colour variations are blue in the game data (although that is one of the colours which appear in the game).

I also have a vague memory of some game where the remappable colour was a slightly lighter or darker version of one of the colours used in-game, but I cannot remember it right now.

[jimbob]

i remember raiden in MK being like green or red, despite that not being his natural color.

[edit] wich i realise has no bearing on duke whatsoever... but anyway.

[brullov]

While searching for the info for my upcoming video about interesting Duke Nukem 3D art facts, I found the source textures for the signs. They are even in the same order in the game as in this catalog. It is Autodesk Texture Universe, released in 1994. Unfortunately, I can not find it online or a CD version to buy. Maybe somebody has access? I'd love to check it.

[ck3D]

Would anyone on here happen to have the specific castle.map this gentleman here says he has been looking for for years, the one which apparently was most prominently featured in the Prima guide?

[Fantinaikos]

Someone ever heard of '96 Crazy Drake before? It is, well... pretty obvious what the cover art is a parody of.

Should be an Earthworm Jim inspired platform with "6 episodes, with over 20 levels, 6 bonus levels and 6 special levels and one supersecret".

[MrFlibble]

I played the shareware version but this is the first time I see this cover art. Nice!

[Gargoyle]

I was playing through E2 for the 69th time and while blasting octabrains with the devastator in the E2L7's waste tunnel, this wall opened up:



Mind was blown but I do recall opening this wall before, maybe in one of my earliest playthroughs. Always went for the red door above because of the kills.

[Fox]

I always went through the wall

[NNC]

It took me like 10 years to find the shrinker in Warp Factor. That was, IIRC my latest discovery in the game. The jetpack in Raw Meat and the caribbean wall with expander ammo in Derelict were also very late discoveries.

[Aleks]

The Watchtower, on 02 June 2023 - 11:10 AM, said:

It took me like 10 years to find the shrinker in Warp Factor. That was, IIRC my latest discovery in the game. The jetpack in Raw Meat and the caribbean wall with expander ammo in Derelict were also very late discoveries.

Wow. While the shrinker in Warp Factor and expander ammo in Derelict were "always" quite obvious to me, I had no idea about the jetpack in Raw Meat, just checked and noticed it - incredible

[Gargoyle]

Before the previous discovery, my latest finds were the fake wall with the armor and the scuba gear in E1L4 and the underwater RPG in the same level (learned both of these from BMD's walkthrough 4 years ago). Also, chaingun ammo in the toxic waste secret in E1L6.

[Doom64hunter]

Aleks, on 02 June 2023 - 11:44 AM, said:

Wow. While the shrinker in Warp Factor and expander ammo in Derelict were "always" quite obvious to me, I had no idea about the jetpack in Raw Meat, just checked and noticed it - incredible

The jetpack?





Which one?

Yeah I didn't know about either of them until I checked.

Another one I only found a few years ago was the freezer ammo with an atomic health and armor behind the fake walls in the center pool in E2L9.

[Aleks]

Doom64hunter, on 04 June 2023 - 06:33 AM, said:

The jetpack?

duke0000.png

duke0001.png

Which one?

Yeah I didn't know about either of them until I checked.

Another one I only found a few years ago was the freezer ammo with an atomic health and armor behind the fake walls in the center pool in E2L9.

I definitely meant the one from the first screenshot, which I only checked in Mapster yesterday. Not sure about the second one, but it's something I vaguely remember, so might have found it at some point.

[Gargoyle]

Doom64hunter, on 04 June 2023 - 06:33 AM, said:

duke0000.png

Another one learned from BMD which I totally forgot. Need to DM E3L1 more.

[ck3D]

I just found a new Build quirk I wasn't aware of before; it's known that elevators and rising/lowering floors will carry sprites that are directly inside the sector, but I've realized traveling cranes also counted as such (as moving sprites, they adapt to sectnum). That means by placing elevators in the path of a traveling crane, it's possible for Duke to diagonally offset the crane's movement even when the crane is carrying another sprite, or even Duke himself, for however long the traveling crane crossing the elevator takes. The crane seems programmed to return to exact fixed points, which means it will get stuck against walls if it can't directly travel to reach it anymore until the elevator is triggered again (and then the second there's leeway again it will zoom past and keep going). On the other hand, that means it's a consistent effect, you can't really mess it up, just like elevators too are generally pretty consistent, which means it's possible to sort of have some control over those diagonal shifts with the occasional obstacle. When Duke is being carried, the player can't move or face anything but directly ahead, but they can still shoot and use and thus activate the elevator underneath them again to escape the softlock (and so the elevator should be directly underneath the obstacle, and generally it should be manual). It's probably possible to pin enemies onto walls like that too, so that they stand still but I haven't tested that yet.