alias conrad coldwood, on 16 September 2014 - 11:19 AM, said:
_SE.MAP, room 11 (first column, second row), that's how 3D Realms build doors. The true problem is the misplaced sector effector (it's right on the shared vertex), that's why it's glitching out. Oddly it doesn't cause problems in EDuke. Because Build doesn't use floating point (and it can't be a precision issue), my guess it that Build thinks the sprite is located in the neighbour sector, while EDuke think it's in the door sector... I might be wrong.
About the sprite, that's what I thought at first, but it doesn't seem to make sense to me. After all, wouldn't it work only if the other sector would be tagged as a swing door?
For buildings doors that way, I'm not 100% sure about linking the door to an adjacent wall (it does work in some cases but I doubt it's recommended and people usually avoid to do that. I think it can easily cause issues if you decide to join or delete sectors).
However it is a Build rule to never put 2 vertices in the same physical space, because it's very likely to corrupt your map. I usually put swing doors or SoS sectors as close as possible with the grid unlocked (the space between both points would be "1"), like this the difference isn't noticeable to the player and it avoids any potential issue.
Original game maps aren't very good examples because a LOT of them are corrupted, they just didn't know it; I wouldn't be surprised if they got tons of glitches and had no idea what caused them. Though now we do know what can cause corruption so it's better to avoid it...
Anyway, the map is great and I was only doing this because I really liked it and had your consent and you don't have Megaton, so I was just trying to help.
But I'll take your fixed version, and try what you said for the curtain sprites, and upload that on the Workshop. Your map after all so it makes sense.
Don't feel bad about it, myself I only learnt a couple of months ago that to make a vanilla map, it's FAR from being as simple as 'not going over the old limit'. People tend to think that it's as simple as 'not using any EDuke32-only feature', but it's not, since EDuke32 has its shares of improvements and behaviours which are slightly different from the original game, either intentionally or not.
People tend to forget that in vanilla, you can't floor-align every kind of sprites, that you can't put a texture with transparency behind a transparent mask wall (or else the 'transparent' part of the texture behind the mask wall will appear pink rather than black), that you can't put non active sprites on subway trains or other moving sectors, and that some effects behave slightly different depending on how you use them, and that the more you combine different effects together and use them in non-intended ways, the more likely it is that it won't behave the same in vanilla.
The problem is that nobody fully really knows the difference and that you can only learn it the hard way.
It would be a good idea to start documentation on the matter though, the problem is that I doubt anyone knowledge-able around here will care enough for non-Eduke32 compatibility.
In my case it was too late to come back and change the map when I found out some things didn't behave the same, but in yours it was still easily possible, so it's no big deal really.
Hope you make another map soon. They're everything I want to see in a DN3D map, they could almost belong in a Sunstorm Interactive add-on, and that's the biggest compliment I could ever give as far as a Build map is concerned.