Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 030
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #30
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Monday, 31 October 1994 Volume 01 : Number 030
Re: Changing the Doom Pallette
Re: Node building
Re: txalign
Re: DEU 5.3
Re: Silent teleporters
Re: txalign
Re: Node building
Re: Node building
Non-Delivery of:Re: txalign
DEU 5.3 -wad conversions to DOOM2
79!!!
Non-Delivery of:Re: Node building
Re: Silent teleporters
Re: Node building
Re: DEU 5.3 -wad conversions to DOOM2
----------------------------------------------------------------------
From: A computer genius <stevenl@ccnet.com>
Date: Sun, 30 Oct 1994 17:35:46 -0800 (PST)
Subject: Re: Changing the Doom Pallette
On Sun, 30 Oct 1994 DTeeter@aol.com wrote:
> Has any one ever thought of changing the Doom palette to 255 grays (plus
> cyan).
Only problem with that is the way the palette works in the mode Doom uses
can only do 64 shades of any color. (Gray included)
------------------------------
From: "Kram Llens" <kram_llens@rmit.edu.au>
Date: Mon, 31 Oct 1994 13:39:52 EST-10
Subject: Re: Node building
> From: sky@verity.com (Sky Golightly)
>
> Our sysadmin's wife plays. So, there's at least one more, female DOOM
> player that is.
>
Someone wrote femdoom, to put a female face in the status bar, so
that is likely to be another one.
Kram
Kram_Llens@rmit.edu.au RMIT, Melbourne, Australia
Ph (03) 660 5378 Fax (03) 660 5342
"I bought some dehydrated water, but I don't
know what to add to it" -Steven Wright
------------------------------
From: tedv@geom.umn.edu
Date: Sun, 30 Oct 94 21:08:44 CST
Subject: Re: txalign
> Sounds like an impressive lot of work. Whats the current features list
> standing at? Oh, and do you need some beta-testers?
Yes, it is. But all I can say is that I'm done with my work. Oh, except
there's a bug report in my mailbox from my last release of dialog box
code. It shouldn't be hard to fix or anything though... I hope. But
the code itself is written.
> >Any votes on this? Yea? Nay? If I get enough "yes"s, I'll run the idea
> >past Raphael.
>
> That would be cool. Could put them up in binaries. To tell you the
> truth, until I joined this list I thought that 5.3 had died. I'm sure
> others feel the same. A reminder might be a nice idea. Just to still up
> things.
Yeah.... We were thinking about posting a message to a.g.d.announce
concerning the status of DEU 5.3 from a letter Raphael sent us, but
we wanted to check with him first. To tell you the truth, I haven't
red news in a couple of weeks so for all I know it might already have
been posted... Oh, and the current tally is 3 yes for screen shots,
1 no for screen shots.
And incidently, we already have a lot of beta testers. :) So no more
new beta testers. Currently the only way to join the DEU project now
is to actually do some coding work.
- -Ted
- --
Ted Vessenes | "The only force stronger than fate is dramatic irony."
tedv@geom.umn.edu | "[William] Shatner couldn't direct his way out of the
tedv@cs.umn.edu | bathroom with both hands and a map!"
tjvessen@midway.uchicago.edu -Ryan Ingram (1st), -Kibo's .sig (2nd)
------------------------------
From: tedv@geom.umn.edu
Date: Sun, 30 Oct 94 21:18:51 CST
Subject: Re: DEU 5.3
> Is it just me, or does it sound a little silly to make bottoms up
> rewrite of DEU into a .1 upgrade? It seems that you guys should be
> thinking about making it DEU 6.0.
Well... This isn't a bottoms up rewrite. Only the interface has been
truely rewritten. The rest is just a set of addons to the current
program.
Re: DEU 6.0: B. Wyber has been working on it for a couple of months now.
I've gotten to see a preview of it (not very detailed yet, but it looks
nice; I got some ideas for DEU 5.3 interface from that preview). This
is a core rewrite, and the major reason for the rewrite (aside from
interface) is to allow for an ever versatile UNDO button. Well, there
will be a lot more than that.
But we haven't forgotten about DEU 6.0. The current rumor is also that
we will just work on DEU 6.0 after the 5.3 release.
But that's all just rumors. :)
- -Ted
- --
Ted Vessenes | "The only force stronger than fate is dramatic irony."
tedv@geom.umn.edu | "[William] Shatner couldn't direct his way out of the
tedv@cs.umn.edu | bathroom with both hands and a map!"
tjvessen@midway.uchicago.edu -Ryan Ingram (1st), -Kibo's .sig (2nd)
------------------------------
From: cgasparo@cymbal.aix.calpoly.edu
Date: Sun, 30 Oct 1994 20:47:57 -0800
Subject: Re: Silent teleporters
>> I know not if this has already been covered, my guess would be yes, but
>> I have been trying to create silent teleporters. Getting rid of the
>> graphic is easy enough as you just make it totally invisible, but I am
>> stymied as to how to get rid of the sound. Solutions?
>> Steve H.B.
>>
>Maybe if you create a sound file a few bytes long, containing only
>silence... I can't see what that wouldn't work, and it can even be a PWAD..
Well, that would work but for the fact that my version of dmaud doesn't
contain the register for the teleporter sound, as well as the fact that
the objects involved (teleport landing and teleport flash) do not
contain a reference to the sound (look in dehacked). I belive that it is
refered to in the frames with the sub table but it doesn't seem to be
the same as other sounds. The sound register exists but, as I said, my
version of dmaud (v-1.1) doesn't have it. Is it contained in a later
version of it? Is there another program which allows access to it?
Steve H.B.
------------------------------
From: cgasparo@cymbal.aix.calpoly.edu
Date: Sun, 30 Oct 1994 20:50:23 -0800
Subject: Re: txalign
>And incidently, we already have a lot of beta testers. :) So no more
>new beta testers. Currently the only way to join the DEU project now
>is to actually do some coding work.
>-Ted
No prob. And I can't code yet so I'll just sit by and work on my wads.
Steve H.B.
------------------------------
From: "Scott D. Webster" <webstes@iia.org>
Date: Sun, 30 Oct 1994 23:53:40 -0500 (EST)
Subject: Re: Node building
On Sat, 29 Oct 1994, Jeff Rife wrote:
> I had this weirdness, too. It is related to the orthogonality (squareness)
> of the wad, I think.
That very well may be it. I went back & re-checked every stinkin' single
linedef and all the sector references on the sidedefs are correct. The .wad
is _not_ very orthogonal (can't wait to see what the spell checker thinks
of _that_ word). :) Of 16 sectors only 6 are square along the grid with
one being a square rotated like a baseball diamond. I think I'm going
to post it to alt.binaries.doom and see if anyone will download it and
see if they can figure out the problem. I'm stumped. Since it does
compile w/ nodebld, though, at least I can keep working on it.
Scott D. Webster Junior, Computer Science - William Paterson College
webstes@iia.org ??????????????????????????????????????????
scottw@deathstar.wilpaterson.edu ?? How many wigs would a whizzywig whiz ??
?? if a whizzywig could whiz wigs? ??
??????????????????????????????????????????
------------------------------
From: cgasparo@cymbal.aix.calpoly.edu
Date: Sun, 30 Oct 1994 22:44:48 -0800
Subject: Re: Node building
>> I had this weirdness, too. It is related to the orthogonality (squareness)
>> of the wad, I think.
>
>That very well may be it. I went back & re-checked every stinkin' single
>linedef and all the sector references on the sidedefs are correct. The .wad
>is _not_ very orthogonal (can't wait to see what the spell checker thinks
>of _that_ word). :) Of 16 sectors only 6 are square along the grid with
>one being a square rotated like a baseball diamond. I think I'm going
>to post it to alt.binaries.doom and see if anyone will download it and
>see if they can figure out the problem. I'm stumped. Since it does
>compile w/ nodebld, though, at least I can keep working on it.
Sure, I'll download it. And BTW, as far as node-builders go I've had no
problems at all with BSP1.2x. Of course you need floating point support
for it but it's never wronged me. Anyways, I'll DL and take a look at it
along with anyone else who wishes to. Just put 'scott test 1' in the
subject or something like that to make us recognize it.
Steve H.B.
------------------------------
From: "POSTMASTER" <POSTMASTER@notes.seagate.com>
Date: Mon Oct 31 00:54:10 1994
Subject: Non-Delivery of:Re: txalign
Intended recipients: brian myers
Failure reason: Router: Unable to open mailbox file GISKARD mail.box: Server not responding
From: tedv@geom.umn.edu
Received: from lovelace.geom.umn.edu by cameron.geom.umn.edu; Sun, 30 Oct 1994
01:11:40 -0500
Message-Id: <199410300611.AA29830@lovelace.geom.umn.edu>
Received: by lovelace.geom.umn.edu; Sun, 30 Oct 1994 01:11:38 -0500
Subject: Re: txalign
To: doom-editing@nvg.unit.no
Date: Sun, 30 Oct 94 1:11:38 CDT
In-Reply-To: <9410292227.AA98928@cymbal.aix.calpoly.edu>; from
"cgasparo@cymbal.aix.calpoly.edu" at Oct 29, 94 3:27 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-doom-editing@nvg.unit.no
Precedence: bulk
Reply-To: doom-editing@nvg.unit.no
> You're not making it a windoze app are you?!?!? Please say you just
> meant a GUI? I assume thats what you meant. BTW: What is the ETA of 5.3?
No, we just mean a GUI. *We* have more self respect than to make something
that would run in windoze. But rumor has it that DEU 5.3 will also run
in linux... But I don't know how long after 5.3 this will be released, etc,
etc. Just consider it a rumor.
ETA of 5.3: an iD two-weeks[tm].
Here's what has to happen for 5.3 to be released:
I have to finish the tab/shift-tab keyboard focus for keyboard interfacing
Other coders need to finish the details of their projects (I hear someone
is having a real bear with the GIF code. The post script printing code
is done though.) Most of the work is alledgedly done. You can consider
the dialog box code (my segment) 97% done. The texture alignment is
like.... 95%? something close to that. We've gone a long way.
Raphael pastes all of the changes together into a beta.
We test the beta for a week or so, make all of the needed changes,
And release 5.3.
Yay. It's the first two steps that give the greatest uncertainty in the
release date. I know I should have more time since I'm switching my class
load to be softer, but I don't know what's holding up other people.
Incidently, I've been thinking about making some screen shots of DEU 5.3
just so people know that we haven't been slacking off and that DEU *has*
progressed greatly... But the screen shots are still nothing compaired
to the real program.
Any votes on this? Yea? Nay? If I get enough "yes"s, I'll run the idea
past Raphael.
> >No, alignment is only on a single sidedef. However, you can tweek things
> >like this by setting or resseting upper/lower unpegged while still
> >setting offsets. It will give you infinite flexability, but it will
> >increase what you can do a little more.
>
> Could you clarify that last bit. It almost made it sound like you could
> do seperate alignment of uppers and lowers and norms.
Not really. You just have slightly less inflexability.
Suppose you have a sector that is 96 high. You put a normal wall texture
that is 128 high. If you set the linedef lower unpegged, the texture will
be drawn from the bottom up, not the top down. This has a simulated
effect of giving the texture an offset of 32 (or would that be -32?). Now
since you can set one flag for the upper texture and one for the middle/lower
textures, you can "simulate" different offsets. Of course, you would also
get weird effects if the sector changed heights.
So in most cases, no. But if you really work at it and have a very
special case, you can get things to work out fine.
- -Ted
- --
Ted Vessenes | "The only force stronger than fate is dramatic irony."
tedv@geom.umn.edu | "[William] Shatner couldn't direct his way out of the
tedv@cs.umn.edu | bathroom with both hands and a map!"
tjvessen@midway.uchicago.edu -Ryan Ingram (1st), -Kibo's .sig (2nd)
### Message trace information:
### IGATE1 Version 8, IGATE2 Version 10
### MsgFileName: m:\mgate\inbound\23494800.MIN
### From: doom-editing@nvg.unit.no
### To: brian_myers@notes.seagate.com
- --
POSTMASTER -- POSTMASTER@notes.seagate.com
- -------------------------------------------------------------------------
Seagate Technology - 920 Disc Drive - Scotts Valley, CA 95066 USA
Main Phone 408-438-6550 - Email Problems postmaster@notes.seagate.com
Technical Support: BBS 408-438-8771 Fax 408-438-8137 Voice 408-438-8222
- -------------------------------------------------------------------------
### OGATE Version 8 message trace and attachment information:
### MsgFileName: m:\mgate\outbound\794.MSG
### Org Date: 10-29-94 11:50:02 PM
### From: doom-editing@nvg.unit.no@INTERNET @ SEAGATE
### To: doom-editing@nvg.unit.no@INTERNET
### Subject: Non-Delivery of:Re: txalign
### Attachments: none
------------------------------
From: "Gregg J. Anderson" <cadman@krypton.mankato.msus.edu>
Date: Mon, 31 Oct 1994 03:53:16 -0600 (CST)
Subject: DEU 5.3 -wad conversions to DOOM2
First, a big *thank you* for all those putting in their time on DEU.
I only wish my C skills weren't currently just beyond the 'Hello World'
stage, :-( or I would be more than happy to lend a hand.
What are the plans (if any) for converting DoomI wads to DoomII wads in DEU?
Will substituting new textures for those textures that have been removed
in Doom2 be an automatic process?
Doing it manually can be quite tedious on larger wads...
An external config file for the user to map out substituted textures would
prove to be quite useful, I would think.
Also, is there any word from those doing the GCC port, or will DEU 5.3 be
supporting extended memory?
Happy hacking,
=Gregg=
_____________________________________________________________________________
Gregg J. Anderson =o= cadman@krypton.mankato.msus.edu
Mankato State University =o= cadman@vax1.mankato.msus.edu
Mankato, MN USA =o= Flames: Barney@purple.dino.CIA.gov
- -----------------------------------------------------------------------------
GCS/MU/O d? H S g=(?) p? au-->+ a- wH V- C++>++++ UU>Lu(u-) P+ L 3 E N++
K++ W--- M-- V-@ -po+ Y+ ++@ !5 jx R G? tv- b+(b) D++>+++ B++ e+>e- u++(u)
h+@ F? r* n-- y+>++ Necrophaliacs unite! -Support Dr. Kevorkian!
------------------------------
From: Paul Good <pgood@destiny.dorm.umd.edu>
Date: Mon, 31 Oct 1994 05:58:20 +0000
Subject: 79!!!
That sucker bounces you HIGH!! =]
.... the magic number is 79 units high to be launched over by the
arch-vile. I did some playing and tweaking, and I have created a wad that
has the perfect (I think) setup for the arch-vile jump idea. You can be
popped over the wall if you stand in a corner and press towards it, or
(if you're lucky) you can stand on the line on the floor (128 from the
wall) and go clean over. This is a micro no-frills wad, just you, a
space, a wall, and an arch-vile. IDDQD and then go.
- pgood
- ---------------- almost 2K HUGE file!!! =] -------------------
begin 640 boing.zip
M4$L#!`H````&`&*37QUMGRLL!04``/X)```)````0D])3D<N5T%$#P`2`R05
M-B<X.6I[3)UN'PD&`1,TY?:6]Z%>#4ITP;$[33`\\'_1&A#@08#&`\KVESR0
M9`\0S=;I?]\^H)DHKOD"Q=9,"VAV@P">-]#,QG^0[P:V20+;-MSS!)K9>,FU
M3V";&&_[!&43P2-HMN$3I!/'757R"+9)!=OV?()FDD&S1;^@F6QPSQ7<DPX!
M4OCV`MNDA&W[GD$S&>$LWJ"9A-!LPPMH)B<TV_X*FLD*S3Y@:6NF+33[@W=K
MIB^\S1\TDQBNQ()O"3`^0/D`YQU[?8#V`=X'>%1JT*PT`>[;$U$]<(#!`0H[
M=N(`BWVQ;E)9-ZJ+$GR+)1'=U-54-S7\AV$/,>PCGEDPHGD6PP[TP/`.`^9>
MR&"?E-)-"I6:=.C2F#".4?M@WA[F0M`,CJ<Q^6R?9K$/B`'VB<.GJC7!6K9/
M=6/[`/=/M_@G]JGA]@%9P#XZQ3TQ)[D;Z\:6IQG@6!:'ZJ9#=*/>%Q%$<L"R
M90WFFV[Q373C`^Y&!8_V;XMF(FNJN&[$O03W3U6%[<-<2^A1^R`=P^QCU3CQ
M@V$7/,Y"F3XE`J6AT@A\,+E#'2_ZXL:+%B_LTW(Y=.,K.3;DZ'U#N1:X;>NF
M)^RC3W],_!'MA^-C?BSYL>"';KH]B:8@CM5VS:J:NFF(49H'_"_5!@Q@6($L
MVW!,:'BS`1W_ERI@>.`"GF6U.V[8`<(-"'$@Z(!>`TKU[U&@5O]:_X,-2!0@
MJTFW\>%\_Q].>X]'`VHR]B0',GCT@=7PN:D)!"IYX"^6!FI:#?P&*:"872K5
M.WY70*42ZPYX0*R3!HXF+WT*$<A4J"E^GPU^C6A^=F`'^T3S,',_&(JX=T")
M2I4*!W[@5,@$Q6PKZMB!)NB+:-6Q%I6PS%I-L:Z>\$XT+Y4PA4HFWAU0)5./
MK`=E*_ADHGFF`Q>\$\W;=,K@FFC^IK-?H3I%I0>,<,FD@[7)0%4FBB>P2^RO
M!=39WMN[Y>;N>HP`UJ``_ST"F8.%P8IWM`<+0M@'!#0'I;#-'6VSPG=_;S`D
MND!`:U#B_RF5P=[@_YH[[KGBM)[`E`8T^X('V18LN8!Q*OF!@`7\/OT?-D!0
MQW*D!\(Y=BW;;A#P04#;C,GV3MTW+MN-/V"-,K5M2W%##6B;`]GF`7:?LPQH
M)+!^*A7FUQG'!Z4:$R=``)Y$9.O7J4NSQD@N&_+)/"!E`Q7D?XS^RJ!,)G8=
MNT-T*F<<(%>`7P&&!3@68%F`9P&F!;@6H)N]JMP!U@5X%V!>@'L!]@7X%R!A
M@(<!,AKB`"$#I)2ZOAF@9X"A`8X&:!I@:H"K`;[JW`'B!MAKSCXL%_AR@,T!
M0CO\`5H'R!W@=X#B`98'J!X@>X#P+LWMM7RS60?XX@$1!E08D&&`1S#$@!(#
M4@QH,2#&@!P#_"QJ&+;!X-FQ%/_@F#\(!]4.D8R=`[*`V?,&*X,HI@G$@^L9
M5$3'>@95##&L!(KAAC7`PF2OH1..N8%DU&5H@F2B&"R!F,Z&QB4DH_*G<,P6
M0QDLHXK!'EA,-H]'^"<C%,,OZ+=DK!BL@F-B&.#.D0P&EVP:%"K,&*7*AKMU
MI8HTJ=.C4S;7EMU$XCL3YXL2+6ITJI%E=P=;/C4ID6=.@["<R;A;+2J5:A%/
M?RJ@9R<R[E.+]$OPQ`L,34^!?BB5WGDJN6<GUA-%XU\$7%$IFJ/Y%F\JC!_8
M.+34HDJB[4_V[#R@;>%9QHHL!U!+`0(+``H````&`&*37QUMGRLL!04``/X)
M```)````````````(`````````!"3TE.1RY704102P4&``````$``0`W````
&+`4`````
`
end
------------------------------
From: "POSTMASTER" <POSTMASTER@notes.seagate.com>
Date: Mon Oct 31 04:24:40 1994
Subject: Non-Delivery of:Re: Node building
Intended recipients: brian myers
Failure reason: Router: Unable to open mailbox file GISKARD mail.box: Server not responding
From: cgasparo@cymbal.aix.calpoly.edu
Received: by cymbal.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03)
id AA28753; Sun, 30 Oct 1994 02:03:27 -0800
Date: Sun, 30 Oct 1994 02:03:27 -0800
Message-Id: <9410301003.AA28753@cymbal.aix.calpoly.edu>
To: doom-editing@nvg.unit.no
Subject: Re: Node building
Sender: owner-doom-editing@nvg.unit.no
Precedence: bulk
Reply-To: doom-editing@nvg.unit.no
><discussion of problems w/ deu & bsp node building
>
>> Umm... silyl question I know but you are using 1.666 yes? And all of the
>> sector references on your linedefs are facing the correct sectors?
>> You're not missing any textures? Do you pass all of DEU's checks?(if you
>> use DEU)
>> Steve H.B.
>
>Well I'll go back and check it again, but it _did_ pass deu521gcc's f10
>checks. It also passed doomcad's checks (doomcad worked for the
>nodebuilding). Do you think it would actually work correctly with
>doomcad even though it had an error? I looked for all the things that
>have caused HOM's for me before (the things the faqs said to look for).
>It's definately not the textures. I'll check about the sector references
>again. If you flip a linedef deu should correct the sidedefs, right?
>
Remember, DEU has flip linedef and swap sidedef. The two do very
differnt things. The first only changes the coordination of the line,
the second swaps the actual stuff. You can also pass all the tests and
still have errors. Maybe I'm slow but it took me a bit of time to be
able to de-bug my wads one by one. Check those sector references!(not
tags) If worst comes to worst change them by hand.
Steve H.B.
BTW: DEU programmers. One little thing I thought I would mention. DEU
seems to always makke a first sidedef before a second when using the add
sidef command. Click on add second or even hitting three still makes me
go back, add the second again(made the first the first time) then delete
the first. Is it just my copy? This would be a great help if it would be
fixed now that I have become 'proficient'.
### Message trace information:
### IGATE1 Version 8, IGATE2 Version 10
### MsgFileName: m:\mgate\inbound\02594100.MIN
### From: doom-editing@nvg.unit.no
### To: brian_myers@notes.seagate.com
- --
POSTMASTER -- POSTMASTER@notes.seagate.com
- -------------------------------------------------------------------------
Seagate Technology - 920 Disc Drive - Scotts Valley, CA 95066 USA
Main Phone 408-438-6550 - Email Problems postmaster@notes.seagate.com
Technical Support: BBS 408-438-8771 Fax 408-438-8137 Voice 408-438-8222
- -------------------------------------------------------------------------
### OGATE Version 8 message trace and attachment information:
### MsgFileName: m:\mgate\outbound\808.MSG
### Org Date: 10-30-94 02:59:51 AM
### From: doom-editing@nvg.unit.no@INTERNET @ SEAGATE
### To: doom-editing@nvg.unit.no@INTERNET
### Subject: Non-Delivery of:Re: Node building
### Attachments: none
------------------------------
From: brian@phyast.pitt.edu (Brian K. Martin)
Date: Mon, 31 Oct 1994 10:15:22 -0500 (EST)
Subject: Re: Silent teleporters
>
> >> I know not if this has already been covered, my guess would be yes, but
> >> I have been trying to create silent teleporters. Getting rid of the
> >> graphic is easy enough as you just make it totally invisible, but I am
> >> stymied as to how to get rid of the sound. Solutions?
> >> Steve H.B.
> >>
> >Maybe if you create a sound file a few bytes long, containing only
> >silence... I can't see what that wouldn't work, and it can even be a PWAD..
>
> Well, that would work but for the fact that my version of dmaud doesn't
> contain the register for the teleporter sound, as well as the fact that
> the objects involved (teleport landing and teleport flash) do not
> contain a reference to the sound (look in dehacked). I belive that it is
> refered to in the frames with the sub table but it doesn't seem to be
> the same as other sounds. The sound register exists but, as I said, my
> version of dmaud (v-1.1) doesn't have it. Is it contained in a later
> version of it? Is there another program which allows access to it?
> Steve H.B.
>
I did this a while ago for the DieHard DOOM Project. Don't mess
with dmaud, just use DeHacked. Change the duration of the first
teleporter frame to 1, and change it's 'next frame' to 1 (or
is it 0?, don't matter, look at the last frame and see).
brian
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Mon, 31 Oct 1994 10:30:25 EST
Subject: Re: Node building
cgasparo@cymbal.aix.calpoly.edu ,in message <9410302256.AA23607@cymbal.aix.calp
oly.edu>, wrote:
> all just made sense and debugging it by hand was a snap. Thats when I
> found out that DEU will find blatant mistakes, but you can still do
> write things in a wrong way.
Uh, being a consistency checking nut, I want to hear about this... I
personally believe that anything that can make doom screw up and is
computable should be the target of a consistency check.
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!" People won't believe you unless I
verify it though :)
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.
2S means 2-sided
THINGS:
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).
* an item that is completely not inside a sector
* an item that is visually too tall for its sector
* A teleporter linedef with no destination thing in any tagged sector.
* missing a player 1 start
*W missing player 2-4 starts, missing deathmatch starts
* >10 deathmatch starts (bad, according to ID guys)
VERTICES:
* two vertices that share the same coordinates.
* vertex not used by any linedef
LINEDEFS:
* degeneracy. linedef with same starting and ending vertex.
* linedef that refers to the same sidedef twice (is this really bad?
DEU checks for it).
** 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.
* linedef that intersects other linedef.
* linedef that refer to nonexistent sidedefs, or vertices.
* linedef with one sidedef should have impassable set, and 2S clear.
* linedef with two sidedefs should have 2S set.
* 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.
SIDEDEFS:
* sidedef not referred to by any linedef
* sidedef that refers to nonexistent sector.
* sidedef on 1S linedef missing a normal texture.
* sidedef on 2S linedef missing a required upper or lower texture.
) sidedef
without an upper texture
referring to a sector with ceiling higher than the neighbor
where one 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
** sidedef that would be missing an upper or lower texture due to
the motion of a sector's floor/ceiling.
* multi-patch texture on a 2S linedef's NORMAL texture. (Medusa effect)
* 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)
* 2S sidedef
1) with a texture on the normal that is too tall for the
normal space and
2) where there is no floor change
* (don't know if this is actually bad or not...) 2S 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 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
* sector taller than 1023 pixels (DEU checks for this. Is it really
bad? It's certainly strange).
CREDITS:
DEU's editobj.c by Brendon Wyber and Raphal Quinet.
DoomCAD by Matt Tagliaferri.
The Unofficial Doom Specs by Matt Fell
the guys on doom-editing@nvg.unit.no.
------------------------------
From: tedv@geom.umn.edu
Date: Mon, 31 Oct 94 9:33:40 CST
Subject: Re: DEU 5.3 -wad conversions to DOOM2
> What are the plans (if any) for converting DoomI wads to DoomII wads in DEU?
> Will substituting new textures for those textures that have been removed
> in Doom2 be an automatic process?
> Doing it manually can be quite tedious on larger wads...
Mmmmm... I've heard nothing of this, but I might have missed it. There are
numerous different segments of code going on and I can't keep track of all
of them. So: Don't be suprised to see it in DEU 5.3, but don't be suprised
not to see it either.
But it's a good idea. If no one is working on it and I have time, I might
just put it in myself.
> An external config file for the user to map out substituted textures would
> prove to be quite useful, I would think.
I agree. Of course, DEU would have to be able to do a base conversion as
well. I have a routine in mind that might be able to pull it off...
though it would be timeconsuming. As in... longer than rebuilding nodes
on a 200K level. But then *you* guys probably wouldn't have to run it. :)
> Also, is there any word from those doing the GCC port, or will DEU 5.3 be
> supporting extended memory?
Lessi.... There WILL be a GCC "port" version. (Incidently, I do all of
my work in GCC and then port back to BCC for memory reasons. ;) I don't
know if the official release will be the BCC version or the GCC version.
We are/were tossing around the idea of compiling under BCC 4.0, but we
decided that it definately had to be BCC 3.0 compatable.
- -Ted
- --
Ted Vessenes | "The only force stronger than fate is dramatic irony."
tedv@geom.umn.edu | "[William] Shatner couldn't direct his way out of the
tedv@cs.umn.edu | bathroom with both hands and a map!"
tjvessen@midway.uchicago.edu -Ryan Ingram (1st), -Kibo's .sig (2nd)
------------------------------
End of doom-editing-digest V1 #30
*********************************
