By Lee Killough
>Hey, you guys, I need help! Howda hell do I make switches work?
>I want to press a switch that lifts something elsewhere, but I can't!
>The same thing with crushers and teleport...................................
>How do I manage to teleport to a new sector??????
Welcome to Sector Tags.
Each linedef has a number stored in it called a "sector tag". Sector tags are
used to identify the sectors that a linedef will operate on when activated.
Each sector also has a sector tag. That sector tag is used to "tag" the sector
with a particular number that can be used to identify it in action linedefs.
More than one sector can share the same sector tag, in which case all of the
sectors sharing the tag will be affected similarly when that tag is activated
by a linedef.
To make a teleporter work, you must draw teleporter linedefs (type 97) that
tell Doom that the line is a teleporter crossover point. Then you must draw
a sector where the teleporter will take the player (or monsters).
The teleporter linedef and teleporter destination sector must both be tagged
with the same tag, and is should not be 0. That way, when the player crosses
the linedef, Doom looks at the linedef's sector tag, and the looks for all
sectors sharing that same tag. In the case of a teleporter, you ordinarily
should only use one such sector (I've never tried teleporting to two sectors
at once -- uggh! I might come out in pieces!).
Finally, you must create a Teleporter Destination Thing in the destination
sector. This Thing tells Doom the player's location and direction when they
land at the teleporter's destination. It is similar to a player start.
teleporter
linedef
(type 97) teleporter
tag=1 destination
| sector, tag=1
| ------------------
| | |
| | * |
| | teleporter |
| | destination |
| | Thing |
| | |
------------------
By the way, sector tags are not to be confused with sector numbers.
For crushers, doors, lifts, etc., the idea is similar: you create a
linedef (either a switch, grab, or walk type), and you set its "sector
tag" to a value unique to this event, and not 0. Then you set the sector
you want it to affect to have a "sector tag" of the same value as the
linedef's "sector tag". When you walk over that line, or you press that
switch, or you shoot at the wall, you will be affecting the sectors
that have the same sector tag as that linedef has.
If you get the "no more plats" message and Doom crashes, it means you
tried to create a lift, but forgot to set the sector tag to something
other than 0. As a result, almost the entire level is selected, and Doom
cannot handle lowering the whole level as if it were one big elevator.
>hmm, a lot of my editors are going nutzoid or something, either producing >bad wads that crash or produce HOM and void blurs for absolutely no >reason. it may or may not have to do with the fact that my editors are for >1.666 and my game is 1.9, so i was just wondering if anyone knows where i >can pick up a free editor that works well with v1.9. just a few minutes >ago i made a wad with nothing but one small square sector, and even that >crashed. its so bad its not even funny. Oh, Doom requires at least two sectors (actually, two ssectors). No kidding! This is because the BSP tree must always contain at least one node, and each node needs a left and a right child. Nothing has changed from 1.666->1.9 that should require differences in editors. I would make sure that your wad is not corrupted. If anything, version 1.9 should have fewer problems than 1.666, since the limit on the number of visible segs was increased (segs are sections of linedefs a nodebuilder creates -- every linedef generates at least one seg for each sidedef it has, but it can sometimes be split by the nodebuilder into two or more segs, and these add up towards the Doom limit). HOM that is not caused simply by missing textures (the newbie kind of bugs), is caused by too many lines in view at once, but it can be corrected sometimes by tweaking the node builder. You can add lines on the map parallel to the direction that the player is looking at when the problem is seen, and this sometimes fixes the problems, because what you are doing is making the node builder change its decisions on how to divide the map, and it tries to avoid breaking lines.
>I'm working on a Doom I map and haven't been able to make the "blocks >sound" flag work, or maybe I don't understand what it is supposed to do. >I can hear monsters, lifts, etc., across the line. Is it just supposed >to keep them from hearing you? Yes. It's only supposed to keep monsters from hearing the player. It takes two such linedefs to actually block the sound -- it will travel through one, however. Sounds that monsters hear travels between all two-sided lines except when floor and ceiling heights are such that the opening is completely blocked (like a closed door), or when the sound has reached a second "blocks sound" line. Note that sound always travels completely throughout a sector if it enters that sector, even if it is unconnected. So if you use the same sector in two different rooms, say for some furniture, then monsters in one room will hear you in the other, because sound will travel "through" the sector. By messing with the reject map, which is a table telling Doom whether monsters can SEE players from one sector while they are in another one, you can further disable monsters and even make them pacifists. The reject map affects their ability to see, and thus whether they will attack, but not their ability to hear. Whether a monster can hear a player is black-and-white -- only by using "blocks sounds" can you simulate a monster's hearing decreasing with distance from the player in an open area. If they can hear a player at all, then it does not matter at that point how far the player is. For players' sounds, simple linear distance is the only limiting factor. This means that if two rooms are next to each other, the player will always hear what's in the other room. However, closed doors and one-sided linedefs will decrease the sound a player hears. Crushing ceilings are especially easy to hear, even in other rooms blocked by walls or closed doors. The starting sounds of some monsters, such as the Cyberdemon and Spider Mastermind, are also heard throughout the entire level by the player. The "impassable" flag is another often-misunderstood one -- it simply means that neither monsters nor players can walk across the line. It does not stop weapons or stop anyone from seeing or hearing through it, however. "Blocks monsters," "Never on map," and "Always on map" are about the only self-explanatory linedef flags. The unpegged flags control how textures are drawn and the "lower unpegged" one is trickier than the upper "unpegged one" because the lower one affects normal textures as well as lower ones, and its actual effect depends on a combination of factors including the ceiling height of the neighboring sector! "Secret" simply makes a line appear on the map as red line, the same as a 1-sided line looks. It does not have anything to do with secret percentage (which is actually controlled by a special sector type that tells Doom that an entire sector is secret). If a line is secret, it will not be revealed on the map as a different color (unless there is a floor dropoff), but nothing else is changed. "2s" means that normal textures can be seen through. This is the most confusing flag, because you can actually have a line with 2 sidedefs but without the 2s flag turned on. In this case, the side will be drawn just like a 1-sided one and it will have only its normal texture drawn, but rockets and plasma (and players) can go through it, even though bullets cannot go through it. Monsters cannot see through lines with the 2s flag cleared, but they can shoot through it, assuming they find a target in the same direction to shoot at.
>I'm having trouble with making an outdoor building. I think the ceiling is
>112. Every time I try to add a texture it leaves spaces.
If you are getting tutti-fruiti, which means random colored debris on
walls, then you need to either check the y-offset or turn off the unpegged
flags (mostly in the case of a stairstep), or you need to choose a texture
that is 128 pixels high. Textures that are not exactly 128 pixels high
(the highest they can even be), are not able to be drawn correctly taller
than their own height.
If you are doing your own texture editing, then simply increase the size
of the texture to be 128 pixels high and use two patches instead of one,
with one of them filling up the gap left by the other one when the texture
is increased to 128 pixels high.
For outdoor buildings, you should contain the building entirely inside a
sector whose ceiling height is how high you want the building to look
from outside.
You should use one-sided linedefs that have their right sides pointing
out, for the outside walls that are not doors or windows. Do not use
two-sided lines everywhere because then you can shoot rockets through
them, the game will run more slowly, and other problems can happen.
If you add a window, turn the upper and lower unpegged flags on in the
window's linedef so that upper and lower textures line up with normal
textures of the adjacent walls (assuming the x-offset is correct).
Create a window sector between the inside and outside and set its
floor and ceiling heights to set the opening.
To align textures, use the unpegged attributes for windows as I said
above, but either use an editor that supports auto-alignment, or
compute the x offsets of the wall textures by adding up their lengths
and reducing them every time modulo the width of the texture. For
example, if the texture is 64 pixels wide:
len=70 len=40 len=60
*----------*-------*----------* -> left to right
sum 0 70 110 170
xoffs= 0 6 46 42
Postscript:
Tutti-Fruiti was caused by Doom's R_DrawColumn routine performing mod-128 arithmetic for all of its texture offset calculations. Therefore, drawing any texture less than 128 high at higher than its texture height, would not "reduce" correctly and garbage (TFE) would be displayed.
This bug was fixed in Boom.
> 2 questions about some problems I'm having with textures. Nothing >fatal, but really ugly: > > 1. I have a long hallway with a crushing ceiling, and the only way >to get through it without becoming a red stain is to pass through a >two-sided linedef (which is NOT see-through) which is halfway down the >hall and take cover in a small sector until the ceiling raises again: > > > __ > ___________|_ | -----small sector you hide in > Exit| | > |____________ | > | | > | | > | | > | | > | | > |_| > > The problem is, the texture (SP_HOT1 if you needed to know) I used >to make the wall non see-throughable sort of "sinks" into the ground >when the ceiling starts lowering. You can still see the normal texture >while the "Wall Above" texture above it becomes visable. > > (I know, it doesn't make sense, maybe you've seen it before, >though). > Try playing with the "unpegged" attributes of the linedef. Briefly, here's what they do: Upper unpegged makes upper textures, which are the ones you see hanging down on a crushing ceiling, get drawn so that the top of the texture is at always at the ceiling. If you make your crushing ceiling upper unpegged, then it will look like it "unfolds" onto the ground rather than coming out from the ceiling. Lower unpegged makes lower textures get drawn so that the bottom of the texture is always a constant distance away from the ceiling no matter what floor height is, and it also makes lower textures line up with normal textures that are not unpegged but are next to it. If you make your crushing ceiling have "upper unpegged" linedefs then you will not see the textures moving while the ceiling is moving. If this cannot get it perfectly right, consider putting 2-sided linedefs right in front of each other, so that one stays constant and looks like a wall (but is walk-through) and the other one works with the crushing ceiling, door, or other effect.
> 2. I have a sector which is an open area (sky texture is used as a >ceiling). An adjascent sector, which is about 256 units higher, >provides one of the lower sector's wall (you got all that? :]) > > The higher sector has two height levels (which would really make it >two sectors) which are connected by a staircase: > _________________________________ > | | | | > | | Fl: | | > | | 320 | | > | |__________| | > | |__________| | > | |__________| | > | Floor: |__________| | > | 0 |__________| | > | | | > | | Floor: | > | | 256 | > | | | > | | | > ___________|____________________| > > The "Wall Below" texture that forms the right wall of the lower >sector is unalligned. I believe it's "WOOD3", but I wouldn't bet my >life on it. The wall looks like: > >_____________________________ > >______ >______ > __ > __ > __ > __ > __ > __ > __ > __ > ________________ > ________________ > > >______________________________ > > > (I love art) > > Is there any way I can allign the textures? (the misallignment >starts where the stairs are). Make the parts of the stairs around the sides of the walls (but not the steps) lower unpegged. This will make all of them line up at the bottom and they will also line up with normal textures on a wall nearby. Then change the x offsets of those lines so that the drawing of the texture starts correctly from step to step. For example, if the texture is 64 pixels wide and the step is 16 pixels wide, make the x offsets 0, 16, 32, 48, 0, 16, 32, 48, etc. You might consider getting Scott Amspoker's textures.zip file, located at: http://ftp.netc.pt/pub/idgames/docs/editing. It explains the unpegged attributes in more detail.
>I get this problem when I run 2 or more .wads that total # of levels
>totals 13 or more.
>When I try to do this I get to play like the first 6 levels of a 9 level
>wad & the last 6 of a 12 level wad. Why does it do this & con I stop it
>from happening?
>
Are you trying to run several totally unrelated wad files at once?
If so, then it's unpredictable what will happen. Every wad file modifies
resources such as maps, textures, sounds, etc., and when more than one
wad is given on the command line (like -file wadfile1.wad wadfile2.wad ...),
then the last one takes precedence, for each resource. This means, for
example, if you have two wad files, and they both modify MAP01, then the
last one is the one that controls MAP01. But the music on MAP01 might be
determined by the first one, if the second one did not specify any music
for MAP01. Music, graphics, sprites, sound effects, textures, flats, levels,
etc. -- these are all resources that can be independently modified or
not by each wad file.
In general, you are not supposed to run several wad files at once, because
they will almost certainly conflict.
You can combine wad files, if you make sure that resources do not conflict,
but this must be done using editors or other utilities, not just the command
line.
The total number of levels does not depend on the wad files. It is determined
by the version and game of Doom you have. There are 27 levels in Doom 1, 32
in Doom 2, 36 in Ultimate Doom, and 9 in the shareware version (but the
shareware version does not allow pwads anyway).
Loading a wad file does not change the number of levels -- it merely replaces
or modifies some or all of the existing levels. Ones that do not get modified
stay the same as if you were running the original game (the IWAD, pronounced
eye-wad).
What it sounds like happened with your particular example is this:
Wad file 1: Wad file 2:
MAP01
MAP02
MAP03
MAP04
MAP05
MAP06
MAP07 !!! MAP07
MAP08 !!! MAP08 <- wad file 2 overwrites MAP07-MAP09,
MAP09 !!! MAP09 leaving only the first 6 levels of
MAP10 the first wad file.
MAP11
MAP12
MAP13
MAP14
MAP15
MAP16
MAP17
MAP18
In general, do not run more than one wad file at once, unless the wads all
come from the same package, or you know that they do not overwrite the same
resources.
Get a front-end if you want to make it easier to run several different wads.
>I can't get lmps to work right. > I got a program to convert them to my doom version, but after a >person dies and comes back to life, they appear in the wrong spots so >they are running against walls, and shooting walls. I hate this!! I >havent gotten 1 demo to work!(exept the ones that I made) > >Can anyone help to why this happens? and how to get them to play >corectly? > The reason this happens is the reason why they try to prevent you from running LMPs on different versions of Doom. It cannot be fixed. The reason is that LMPs record a series of virtual keystrokes, and play the game from scratch in real-time as though those keystrokes are being played by you every moment. If those keystrokes are played on a version of Doom or on a wad file that is even in the slightest different from the one that the LMP was recorded on, then the playback and the recording can become "out of sync" and the player will start walking into walls, shooting at thin air, getting killed without even trying to fight back, etc. Factors which can cause this to happen are: tiny differences in the walking speed a player takes each frame; differences in the lengths of lines on the map; differences in the behavior of monsters; differences in metrics (how high a player or monster is; what distances are required in order to walk through an opening or activate an object; etc.); differences in how the nodes were built; the list could go on. You can sometimes get away with the trick of changing the version id of a LMP and playing it on your version of Doom even if it is not the same as the original, but sometimes you cannot. When you cannot, there's nothing you can do about it except contact the author and get a newer LMP (in case the LMP is old), or upgrade your version of Doom (in case your version is old), or remove a demo from a wadfile.
>I am running Doom2 in MS-Dos mode on a 486Dx33 machine with Win95 >installed (this shouldn't matter since I play in MS-Dos mode, right?). >I prefer to play in turbo mode but this doesn't seem to matter on some >levels where the game shows very sluggish responsiveness (i.e. the >weapons fire slowly, the marine responds slowly to mouse and keyboard >commands). On other levels, with the same settings, the action is >fast and responsive. Is this a function of differing amounts of >graphic detail from level to level or is this a problem with my >processor? Any suggestions as to config.sys and autoexec.bat settings >to alleviate this problem? Thanks. It could be a problem in the wads themselves. Try cheating with idkfa and then try shooting a rocket at a wall. If it goes through the wall, then it means the authors of the wad used a common but unnecessary and bad approach when creating their wad: they used 2-sided linedefs everywhere. As a result, even if the walls are not see-through, Doom must compute each one of them, as though the walls were see-through. If the wad authors used one-sided linedefs where possible, then Doom could simply stop rendering immediately when it reached a one-sided line, thus making the game faster. The authors of one wad, which I will not name, admit that their wad is slow, but the reasons they give are wrong: it is not slow because it is a very complicated level -- it is slow because they used almost nothing but 2-sided lines, which makes Doom work much harder. 2-sided lines (even with the 2s flag turned off) do not stop plasma or rockets either, and they require much more work to process because they allow for the possibility of being seen through, and of objects on the other side of them being reachable. If you know about wad editing, simply look at the wad under an editor and see if it contains almost nothing but 2s lines. If so, then it's a poorly designed wad. The rocket test should tell you immediately, though. A good reject map may also improve playing speed.
>Hi, people!
>Maybe you can help me...?
>I'm building a WAD with DCK, nothing too complicated, since I am a beginner in
>the matter. There is a room in which I always get a "visplanes=xxx" error &
>bumping out to DOS, where xxx is a variable number (around 130). Other times
>it says "findplanes: No more visplanes", or things in that style. This happens
>when I look towards a certain direction, but not always in the same point. I
>guess the error means I'm trying to show too many planes or object faces at a
>time, but I don't think the room is that huge! i've tried simplifying the
>zone, but no help. DCK shows no error, anyway.
>
>I'd appreciate any help, I don't know what to do!
>can anyone help me with this. my level is based on the marina.wad but i
>expanded it quite a bit. i read on faq that said something about light
>levels but mine are all the same. none of the linedefs are over 1024. i
>thought maybe the nodebuilder was at fault (im a bit of a newbie) so i
>changed editors (windeu=>deep) but got the same error. i even tried
>cutting out part of the area, but still the same thing. if anybody has
>any ideas please reply, thanks.
Skip to below if you need a quick solution.
Try decreasing the number of different sectors that are in view at any
point on the map.
As for node builders, try BSP. I added the -factor option to BSP because
I noticed a visplane overflow problem that could be corrected by playing
around with the nodes. Try BSP using -factor 10, then -factor 5, and
-factor 1. Smaller values sometimes tend to reduce the chances of visplane
overflows, but they also lead to larger wads because they allow more line
segments to be split. But I make no guarantees that BSP or any other
node builder will fix the problem -- some wads have just too many different
visible flats for the node builder to make any difference.
If you have a lot of sectors with lots of different heights, try reducing
the number of height changes by, say, reducing the number of steps in a
flight of stairs, or simplifying the structure of an object that sits inside
a large room.
If you have a large, wide open room with lots of sectors in it, try to
trick the node builder by splitting the room into small sections separated
by 2-sided linedefs that are totally transparent (-). One way that the node
builder seems to contribute to visplane overflows, is when it does something
like this (numbers refer to sectors):
--------------------------
| 1 node line |
| - <---> - |
| |2| |3| |
| - <---> - |
| node*line |
--------------------------
Those arrows are node lines that the node builder generates, not lines you
create. The only lines you would create in the figure above are the 12
lines making up the outside of the room and the four sides of each of the
two sectors labelled 2 and 3.
If the node builder generates node lines as indicated above, it will cause
the player to see through two invisible node lines when they are standing at
the position indicated by * in the bottom of that figure. What you want the
node builder to do instead is this:
--------------------------
| 1 ^ ^ |
| -| |- |
| |2| |3| |
| -^ ^- |
| | * | |
--------------------------
| |
^ node lines ^
That way, the player does not see through anything down the middle of the
room, since the node lines are off to the sides.
You can sometimes trick a node builder into doing what you want by adding
lines yourself:
--------------------------
| 1 | 4 | 5 |
| -| |- |
| |2| |3| |
| -| |- |
| | * | |
--------------------------
It seems ironic that increasing the number of sectors like this can help,
but it might actually work, since the node builder will then sense that it
is better to choose those vertical lines you added as the node lines, and
this will prevent it from cutting the player's view with several node lines.
Actually, you might just want to add 2-sided lines without actually spliting
sectors, since this should do the job also. Node builders generally try to
avoid splitting lines, so if you can add extraneous lines in such a way that
the node builder would be splitting them if it chose the wrong node lines,
then it might work.
A node builder must split a map into nothing but sub-sectors, sometimes
called simple-sectors. A sub-sectors is almost never more than any sector
you create (except in some special effects like transparent doors), but a
sector you create may be broken up into sub-sectors. Each time sectors
are broken up they are broken up by choosing a node line to divide the
"universe" into two halves.
From empirical research I have found that the way that the node lines are
chosen can contribute to visplane overflows. To prevent visplane overflows,
you want the player's view to be cut by as few invisible lines as possible.
In a large room with many sectors of varying heights scattered around, the
node builder might choose a node line which cuts right through the middle
of the room, and if there are many cuts like this, it can add up to visplane
overflows.
PS. Some more recent insights on visplane overflows:The exact cause of visplane overflows, as best as I can tell, is:
Too many changing ssectors (sub-sectors) in view at once, with changing floor and/or ceiling properties. Floors and ceilings count separately towards the limit, and only when each is actually visible to the player. Two flats are considered compatible if they have the same texture, the same lighting level, and the same height (unless the texture is F_SKY1, in which case height does not matter). If two visible flats are compatible, and they are only separated by a 2s linedef or by flats that are not visible, then the visible flats are merged into the same visplane.
Visplane overflows are not simply caused by:
My hypothesis is that visplanes are some kind of polygons, either in the 2-d space of the game's map, or in the 2-d space of the viewing screen, which represent flats and which act as a kind of "cache". Doom probably draws flats in a back-to-front manner (painter's algorithm), and so whenever a new ssector is found which has a seg that needs to be drawn, Doom looks for a compatible visplane whose polygon contains the seg, and creates a new one if a compatible one cannot be found, stopping at 128. How the polygons are formed and merged, and when segs are considered members of the polygons, is the big question.
The BSP23x node builder removes visplane overflows, or reduces the chances of visplane overflows from happening, by using a heuristic which reduces the number of sector splits across wide open space.
More detailed technical information about
visplane overflows
>can anyone tell me how you apply the wall texture that give you an >"unattached" sky effect (cityscape, mountainscape and clouds)? If you simply mean you want to use the "floating" sky (that's the official term), which looks somewhat realistic, then you simply need to make the ceiling of your sectors F_SKY1. F_SKY1 is a special kind of ceiling texture which actually comes, as you suspect, from the SKY1, SKY2, SKY3 wall textures, but Doom makes them "floating". Which one (SKY1, SKY2, SKY3) is chosen depends on the level, and rotates from level to level (you cannot change this without hacking the .EXE file). So simply make your ceiling texture F_SKY1, and you will see the sky. >I've checked out levels on Doom II but can't see how it's done. All >the places where the 'scapes appear have a sector with a lower >ceiling than the ajacent sector and no upper texture. No sign of the >appropriate wall texture (SKY1, SKY2 or SKY3) though. Look at the ceiling textures for the sectors that surround those buildings. It is F_SKY1. If two adjacent sectors both have F_SKY1 as their ceiling texture, then no matter what the upper textures are (or even if they're missing), a sky will be drawn between the two sectors' ceilings and it will look like there is no difference (still the same sky). Therefore if you want to make buildings of different height, simply contain a building within a separate sector, and make the ceiling height of that sector the height you want the building to be. No upper textures are needed, because if both that sector and the one outside of it have F_SKY1 ceilings, then it will be nothing but sky that is drawn between them.
> Okay, I'm cooking. Got a WAD sorted out. Recognize all the effects when things
>go wrong. Starting to write some decent levels. Two things stop me, however..
>
>i) How do I give a door a ceiling ie a frame. I can do the side frame bits but
>not the top bit. How can I do this- it looks a bit strange with the door going
>all the way up to the ceiling
You can put another sector "in-between" the door:
DR door type linedef
\/
---------------------------
| sector 1 |
| |
---------------------------
| sector 2 | <- make the ceiling height of this sector
--------------------------- the height you want the door to go up to
| |
| sector 1 |
---------------------------
/\
DR door type linedef
What you need to do is make sector 2 have a ceiling height equal to the
height you want the door to open up to (actually, the door will open to 4
pixels lower than it). Make the linedefs in sector #1 shown above all have
sidedef references to sector 1, so that both halves of the door which are
split still make up the same sector, so that when the door is activated on
either side, both sides open. If this is too hard for you to do because
your editor makes it hard for you to create unconnected sectors like this,
then there is an alternative way:
SR door type linedef, tag=x
\/
---------------------------
| sector 1 tag=x |
| |
---------------------------
| sector 2 | <- make the ceiling height of this sector
--------------------------- the height you want the door to go up to
| |
| sector 3 tag=x |
---------------------------
/\
SR door type linedef, tag=x
In this case, you need to make the door linedefs have a "switch" door type
instead of a normal door type, and you need to tag both linedefs with both
sides of the door (sectors 1 and 3).
(Actually, sectors 1, 2, and 3 in the above examples can be any sector
numbers -- this is just an example).
Yet another way to do it, if it looks strange being broken in the middle
like that, is to put the sector on the outside, like this:
------< DR door type linedef
/ \/
| ---------------------------
| | 1 |
| | |
-> ---------------------------
| 2 | <- make the ceiling height of this sector
--------------------------- the height you want the door to go up to
In any case, the rule to remember is this: when a door is opened, it
raises the ceiling height of the affected sector(s) to 4 less than the
lowest ceiling height of the sector(s) adjacent to each of them. By putting
a "buffer" sector near the door with a lower ceiling height than the
surrounding room, you can make the door open to a height lower than the
room. You can make the buffer sector very thin, almost invisible, too.
>
>ii) If I make a door and put a texture on it, the texture is too big for the
>door and not all of it is shown. How do I adjust this?????
>
You can use the y offsets. The y offset, which is specified in a sidedef,
tells Doom where, modulo the texture size, to being drawing the texture. Door
textures, like all upper textures, are normally drawn bottom-up, but you can
make them draw top-down if you set the "upper unpegged" flag. But if you set
the "upper unpegged" flag on a door, then the door will look funny when it
opens because it will appear to "roll up" rather than actually move up.
Key points: door textures are upper textures that are normally drawn
bottom-up, but can be drawn top-down if the upper unpegged flag is set. In
any case, the sidedef's "y-offset" can be used to adjust where exactly the
texture starts being drawn.
>iii) Finally (I know I said it was two.....), how do I make a window to look
>out onto the red sky and mountains?????????
Create a buffer sector connected to the wall:
_________________________ <- make this line have a normal
| | texture of SKY1, SKY2, or SKY3
| buffer sector | or any other texture you want.
-------------*-------------------------*----------------
^
|
make this line "upper unpegged", "lower unpegged",
and make its upper and lower textures the same as
the adjacent wall texture, but leave the normal
texture blank (i.e. "-").
Make the buffer sector have a floor and ceiling height that you want the
window opening to have. Make the line on the other side of the sector have a
SKY1, SKY2, or SKY3 texture, or any texture for that matter.
Note that this creates a "static" sky texture, which is like a picture. If
you want a "floating" sky, which looks the the sky outside when the player
moves around, then it's a little more complicated:
--------------------------------------------------------
| Make this sector have F_SKY1 ceiling |
| |
| |
-------------*-------------------------*----------------
| buffer sector |
-------------*-------------------------*----------------
In this case, you still need to make a buffer sector for the window, with
floor and ceiling heights to set the heights of the opening, but you need a
sector on the opposite side, with a ceiling texture of F_SKY1. The ceiling
height of that sector can be made very small in order to make it all look
like sky. If you want, say, a lake outside, then you can set the floor
texture of that outer sector to have a F_WATER1 or other floor texture.
There are other special tricks you can use to make the picture look better,
but I do not have time to go into the details, which are complicated (they
require at least 3 more lines to be added, as well as careful positioning
and alignment).
One thing to remember about F_SKY1 ceiling textures: Whenever two sectors
separated by a common linedef have F_SKY1 as their ceiling texture, then no
matter what the ceiling height differences are between the two sectors,
upper textures are always drawn as floating sky textures. Another way to
think of it is that the upper textures are not even drawn. This property
allows you to construct outdoor buildings of different heights, by enclosing
the buildings inside sectors of different ceiling heights, but with F_SKY1
as the ceiling texture:
-------------------------------------------------------------
| ---------------------------- 1 |
| | buffer sector | |
| | ------------------- | --------------------- |
| | 2 | 3 building A | | | 4 building B | |
| | ------------------- | --------------------- |
| | ceiling=F_SKY1 | main sector |
| ---------------------------- ceiling=F_SKY1 |
-------------------------------------------------------------
Numbers refer to sectors. Sector 1 is the main outside sector, with F_SKY1
ceiling. Sector 2 is a buffer sector, with F_SKY1 ceiling also, but with a
smaller (or larger) ceiling height. Since both sectors have F_SKY1 as their
ceiling texture, there is actually no "upper" texture drawn on the lines
separating sectors 1 and 2. This allows building A's height to be set
independently of building B's. Building A's height will be set to the
ceiling height of sector 2, while B's height will be set to the ceiling
height of sector 1. No differences in ceiling heights will be noticable
because of the special way F_SKY1 works.
For more information, I suggest you read Scott Amspoker's FAQ on textures,
located at ftp.cdrom.com:/pub/doom/docs/editing/textures.doc (I think that's
right...). It will explain to you all about y offsets, unpegged attributes,
F_SKY1, etc.
>Is there a file size limit to WADs? I am modifying a WAD and when I run >Doom with the new WAD, it begins okay, but I begin to play, and it crashes >and gives me an error of something like "cacheNumLumps >= NumLumps" or >something like that. Has anybody else experienced anything like this? > >Does anyone know where I can get a good DOOM 1 to DOOM 2 wad converter. >The one I use only does graphics. DM2CONV does conversions pretty well. Note that if you want exact conversions, then you need to use the graphics program that accompanies it, and you might also have to change the response files so that the conversion does not change any Doom 1 Things into Doom 2 things (by default, it randomizes so that, say, half of the Barons get converted to Hell Knights). I have a response file already that tries to make the conversion as exact as possible. If you want to convert your entire Doom 1 IWAD (the original game) into a Doom 2 PWAD, this is also possible, except that secret levels and sky textures will not be the same (nothing can be done about this, without changing DOOM2.EXE). I wrote a .BAT file that uses DEUTEX and DM2CONV to convert your supplied DOOM.WAD (iwad) into a pwad for Doom 2. Try DM2CONV, but remember to experiment with the response files (.RSP) to control exactly how the conversion takes place. >what is a *.wad file and how do you use it? A wad file is composed of "lumps" and a directory that lists them. Each lump has a name and a piece of data -- in a way, wads mimick directories and lumps mimick files. I have seen wads in other games besides Doom, but most of them are made by either Id or Apogee. A wad file does not work the same necessarily in those games -- but a wad is still a wad. In Doom, there are two kinds of wads -- Iwads and Pwads. Iwads are the ones that come with the games, like DOOM2.WAD in your Doom 2 directory. An IWAD defines a complete game. Pwads, which are all the wads that everyone talks about downloading and making for themselves, are "Patch wads". They modify certain aspects of the game without totally replacing it. Most commonly in Doom pwads, the game's levels are replaced, so that new buildings, new monster arrangements, new secrets, etc. appear. To use a doom pwad, simply run Doom or Doom 2 with the -file switch: doom -file wadfile.wad wadfile2.wad wadfile3.wad ... doom2 -file wadfile.wad wadfile2.wad wadfile3.wad ... The "..." indicates that an arbitrary number of wad files may follow the -file switch. Usually only one will be used, as in: doom -file onewad.wad Since pwads replace only parts of the game (well, some pwads replace nearly everything, but they are still technically pwads), they may seem to have no effect sometimes on the game, because they might only change one level out of ~ 30 levels, or they might only change the music, etc. Nearly all wads that are not simply music or sound effects wads, replace at least one level, though. The shareware version of Doom 1 does not allow pwads, so you must register Doom to use pwads. Much older versions of shareware Doom allowed it, although Id Software asked no-one to use pwads in the shareware version. As a result, most level authors intentionally made their levels unplayable on the shareware version, by adding Things like plasma guns, which only appear in the registered version and cause the shareware version to crash. Long answer, I know... Simply type something like: doom -file wadfile.wad and have fun.
>What causes the problem where bullets and/or projectile weapons appear to go
>through walls (i.e., there is no impact frame)? Is there any way to fix it?
If you make your wall linedefs have 2 sides, then even if you cannot see
through them, and even if they are impassable, bullets and other weapons
still go through them.
You can stop bullets from going through two-sided lines by turning off the
"2s" flag, while still leaving two sidedefs with the line. A line can have
two sidedefs but still be "not 2s", in which case bullets will not go
through them, and no-one can see through them, but plasma and rockets (which
are called 'projectiles') can still go through them.
The only way to complete stop all weapons, including rockets and plasma,
from going through walls, is to use true 1-sided linedefs, or to make the
floor/ceiling height differences of the two joined sectors large enough so
that either the upper or lower texture is all that is seen.
Make sure that you use walls like this:
_________________________
|
hall near room
___________|_____________
____________________ <- small gap of "null space"
| | | separates the two areas and
| | prevents things from flying
|_ room _| through walls. A door or a small
| | hallway can be added to connect
| | them.
|_________|__________|
Instead of:
_________________________
|
hall near room
_________________________ <- a 2-sided line separating rooms can
| | | always be shot through in some way
| | if the normal (middle) texture is
|_ room _| viewable, since rockets and plasma
| | can always go through normal textures
| | of lines with 2 sides defined for
|_________|__________| them, and bullets can go through
those which have the 2s flag turned
on.
Postscript:
There was a "sky hack" bug in Doom which caused bullets and projectiles to go through lower textures if the two ceilings were both F_SKY1 and there was a ceiling height difference. This was id's attempt to make skies look more realistic, by not making bullets or projectiles explode on a sky wall (it would give away that the room is finite, despite there being a sky -- wouldn't it look better if the rocket or bullet just "disappeared" into a sky instead of exploded?). However, they forgot to consider the z-coordinate of the impact, so sometimes bullets and projectiles would miss non-sky portions of walls.
This bug was fixed in Boom.
(comments based on an actual wad -- I see these mistakes often)
A linedef has a left side and a right side. The left and right sides are
defined based on where they would be if you were looking at the ending vertex
from the starting vertex. Most editors (all decent ones) indicate the right
side by hanging a perpendicular ( |- ) on the right side.
Your wad had 2-sided linedefs for all but the outermost and innermost building
walls, even though they looked like they should be one-sided since there are,
in keeping with this assumption, two walls for each room, an inside one and
an outside one. This is normal, correct practice in wads. What is not correct
is that these walls should have 2-sided linedefs, which they did in your wad.
In the Doom literature, a linedef is called 2-sided if it has two sides
defined for it, regardless of whether the "2-sided bit" is turned on.
A line can have two sides and still have the 2-sided bit turned off, in
which case monsters cannot see through it and bullets cannot go through it,
but rockets and plasma can go through it.
If it is your intention to create a deatchmatch wad where each player fires
rockets or plasma at each other through the walls without being able to see
their opponents, then I'm sorry -- simply change the wall linedefs to have
any textures for their second sidedefs, but leave the 2s bit turned off.
If a linedef has only one side, then it must be the right side. Almost all
of your linedefs had to be flipped in order to satisfy this requirement.
If a linedef has only one side, then nothing at all can go or see through it,
and any attempt to use see-through textures will result in HOM (Hall of
Mirrors).
If a linedef has two sides and has the 2s bit turned on, then its middle
texture can only be from a single patch. Otherwise Doom slows down > 10 times
when the player looks at it (this is known as the Medusa effect). Actually,
Medusa does not occur unless two or more patches make up the visible part
of any column. As long as no patches share the same column in the visible
part of the texture, Medusa does not occur. The SKIN textures of Doom are
examples of textures that are multipatched but still work as normal textures
of 2s lines.
One of your doors was left open because its ceiling height was the same
height as the surrounding rooms. I changed it to make it have a ceiling
height of 0 so that it would start off closed and operate like all of the
other doors.
The doors in a few of the rooms had their linedefs backwards just like all
the other linedefs. For doors which are activated by the spacebar, this is
really a bug, since those doors must always have their right sides facing
outwards in order to work properly. Doors and other "grab"-activated effects
must be oriented such that the player sees and touches ("grabs") the right
side of the linedefs. If a door's linedefs are backwards, it can cause strange
effects -- the door will not open or shut normally, but if you press on the
spacebar while standing inside the doorway while the door is open, then you
will "open" or "close" the entire room just outside of the door, which
usually has no effect since its ceiling height is already the highest one
around. The net result then is a door which makes a sound from an odd
direction, but no movement.
About half of the door tracks did not have the lower unpegged attribute,
and so their textures moved with the doors during opening and closing. This
is a matter of preference.
Your wad had the same sectors referred to in many different rooms. While
this might work in some cases, it is non-standard practice and is error-prone.
Do not use the same sector to refer to rooms which are not touching. If one
area should not be seen from another area at ANY time (such as when a door
is closed), then the two areas should have different sectors. Only use the
same sectors for multiple areas if they are connected and the player can
always walk from any part of the area to another. Don't, for example, use
the same sector for rooms separated by a door.
Some of the sectors were not closed, which caused the invisible barriers.
I noticed that in one hallway, right next to a door, it was impossible to
walk to the door:
door
___________
hallway
barrier -----------
| |
| |
| |
When I turned on no clipping mode to walk through that barrier, I noticed
that the door split in half. This is consistent with the sectors not being
closed, confusing the Doom engine as well as the blockmap builder that
generated the barrier.
Your linedefs should be changed to truely 1-sided linedefs, not 2-sided
linedefs with the 2s flag turned off, unless: you want rockets and plasma
to go through walls; and, you don't mind most consistency checkers reporting
errors in your wad even though it works okay.
You need to make sure your sectors are closed, and you should not use the
same sectors for rooms which can be on opposite sides of a door or any
other sector whose floor and ceiling heights can change. Otherwise, problems
like invisible barriers, Doom crashing, and other strange things can happen.
>There is a bug in Reject Map Builder v1.1.0 which is when you use it on a >Pwad it makes mosters float . I don't know why this happens , but I do know >that when I used it on a PWAD and then played a different PWAD the monsters >where floating in it . I was woundering if anybody knew why ? Dose RMB use >your main IWAD when building ? I don't know , but do want to know , what is >going on . Thanks I think what you mean is that the Things appear on the ceiling rather than on the floor, and there is an invisible barrier around the area they are elevated on. This occurs with node builders and perhaps RMB too. You can work around it, at least, by adding linedefs to your map around the area that they float on. When playing the game, try to notice where the invisible barrier is, and then under an editor, add a line to match that barrier, but make the line 2-sided and never on map, and split the sector in half so that there are two sectors now. This trick should not affect game play one bit but it seems to work around node builder problems. In general, add extra, non-functioning linedefs to the map where it is having problems, and this will usually cure the problem because the node builder or other program will now have a totally different picture of the nodes (which look nothing like the map, although they compose it). About the IWAD: I do not think RMB needs your IWAD, except maybe to protect against using it on shareware versions.Note: BSP21x fixed a bug in earlier versions of BSP, which had caused this invisible barrier problem and others problems as well. Here is an detailed explanation of the bug.
>With regards to buildings of different heights, I mean, can I have one building >128 high and another building say 400 high without having the wall that encloses >the entire wad be or look 400 high. It sounds simple enough but when I tried it, >it looked all messed up. If you are talking about buildings in the context of a sky ceiling, such as Doom 2's Downtown level (MAP13), then it is possible to do what you are asking. Simply enclose around the building a sector whose ceiling height is the height you want the building to be, but make the lines "never on map". Make both this sector and the one outside of it have F_SKY1 ceiling texture (this is important). Make the lower and normal textures of the lines "-" and don't worry about upper textures (Doom says "don't care" about upper textures when both sides of a line are on sectors with F_SKY1 ceiling texture). Example: ----------------------------------------------------------------------------- | outer sector; any ceiling height will do; just be sure to use F_SKY1 ceiling| | ceiling height determines the outer walls' height. | | ------------------------- ------------------------- < | | | ceiling=F_SKY1 | | ceiling=F_SKY1 | \_ linedef | | | --------------- | | --------------- | <- "never on | | | | Building 1 | | | | Building 2 | | map" and | | | --------------- | | --------------- | textures | | | height=height of bldg 1 | | height=height of bldg 2 | are all - | | ------------------------- ------------------------- | | | ----------------------------------------------------------------------------- When a one-sided linedef is used for a building's side, the building's height is determined by the ceiling height of the enclosing sector around the outside of the building. When a two-sided linedef is used, the height of the enclosing sector also matters, since it determines how much, if any, of the upper texture is used, but so does the adjacent sector also. This is how windows can be created in tall buildings, such as in Doom 2's MAP13. A sector surrounds the building to set the height of its top, and then the building is drawn with 1-sided linedefs for normal walls, and 2-sided linedefs for doors and windows. The whole building is drawn as if it has the height of the sector it is totally contained within. It is important that both this containing sector and any other adjacent sectors, such as ones for other buildings, have F_SKY1 as their ceiling texture. When two sectors both have F_SKY1 as their ceiling texture, then no matter how their ceiling heights differ, they appear to be one big "sky" of the same height because any upper textures that would normally be defined by the sidedefs of the joining lines are ignored and displayed as simply part of a larger sky. You do not need to set the ceiling height of the entire level to 400 or anything like that, because as long as two sectors have the sky ceiling, lines that join them will not have any upper textures drawn and the sky will look, well, as high as the sky! The illustration above is very general; you do not even need an outer sector necessarily unless you want to erect a fence/wall around the level and be able to set its height. For two buildings, you only need two enclosing sectors, not three. Of course, if you never need to walk into or out of the building -- only teleport in or out of it, or jump onto its top, then raising the floor height is the simplest way to go.
>What I finally did to fix it was make independent sectors out of each of >the columns, still with the same >floor\ceiling heights, then assign the tags from the original six sectors >to the twelve new ones. >I also had to put small sectors, with floor heights to match that of the >bottom floor, inside each of >the new sectors, so that the new sectors' floors would continue to drop and >not stop when the reached >the level of the floor they were located in. Functionally, it's the same >as before, but now DCK >and/or the game engine isn't confused any more. I've also used this trick of making unconnected regions have the same sectors, but as you have noticed, it is risky. I have never heard of such a problem as you were having, which makes me think it may be due to the node builder. Remember when using this trick that sound travels through the sector, so that if you make a sector unconnected but in several rooms, then monsters in every room with that sector can hear monsters in other rooms (unless of course block sound lines override this). In general here's my advice on using unconnected sectors: Do not make a sector unconnected if: 1. The unconnected regions are in rooms separated by doors or other activated devices, so that visibility between the two unconnected regions can change during the game without the player or other Things moving except as per floor height. In other words, the unconnected regions should not be separated by a lift, door, crusher, etc., and become visible or invisible with each other based on activating a linedef. 2. You do not want sound to travel between the sectors. Even if the sectors are in rooms separated by closed doors or are totally isolated, sound will travel as though the rooms are connected, if the same sector is used. 3. A Thing is in one of the sectors. This is the problem you just experienced. Doom bases the height and movement of a Thing on the sector that the Thing resides in. All of these reasons may be dismissed from time to time, if you want to do special effects. For example, I recently made a bathtub special effect that lets the player walk into a bathtub, press a switch to make it fill up with water, and press the switch again to empty it. The player also wades in the water while it is filled up (the deep water effect, where the height of a Thing is lower than the height of the floor texture). This special effect uses a lot of unconnected sectors. Another reason your floor lowering trick might not have worked is if the sector being activated touched another sector that was moving. Doom seems to get confused if two sectors being lowered with the same tag are adjacent. It's sort of like a 'race condition' between the two floors to see which one is actually lower -- As soon as one is activated, it must figure out which adjacent one it should move towards, and if one of the adjacent ones was also triggered and is moving, then Doom may have a hard time figuring out what floor height to lower the sector to.
> i've been working on a new small wad, but keep getting bigtime homs. >What can I look for as a possible cause. In part of the wad I have made maze >that u walk thru plus it has sniper spots that over look the maze HOM can be caused by: 1. Missing upper and lower textures on 2s lines when there are ceiling and floor height differences, respectively (except when both sectors have F_SKY1 ceiling in which case upper textures do not matter). 2. Missing normal textures on one-sided lines, or lines with 2s flag turned off 3. Too many lines in view at once Sometimes a wad will act strangely if there are overlapping lines, and you will not even be able to see them because they are completely overshadowed by another line. Sectors not being closed usually does not affect textures or cause HOM -- it usually only affects Things, although a sector not being closed may be an indicator that a wall texture may not be drawn correctly and may have HOM, if the sectors on either side of it seem fishy. Except for missing textures, including ones that are hidden in overlapping lines, I cannot think of anything that would cause HOM in a small wad unless it had a huge number of lines in a single room.
Postscript:
The Boom engine removed the 2s HOM limit entirely (now no matter how many 2s lines there are, no HOM will appear), and a new feature has been added which generates a flashing red wall when HOM is detected, to catch HOM mistakes during editing.
>I'm curious about this "deep water effect." I've seen it
>mentioned in the NG, but don't know how it's done. I must be more of a
>newbie than you think, since your description above doesn't make sense to me.
>How do you get a Thing to stand_below_ the floor level?
The deep water effect is, surprisingly, one of the easiest special effects
to do and it does not depend much on the node builder used (unlike transparent
doors and some other effects).
Example:
3
---------------------------------
| 2 |
| |
| 1 |
| -------------------- |
| | 1 | |
| | | |
3|2 1|1 Thing 1|1 2|3
| | | |
| | 1 | |
| -------------------- |
| 1 |
| |
| 2 |
---------------------------------
3
The numbers refer to sidedef sector references. A sector in Doom is defined
totally by sidedef references, which in turn are referenced in linedefs. A
sector only has a floor height, ceiling height, type, tag, etc., but no
position, at least not exactly.
Whenever a series of linedefs inside of one sector have sidedef references to
a different sector with a lower floor height, but on both sides of the line,
then that sector's floor height determines the height that Things are at
inside of it, while the outer sector sets the height of the floor and ceiling
textures. In-between the two sectors the floor height that Things rest on is
determined by the outer sector's floor height. If you make the area between
the inner and outer sectors as small as possible, then you can make the
inner sector almost totally determine the height at which Things will be
drawn from inside.
In the example above, sector 2 is the sector that defines the floor height of
the floor texture that is drawn. Sector 1, however, can have a lower floor
height, but since the linedefs making up sector 1 refer to sector 1 on both
sidedefs, the floor and ceiling are still drawn according to sector 2's
heights, even though a Thing may be at a lower height inside sector 1.
Lets say you wanted to hide a megasphere or some other Thing "underground" as
a secret. Then you could simply create a series of nested sectors like the
above drawing, such that the first sector inside the outermost one has lines
with both sides referring to the same sector. As long as the first one inside
the nest has both sides of its lines referring to the same sector, the floor
will be drawn at the height of the outermost sector, regardless of whether the
lines deeper inside the nest have both sides referring to same sectors or not.
By making these nested sectors, you can create "steps" down to the Thing. Each
step can be no more than 24 units, or else the player will not be able to get
back out.
I am working on a wad right now with someone else and I am adding this special
effect to put keys and other items (like a megasphere) underground, underneath
a street. A manhole cover on the street looks rather flat, but actually, if
you walk across it just right, you (a Thing) can fall to a height lower than
the street, and can pick up another Thing (the megasphere), which is normally
invisible due to the deep water effect. In this case it has nothing to do with
water but it's based on the same idea -- namely, that Things can be at lower
heights than floor textures, if a sector containing the Thing(s) is made up of
lines that have both sides referring to the same sector, one with a lower floor
height than the one it is contained in.
The trick is that sector 1 in the drawing above is made up of lines that have
sector 1 on both sides, while no lines directly connect sectors 1 and 2. As
a result, Doom simply draws sector 2 as if it were one big sector without any
others inside of it, for floor texture drawing purposes, but when it comes to
Things, then the inner sectors' floor heights matter.
>how do you make the arrangement thats cause power up's and monsters >to appear only in the level "Im too young to die"? The way to make items change from skill level to skill level is to change the flags in the Things. Every Thing, be it a monster, pillar, dead body, ammo, weapon, etc., can be programmed to appear in skill levels 1&2, 3, or 4&5, or any combination thereof (but if it appears in skill 1, or it doesn't, then the same must be true of skill 2, and similarly between 4 and 5). It is also possible to program a Thing to appear only during multiplayer games. Unfortunately, a Thing cannot appear in single-player games and NOT appear in multiplayer games -- if it appears in single-player games then it must appear in all games. The only way I know how to make an item available only during single-player mode is to block it with a pillar or other object, and to make that object only appear during multiplayer games. That way, if the game is single-player, then the blocking Thing does not appear and the player can reach the one behind it.
>transparant doors... WAAW!!!!!! IS THIS POSSIBLE ?????? Can you please
>mail me how ??? I searched for this and couldn't find it...
Create a normal door:
|
-----------------------------------------
|- -|
-----------------------------------------
|
Next, make sure that one of the two linedefs in the doortracks is the
lowest-numbered linedef among the 4 lines that make up the door. Under some
editors (such as DCK), you can accomplish this by splitting the door lines
(the ones besides the doortrack lines), and then dragging the newly created
vertices to merge them. The way this works is that by splitting one of the
lines, you get two lines, one of which is almost always going to be larger
than all of the others. Then by merging the newly created vertex, you
replace the old door line with this higher-numbered new one. Suffice to say,
one of the two doortrack linedefs must be the lowest-numbered among the 4
lines making the door.
|
-----------------------------------------
either this -> |- -| <- or this must be lowest-numbered
-----------------------------------------
|
Next, create two extra sectors off to the side of your map -- their size and
wall textures are not important, but their sectors are:
__________
| | floor = 1
| 1 | ceiling = 1
|__________|
__________
| | floor = 0
| 2 | ceiling = 127
|__________| textures and lighting determine door flats
Next, change the sidedef references in the original door, to refer to these
extra sectors instead of the original door:
|
-----------------------------------------
| 1 |
|- 2 2 -|
| 1 |
-----------------------------------------
|
The numbers above refer to the sectors. You want the doortrack's sidedefs
to refer to sector 2, which has a floor height of 0 and a ceiling height of
127, while you want the door's sidedefs to refer, on the inside, to sector
1, with a floor height of 1 and a ceiling height of 1.
Next, change the sidedefs on the door's linedefs to have your desired
transparent texture as their normal textures, but leave out the upper and
lower textures. Make the y-offsets equal to 128:
normal texture = door texture
y-offset = 128
|
-----------------------------------------
| |
|- -|
| |
-----------------------------------------
|
normal texture = door texture
y-offset = 128
That's all there is to it! Be sure that at least one of the doortrack's
linedefs is the lowest among the 4 linedefs, and be sure that the correct
sector heights and sector references are used. And of course, be sure not
to forget the door linedef types (type 1), for the two door linedefs.
This will create a transparent door. If you use BSP or WARM, you can
remove a flash of HOM (hall of mirrors) that occurs when the door opens.
Under WARM, you have to use a command-line switch and list each sector
in the wad that needs special treatment. Under BSP, simply change the
sector that the doortracks refer to, to have a sector tag greater than
or equal to 900:
__________
| | floor = 0
| 2 | ceiling = 127
|__________| sector tag >= 900
For an example, look at the TRANSDOR.WAD example that comes included with
BSP.
>Does anyone know what this error message means?? I am in the middle of >creating my first WAD, but everytime I test it, it crashes and in DOS it >says: > >Z_CheckHeap: block size does not touch the next block The "Z_CheckHeap: block size does not touch next block" error is actually a memory allocation-related error, even though it almost always means that someone's wad has a sidedef that refers to a bad sector (such as -1, which usually stands for a missing sector). "Z_CheckHeap: block size does not touch next block" is a consistency check failure which says that the address of a block of allocated memory, plus its allocated size, does not touch the next block of allocated memory: ------------------------------------------------------------ | header | block of memory | header | block of memory | ... ------------------------------------------------------------ Each "header" looks something like: ------------- size = number of bytes in block | size | prev | prev = pointer to previous block ------------- The invariant which must always be satisfied, is that the address of the block, plus the block's size, must point to the next block's header. This is what is meant by "blocksize touches the next block". This can be tested by putting expected signatures (constant byte strings) in each block header, or by making the blocks linked lists, in which case the block's size and the block's "next" or "prev" pointer(s) can be used to independently arrive at the next block, and must always agree. Why, then, would a huge unsigned value, or just a negative signed value, in a sidedef sector reference, cause the memory allocator to fail a consistency check that involves block sizes? The most reasonable explanation I can come up with, is that the sector numbers are used as subscripts in a array which is allocated on the heap. Doom allocates exactly n elements in this array if there are n sectors, and so if any sidedef refers to a sector outside of the range of 0 to n-1, then the array bounds are exceeded, and so Doom, when it writes to the array, will overwrite the headers which precede and follow each block, causing the Doom internal consistency check to fail the next time it is tested. It just so happens that illegal sidedef sector references cause memory block headers to be corrupted which are always tested for consistency shortly thereafter, which is why the Z_CheckHeap error message occurs immediately and every time this problem exists in a wad -- somehow Doom always, at startup, traverses the headers that surround that sector table, and so any writes to memory just outside of the range of valid sectors, which can be caused by bad sidedefs, will mess with the headers and will be immediately caught by Z_CheckHeap before Doom even initializes graphics. The cause of "Z_CheckHeap: block size does not touch next block" is a bad sector reference in a sidedef, regardless of whether the sectors are closed, and regardless of what their geometry is. Fixing the error simply involves fixing or removing the bad sidedef. This is true for all versions of Doom.