[pepsodent]

ck3D, on 25 March 2026 - 11:33 AM, said:

an editor quirk that maybe was or wasn't fixed but happened for a while recently; seems to happen when the sector containing the sprites is large and/or the spritework is complex, say you split it after the (sprite arte-)fact to draw a shadow and boom half the sprites suddenly belong to the wrong sector out of the two but they haven't moved, just inherited incorrect sectnum relative to pos. When that happens can just select all the affected sprites (even walls in the area, can be a useful anchor if locked onto grid and you really don't want to move anything) and just click without moving mouse, instant recheck. Now obviously that means if you have manually changed sectnum somewhere the check will also reset that.

this happens if you have expert mode on, which disables automatic sprite to sector ownership correction. Say you got a sprite with certain owner number, but then you have some splits and new sectors in the area and so those sectors switch their numbers around but those sprites will still have same old owner number that now belongs to some other sector. By default mapster autocorrects this but that feature is turned off with expert mode so you can have some sectnum abuse.
At least thats what I think is happening, I noticed that quirk when making the last bits of Weather Report, just as I turned expert mode by that point. And yeah clicking them in 2D mode sets correct ownership to fix the issue.

[ck3D]

pepsodent, on 25 March 2026 - 12:55 PM, said:

this happens if you have expert mode on, which disables automatic sprite to sector ownership correction. Say you got a sprite with certain owner number, but then you have some splits and new sectors in the area and so those sectors switch their numbers around but those sprites will still have same old owner number that now belongs to some other sector. By default mapster autocorrects this but that feature is turned off with expert mode so you can have some sectnum abuse.

You don't need expert mode on for the splitting bug to happen, clearly I've gotten it multiple times before in the default settings that I use 99.99% of the time. You (and Aleks) are correct about what's happening in your situation when expert mode is on and you manipulate stuff, but I assure you it can also happen just in 'normal' settings splitting the wrong sector where it's a bug (maybe already is fixed by now). It is rare though, and to happen feels like it needs excess somewhere in the mapping process that might mess with memory (?), i.e.. recalculation of too much during the split.

[unedukecated]

Well sectnum for that certrain sprite is correct, I even deleted it and placed a new one and yet nothing helps. I guess it's kinda HOM, must have messed up sector work there somehow like drawing a new one around a smaller one or similar. Whatever, I hope it's not really noticable.

Aleks, the trick with the view-aligned sprite inside sprite structures works like a charm, thanks! I also didn't know about clipdist.

[ck3D]

HOM is something very specific, it happens when there is a sector rendering error e.g.. multiple SOS layers visible at once (no TROR), or mirrors the reach of which clash together (it has to do with player position and detection, there is a strange science to them when you are going to use several of them in the same map, maybe that already is something you suspect given IIRC 7GHUB had a couple of mirrors that broke). Engine doesn't know what to draw so renders nothing but repeats what it already has in memory, kind of insists to print it over and over into the sector space until it's out of sight again, results in the 'solitaire' effect. If that isn't what you are getting then it isn't HOM (and to clear up any possible confusion, HOM/Hall Of Mirrors is the visual description of a problem somewhere but never the problem itself per se, it is the symptom and notification of an underlying error, doesn't happen at random), I am intrigued now though, shouldn't refrain from posting 3D screenshots with problem in/out and 2D map screenshot of that area of the level (in spoilers if you wish) in order to possibly receive further help.

[lllllllllllllll]

Puke Fukem, on 26 March 2026 - 03:20 AM, said:

Well sectnum for that certrain sprite is correct, I even deleted it and placed a new one and yet nothing helps. I guess it's kinda HOM, must have messed up sector work there somehow like drawing a new one around a smaller one or similar. Whatever, I hope it's not really noticable.

Aleks, the trick with the view-aligned sprite inside sprite structures works like a charm, thanks! I also didn't know about clipdist.

Does the sprite only disappear in the extra margins in widescreen?

[unedukecated]

lllllllllllllllllllll: no

ck3d: You asked for it! Sprite is a doortile being pushed up between 2 walls (door sector), Screens are the way they should be, but the doortile expands itself up above the bright wall as if it's transparent. But only if you are in sector marked with "1", if you come closer to the door everything is normal.

Bonus: from sector marked with "2" the transparent curtain sprite left of the door sprite suddenly becomes much brighter altho it should be darker the further you are away from it. I suppose it's the same issue, not HOM. I sometimes like to add more sections to previous sections. Not sure if you can work with these screens.

Everything normal:


Doortile almost fully visible ingame from sector marked "1":




Door sectors, 2D:


Bonus:

ingame it's way too bright, compared to "everything normal" screen:

[ck3D]

Oh it may not be a map bug per se but a construction thing. Someone who actually can run Polymer would have to confirm, but I would imagine maybe the rendering of sprites works the same as, or comparably to software/classic? In any case, in classic/base game settings you simply can't overlap sprites or they will clip through one another with different priority depending on view angle (and so also distance etc.), which is also why 3D spritework in theory always should be 1-way sprites (or you'd get say sides of box/crate drawing wrong/visually clipping). Polymost 'fixes' that in that it forces the right drawing order no matter what and so it 'allows' for shortcutting of process and tricks such as sprites only partially clipping through structure etc. at the cost of breaking the visuals in classic/software, and maybe in Polymer too I'm wondering? Realizing you probably developed 7G HUB in Polymost (but maybe you didn't), I hope this isn't a case like I've lamented seeing in the past where someone has developed undesired mapping habits because of the Polymost 'fixes' not realizing that the behavior was Polymost specific (thankfully if that is the case should be easy to unlearn/adapt).

It's a bit difficult for me to tell what exactly is going on in the 2D shot in the sense that I would imagine several sprites overlap in one spot (either way the placement still looks like it would be glitchy in classic; now Polymer?). Also to prevent some other undesired visual clipping like Aleks has described before, it is (annoying but) efficient to develop the habit of never applying sprite directly onto wall but always drag there as close as reasonable (i.e.. couple of Build units) with grid lock off. Otherwise Polymost likes to make the wall chew on the sprite as Duke walks and it looks terrible (almost every Blast Radius update I've made for the past two years or so has been to adjust instances of that stuff for Polymost compatibility purposes, since of course that is Polymost behavior I observed existed late).

EDIT - Oh looking at 3D closer I think I see your problem. It indeed would be because your sprite is flush with the wall. Right now it's exactly on the wall so engine can't decide whether it should draw or not depending on sectors on sight. That would mean it's a sectnum thing fundamentally but you couldn't track that down not knowing why the sectnum should be different. I'm still struggling to decipher the way you constructed this a little though, what's a sprite and what's not. I suspect you would need a narrow independent sector somewhere in the equation to hold the sprite for your contraption to work depending on what you did.

Not too sure I get what is too bright in the bonus screenshot either but if the problem is a given sprite (or wall, etc.) doesn't blend in with the rest of the vis fog then must be because it has a brighter shade value (numerically lower) than 0.

[unedukecated]

Funny, in classic/polymost the sprite is displayed correctly always from anywhere. But the curtain isn't, it's missing 3 sprites and there is only 1 left. I always check sprites now via playtest, and if wall sprites become buggy I move them around, usually 1 grid at smallest grid size too lazy too turn gridlock on/off all the time. This always helped so far, but not in this specific case. It's not a renderer problem I'd say, it's a sector construction mistake methinks since it really only happens in certain sectors while the sprite is correctly displayed from all angles in other "working" sectors. Just like it was in some other area until I magically found a way to fix it there. And I'm sure it's also happening elsewhere in the map too, so: whatever, as long as it doesn't corrupt the whole map and as long as it's not a major gameplay issue I'll leave it for now as is and maybe come back later if I don't forget. It's really nothing, but yet it really bothers me.

About the "bonus" curtains sprites: compare screenshots 2 and 5, 2 is closer to the curtains than 5 and you can barely recognize the curtains/color, now moving back (!), meaning distance is farther away the curtain sprites suddenly become much more visible and brighter in sector "2" - it should be get even darker and even more unrecognizeable the farther you are away. Similar problem to the doortile sprite.

[lllllllllllllll]

If the sector is bad (the one you are standing in) trying to merge it makes the highlight appear as if to select between overlapping sectors or an error over trying to join non-adjacent sectors come up

A shift+CTRL+enter might not hurt either

[Aleks]

Puke Fukem, on 26 March 2026 - 12:34 PM, said:

Funny, in classic/polymost the sprite is displayed correctly always from anywhere. But the curtain isn't, it's missing 3 sprites and there is only 1 left. I always check sprites now via playtest, and if wall sprites become buggy I move them around, usually 1 grid at smallest grid size too lazy too turn gridlock on/off all the time. This always helped so far, but not in this specific case. It's not a renderer problem I'd say, it's a sector construction mistake methinks since it really only happens in certain sectors while the sprite is correctly displayed from all angles in other "working" sectors. Just like it was in some other area until I magically found a way to fix it there. And I'm sure it's also happening elsewhere in the map too, so: whatever, as long as it doesn't corrupt the whole map and as long as it's not a major gameplay issue I'll leave it for now as is and maybe come back later if I don't forget. It's really nothing, but yet it really bothers me.

About the "bonus" curtains sprites: compare screenshots 2 and 5, 2 is closer to the curtains than 5 and you can barely recognize the curtains/color, now moving back (!), meaning distance is farther away the curtain sprites suddenly become much more visible and brighter in sector "2" - it should be get even darker and even more unrecognizeable the farther you are away. Similar problem to the doortile sprite.

I generally never put sprites directly on the wall, the surest way to correctly place them is to put them whatever number of units ahead of the wall and press "O" to ornament them on the wall.

But in your case, I'd leave it as is as this is nothing game (or map) breaking, maybe you will be able to iron this out during beta tests.

[ck3D]

Aleks, on 27 March 2026 - 11:17 AM, said:

I generally never put sprites directly on the wall, the surest way to correctly place them is to put them whatever number of units ahead of the wall and press "O" to ornament them on the wall.

IIRC, O will plaster them back onto the wall and it is shift + O (I think, maybe in 2D mode only) that only modifies their angle without any displacement (at least something like that used to work in older Mapsters, maybe is obsolete now). I try to avoid automatically forced sprite angles whenever I can, I find the O method just as sketchy as sticking directly onto wall for it seems to make bad roundup in the calculation when walls are diagonal, mimicking it on purpose in practice means 33% of the time the angle is correct, 33% of the time is one unit off, 33% of the time is two units off or something (guessing by the raw number of super fast key jabs it takes to fix each instance). Of course in practice sticking directly to walls/O is the fastest way to get as close to the desired angle as possible but it should always be rechecked/adjusted or you risk weird stuff in this or that renderer, most of which will never matter to anyone but the map maker but hey.

Also placing sprite directly onto wall in 3D mode has the consequence of resulting in inconsistent sprite Z's which can result in switches 'mysteriously' not working and yadda yadda (unless manipulated after the fact to fix).

[unedukecated]

@ llllllllllllllllllll: thanks, I've tried joining sectors to find the broken one but no luck so far, the problem is it's near a destructible building made of quite a lot of smaller sectors

@ Aleks: thanks, I will leave it for now. I never use "O" for wall ornament, 1 sprite directly on wall should always be fine, but if you want more you need a gap between them or at least one of them will flicker, either 1 grid at smallest grid size or turning grid lock off and put them close to the wall manually. I use playtest a lot more often now, like after placing several sprites. To check if they flicker, are properly aligned and all that stuff. I was using full screen Mapster all the time before, but no more.

@ ck3d: thanks, Build/Mapster works in mysterious ways sometimes. At least that's what I think from time to time. Good to know there are still so many undocumented info and tricks all around their features. I will see if I have time to watch a bit of TLOD stream today, you anarchist!

[ck3D]

Yes using grid lock off (for any placement of sprites that I don't want for certain anchored onto precise spots, e.g.. effectors, pivot points) and then just dragging away from wall is how I do it too and it's the fastest way, technically you still risk the slight angle offset I was mentioning earlier but usually the distance from wall is enough to cancel out the clipping because the bad roundup is so small. Still there are some instances where the wall is at an especially weird angle where it is better to rectify but well you would see it.

It is going to sound nitpicky but that is the engine not me, as much as it is good practice to drag away 1 unit from wall it is even better to drag away 2 units from wall (then don't need any further), the reason again being bad roundup somewhere that makes the engine hate exactly one-unit width gaps (also between walls, etc.), for instance if you have a one-unit gap between two disjointed red walls there is a big chance the back one will render in front of the front one with enough distance and/or specific angles, whereas if you just pull away one notch further somehow magically fixes the problem (the possibility of the glitch has a lot to do with the wall lengths too). One of those Build oddities that are so niche not so many people get to bring them up but may be useful to know in the future if you're going for fine sector work style.

Regarding your sectors that do not fade away with the rest and thus look brighter with distance, again check your shade values, they shouldn't be anything in the negatives. If that is not it then check if sector visibility is consistent with the rest of the surrounding sectors, if not select the sectors that are too bright (or dark) and use 3D mode Alt + (Shift for small increments +) Mouse roll/scroll to adjust. I don't think you have broken sectors anywhere (doesn't seem like it to me at least), I highly suspect it is either of those things.

[unedukecated]

ck3D, on 28 March 2026 - 09:08 AM, said:

Yes using grid lock off (for any placement of sprites that I don't want for certain anchored onto precise spots, e.g.. effectors, pivot points) and then just dragging away from wall is how I do it too and it's the fastest way, technically you still risk the slight angle offset I was mentioning earlier but usually the distance from wall is enough to cancel out the clipping because the bad roundup is so small. Still there are some instances where the wall is at an especially weird angle where it is better to rectify but well you would see it.

It is going to sound nitpicky but that is the engine not me, as much as it is good practice to drag away 1 unit from wall it is even better to drag away 2 units from wall (then don't need any further), the reason again being bad roundup somewhere that makes the engine hate exactly one-unit width gaps (also between walls, etc.), for instance if you have a one-unit gap between two disjointed red walls there is a big chance the back one will render in front of the front one with enough distance and/or specific angles, whereas if you just pull away one notch further somehow magically fixes the problem (the possibility of the glitch has a lot to do with the wall lengths too). One of those Build oddities that are so niche not so many people get to bring them up but may be useful to know in the future if you're going for fine sector work style.

Regarding your sectors that do not fade away with the rest and thus look brighter with distance, again check your shade values, they shouldn't be anything in the negatives. If that is not it then check if sector visibility is consistent with the rest of the surrounding sectors, if not select the sectors that are too bright (or dark) and use 3D mode Alt + (Shift for small increments +) Mouse roll/scroll to adjust. I don't think you have broken sectors anywhere (doesn't seem like it to me at least), I highly suspect it is either of those things.

I do with 1 grid only, check via playtest walking around, changing angles. If all is fine, it's fine. If not: change something. Only if I have multiple sprites on the same wall and like the same position I do 1 wall sprite, 1 grid gap then next sprite and repeat...

About the sector thing: it's not shading, nor sector visibility. Curtains automatically become brighter if inside that broken sector, or one next to it. If you move to any other nearby sector the curtains stay dark and never change their look - the way it should be. Same for the doortile, part of it is hidden because the sprite is stuck inside a sector between 2 red walls. Now if you look at that wall from a close sector (as seen in 1 of the screenshots) everything is fine, but if you move to that broken sector(s) the invisible part shows up through the wall...

Edit: how the fuck do I make that headlamp stay on the ceiling? (which is a sprite). I can only get it working if I stuck it onto a wall which makes no sense for a ceiling lamp.

[lllllllllllllll]

Is the transparent glass pane a masked wall in the center of the window with a curtain sprite right on top of it?
Even though they are both transparent maybe that is causing problems.

[ck3D]

Puke Fukem, on 28 March 2026 - 10:15 AM, said:

Edit: how the fuck do I make that headlamp stay on the ceiling? (which is a sprite). I can only get it working if I stuck it onto a wall which makes no sense for a ceiling lamp.

Assuming you mean that one Atomic edition Duke Burger lamp thing. 2D mode select sprite, insert to copy, 3D mode point at sprite copy, hold click, (B and H if sprite wasn't already blocked/hittable), R x2 to make flat, change to non-actor tile / let go of click; point at top of sprite, hit 1 if sprite isn't one-sided with top visible, hold click, shrink to smallest size possible, ; I to make sprite invisible (just I toggles invisible sprites on/off in 3D mode, invisible sprites show up as green/transluscent). Will make a little invisible platform that is pixel wide and support the lamp sprite. Be mindful Duke can jump onto it if not close enough to ceiling (but can be reasonably low). Won't be able to bump his head against it. Don't move the sprites so they no longer overlap or that might break the combination of tiny sprite + lamp collision. If the lamp still falls to the ground, raise it a little higher or the invisible platform a little lower.

A lot of Atomic edition (especially DB) prop sprites have wonky/bugged behavior in base 1.4D+ that EDuke32 attempts but even struggles sometimes to fix. This specific lamp shouldn't need a modification on the port side though, it's a (poor) game choice (most likely omission), on par with all minibosses but Battlelord Sentries being duds (although I think that was a deliberate choice to reserve space for possible later official story development, WT seemed to confirm that) or calling Trooper AI after getting shrunk (blew my mind way back when Danukem pointed that out for me).

[unedukecated]

lllllllllllllll, on 28 March 2026 - 12:01 PM, said:

Is the transparent glass pane a masked wall in the center of the window with a curtain sprite right on top of it?
Even though they are both transparent maybe that is causing problems.

Yes and no, yes it's a masked wall in the middle of the window, but the curtain sprites are not right on top of it, there is a gap. This can't be it, I'm sure it's some ruined sector work somewhere near there...

ck3D, on 28 March 2026 - 12:24 PM, said:

Assuming you mean that one Atomic edition Duke Burger lamp thing. 2D mode select sprite, insert to copy, 3D mode point at sprite copy, hold click, (B and H if sprite wasn't already blocked/hittable), R x2 to make flat, change to non-actor tile / let go of click; point at top of sprite, hit 1 if sprite isn't one-sided with top visible, hold click, shrink to smallest size possible, ; I to make sprite invisible (just I toggles invisible sprites on/off in 3D mode, invisible sprites show up as green/transluscent). Will make a little invisible platform that is pixel wide and support the lamp sprite. Be mindful Duke can jump onto it if not close enough to ceiling (but can be reasonably low). Won't be able to bump his head against it. Don't move the sprites so they no longer overlap or that might break the combination of tiny sprite + lamp collision. If the lamp still falls to the ground, raise it a little higher or the invisible platform a little lower.

A lot of Atomic edition (especially DB) prop sprites have wonky/bugged behavior in base 1.4D+ that EDuke32 attempts but even struggles sometimes to fix. This specific lamp shouldn't need a modification on the port side though, it's a (poor) game choice (most likely omission), on par with all minibosses but Battlelord Sentries being duds (although I think that was a deliberate choice to reserve space for possible later official story development, WT seemed to confirm that) or calling Trooper AI after getting shrunk (blew my mind way back when Danukem pointed that out for me).

City layout is done, now I need to make million things out of sprites but this is ridiculous. The Hanglight doesn't fall, but the headlamp does fall? Makes no sense!

[unedukecated]

Alright, I have tried that now. Should have come up with the same idead, but didn't. The "problem" now is in that certain spot/room the headlamp is hanging quite low due to kinda low ceiling which leads that one really can jump onto that invisible supporting sprite. I don't like this, I will use the hanglight instead.

Anyhow now something else:
1) how can I make vent sprites indestructible? I googled around but couldn't find a way satisfying. Having a lil vent shaft below a ceiling in some larger room so forcefield or mask wall is not an option. If all fails I will just some indestructible tiles instead.
2) can I make a group of flying sprites hover up and down a lil bit continuously? I know you can make sectors rise and fall but does this support inactive sprites as well? Haven't tried it and before I spend hours on this I'd rather ask here. Thanks!

[Mark]

I've been using Polymer since about 2010. I learned early to move all wall sprites away from the wall by a half of the smallest grid square. I just assumed they will flicker so I move them automatically. And if I have overlapping wall sprites I make sure to move one of them at least a half grid square in front of the other one to avoid flickering. At one time I had someone modify Mapster to drag any wall sprite that half square from the wall by pointing at it in 3d mode and pressing a key. Unfortunately after a couple of years of using it I wanted to update to a newer Mapster and lost that feature. I also noticed long ago that sprites with transparency placed in front of another with transparency will visually glitch from certain angles. I also found sprites with transparency in front of 3d models have a good chance of causing the player view to clip right thru the model.

[unedukecated]

Interesting Mark! Sprite clipping and flickering is really annoying indeed. I hope nothing awful shows up when I now place thousands of sprites to bring many parts to life. Like 12000 left and zero walls left. But Polymer does a good job - most of the time. What really sucks and only in Polymer is that many sprites are like surrounded by a thin black lines. Switch to classic/polymost and they are gone:


Also: wall clip enemy.

[Mark]

I could be wrong but that line on the top of sprites might be a recurrance of an old bug. The bottom line of pixels get drawn at the top. Shortly after it was discovered it got fixed. Then about 2-3 years ago it came back again during a project I was helping with. I mentioned it but got no response from anyone. Its one of the handful of Polymer breaks that keeps me using an eduke32 version from 2021. It also showed in Polymost at the time. I have no idea if its been fixed again or not since I use old versions.

[Mark]

In Mapster have you ever used the F11 key to adjust map brightness to make working in dark areas easier? That was another break that annoyed me. Instead of making the map easier to see, all it did was whitewash the screen. Another big reason I stay with older versions. My maps are usually very dark and I rely a lot on that feature working properly.

[unedukecated]

Mark, on 29 March 2026 - 05:08 PM, said:

I could be wrong but that line on the top of sprites might be a recurrance of an old bug. The bottom line of pixels get drawn at the top. Shortly after it was discovered it got fixed. Then about 2-3 years ago it came back again during a project I was helping with. I mentioned it but got no response from anyone. Its one of the handful of Polymer breaks that keeps me using an eduke32 version from 2021. It also showed in Polymost at the time. I have no idea if its been fixed again or not since I use old versions.

Yeah okay, now who can bring it back?

About F11: a nightmare I also never use. Does anyone? It's good to set shading late like shortly before finishing a newly constructed map, but I also do it earlier to check how it looks like or if I have to change textures. Or maybe make them not too dark at first, shade of 10 instead of 20+.

[lllllllllllllll]

Puke Fukem, on 29 March 2026 - 08:20 AM, said:

Alright, I have tried that now. Should have come up with the same idead, but didn't. The "problem" now is in that certain spot/room the headlamp is hanging quite low due to kinda low ceiling which leads that one really can jump onto that invisible supporting sprite. I don't like this, I will use the hanglight instead.

Anyhow now something else:
1) how can I make vent sprites indestructible? I googled around but couldn't find a way satisfying. Having a lil vent shaft below a ceiling in some larger room so forcefield or mask wall is not an option. If all fails I will just some indestructible tiles instead.
2) can I make a group of flying sprites hover up and down a lil bit continuously? I know you can make sectors rise and fall but does this support inactive sprites as well? Haven't tried it and before I spend hours on this I'd rather ask here. Thanks!

1) Best I can come up with is making them bullet proof using invisible blocked sprites
2) With any luck Float, if not, FloorZ. Make an activator loop with door close delays timed to at least just after the Z finishes moving up or down
Float might be usable if the floor is a skybox texture with the sprites sitting directly on it

[unedukecated]

lllllllllllllll, on 30 March 2026 - 02:30 PM, said:

1) Best I can come up with is making them bullet proof using invisible blocked sprites
2) With any luck Float, if not, FloorZ. Make an activator loop with door close delays timed to at least just after the Z finishes moving up or down
Float might be usable if the floor is a skybox texture with the sprites sitting directly on it

1) funny I didn't thought of using invisble blocked sprites but now I used other tiles and only vent tiles where the shaft is really destructible and accessible (to get items!)
2) I have no idea how to set it up, the floor is water with lotag 1 obviously and a group of sprites is just hovering above, and I want them to float up and down continuously without a trigger but I guess this couldn't work. Whatever, not really necessary but would be cool to have. Anyway thanks a lot for your continous input and help!

[ck3D]

1/ Invisible sprites wouldn't have worked (would have been able to destroy the vent if within hittable explosion radius, which can be large, e.g.. tanks...), but it's good you went for something less potentially misleading. Sometimes when you want an idle version of a specific game object that is simple enough to redraw a simple sector version of, then use the original tile as texture on top of, then that can be a solution that works well (for instance W.A.R.T.H.U.G.Z. in the KTIT building has broken sector fan).

2/ Basic rule is (most) floor movement in Z (so including but not limited to SE31) will also move all sprites inside of that sector up/down (including certain effectors) and respect the offset regardless of their distance to floor (can even start buried way out of bounds, up in ceiling etc.). Can have an ACTIVATOR with an unused channel lotag and SE10 with reactivation delay inside like ||||... told you and it will loop. Remember you can manually edit parent sectnum of sprites so they don't have to belong to the sector they geographically are placed in. (Ceiling doesn't work, always has to be floor.)

Parallaxed floor trick would also work but most likely result in collision issues if the player or other actors can reach it. edit - scratch that, probably wouldn't work due to the strange ways Polymer draws skies.

[lllllllllllllll]

Using the sectnum trick ck mentioned on the sprites and matching their Z to that sectnum'd sector using Float you might get the effect you are looking for. You can see Float in action on Faces of Death in the final room

[unedukecated]

Uhm thank you guys, sound all very technical. I'll see if I can make it work and check Warthugz and Faces of Death maps again, thanks!

[Aleks]

Changing sectnums on items/weapons is not a good idea - it makes them impossible to collect (i.e. each time an item is physically placed outside of its parent sector, it effectively becomes just a decoration).

[pepsodent]

Aleks, on 01 April 2026 - 07:45 AM, said:

Changing sectnums on items/weapons is not a good idea - it makes them impossible to collect (i.e. each time an item is physically placed outside of its parent sector, it effectively becomes just a decoration).

thats interesting. If I could make pickups wall aligned in vanilla game this would be a nice way to make decorative weapons and ammo.