Rising Gate Trick

I have not seen this technique done in any wad except one, but I wondered maybe if you have. This is a trick where you use MIDGRATE or some other texture rise up. Since these textures can only be used as main textures, this is something I could never figure out.

I saw this trick done in E3M1 of "2002: A Doom Odyssy." It was recommended to me by a friend as we discussed the pop-up monster technique. The trick is done by putting one door-like sector in, and then creating a second sector inside it, which ends up being diamond-shaped and having its side vertexes hooking up to the center of the door tracks (but the other two sitting freely inside the first sector). Also, this inner sector has another linedef running through it, which has the gate texture on its front and back; that's what you see. The outer sector (the "door") has normal floor/ceiling heights, but the inner sector (the diamond) has a ceiling one unit above the floor. I've found that HOM's are created when you have the ceiling exactly on the floor (go figure). Because of the ceiling height difference, the center linedef, the gate, has to have a Y offset of the height of the texture you used, -1.

Unfortunately, the only trigger you can use for this inner sector is Ceiling: W1: Up to lowest ceiling. But it works - mostly. Except when it's about halfway up, I can see the floor texture rising with it briefly. That never happened in 2002:ADO.

Has anyone else played that wad or done this trick? Can anyone tell me why I got this little bug and 2002:ADO didn't?

Something similar can be found at DooM World's editing pages , but it's cool that you discovered this trick on your own.

Team TNT's Eternal DooM also contains at least one "rising" gate, but that does not use vanilla DooM.

You can use SR "door" specials too. Make it more like the DW link REX gave. As you can see, the shape does not have to be diamond - I think that was the shape the 1st time it was done (95? or so) - turned out simpler variants worked too.

All basically the same idea. For BOOM, the 242 linespecial is easier to use and you never get "flash". For ZDOOMHEXEN this is 209.

It's always cool when you finally figure out how to do something that is not obvious. There are probably more tricks to discover - all it takes is interest and time.

netnomad312 said:
when it's about halfway up, I can see the floor texture rising with it briefly. That never happened in 2002:ADO.

Has anyone else played that wad or done this trick? Can anyone tell me why I got this little bug and 2002:ADO didn't? [/B]

It could be this...
Make sure that the front and back of the linedefs are assigned to the same sector (the sector that's producing the 'ghost' floor texture). I had a similar problem with the fake bridge trick (also seen in Eternal Doom, and quite a few other wads nowadays) which was fixed by making both the back and front sides of the linedefs point to the same sector.
e.g. if the ghost floor sector is numbered 1, make the front and back of it's linedefs point to sector 1.
I should probably point out that Cyb told me about that. Credit where credit's due, an' all.
Hope that helps.

Er... I tried that, just with one linedef, and it opened the sector.

I recently figured out that I could also do doors, but I'll still check out that link. BTW, I am not using any source ports, and that's deliberate; I'm appealing to the widest audience with a megawad done in plain vanilla.

As I said, doing that to one linedef opened the sector, but now I've figured out that doing that to all of them makes the inner sector have a zero or one sides error.

In the level, the inner sector is 29 and the outer sector is 28. When I set all the diamond's linedefs to have 28 as both sectors, I got the zero or one sides error. When I set them to have 29 as both sectors, I got no errors, but the sector would not rise when I walked over the right linedef. Am I doing it wrong?

Hmmm.
Well, using the vanilla Doom engine shouldn't make any difference, (Eternal Doom uses the original Doom 2 engine).
I've done the opposite to you in a wad I've just finished, where the sector lowers, rather than raises. That trick I got strait from Eternal Doom, so you should definitely check that out. It's quite fiddly to implement, and it involves a few dummy sectors.
There aren't any no lines errors with this trick, either.

There's another complication now. I tried using giving door triggers to the inner sector, but it didn't work. I used W1: open/close(turbo) on one linedef on one side of the door, and then had a switch on the other side which did the same thing. When I tried it, I ran over the right linedef but nothing happened. Then I walked through the wall (using idclip) to the switch and pressed it. The gate tried to open, but didn't; instead I couldn't see through the gate anymore, just HOMs. Should I have redone the sector to do the door trick? I'm still using the diamond thing I was using earlier.

That's a quite ancient trick, and there are a couple of old megawads that use them (although only sporadic). This is how you make transparant doors.

Yes, I've been there already... the problem is, I don't have either of those node builders working. I don't think this is the problem, because I would at least see the door rise. But it doesn't.

Can you tell me what the command line for BSP 5.0 is? I'm using WadAuthor and I need that command line. But every time I run it it says I have too many arguments. Weird.

netnomad312 said:
Can you tell me what the command line for BSP 5.0 is?

BSP.EXE input.wad output.wad

That was what I tried:
C:\Program Files\Doom II for Windows 95\bsp.exe $_Wadfile $_Wadfile

Says "Argument list too big." It tries to run dos4gw.exe, then it gives me that message.

That's because you are using long filenames. WA doesn't put the name in quotes, so BSP barfs. Solution it to put your PWADs in a folder where the name is no longer than 8 characters and has no blanks.

Why does the 8 character thing matter? If, for instance, I saved stuff in C:\Wadauthor, it would say C:\Wadaut~1\whatever.wad.

I'm not great with DOS... do you know how to copy in DOS? I'd like to create a user tool which will copy the wad I saved into the Doom II folder.

I remember that trick. It was in H2P and MM2.

netnomad312 said:

Why does the 8 character thing matter? If, for instance, I saved stuff in C:\Wadauthor, it would say C:\Wadaut~1\whatever.wad.

The problem is that when the application is reading your command line it is not reading the truncated version that you indicated.

I'm not great with DOS... do you know how to copy in DOS?

(Drive):\(Path)>copy (full filename) (Destination drive):\(Destination Path)\(file name optional)

I'd like to create a user tool which will copy the wad I saved into the Doom II folder.

I'm not quite sure what you mean by "wad I saved". Are you talking about saving a wad as part of a map editing process? If so, from your editor you can specify the path that you want it saved. If you're talking about BSP as an external node-builder from WadAuthor, the same thing applies. If you're talking about running BSP from the command line then you can specify the path there.

netnomad312 said:

Why does the 8 character thing matter? If, for instance, I saved stuff in C:\Wadauthor, it would say C:\Wadaut~1\whatever.wad.

Well I'm assuming you changed the nodebuild to use an external nodebuilder. That does what I said - quotes are missing. You can, however, make a new "tool" and put in exactly the same parms and that will work since it uses the short 8 filename equivalent.

I'm not great with DOS... do you know how to copy in DOS? I'd like to create a user tool which will copy the wad I saved into the Doom II folder.

Normally you don't need to put PWADs in the DOOM folder though - just gets messy:)

If you really want to anyway, create a copywad.bat file that contains:(you can't use a WA tool since using $_Wadfile gives the whole path):

copy c:\myfolder\%1.wad c:\doom2\%1.wad

To test just type: copywad mywad either in start/run or from a command line window ("dos").

c:\myfolder = your folder name containing pwad
c:\doom2 = your location for DOOM2

You could probably put cmd.exe for XP (or command 98x) as a tool in WA to get to the command line prompt.

I'm assuming you wanted to do this for various pwads, not just one (hence the %1 variable). If you want to do this for only ONE pwad all the time, then just make a tool in WA that contains the "copy c:\myfolder\mypwad.wad c:\doom2\mypwad.wad".

Oh - last thing - if you don't use long filenames, it's a bit simpler too - you can use the regular external replacement code:)

So:
copy c:\myfolder\%1.wad c:\doom2\%1.wad
is all I need in the batch file? I don't use any $_Wadfile in there?

I'd like to be able to run my batch file from WA, but do I need to give it parameters (like $_Wadfile)?

Also... BSP isn't giving me an error. Now that I'm saving everything in C:\Wadauthor, it says:
Error: Cannot open WAD file C:\Wadauthor\tower.tmp.

tower.tmp should be tower.wad :P

That's what I thought. In the command line I put $_Wadfile twice. My command line:

C:\Wadauthor\bsp.exe $_Wadfile $_Wadfile

And then I still have to test my little batch file. *Sigh...* I wish node building didn't play such a huge part in how the level runs...

What's with $_wadfile? Why not just bsp.exe tower.wad <insert wad name here>

Because I'd rather not change the tool execution with every wadfile. But for now that's worth a shot...

netnomad312 said:

So:
copy c:\myfolder\%1.wad c:\doom2\%1.wad
is all I need in the batch file? I don't use any $_Wadfile in there?

You can't use $_Wadfile since that would replicate the complete path. It's a bit of a PIA since you have to MANUALLY type in the batch file name and the filename (minus the wad part). Read on.

I'd like to be able to run my batch file from WA, but do I need to give it parameters (like $_Wadfile)?

See above - that's a no go.

Also... BSP isn't giving me an error. Now that I'm saving everything in C:\Wadauthor, it says:Error: Cannot open WAD file C:\Wadauthor\tower.tmp.

"Wadauthor" is MORE than 8 characters, maybe that's ok? I was trying out your name, but I'm having brain fade and can't double verify with that name - however, 9 is technically a long file name. Is your pwad in that folder?

Since you've done that, easy fix: make it WA (instead of Wadauthor) and we know for sure:). Put all your levels in folders that have 8 or fewer characters with NO blanks and all your problems go away. DOOM2 also has problems here.

Although I would do the above, you can do the BSP thing IF you make a custom WA tool containing BSP.EXE - that works with $_Wadfile $_Wadfile even with long file names. Don't ask why it's done 2 different ways:)

Well, I tried just making a batch file for the one wad, and that worked. But you know what sucks? Nothing changed? If you look up my thread "When offsets don't work..." someone told me that I needed a better node builder and reccomended BSP. But there are still places where the textures are displayed wrong as if I had given them offsets that don't make sense (ex.: in level 11, two crate sides are displayed as if they had X-offsets of 32).

I still have to test out that BSP method on that page that ReX gave me. I'd like to point out that using BSP didn't fix my ghost sectors, either...

netnomad312 said:
Nothing changed? If you look up my thread "When offsets don't work..." someone told me that I needed a better node builder and reccomended BSP. But there are still places where the textures are displayed wrong as if I had given them offsets that don't make sense (ex.: in level 11, two crate sides are displayed as if they had X-offsets of 32).

Your nodesbuilder does not have anything to do with texture offsets. The way a texture gets 'wrapped' on a surface also depends on the kind of surface... upper textures (eg. on raised ceilings) usually get drawn top-down, starting with the top of the texture. Lower textures (lowered/raised floors such as steps, crates) get drawn bottom-up starting with the bottom of the texture. But, if you mess with the upper/lower peg flag ("let's force that texture to be drawn bottom-up") you sometimes don't get the desired result if the total floor/ceiling height difference isn't a multiple number of the texture height. I found this usually happens when you have more than one texture on one sidedef, but I never really investigated this as I just play around with offsets/flags until it works.

True, buy what about X offsets? That's the big problem...

netnomad312 said:

True, buy what about X offsets?

As Mordeth indicated, nodebuilding does not affect texture alignment and offsets, including x offsets. Occasionally, because of the lower or upper unpegging problem mentioned by Mordeth on textures (i.e., when they're not multiples of the texture height) the textures look mis-aligned.

Perhaps you should post a link to the section of your map where this problem is occurring. (I.e., copy the section into a new wad, and make that new wad available for people to look at.)

I meant, the unpegged tags should have nothing to do with the X offsets. Neither of the crate sides had any tags at all except two-sided.

Well, here's a picture of the error. If you still can't figure out my problem, then I'll make a wad...



(Edited a few minutes later...)
Looks like there's something wrong. Okay, just open this link in a new window...
http://www.geocities.com/netnomad312/ERROR.jpg

netnomad312 said:

I meant, the unpegged tags should have nothing to do with the X offsets. Neither of the crate sides had any tags at all except two-sided.

You're right about unpegged stuff not having anything to do with the x offsets (except that textures sometimes look misaligned).

Well, here's a picture of the error. If you still can't figure out my problem, then I'll make a wad...

The picture suggests that an x offset has been applied to the crates. Is it possible that you're using a wad with a CRATE texture that has an x offset built into it as a default? EDIT: No that wouldn't be the reason -- I looked at the picture again, and other crates seem to be fine.

It looks as if the linedef representing the side of the crate has been split, and a 32 unit x offset has been applied to the first line segment.

I guess the only way to tell for sure is to actually open the wad in an editor. So if you can make the wad (or section of it) available, someone may be able to help you.

Gah! You know what? I was looking at the front sidedef the whole time, while for some reason the back sidedef does have an X offset of 32. Boy, do I feel stupid now...

Anyway, I've decided that the BSP thing isn't going to happen, either. I tried it, and not only did I get open sector errors on "sectors 4 and 5," but the linedef between sectors "2" and "1" kept blocking me, and displayed a HOM. But the ceiling was 128... anyway, I don't want any open sectors, so I'll just have a W1: Up to highest ceiling again.