Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 117
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #117
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Wednesday, 11 January 1995 Volume 01 : Number 117
Re: Descent (sorry)
sidedef mode again
Medusa strikes again
Re: sidedef mode again
Re: Medusa strikes again
Re: sidedef mode again
Line types
Re: sidedef mode again
mulitple wads
Re: Line types
Re: Line types
Re: sidedef mode again
Re: sidedef mode again
Adding new music to PWAD
Re: sidedef mode again
Re: sidedef mode again
consistency checking
Re: Adding new music to PWAD
Re: Descent (sorry)
Re: consistency checking
----------------------------------------------------------------------
From: Ian Johnson <ijohnson@falcon.cc.ukans.edu>
Date: Tue, 10 Jan 1995 19:23:25 -0600 (CST)
Subject: Re: Descent (sorry)
On Tue, 10 Jan 1995, Brad Willman wrote:
> um... and I have done some Descent Level editor thing so far...
> it sort of looks like 3d studio(Tm) :) right at this moment....
There's an idea for those working on Descent editors: a feature that
allows importing files from 3D Studio, or various other modeling and CAD
programs...once you get regular Descent editing figured out, of course.
Ian
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Tue, 10 Jan 1995 21:51:04 EST
Subject: sidedef mode again
So, in linedef mode you color lines according to their function. In sector
mode you color them according to what their adjacent sector types are. What
about sidedef mode?
I've been thinking about coloring them according to what textures they are
missing.
BTW, did anyone get a definitive answer on the Medusa normals question? What
exactly makes a texture suitable for use on a ST/2S normal?
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Tue, 10 Jan 1995 22:22:46 EST
Subject: Medusa strikes again
OK, I just finished a survey of all the missions in DOOM2. Here are textures
which ID used on ST normals.
BFALL1 : 64x128
BFALL1 +0+0 1 0
BIGBRIK2 : 64x128
RW23_4 +0+0 1 0
BRNSMAL1 : 64x64
W111_2 +0+0 1 0
BRNSMAL2 : 64x64
W111_3 +0+0 1 0
BRNSMALC : 64x64
W112_1 +0+0 1 0
BRNSMALL : 32x64
W112_3 +0+0 1 0
BRNSMALR : 32x64
W112_2 +0+0 1 0
DBRAIN4 : 64x32
RWDM11D +0+0 1 0
METAL2 : 64x128
RW33_1 +0+0 1 0
MIDBARS1 : 64x128
RW43_1 +0+0 1 0
MIDBARS3 : 64x72
RW45_1 +0+0 1 0
MIDBRN1 : 64x112
DOOR12_1 +0+0 1 0
MIDBRONZ : 64x128
RW10_4 +0+0 1 0
MIDGRATE : 128x128
M1_1 +0+0 1 0
MIDSPACE : 64x128
RW47_1 +0+0 1 0
MODWALL2 : 64x128
RW31_2 +0+0 1 0
PIPE4 : 256x128
TP7_1 +0+0 1 0
TP7_2 +128+0 1 0
SKSPINE2 : 256x96
SPINE3_1 +0+0 1 0
SPINE3_2 +128+0 1 0
SP_FACE2 : 64x128
BODIES +0+0 1 0
TEKBRON1 : 128x128
RW36_1 +0+0 1 0
RW36_3 +64+0 1 0
ZIMMER8 : 64x128
RW42_4 +0+0 1 0
My analysis is that the patches in each of them all have a y offset of 0
(which has been hypothesized before). If this is the case, then this rules out
the following textures (however, it still leaves a buttload):
BIGDOOR1
BRNPOIS
BROWN1
BROWNHUG
BROWNPIP
COMPBLUE
COMPSPAN
COMPSTA1
COMPSTA2
COMPTALL
COMPWERD
CRATE1
CRATE2
CRATE3
CRATELIT
CRATWIDE
DOORBLU
DOORBLU2
DOORRED
DOORRED2
DOORYEL
DOORYEL2
EXITSTON
GRAY1
GRAY2
GRAY4
GRAY5
GRAY7
GRAYPOIS
ICKWALL1
ICKWALL2
ICKWALL3
ICKWALL4
ICKWALL5
LITE3
LITE5
LITEBLU4
METAL1
NUKEEDGE1
NUKEPOIS
SHAWN1
SLADPOIS
SLADSKUL
STEP1
STEP3
STEP4
STEP5
STEP6
STONE
STONE2
STONE3
SUPPORT2
SW* (except SW[12]SKULL)
TEKWALL1
WOOD4
WOODGARG
------------------------------
From: andy@eng.kvaerner.no (Andrew Walker)
Date: Wed, 11 Jan 1995 10:15:06 +0100 (MET)
Subject: Re: sidedef mode again
>
>
> So, in linedef mode you color lines according to their function. In sector
> mode you color them according to what their adjacent sector types are. What
> about sidedef mode?
>
> I've been thinking about coloring them according to what textures they are
> missing.
>
Sounds good. On a practical note though, can you manage to identify *POSSIBLE*
missing textures, e.g. when moving floors and ceilings expose missing textures
that are not visible in the static map picture?
Of course, experienced WAD designers won't fall foul of these missing texture
traps, but sometimes I wish DEU would spot them for me.
- -Andy
- --
Andy Walker Kvaerner Engineering a.s.
Andrew.Walker@eng.kvaerner.no P.O. Box 222, N-1324 Lysaker, Norway
......if the answer isn't violence, neither is it silence......
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Wed, 11 Jan 95 09:41:45 GMT
Subject: Re: Medusa strikes again
Robert Forsman wrote:
> OK, I just finished a survey of all the missions in DOOM2. Here are textures
>which ID used on ST normals.
>
[snip]
>
> My analysis is that the patches in each of them all have a y offset of 0
>(which has been hypothesized before). If this is the case, then this rules out
>the following textures (however, it still leaves a buttload):
[snip]
It would seem that there must be no overlap either (contrary to my earlier
mailing, I know Bob!) - but there aren't many textures that this effects in
addition to the ones Bob has already mentioned as eliminated because of Y
offset. BROVINE (etc) is all that springs immediately to mind, but I don't
have the list in front of me right now...
- -Steve
------------------------------
From: eedraq@chapelle.eed.ericsson.se (Raphael Quinet)
Date: Wed, 11 Jan 95 11:39:53 +0100
Subject: Re: sidedef mode again
> Sounds good. On a practical note though, can you manage to identify *POSSIBLE*
> missing textures, e.g. when moving floors and ceilings expose missing textures
> that are not visible in the static map picture?
>
> Of course, experienced WAD designers won't fall foul of these missing texture
> traps, but sometimes I wish DEU would spot them for me.
>
I have been thinking about this problem. I re-wrote the part of DEU that
deals with LineDefs and Things, so that each type has a set of properties.
One of these properties tells DEU if the Sector activated by a LineDef will
move up or down. I am now adding the code to check for textures that are
uncovered when the floor or ceiling moves.
This will make the test for missing textures a bit slower, but I think it's
worth it. By the way, I also added a check for Things. It checks if any
Things are outside of the map, or in a room which is too small for the
Thing to fit (ceiling too low). I am also adding some code to check if each
teleporter has a teleporter exit in the corresponding Sector, etc.
My aim is to have DEU 110% compliant to Bob's Consistency Checker (tm). :-)
Maybe DEU 5.3 will already do 80% of it. By the way, thanks to Robert Forsman
for his great document.
- -Raphael
------------------------------
From: Robert E Arthur <rea@st-andrews.ac.uk>
Date: Wed, 11 Jan 1995 13:54:56 +0100
Subject: Line types
I am having endless problems with line types - it appears that the level
I am working on contains (or *would* contain) about three situations
where I need a sector to do (fairly simple) things that ID never did,
forcing me to change the design of my level. However, in case I am
using out of date information, is there any way to make a ceiling
raise/goto its HAC?
Also, can I make a floor lower/goto any adjacent floor with either
trigger *or* numeric change? It doesn't seem like *too* much to ask!
Oh how I wish someone would wave a magic wand and make line types
editable ;)
Byeeeee,
Bob.
...Somking is the principle cause of statistics...
------------------------------
From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Wed, 11 Jan 95 08:24:05 CST
Subject: Re: sidedef mode again
>My aim is to have DEU 110% compliant to Bob's Consistency Checker (tm). :-)
>Maybe DEU 5.3 will already do 80% of it. By the way, thanks to Robert Forsman
>for his great document.
This reminded that I had meant to post my collection of items-to-be-
checked-for-consistency. Seeing as how I can go by Bob also, I can add to
Bob's Consistency Checker without any inconsistency. Anyway here is the
list:
E Level area too large for BLOCKMAP (creates more than 21844 blocks)
E More than 64 animated walls
E Need at least two sectors (really need at least two subsectors)
E Manual door type on one-sided LINEDEF
E Missing first/right SIDEDEF
E LINEDEFS cross
E zero-length LINEDEF (VERTEXES overlap or same VERTEX)
E LINEDEF has illegal right SIDEDEF reference
E LINEDEF has illegal left SIDEDEF reference
E SIDEDEF has illegal SECTOR reference
E Illegal special SECTOR type
E No Player 1 start
W/E No Player 2 start (error in Cooperative mode)
W/E No Player 3 start (error in Cooperative mode)
W/E No Player 4 start (error in Cooperative mode)
W/E Less than 4 deathmatch starts (error in Deathmatch mode)
W More than 10 deathmatch starts
W No exit mechanism (LINEDEF nor SECTOR)
W One-sided LINEDEF has 2S bit set
W One-sided LINEDEF doesn't have Im bit set
W Two-sided LINEDEF doesn't have 2S bit set
W Missing upper texture
W Missing lower texture
W Two-sided LINEDEF normal texture has overlapping patches
W Texture not long enough
W Special LINEDEF has zero tag
W Special LINEDEF does not reference any SECTOR
W Special SECTOR has zero tag
W SECTOR has non-zero tag, but is not referenced by LINEDEF
W SECTOR has more than one teleport exit
W Teleport LINEDEF refers to more than one SECTOR
W Target SECTOR has no teleport exit
W SECTOR floor height above ceiling height
W SECTOR not closed
W Unreferenced SECTOR
W Unreferenced VERTEX
W Unreferenced SIDEDEF
W THING not in SECTOR
W Creature stuck in one-sided LINEDEF
W Creature overlaps another creature
W THING too tall for SECTOR
W Red key but no red door
W Red door but no red key
W Blue key but no blue door
W Blue door but no blue key
W Yellow key but no yellow door
W Yellow door but no yellow key
W Red key not present in all skill levels
W Blue key not present in all skill levels
W Yellow key not present in all skill levels
Robert Fenske, Jr. rfenske@swri.edu Sw | The Taming the C*sm*s series:
Electromagnetics Division /R---\ |
Southwest Research Institute | I | | "The Martian canals were the
San Antonio, Texas USA \----/ | Martians' last ditch effort."
------------------------------
From: D.Casali@rea0808.wins.icl.co.uk
Date: Wed, 11 Jan 1995 08:23:06 +0000
Subject: mulitple wads
I have recently paid a huge price when trying to run two sound
patch wads at once and saving a game in Doom2. It crashed and
then proceeded to wipe out my directory structure in all
associated directories, as well as giving drive C a bad file
allocation table. Has anyone come across this error before? or
perhaps no-one else tries to run two sound wads at once??? DC
------------------------------
From: Robert E Arthur <rea@st-andrews.ac.uk>
Date: Wed, 11 Jan 1995 15:42:40 +0100
Subject: Re: Line types
> From: Robert E Arthur <rea>
> [stuff about line types]
Sorry - I knew there was something missing - both of these should be S1
activated.
Byeeeee,
Bob.
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Wed, 11 Jan 95 15:22:52 GMT
Subject: Re: Line types
At 12:54 pm 11/1/95, Robert E Arthur wrote:
>I am having endless problems with line types - it appears that the level
>I am working on contains (or *would* contain) about three situations
>where I need a sector to do (fairly simple) things that ID never did,
>forcing me to change the design of my level. However, in case I am
>using out of date information, is there any way to make a ceiling
>raise/goto its HAC?
type 40 - W1 is the closest you can have.
>
>Also, can I make a floor lower/goto any adjacent floor with either
>trigger *or* numeric change? It doesn't seem like *too* much to ask!
>
37 & 84 (both W, not S, I'm afraid) is all. So, yes, it is too much to ask.
Mostly because the nasties you getting rid of with such lines are usually
in pits and such-like. Nukage slime looks silly on platforms ;)
>
>
>...Somking is the principle cause of statistics...
smoething like that, anyway......
- -Steve
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Wed, 11 Jan 1995 11:03:18 EST
Subject: Re: sidedef mode again
eedraq@chapelle.eed.ericsson.se (Raphael Quinet) ,in message <9501111039.AA1426
0@chapelle.ericsson.se>, wrote:
> My aim is to have DEU 110% compliant to Bob's Consistency Checker (tm). :-)
> Maybe DEU 5.3 will already do 80% of it. By the way, thanks to Robert Forsma
>> n
> for his great document.
DEU was the source of >1/3 of the checks in that document. The rest are
from conversations on this list. I just arranged it all in one place.
I have added a new 1* consistency check in the sectors section: lack of a
secret sector. This causes a very frustrating 0% secrets to appear on the
ending screen. Heretic doesn't have this problem, but it's probably better
to add the check than procrastinate until you have a special heretic flag.
Also, when you're checking for the existence of teleporters, make sure that
you ignore all teleporters which have the MU flag set (same with player 1
starts). Tenements has a bug where the only target for a teleporter has the
MU bit set so if you fall into the goo near the archvile in single-player
mode, you are TOAST.
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Wed, 11 Jan 1995 11:12:34 EST
Subject: Re: sidedef mode again
andy@eng.kvaerner.no (Andrew Walker) ,in message <9501110914.AA08217@eng.kvaern
er.no>, wrote:
> Sounds good. On a practical note though, can you manage to identify *POSSIBLE
>> *
> missing textures, e.g. when moving floors and ceilings expose missing texture
>> s
> that are not visible in the static map picture?
Well, I'm taking my hat off to Raphael because he's doing this, and I will
probably run a sed script on his code to make it usable by me :) However, it
is NOT a programming feat I recommend to wusses. It would be tedious and
error-prone and a real bitch to test. I think we almost have a grip on what
happens to all the DOOM II linedefs, but we could be wrong. It will be a
while before we completely understand the behavior of Heretic.
> Of course, experienced WAD designers won't fall foul of these missing texture
> traps, but sometimes I wish DEU would spot them for me.
Wrong again. DOOM II has missing textures all over the place, as does
heretic. However, most of them are almost unnoticeable, except for the one
building in The Courtyard which is missing an entire linedef.
The most experienced WAD designers in the world still fuck up. Let a
machine do the tedious work-checking for you. Pity the DOOM engine doesn't
dump a file of fuck-ups for you to peruse later...
------------------------------
From: Stephen Gates <skg8310@email.unc.edu>
Date: Wed, 11 Jan 1995 11:23:26 -0500 (EST)
Subject: Adding new music to PWAD
What's the best way to add new music to a PWAD? I just created a
beautiful Deathmatch WAD and want some jazzy/pop background music.
Anyone up for making it?
Also, I'm new here. Is it customary to post binaries of new PWADS we've
made?
Anyone else have problems with Doom's autoaiming? I've built large areas
with ledges but have had to lower the ledges and shrink the areas
considerably because the game won't autoaim at a certain distance (which
is not very far). It's a real pain in the wazoo.
- --Stephen
------------------------------
From: Stanley Stasiak <stan@yarrow.wt.uwa.edu.au>
Date: Thu, 12 Jan 1995 00:33:36 +0800 (WST)
Subject: Re: sidedef mode again
> W More than 10 deathmatch starts
That reminds me... why does e1m6 have 11 dm starts? hmm?
Also, what significance does the 'multi' bit have on dm starts.
e1m1 has it others dont.
Stan.
------------------------------
From: eedraq@chapelle.eed.ericsson.se (Raphael Quinet)
Date: Wed, 11 Jan 95 17:34:12 +0100
Subject: Re: sidedef mode again
> This reminded that I had meant to post my collection of items-to-be-
> checked-for-consistency. Seeing as how I can go by Bob also, I can add to
> Bob's Consistency Checker without any inconsistency. Anyway here is the
> list:
>
[...]
Thanks for the list. I just checked it, and my code for DEU 5.3 has already
most of these tests implemented.
> W SECTOR has non-zero tag, but is not referenced by LINEDEF
There will be a problem when checking Id's levels, because they use
non-referenced tag numbers to prevent their IDBSP nodes builder from
doing Bad Things. So you should be careful about #99, #999 and maybe
some others. And of course, there is the special tag 666, which should
only be used on ExM8.
> W SECTOR has more than one teleport exit
Only one teleport exit on *each difficulty setting*. It is allowed
to have several exits for your teleporter, as long as there is only
one active at a time (D12, D3, D45).
Even if a teleport has several exits, Doom will not crash (as far as
I know). The first one will be choosen.
> W Teleport LINEDEF refers to more than one SECTOR
This is not a problem, considering what I wrote above. This is even
a very good way to have a level which has to be solved in totally
different ways depending on the difficulty setting: you teleport in
different places.
> W THING not in SECTOR
This has to be checked for Doom, but the situation is a bit different
with Heretic. In Heretic, some "sound-only" objects are usually oustide
of the map, just behind a wall. I had to modify the code in DEU 5.3 for
these objects (because I want to support Heretic too).
> W Creature overlaps another creature
Or any other object.
- -Raphael
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Wed, 11 Jan 1995 11:38:32 EST
Subject: consistency checking
fenske@rocke.electro.swri.edu (Robert Fenske Jr) ,in message <9501111424.AA2866
4@rocke>, wrote:
> E Level area too large for BLOCKMAP (creates more than 21844 blocks)
> E More than 64 animated walls
> E Manual door type on one-sided LINEDEF
What happens if the linedef is non-ST but is still 2-sided?
> E Illegal special SECTOR type
> W One-sided LINEDEF doesn't have Im bit set
Not sure this one is necessary.
> W Two-sided LINEDEF doesn't have 2S bit set
This has uses.
> W Two-sided LINEDEF normal texture has overlapping patches
We still haven't completely figured this out yet. Romero, help?
> W Texture not long enough
Huh?
> W Special LINEDEF has zero tag
If it's not a manual door.
> W Special LINEDEF does not reference any SECTOR
> W Special SECTOR has zero tag
uh, I can have a blinking sector without a tag.
> W SECTOR has non-zero tag, but is not referenced by LINEDEF
> W SECTOR has more than one teleport exit
> W Teleport LINEDEF refers to more than one SECTOR
I think this would be acceptable if there was still only one thing per
difficulty level. Gotta investigate...
> W Red key but no red door
> W Red door but no red key
> W Blue key but no blue door
> W Blue door but no blue key
> W Yellow key but no yellow door
> W Yellow door but no yellow key
> W Red key not present in all skill levels
> W Blue key not present in all skill levels
> W Yellow key not present in all skill levels
Ah, very nice.
Anyway, added. Keep yours up-to-date! Always good to have redundancy.
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Wed, 11 Jan 95 17:08:03 GMT
Subject: Re: Adding new music to PWAD
>
>Also, I'm new here. Is it customary to post binaries of new PWADS we've
>made?
>
No, no no, PLEASE!!! Put 'em up on CDROM.COM and let those who are
interested fetch 'em.
- -Steve
------------------------------
From: "Tim Hawkins" <Tim.Hawkins@specastro.com>
Date: 11 Jan 1995 10:12:49 -0800
Subject: Re: Descent (sorry)
1/11/95
10.07
RE>>Descent (sorry)
While were at it, lets try to add 3D Painting to the Descent Editor. :)
Being an old 3D Studio, (now Wavefront) user, I think that would be a
tremendous assest to the editor. They had to import their 3D models in their
somehow, I wouldn't doubt they used 3D Studio.
Tim "the hawk" Hawkins
- ------------------------------
Date: 1/11/95 1.09
To: Hawkins, Tim
From: doom-editing@nvg.unit.no
On Tue, 10 Jan 1995, Brad Willman wrote:
> um... and I have done some Descent Level editor thing so far...
> it sort of looks like 3d studio(Tm) :) right at this moment....
There's an idea for those working on Descent editors: a feature that
allows importing files from 3D Studio, or various other modeling and CAD
programs...once you get regular Descent editing figured out, of course.
Ian
- ------------------ RFC822 Header Follows ------------------
Received: by specastro.com with SMTP;11 Jan 1995 01:05:58 -0800
Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.9/8.6.9) id
IAA15525 for doom-editing-outgoing; Wed, 11 Jan 1995 08:07:02 +0100
Received: from runix.runit.sintef.no (runix.runit.sintef.no [129.241.1.5]) by
sabre-wulf.nvg.unit.no (8.6.9/8.6.9) with SMTP id IAA15478 for
<doom-editing@nvg.unit.no>; Wed, 11 Jan 1995 08:06:35 +0100
Received: from kuhub.cc.ukans.edu by runix.runit.sintef.no with SMTP (PP)
id <20879-0@runix.runit.sintef.no>; Wed, 11 Jan 1995 02:23:46 +0100
Received: from falcon.cc.ukans.edu by KUHUB.CC.UKANS.EDU (PMDF V4.3-11 #9008)
id <01HLOY16E20G8X3NMQ@KUHUB.CC.UKANS.EDU>;
Tue, 10 Jan 1995 19:23:37 -0600 (CST)
Received: by falcon.cc.ukans.edu; id AA05911; Tue, 10 Jan 1995 19:23:25 -0600
Date: Tue, 10 Jan 1995 19:23:25 -0600 (CST)
From: Ian Johnson <ijohnson@falcon.cc.ukans.edu>
Subject: Re: Descent (sorry)
In-reply-to: <2ad.359.47@uniserve.com>
To: doom-editing@nvg.unit.no
Message-id: <Pine.OSF.3.91.950110192002.18408A-100000@falcon.cc.ukans.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-doom-editing@nvg.unit.no
Precedence: bulk
Reply-To: doom-editing@nvg.unit.no
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Wed, 11 Jan 1995 13:01:01 EST
Subject: Re: consistency checking
S.Benner@lancaster.ac.uk (Steve Benner) ,in message <ab39c386030210043f93@[148.
88.12.82]>, wrote:
> Hi Robert,
>
> I haven't been keeping track of all these consistency checking additions of
> late, especially as I'm sure you have been! Could you send me your latest
> BCC list sometime please after you've added the latest goodies? (I love
> the door/key checking idea too. Brilliant!) Ta!
Have one:
Bob's Consistency Checker
- by Robert Forsman <thoth@cis.ufl.edu>
This document describes Bob's Consistency checker. Such a program
does not yet exist, and may never (unless Bob gets some spare time).
You may compare your consistency checker to this checklist and make
claims like "25% Bob compliant!".
This list is not purely the product of my own brain. I have used
both DoomCAD and DEU and the consistency checks they provided have
provied invaluable (yet, incomplete). Also, discussions of DOOM
engine limitations on the doom-editing mailing list gave me ideas for
new consistency checks.
I refered to the DEU 5.2.1 source while writing this document. Long
live TRULY free software!
If you have any contributions, drop me a line and get yourself a
mention.
* is basic check
** is an advanced check and usually requires that someone with a brain
write the code.
W flag means a warning (violating these checks might be necessary or
reasonable for certain special effects, but usually it's a mistake).
ST means shoot-through (bit 2 of the linedef flags, often referred to
by the name 2-sided, although this is misleading)
THINGS: (remember difficulty masks)
The following four result in a monster that rotates to face you,
but never attacks.
* Monster centered in a sector that is too short for it.
** Monster partly in a sector that is too short for it.
** Monster half-stuck in a wall (not sure how the engine computes this).
* Monster too close to another monster (they are both stuck till one
dies, then the other is freed) (not sure how the engine computes this).
* thing with bogus type
* an item that is completely not inside a sector
*W an item that is visually too tall for its sector
* teleporter target with no source linedef
* missing a player 1 start. remember the difficulty masks)
*W missing player 2-4 starts, missing deathmatch starts
* More than one player 1 start (causes ghost player 1 things). This
probably applies to player 2-4 as well. Remember the difficulty masks.
* >10 deathmatch starts (bad, according to ID guys)
VERTICES:
* two vertices that share the same coordinates.
* vertex not used by any linedef or seg
LINEDEFS:
* linedef that refer to nonexistent sidedefs, or vertices.
* linedef with bogus type
* degeneracy. linedef with same starting and ending vertex.
** overlaying linedefs. Simple example:
line from (4,0) to (-2,0) and another
line from (2,0) to (-4,0).
another example
line from (4,0) to (0,0) and another
line from (0,0) to (4,0).
* linedef with no sidedefs.
* linedef with a left sidedef but not a right.
(or, more compactly: linedef with no right sidedef.)
* linedef that intersects another linedef.
* linedef with one sidedef should have impassable set, and ST clear.
*W linedef that has two sidedefs, an impassable bit set, and no
texture on either normal.
*W linedef that bounds two sectors where the ceiling height
difference is >x, where x is some number that one of those
doom-editing guys will figure out one day (the Flash-Of-Sky effect).
*W lack of a linedef with exit type.
* more than 64 animated walls
* manual door on 1-sided linedef
SIDEDEFS:
* sidedef not referred to by any linedef
* sidedef that refers to nonexistent sector.
* sidedef on non-ST linedef missing a normal texture.
* sidedef on ST linedef missing a required upper or lower texture.
) sidedef
without an upper texture
referring to a sector with ceiling higher than the neighbor
where either of the sectors doesn't have F_SKY1 as the ceiling
) sidedef
without a lower texture
referring to a sector with floor lower than the neighbor
where either of the sectors doesn't have F_SKY1 as the floor
*** sidedef that would be missing an upper or lower texture due to
the motion of a sector's floor/ceiling.
** texture with overlapping patches on a ST linedef's NORMAL
texture. (Medusa effect) Or maybe it's vertically tiling patches
(whatever that means).
**W animated texture on an ST normal. (it doesn't animate in earlier engines)
* sidedef with a short (<128 tall) texture on an upper or lower
texture where the ceiling/floor difference is larger than the
texture's height. (Tutti-Frutti effect) Can also be caused by
yoffsets.
*W ST sidedef
1) with a texture on the normal that is too tall for the
normal space and
2) where there is no floor change (or perhaps if the lower
unpegged bit is set, no ceiling change)
*W normal textures on ST sidedefs can extend into the floor or
ceiling through yoffsets.
*W ST sidedef with a texture on the normal that is too
short for the normal space
* sidedef that refers to a nonexistent wall texture
SECTORS:
* sector with bogus type
* WAD with less than 2 SUBsectors is bad. (so, have >=2 sectors, or
one non-convex sector.)
* sector not referred to by any sidedef
* sector that is unclosed. The sidedefs of a sector should form a
set of closed cycles with all the sidedefs of a single cycle on a
single side of that cycle.
** sector that is REALLY unclosed. ANY line from infinity to
infinity should have linedef crossings that match this regular
expression: ^(spoo* in out)* spoo*$. The "in" is when you cross a
linedef from the "other" sidedef side to the "my" sidedef side. "out"
is when you cross a sidedef from the "my" side to the "other" side.
"spoo" is crossing a linedef that has nothing to do with "my" sector.
No "spoo" is allowed between an "in" "out" sequence.
* sector whose ceiling is lower than its floor (or is there a use
for such sectors?)
* sector that refers to a nonexistent floor or ceiling texture
*W sector taller than 1023 pixels (1.2 engine limit).
* lack of a secret sector (causes 0% to appear in DooM 1/2 which is
frustrating for the player)
TAGS
* A teleporter linedef with no destination thing in any tagged
sector. (remember your difficulty masks)
* A teleporter linedef with several destination things for a
difficulty level.
? teleporter tagged to several sectors (what are the rules, anyway)?
* a linedef that is missing a tag (which ones need tags, anyway?
manual door's don't need them).
* a tagged linedef that has no matching tagged sector.
* a tagged sector that has no matching linedef.
MISC:
* Level bounds too large for BLOCKMAP (creates more than 21844 blocks).
* door without corresponding key, or key without corresponding door.
Remember your difficulty masks.
CREDITS:
DEU's editobj.c by Brendon Wyber and Raphal Quinet.
DoomCAD by Matt Tagliaferri.
The Unofficial Doom Specs by Matt Fell
Robert Fenskey Jr. <fenske@rocke.electro.swri.edu>
the guys on doom-editing@nvg.unit.no.
> I've finished my checking of the 2-s textures limitation now and it does
> seem to be Y=0 and no overlapping patches.
OK, I'll use that.
> Does anyone know if
> Heretic has the same limitation, have you heard/investigated?
I'll have a look through the shareware wad and publish the results. I'm
going to guess that some restrictions are lifted though and I'll tell you why:
My friend who is working on a DOOM-like engine has come to the conclusion
that transparent textures are rendered in the thing stage, not the walls
stage. Since Heretic has some things that use multiple patches (which pisses
me off. I am not flexible enough to preview multi-patch sprites), its
enhanced thing rendering capabilities might carry over into transparent wall
textures.
Since the rendering of a perspective texture is still more complicated than
rendering a scaled sprite, there may not have been parallel improvements, but
we'll see.
I think I'll order the registered Heretic so I can print out a visual
catalogue of textures. Would anyone else be interested in several megabytes
of postscript?
------------------------------
End of doom-editing-digest V1 #117
**********************************
