Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 049
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #49
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Friday, 11 November 1994 Volume 01 : Number 049
Re: 'Smear' effect; why and how to alleviate?
Re: 'Smear' effect; why and how to alleviate?
Re: 'Smear' effect; why and how to alleviate?
Re: Best editor for DOOM ][
Further blockmap consideration
AASTINKY
Re: 'Smear' effect; why and how to alleviate?
Re: Sliding Doors
Re: Strange Message with IDCLIP in DOOM I
Re: Get me off this list
Re: Sound FX Tools for DOOM II?
Re: 'Smear' effect; why and how to alleviate?
Re: Get me off this list
Re: 'Smear' effect; why and how to alleviate?
textures on 2-sided non-2S lines
Re: 'Smear' effect; why and how to alleviate?
Re: textures on 2-sided non-2S lines
Re: Get me off this list
Re: textures on 2-sided non-2S lines
----------------------------------------------------------------------
From: Matthew Ayres <ayres@cdrom.com>
Date: Thu, 10 Nov 94 17:35:20 -0800
Subject: Re: 'Smear' effect; why and how to alleviate?
S.Benner@lancaster.ac.uk (Steve Benner) said...
>Robert Forsman said:
>
>> For those who are curious about my problem, go to ftp.cis.ufl.edu and get
>>canon4.zip from /pub/thoth/. It's 91K unzipped. Run inside the big
>>building and look at the end of the hallway. I still haven't had a chance
>>to thorougly examine my sidedefs (but DEU doesn't complain...).
>
>If you had examined your sidedefs, you would have discovered a texture
>called AASTINKY on the upper and lower textures of lines 476 and 503 (the
>lines that separate the long hall from the mid-stair landing).
>Interestingly, this is the third time this week I've seen this texture used
>on a line! No such texture, Bob.
I'm not sure if AASTINKY is a texture or not. WADED searches the DOOM wad
file for the list of textures. I recall AASTINKY showing up a few times
when I was working with the texture viewer routine. It looks like to
patches of the same thing overlapping a little bit. Still, the current
version of WADED doesn't show that they exist. I replaced them with GREY4,
like all the surrounding walls, and it works fine. There's also one wall
that needs it's textures defined (WADED v1.5x betas detect this... type "2").
>Also, you have corrupted texture names on lines 515 (GRAY4 Z?) - where ? is
>ASCII 0 here and 521 (GRAY4 !!): I think these are caussing the hom at the
>top of the stairs.
I think that's just the undefined texture. There's one wall with lower
front texture defined and higher back texture defined, but no front textures
defined. (this linedef is at the bottom of the stairs, the other side shows
up on the top of the stairs [as you're going up the other way of course])
>Methinks your WAD is corrupted. Hope you've got some backups.
Nope... read on.
>Further indication of problems is given by the fact that WADED fails in its
>attempts to build a blockmap for this wad: the public version just beeps
>and gives up when trying to add the staircase to the block list - the
>latest beta (1.52) gives no errors but produces a WAD (that looks too
>small) that hangs DOOM: when I look at its saved WAD, all the sector info
>in the area of the large marble hall is screwed. Are you reading this, Matt
>Ayres? Look at this wad - it looks a good test-bed for WADED's consistency
>checker! [It isn't WADED's node builder that's at fault, 'cos I get the
>same results whether I rebuild your nodes or not.]
I found the bug in WADED's blockmap builder that was causing the problem.
(all versions of WADED from 1.42 to 1.56.) As WADED builds the blockmap,
it keeps a tally of the size of the blockmap... in an integer. That was
stupid, because some large area maps (like this one) need a long integer.
So, I changed it to a long integer, and it works fine. (v1.57)
>Let us know how this progresses, Bob: seems there's something we need to
>know here, if we can but fathom it!
whatever steve. :)
Anyhow, the WAD works fine for me now. I can make the fixed one available
if anyone (the author? hehe) wants it.
-Matt A.
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Thu, 10 Nov 1994 21:16:00 EST
Subject: Re: 'Smear' effect; why and how to alleviate?
S.Benner@lancaster.ac.uk (Steve Benner) ,in message <20838.9411101542@cent1.lan
cs.ac.uk>, wrote:
> If you had examined your sidedefs, you would have discovered a texture
> called AASTINKY on the upper and lower textures of lines 476 and 503 (the
> lines that separate the long hall from the mid-stair landing).
> Interestingly, this is the third time this week I've seen this texture used
> on a line! No such texture, Bob.
Well, I just used the TEXTURES utility to check and it is definitely there
cairo:~/doom$ ./textures -iwad /dos/doom12r/doom.wad pnames texture1 texture2 -
-oat - | more
Textures utility version 1.04
Copyright (C) 1994 Robert Forsman
Gnu General Public License
Ported to DOS by Robert Forsman and David Allen
AASTINKY : 24x72
WALL00_3 +0+0 1 0
WALL00_3 +12-6 1 0
ASHWALL : 64x128
W104_1 +0+0 1 0
...
------------------------------
From: Matthew Ayres <ayres@cdrom.com>
Date: Thu, 10 Nov 94 18:38:15 -0800
Subject: Re: 'Smear' effect; why and how to alleviate?
Robert Forsman <thoth@cis.ufl.edu> said...
>S.Benner@lancaster.ac.uk (Steve Benner) ,in message <20838.9411101542@cent1.la
>n
> cs.ac.uk>, wrote:
>
>> If you had examined your sidedefs, you would have discovered a texture
>> called AASTINKY on the upper and lower textures of lines 476 and 503 (the
>> lines that separate the long hall from the mid-stair landing).
>> Interestingly, this is the third time this week I've seen this texture used
>> on a line! No such texture, Bob.
>
> Well, I just used the TEXTURES utility to check and it is definitely there
>
>cairo:~/doom$ ./textures -iwad /dos/doom12r/doom.wad pnames texture1 texture2
>-
> -oat - | more
>Textures utility version 1.04
>Copyright (C) 1994 Robert Forsman
>Gnu General Public License
>Ported to DOS by Robert Forsman and David Allen
>AASTINKY : 24x72
> WALL00_3 +0+0 1 0
> WALL00_3 +12-6 1 0
>ASHWALL : 64x128
> W104_1 +0+0 1 0
>...
I don't know what to tell you, other than that chaning the AASTINKY's to
some other textures, will work fine... while AASTINKY's just give HOM's as
if there was no texture defined for that wall. Maybe AASTINKY has a problem
on upper and lower textures (anyone have any idea why that would be??)
-matt a.
------------------------------
From: Carbon-BasedLifeForm <decerman@ouray.Denver.Colorado.EDU>
Date: Thu, 10 Nov 1994 20:01:48 -0700 (MST)
Subject: Re: Best editor for DOOM ][
On Thu, 10 Nov 1994, Matthew Ayres wrote:
> >> BTW: What _is_ the best editor for Doom II ?
> >IMHO, EdMap 1.22.
>
> Normally I would say WADED v1.42. However, I haven't given many other
> editors a fair chance of use to be totally sure. However, I KNOW that
> WADED v2.00 will be better than any editor out there. :-)
>
> -Matt A.
Alright, already!!! When will WADED come out? ;^]
__ __
____ /\ \ /\ \ Dan Cerman
/ \ \ / \ \ _\ \ \ University of Colorado at Denver
/ /\ \_\ / /\ \ \ /\_\ \ \
\ \ \ | | \ \/ \_\ \ __ \_\ decerman@ouray.cudenver.edu
\ \/ |_| \ /\/_/ \ \ \/_/
\ / / \ \_\ \ \_\ "I don't get mad. I just
\/_/ \/_/ \/_/ blow holes in people."
------------------------------
From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Thu, 10 Nov 94 21:41:01 CST
Subject: Further blockmap consideration
>I found the bug in WADED's blockmap builder that was causing the problem.
>(all versions of WADED from 1.42 to 1.56.) As WADED builds the blockmap,
>it keeps a tally of the size of the blockmap... in an integer. That was
>stupid, because some large area maps (like this one) need a long integer.
>So, I changed it to a long integer, and it works fine. (v1.57)
There's another consideration when building the blockmap. Since
the offset for each block's line information is stored in the blockmap,
the blockmap size is limited. The maximum offset can be 65535 (unsigned
int) words. Since it takes a minimum of three words for each block (the
offset plus a 0 plus a -1), there can be at most about 65536/3 = 21845
blocks. 21845 is approximately 147x147 blocks, or a map area of approximately
18816x18816. The is admittedly a very large area, but as a practical
matter the map can't be this large since the map has to contain some
lines. Well, four anyway.
I guess my point is that when building the blockmap the code should
check for the block offset overflow condition to be complete.
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: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Thu, 10 Nov 94 21:45:10 CST
Subject: AASTINKY
The AASTINKY texture is the only one whose width is not a power
of two. So maybe DOOM doesn't handle it properly in some situations.
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: Robert Forsman <thoth@cis.ufl.edu>
Date: Thu, 10 Nov 1994 23:32:30 EST
Subject: Re: 'Smear' effect; why and how to alleviate?
Robert Forsman <thoth@cis.ufl.edu> ,in message <199411110216.VAA15502@aviator.c
is.ufl.edu>, wrote:
> Textures utility version 1.04
> Copyright (C) 1994 Robert Forsman
> Gnu General Public License
> Ported to DOS by Robert Forsman and David Allen
> AASTINKY : 24x72
> WALL00_3 +0+0 1 0
> WALL00_3 +12-6 1 0
Oh shit. Now that I think about it that width (24) looks weird, not being
a power of 2. I bet that's the problem. I had a problem with a texture
that was 96-wide. The engine treated it like it was 64-wide. I would not
be surprised by other stranger problems.
I just picked AASTINKY because it was at the head of the list and I am
getting sick and fuckin tired of gray4.
If anyone ever gets around to characterizing this, that's cool. Otherwise
write it down in the "Doom Book Of Unreproduced (not Unreproduceable)
Weirdness".
> ASHWALL : 64x128
> W104_1 +0+0 1 0
> ...
------------------------------
From: brian@phyast.pitt.edu (Brian K. Martin)
Date: Fri, 11 Nov 1994 00:51:04 -0500 (EST)
Subject: Re: Sliding Doors
>
> >I saw on a.b.d that some one made sliding doors like in
> >Wolf3d. They used doom ver 1.5 though. I couldn't get it
> >to work, but didn't have the 1.5 version of the wad. Does
> >anyone know if this works, or works with ver 1.666. They
> >used a line type 124 as the door and said they did some
> >hacking.
>
> Do you mean horizontal sliding? like --->?
Yep, sliding horizontally.
And yes I got the animated texture to work on switches. A stupid
question now that i think about it, I forgot it's easy with deutex.
Pretty cool too, you can turn on the TV and watch it. That would
have been cool for Trinity.wad in the theater.
That gives me an idea for another type of TV. Use an opaque texture
for sw1 and a clear one for sw2. Then you can have a big screen TV
with real action & sound by enclosing some baddies in a room behind
the switch.
brian
------------------------------
From: Damian Frank <damianf@diamond.res.wpi.edu>
Date: Fri, 11 Nov 1994 01:51:42 -0500 (EST)
Subject: Re: Strange Message with IDCLIP in DOOM I
> > I was back playing DOOM I today and accidentaly hit IDCLIP. It gave me the
> > message ALL MARKERS REMOVED. Anyone have any idea what this means?
> >
> Just a guess, but maybe it removed the markers that you can leave on the
> Auto-Map (the M key, I think)... It could have been just IDCL? Then
> again, I already tried this and nothing happened for me :)
Actually, I believe that, when you're on the map, just C will clear the
markers.
Damian
------------------------------
From: quinet@stud.montefiore.ulg.ac.be (Raphael Quinet)
Date: Fri, 11 Nov 1994 11:11:41 +0100
Subject: Re: Get me off this list
Robert Forsman <thoth@cis.ufl.edu> wrote:
> Never underestimate the noise-generation potential of the stupid*.
>
> Who volunteers to post an FAQ every week to AGDE to train the stupid
> masses?
>
> * stupid here means someone who doesn't know something yet. Hopefully they
> are trainable, they just need pointers to all the docs and about 3 months of
> luckless wad hacking before they get the clue :(
First, a little reminder: the new group is not alt.games.doom.editing, but
rec.games.computer.doom.editing.
I'm currently talking about these problems with John Van Essen, the author
of the RFD and CFV for the new groups. Although the editing group won't be
moderated, we are thinking about having some 'administrators' for this
group (and the other ones too). These guys will post some posting guidelines
for the group every week and deal with the newbies who don't follow these
guidelines (in a polite way, if possible).
I will tell you more about this when we are ready...
- -Raphael
+---------------------------------------------------------------------------+
| Finger: finger quinet@finger.montefiore.ulg.ac.be for some useless info. |
| Mosaic: http://www.montefiore.ulg.ac.be/~quinet (NEW: preview of DEU 5.3) |
| E-mail: eedraq@chapelle.ericsson.se or quinet@montefiore.ulg.ac.be |
| S-mail: Raphael Quinet, 9 rue des Martyrs, 4550 Nandrin (Belgium) |
| or: Raphael Quinet, Kapuzinergraben 2, 52062 Aachen (Germany) |
| --* Send your questions about DEU to: Deu_Help@boblab1.bobst.nyu.edu *-- |
+---------------------------------------------------------------------------+
------------------------------
From: quinet@stud.montefiore.ulg.ac.be (Raphael Quinet)
Date: Fri, 11 Nov 1994 11:15:30 +0100
Subject: Re: Sound FX Tools for DOOM II?
cgasparo@cymbal.aix.calpoly.edu wrote:
> Raphael! Raphael! Tell us the current ETA of 5.3?
> Steve H.B.
Ahem. The ETA is: "as soon as it is finished".
I will soon give a beta version to the beta-testers (please
do not ask for it, I already have enough testers) and I will
release 5.3 a few days later if no major bugs are found.
- -Raphael
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Fri, 11 Nov 94 10:18:03 GMT
Subject: Re: 'Smear' effect; why and how to alleviate?
Matt Ayres said (re CANYON4):
> There's one wall with lower
>front texture defined and higher back texture defined, but no front textures
>defined. (this linedef is at the bottom of the stairs, the other side shows
>up on the top of the stairs [as you're going up the other way of course])
I spotted this last night (God, it is so frustrating being half a world
away, sometimes - a case where being 7 hours in front is definitely 17
hours behind!!) - it's interesting because if you consider relative sector
heights here, the textures that Bob has defined are all that should be
needed. Matt's right when he says that the normal textures are needed here
to get rid of the homs: I notice that they are supplied on all the other
lines between the stairs. Presumably, the combination of flags set on
these lines is causing Doom to ignore sectors on the other side of them
when it decides which textures to show.
Of course, not having the latest beta of WADED [hint] I couldn't test this
on Canyon4, but I'll have a play around with some tests and see if I can
see what's what. Unless some-one already knows, of course. (Hope this
shouldn't have been filtered out through Weanies' Corner: wouldn't that be
embarrassing? ;)
- -Steve
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Fri, 11 Nov 94 14:19:02 GMT
Subject: Re: Get me off this list
Robert Forsman said:
>
>* stupid here means someone who doesn't know something yet. Hopefully they
>are trainable, they just need pointers to all the docs and about 3 months of
>luckless wad hacking before they get the clue :(
I love your optimism, Robert! My WWW pages are slowly taking shape: I hope
these will help provide training in the first instance and a single-place
source of reference info for "old-hands" eventually. The first objective
is to help beginners cut down on that 3 months of luckless wad hacking: I
would be very grateful for the real experts out there to drop in on my
pages from time to time and check some of them out, if they ever have an
idle moment [remember those? ;)] Sorry if I'm still a bit html-stupid at
the moment (hopefully the WAD-editing stuff is better!!)!
- -Steve
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Fri, 11 Nov 1994 10:38:56 EST
Subject: Re: 'Smear' effect; why and how to alleviate?
S.Benner@lancaster.ac.uk (Steve Benner) ,in message <4737.9411111018@cent1.lanc
s.ac.uk>, wrote:
> Matt Ayres said (re CANYON4):
> > There's one wall with lower
> >front texture defined and higher back texture defined, but no front textures
> >defined. (this linedef is at the bottom of the stairs, the other side shows
> >up on the top of the stairs [as you're going up the other way of course])
>
> it's interesting because if you consider relative sector
> heights here, the textures that Bob has defined are all that should be
> needed.
Remember, these linedefs do NOT have the 2S bit set. I expect I missed
that and DEU wasn't smart enough to know that it needed a normal texture.
Could we have a repost of the message that explained the characteristics of
the poorly-named "2S" flag? Mission editor authors could probably benefit
from a reread.
What do you know. I saved a copy of it. Here it is again. Thanks to Jeff
Rife! I think I need to play around with textures on non-shoot-through a bit
more.
- - From: jrife@loanstar.tamu.edu (Jeff Rife)
- - Subject: Two-sided flag on LINEDEF's
- - To: doom-editing@nvg.unit.no
- - Date: Thu, 20 Oct 1994 12:40:16 -0500 (CDT)
Well, I've been kicking this around in my mind for a while, especially after
doing some special-effects WAD stuff, so, here goes...
I think that we need to get the WAD editor designers, the spec maintainers,
and us to call that bit the "shoot through" bit, or something similar. My
reasoning:
1. A LINEDEF with two SIDEDEF's does *not* have to have this bit set to
function correctly. This bit does not determine "two-sidedness". If you
don't believe this, I have a sample WAD that you can look at both sides
of a LINEDEF with this bit unset, and there are textures on both sides,
with no HOM.
2. Monsters and players cannot shoot through a LINEDEF with this bit unset.
3. Monsters don't even think they can see through a LINEDEF with this bit
unset, and *can* see through a LINEDEF with this bit set, regardless of
textures.
4. Players and monsters can pass through a LINEDEF with this bit unset,
although the AI encourages monsters to find an alternate route.
So, basically, all the bit really controls is what happens when a projectile
hits this LINEDEF, and whether monsters think they can attack through this
LINEDEF.
The reason I suggest the change in naming convention is that I was very
confused until I figured out the *real* effects. At the very least, we need
to add these notes to the specs.
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Fri, 11 Nov 1994 11:24:43 EST
Subject: textures on 2-sided non-2S lines
I just did a few experiments with 2-sided linedefs that didn't have the
shoot-through bit set. Here's my conclusions:
[
upper and lower textures are irrelevant. The normal is smeared over the
entire surface regardless of neighboring ceiling and floor heights.
A missing normal causes HOM.
animations work on non-2S lines! Normally they're just frozen, but if you
disable the 2S bit then you can walk through animated walls. Unfortunately you
can't shoot through them. So much for my sniper hiding behind a working
waterfall :( he has to stay hidden behind a non-working waterfall).
]
Matt, please update the UDS with these results. If anyone else can
independently confirm these results I would really appreciate it. Consistency
checkers should take these new results into account.
I know DEU still marks (not-really-)missing lowers and uppers as red in the
info windows, and its consistency checker insists that there's something wrong
with a 2S non-shoot-through linedef.
I'm going to update my consistency checker document...
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Fri, 11 Nov 94 16:28:01 GMT
Subject: Re: 'Smear' effect; why and how to alleviate?
Robert Forsman said:
>Steve Benner said:
>> it's interesting because if you consider relative sector
>> heights here, the textures that Bob has defined are all that should be
>> needed.
>
> Remember, these linedefs do NOT have the 2S bit set. I expect I missed
>that and DEU wasn't smart enough to know that it needed a normal texture.
DEU's not the only one....
[snip]
>- From: jrife@loanstar.tamu.edu (Jeff Rife)
>- Subject: Two-sided flag on LINEDEF's
>
>1. A LINEDEF with two SIDEDEF's does *not* have to have this bit set to
> function correctly. This bit does not determine "two-sidedness". If you
> don't believe this, I have a sample WAD that you can look at both sides
> of a LINEDEF with this bit unset, and there are textures on both sides,
> with no HOM.
>
I remember this posting: it doesn't help much, does it? I agree that the
bit does not determine two-sidedness, in the sense of the linedef having
two sides (i.e. SIDEDEFs) but it *does* determine two-sidedness in the
sense of there being SECTORs on each side, non? Or, put another way, if
this bit is NOT SET, Doom doesn't look for sectors on the other side, and
so *never* uses the upper or lower textures of the sidedefs on this line.
So yes, you must have a solid normal texture on each side of your IM/!2s
lines here. I have never seen this documented anywhere. Please point me to
it, if I've missed it.
- -Steve
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Fri, 11 Nov 94 16:40:52 GMT
Subject: Re: textures on 2-sided non-2S lines
Robert Forsman said:
> I just did a few experiments with 2-sided linedefs that didn't have the
>shoot-through bit set. Here's my conclusions:
> upper and lower textures are irrelevant. The normal is smeared over the
>entire surface regardless of neighboring ceiling and floor heights.
>
> A missing normal causes HOM.
>
> animations work on non-2S lines! Normally they're just frozen, but if you
>disable the 2S bit then you can walk through animated walls. Unfortunately you
>can't shoot through them. So much for my sniper hiding behind a working
>waterfall :( he has to stay hidden behind a non-working waterfall).
>
>]
>
> Matt, please update the UDS with these results. If anyone else can
>independently confirm these results I would really appreciate it. Consistency
>checkers should take these new results into account.
This posting has just crossed with mine on the same topic, but yes I can
confirm all of your conclusions. Some-one posted me a problem WAD some
time ago that used animated 2-s lines to good effect (take a bow Scott
Webster) -- not for sniping though. I hope to put up the pages on lines
and textures to the Wadsters' Guide WWW pages over the weekend...
- -Steve
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Fri, 11 Nov 1994 11:43:03 EST
Subject: Re: Get me off this list
S.Benner@lancaster.ac.uk (Steve Benner) ,in message <18166.9411111419@cent1.lan
cs.ac.uk>, wrote:
> Robert Forsman said:
> >* stupid here means someone who doesn't know something yet. Hopefully they
> >are trainable, they just need pointers to all the docs and about 3 months of
> >luckless wad hacking before they get the clue :(
>
> I love your optimism, Robert!
Well, that's basically what happened to me. I had the miserable fortune of
starting editing back when consistency checkers (except for DOOMCAD's) were
pathetic jokes.
> The first objective
> is to help beginners cut down on that 3 months of luckless wad hacking:
The biggest help would be an editor that explained why the newbie mistakes
were mistakes and told the newbie how to avoid them. That's a lot of work to
spend on a help system when you could be hacking in advanced features...
I did write two documents that would help any postscript-capable newbies get
a grip on upper/normal/lower and a grip on the whole sidedef/sector thing.
(it's what slowed me down).
Check ftp.cis.ufl.edu in pub/thoth/sidedefs.ps, textures.ps. You may feel
free to refer to these docs as hrefs in your HTML docs. Many sites have rigged
their browsers to invoke ghostview when they detect a postscript document.
------------------------------
From: brian@phyast.pitt.edu (Brian K. Martin)
Date: Fri, 11 Nov 1994 14:07:41 -0500 (EST)
Subject: Re: textures on 2-sided non-2S lines
>
> animations work on non-2S lines! Normally they're just frozen, but if you
> disable the 2S bit then you can walk through animated walls. Unfortunately you
> can't shoot through them. So much for my sniper hiding behind a working
> waterfall :( he has to stay hidden behind a non-working waterfall).
>
What are you talking about? Animations always worked for me on 2s and
1s lines,
just make sure they are single patches (in most cases). In fact
one of my wads has steam which is animated and you walk through it. I
don't see why you couln't make a waterfall with a 2s line. (why do you
need to use a 1s line?).
brian
------------------------------
End of doom-editing-digest V1 #49
*********************************
