Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 164
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #164
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Friday, 17 February 1995 Volume 01 : Number 164
Re: almost objective editor comparison
Radical new thread...
Re: DEU 5.3 Beta
Re: Radical new thread...
DME quirk - player now 7 units high?
This Is Getting Stupid Folks.....
Re: This Is Getting Stupid Folks.....
RE: Radical new thread...
Re: DEU 5.3 Beta
Re: node generator comparison
Re: DME quirk - player now 7 units high?
Re: Radical new thread...
Re: almost objective editor comparison
Re: Radical new thread...
RE: Radical new thread...
Doom editing question
----------------------------------------------------------------------
From: David Damerell <djsd100@hermes.cam.ac.uk>
Date: Fri, 17 Feb 1995 02:29:29 +0000 (GMT)
Subject: Re: almost objective editor comparison
On Thu, 16 Feb 1995, Ben Morris wrote:
> > > True. It also used to be hard to figure out, too, I think maybe. Dck and
> > > Edmap came along later, and people talk about them now pretty often.
> > Well, I just tried DCK2.0, and I'm _not_ impressed: even I could make a
> > better copy of DEU than that.
> DCK is by no stretch of the imagination a "copy" of deu. Of course it has
> its similarities - every doom editor can be compared to another.
It feels very much like DEU. Very, very much indeed. DME is a lot more
original, IMHO.
> I guess this attitude is the same one that prompted you to, unprovoked,
> hack DCK in r.g.c.d.e when you really didn't know what you were talking
> about. (for reference, you said "DCK users wouldn't know how to fiddle
> with sector refs if they needed to" - probably one of the most obvious
> operations in the editor. But I doubt you knew that at the time, because
> you "just tried DCK 2.0" as of now.
1) Really, is DCK2.0 the first version of DCK to be released?
2) At the time, I attempted to deduce what DCK was like from the
preceding post about its operations. Now I've used DCK, I'm convinced
that it insulates users from the nature of sidedefs.
> It's a shame statements such as "even I could make a better.." are so easy
> to hide behind, or I'd call you out on it. Doubtless you'd excuse
> yourself as a result of your busy schedule or sudden indifference to the
> subject.
For a start, I'd make the screen display crisper.
David Damerell, GCV Sauricon. djsd100@hermes.cam.ac.uk Trinity, Cambridge
WOODHAL2.WAD ftpable. CUWoCS President. METLMAZE.WAD sometime soonish.
|___| Loneliness pours over you: Emptiness can pull you through. |___|
| | | Your mother's eyes, from your eyes, cry to me... Queen, '39. | | |
------------------------------
From: John Wakelin <johnw@datametrics.com>
Date: Thu, 16 Feb 95 22:31:30 -0500
Subject: Radical new thread...
I am sorry to have to post this to
My_Editor_Rules_Yours_Sucks@nvg.unit.no but I'll risk the flame bath
anyway.
I've got this little deathmatch WAD I've been building. I'm trying
to make it *extreamly* nice. It is not complicated but, there is
some detail to it. I took some extra time to put shadows off of
some of the buildings, and the son_of_a_gun blows up after running
fine for a while. It pukes out this...
R_DrawPlanes: Visplanes Overflow (129)
Obviously a buffer limit is being reached here, but I have never run
into this before(and I have made some extreamly complex wads).
I am no newbie, and I am not missing anything basic (texture, tag,
sidedef). When I go in and remove the shadows it runs fine. If it
was too many texture lines in view, I would have expected HOM but
this is weird.
If you have run in to this before (or are the head programmer of the
best game on earth), and know what the deal is give me a shout. I have
already decided to remove the detail and release it in a lesser form.
I would love to find a way to leave it in, however.
I appreciate your patience with my interruption...we now return to
the battle already in progress.
Have a good day,
John
__________________________________________________________
#include <stupidstuff.h>
#define USER "johnw" /* John Wakelin */
/* Johnw@datametrics.com */
main() /* (703) 385 7700 */
{
while (isstupid(USER)) ignore(USER);
}
------------------------------
From: David Damerell <djsd100@hermes.cam.ac.uk>
Date: Fri, 17 Feb 1995 03:38:30 +0000 (GMT)
Subject: Re: DEU 5.3 Beta
On Thu, 16 Feb 1995, Ben Morris wrote:
> djsd100@hermes.cam.uc.uk (David Damerell) wrote:
> D>DCK seems to attempt to insulate me from the existance of sidedefs - I
> >never saw a sidedef number listed - can I attach several lines to one
> >sidedef?
> No, you can't. You don't even NEED to - there's no advantage to this
> apart from the fact that it might make edits a little faster. In the
> end, though, it makes no difference to the functionality of the level.
There's a lot of things that ppl thought we'd never need to do (this
makes the .WAD smaller) - if ppl had thought we'd never need missing
textures, the goop trench in trinity2.wad would have been impossible.
> D>Also DCK seems to have a very coarse display - DCK in 640x480 looks like
> >DEU in 320x200 to me.
> I assure you this is some kind of subversive plot. 640x480 is 640x480.
It looks kinda - crudgy? In all seriousness, I do think there is a
problem, perhaps because of the large and IMHO ugly font used for
onscreen text.
> D>I downloaded DME 4.0 (beta 2): the docs would seem to imply that the
> >floor-ceiling heights are represented more coarsely than in DooM, and
> >that DME will sometimes flip linedefs because it thinks I have something
> >wrong. Maybe I _want_ it wrong. This is, IMHO, not complete control.
> Maybe you want it wrong. Can you give me an example?
Remeber the 'transparent doors' - that involved things that were
obviously completely wrong and that would most likely crash DooM, and so
no sensible editor would let you do them... Except they worked. Now I
can't think of circumstances in which I'd want a linedef the wrong way
round, but that don't mean they don't exist.
> DCK and EdMap:
> - Series (> 1) of Styles for decorating sectors/lines
Why not group select and edit?
> - Automated set-tags function
Again, this is a group select and edit.
> - Search / Replace textures
I can't see much use for this, but fair enough.
> - "Run DOOM from editor"
That will clash with the use of an external node builder. I'd rather have
a batch file, thanks.
> DCK and DMapEdit:
> - Graphical thing display.
A disputable advantage. DME's thing display seems to clutter the map when
zoomed out.
> - Auto-merging of lines. Not just congruent lines, but lines that
> overlap. DCK includes diagonal merging.
I don't want this automated. If I want it done, I'll do it. Maybe a
consistency check.
> - Multi-texture viewer
An advantage?
> - Automated texture placement
Don't see what you mean.
> DCK, Edmap AND DME:
> - Automated stairs
Should be fixed in 5.3 - and DEU5.21 has 'semiautomatic stairs.'
> - Thing display masks
Point taken.
> - Complete grid control (not just "G" "G" "G" "G" "G")
Erm, it's factors of 2 in DCK at least, innit?
David Damerell, GCV Sauricon. djsd100@hermes.cam.ac.uk Trinity, Cambridge
WOODHAL2.WAD ftpable. CUWoCS President. METLMAZE.WAD sometime soonish.
|___| Loneliness pours over you: Emptiness can pull you through. |___|
| | | Your mother's eyes, from your eyes, cry to me... Queen, '39. | | |
------------------------------
From: Jason Hoffoss <hoffo002@gold.tc.umn.edu>
Date: Thu, 16 Feb 1995 22:26:28 -0600 (CST)
Subject: Re: Radical new thread...
On Thu, 16 Feb 1995, John Wakelin wrote:
> I am sorry to have to post this to
> My_Editor_Rules_Yours_Sucks@nvg.unit.no but I'll risk the flame bath
> anyway.
>
> I've got this little deathmatch WAD I've been building. I'm trying
> to make it *extreamly* nice. It is not complicated but, there is
> some detail to it. I took some extra time to put shadows off of
> some of the buildings, and the son_of_a_gun blows up after running
> fine for a while. It pukes out this...
>
> R_DrawPlanes: Visplanes Overflow (129)
>
> Obviously a buffer limit is being reached here, but I have never run
> into this before(and I have made some extreamly complex wads).
>
> I am no newbie, and I am not missing anything basic (texture, tag,
> sidedef). When I go in and remove the shadows it runs fine. If it
> was too many texture lines in view, I would have expected HOM but
> this is weird.
>
> If you have run in to this before (or are the head programmer of the
> best game on earth), and know what the deal is give me a shout. I have
> already decided to remove the detail and release it in a lesser form.
> I would love to find a way to leave it in, however.
>
> I appreciate your patience with my interruption...we now return to
> the battle already in progress.
>
> Have a good day,
> John
From what I know, visplanes are x-y parallel planes, so not lines, but
floor/ceiling areas in view. Each sector, I think, that has a visible
floor and/or ceiling will require it's own visplane. So, you basically
have too many sectors in view. Your shadowed areas require new sectors,
and this is creating too many visplanes. You might try combining sectors
into extended sectors (make all the shadow area sectors into one
sector). I dunno if this would work or not. It might generate
individual polygons for each visplane instead. This is pretty much my
guess, though. I could be totally wrong. :) But hey, the path to
enlightment starts with an educated guess, right? Having been messing
with 3D drawing lately, this seems like what's probably going on. I
haven't completely figured out how Doom draws those floors in yet.. :)
-Jason
------------------------------
From: thldrmn@sam.neosoft.com (Ty Halderman)
Date: Thu, 16 Feb 1995 23:05:43 -0600
Subject: DME quirk - player now 7 units high?
I just tried DME 4.0 beta 2, and was moderately interested in using it at
least in the interim before DEU5.3 is real :) I also often use various
editors for their different strengths.
Is it just me, or is there something absurd about DME deciding to use its
own metrics for sector heights? Apparently only increments of 8 are
allowed, but those are counted in ones, and everything I have come to think
of as second nature for step heights, player heights, etc. aren't used. For
that matter the heights documented in the FAQs aren't held to unless you do
your own math. i.e. player = 7 high (56), highest step = 3 (24), etc.
Please tell me I missed something. DME otherwise seemed promising, but I
can't bring myself to have a different standard for one of the several
editors I mess with.
=-Ty Halderman ( thldrmn@sam.neosoft.com )
"There I stood, mesmerized, like a lemming admiring the sea..."
------------------------------
From: gene.homan@merlins-realm.com (Gene Homan)
Date: Fri, 17 Feb 1995 04:00:11 GMT
Subject: This Is Getting Stupid Folks.....
All right already. Everyone has a favorite editor. Each one has its
strengths and its failings (or shortcomings anywayze). That's life
folks! We wouldn't be human if we didn't have opinions. But daggumit
(trust me, it's a word - I'M SOUTHERN BY GAWD!), use the one you like
(or a combination) and get on with the damned WADding! This low
shooting over which one is "superior" is immature at best and stupid by
far.
I don't mind the authors posting ads for thier particular effort, or
even WADders praising those efforts (done so myself), but tit for tat
(Take the Tit, Take the Tit!) over "The editor I use is better than the
one you use" is getting Dumb and Dumber (seen it, I laughed, I cried).
Oh well, back to the basics. Has anyone started seriously tearing apart
the different GOB structures in Dark Forces (the demo). The engine of
this puppy looks like it could spit out some killer deathmatches.
Later......
Gene Homan
gene.homan@merlins-realm.com
Author Kingdom Come Wad
------------------------------
From: Piotr Kapiszewski (Kapi) <kapis-p@grinch.cs.buffalo.edu>
Date: Fri, 17 Feb 1995 01:33:40 -0500 (EST)
Subject: Re: This Is Getting Stupid Folks.....
Gene Homan said:
> All right already. Everyone has a favorite editor. Each one has its
> strengths and its failings (or shortcomings anywayze). That's life
> folks! We wouldn't be human if we didn't have opinions. But daggumit
> (trust me, it's a word - I'M SOUTHERN BY GAWD!), use the one you like
> (or a combination) and get on with the damned WADding! This low
> shooting over which one is "superior" is immature at best and stupid by
> far.
> I don't mind the authors posting ads for thier particular effort, or
> even WADders praising those efforts (done so myself), but tit for tat
> (Take the Tit, Take the Tit!) over "The editor I use is better than the
> one you use" is getting Dumb and Dumber (seen it, I laughed, I cried).
I agree with Gene this list is not really here for the purpose of
comparisons as Steve kindly pointed out a while ago. If you need to
carry this discussion further I would suggest another list such as
DOOML for this purpose.
It is not mean as flame bait so if anyone gets upset please accept my
appologies.
- -Kapi
- --
PGP key available from doomgate.cs.buffalo.edu | Piotr Kapiszewski
URL at http://doomgate.cs.buffalo.edu/~kapis-p/ | kapis-p@cs.buffalo.edu
------------------------------
From: D.Casali@rea0808.wins.icl.co.uk
Date: Fri, 17 Feb 1995 08:10:37 +0000
Subject: RE: Radical new thread...
- -----Multi-Part-Message-Level-1-1-29615
Content-type: text/plain; charset="us-ascii"
I had exactly the same problem, a visual plains overflow, or
sometimes I would get "No more visual plains" I know it is due
to having too many sidedefs/sectors in view at once, as I has a
complex area to a level that would crash out when your view
reached it, otherwise the level was fine. I found no way around
it other than placing a huge 1SD wall infront of the feature
- -----Multi-Part-Message-Level-1-1-29615
Content-type: text/plain; charset="us-ascii"
(which of course ruined the entire effect) so I just gave up and
removed that bit. It'd be great to find out there is some way of
overcoming this though...
Dario.
- -----Multi-Part-Message-Level-1-1-29615--
------------------------------
From: Steve McCrea <sm@eng.cam.ac.uk>
Date: Fri, 17 Feb 1995 13:54:07 GMT
Subject: Re: DEU 5.3 Beta
David Damerell wrote:
>
> There's a lot of things that ppl thought we'd never need to do (this
> makes the .WAD smaller) - if ppl had thought we'd never need missing
> textures, the goop trench in trinity2.wad would have been impossible.
>
And then I might not have put that crap bit in. Don't bring my wad into
your side of the argument, David. I like the new editors.
> [the 640x480 mode of DCK]
> It looks kinda - crudgy? In all seriousness, I do think there is a
> problem, perhaps because of the large and IMHO ugly font used for
> onscreen text.
>
So run it in 800x600 or 1024x768. I don't see the "crudgyness" anyway.
> I downloaded DME 4.0 (beta 2): the docs would seem to imply that the
> floor-ceiling heights are represented more coarsely than in DooM, and
> that DME will sometimes flip linedefs because it thinks I have something
> wrong. Maybe I _want_ it wrong. This is, IMHO, not complete control.
>
The floor/ceiling thing can be toggled off for those brought up on DEU,
and for finishing touches. As for the linedefs, there is no possible
use for having them the other way round... Flamebait if ever I wrote it!
> Remeber the 'transparent doors' - that involved things that were
> obviously completely wrong and that would most likely crash DooM, and so
> no sensible editor would let you do them... Except they worked.
>
What transparent doors? What did they do?
> > DCK and EdMap:
> > - Series (> 1) of Styles for decorating sectors/lines
>
> Why not group select and edit?
>
I think you've got the wrong end of this - motifs also assign big/small
door textures, floor/ceiling textures, upper and lower textures, teleport
textures, etc. This would take a long time in DEU.
> > - Automated set-tags function
>
> Again, this is a group select and edit.
>
You can't group select a line and a sector, can you?
> > - Search / Replace textures
>
> I can't see much use for this, but fair enough.
>
That's funny, I think this is fantastic. Perfect for changing from standard
textures to user-defined ones, changing step textures, and so on.
> > - "Run DOOM from editor"
>
> That will clash with the use of an external node builder. I'd rather have
> a batch file, thanks.
>
Might as well have the option, surely?
> > DCK and DMapEdit:
> > - Graphical thing display.
>
> A disputable advantage. DME's thing display seems to clutter the map when
> zoomed out.
>
A matter of taste, then. I find the graphics cute- when I want to deal with
things, I'll be zoomed in 99% of the time.
> > - Auto-merging of lines. Not just congruent lines, but lines that
> > overlap. DCK includes diagonal merging.
>
> I don't want this automated. If I want it done, I'll do it. Maybe a
> consistency check.
>
So switch it off. Joining sectors is much easier with automerging, though.
> > - Multi-texture viewer
>
> An advantage?
>
Yup. How can you deny it? DMapEdit's is better than DCK's.
> > - Automated texture placement
>
> Don't see what you mean.
>
I guess he means placing textures on upper/lowers/middles when the sector
heights change, lines change from 2s to Im, and so on. I must say the sector
heights change thing should be an option - otherwise it could apply the
wrong texture and it would take a playthrough to notice...
> > DCK, Edmap AND DME:
> > - Automated stairs
>
> Should be fixed in 5.3 - and DEU5.21 has 'semiautomatic stairs.'
>
Say what?
> > - Complete grid control (not just "G" "G" "G" "G" "G")
>
> Erm, it's factors of 2 in DCK at least, innit?
>
Yes, but to go to 256 from 128, you press one button, once. You don't have to
wait for the 64, 32, 16, 8, 512, refreshes, which can take some time...
Steve.
------------------------------
From: Steve McCrea <sm@eng.cam.ac.uk>
Date: Fri, 17 Feb 1995 14:01:51 GMT
Subject: Re: node generator comparison
Robert Fenske, Jr. wrote:
>
> "Jason Hoffoss" <hoffo002@gold.tc.umn.edu> wrote:
>
> >Hmm, maybe I could write up a little program to test the optimization and
> >reliability of bsp trees, so we can rate node generators better. Ya,
> >think I will. :)
>
> What are you thinking here? Some criteria I can think of are
> fewest splits, fewest nodes, depth of node tree, width of node tree,
> # left branches, # right branches, and various ratios of these measurements.
>
> One thing I have been interested in is computing the optimal node
> tree for a given level and how close (measured in some fashion, perhaps
> subjectively) a node builder can reasonably get to this optimal tree.
>
You could just rebuild the id nodes and run the demos with the framerate
options...
Steve.
------------------------------
From: Steve McCrea <sm@eng.cam.ac.uk>
Date: Fri, 17 Feb 1995 13:55:36 GMT
Subject: Re: DME quirk - player now 7 units high?
Ty wrote:
> Please tell me I missed something. DME otherwise seemed promising, but I
> can't bring myself to have a different standard for one of the several
> editors I mess with.
>
Get beta5. It has a toggle for height units.
Steve.
------------------------------
From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Fri, 17 Feb 95 08:28:11 CST
Subject: Re: Radical new thread...
>> R_DrawPlanes: Visplanes Overflow (129)
>>
>> Obviously a buffer limit is being reached here, but I have never run
>> into this before(and I have made some extreamly complex wads).
>>
>>From what I know, visplanes are x-y parallel planes, so not lines, but
>floor/ceiling areas in view. Each sector, I think, that has a visible
>floor and/or ceiling will require it's own visplane. So, you basically
>have too many sectors in view. Your shadowed areas require new sectors,
>and this is creating too many visplanes. You might try combining sectors
>into extended sectors (make all the shadow area sectors into one
>sector). I dunno if this would work or not. It might generate
My co-workers have had this problem recently and I had the problem
a while ago. Since the number in the error message has always been around
129 - 135, I suspect that the # visplanes has to be <= 128. But what
exactly constitutes a visplane is unknown to me. I don't think it has anything
to do with sectors since I had a long hall with alternating light and dark
areas where all the light areas were one sector and likewise for the dark
areas and the error would occur when you turned to look down the hall. I
think it's directly related to each polygonal region that has to be drawn.
It would be nice to figure out exactly what causes this. Then a
check for this could be added to Bob's Consistency Checker for those who
are WAD editing on a Cray ...
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: Fri, 17 Feb 1995 09:55:54 EST
Subject: Re: almost objective editor comparison
Great. Now I'm getting into it again. I hope this is less flammable than
most.
Is anyone actually working on WADS or are we all just improving our wad
editors? All my wads are for DOOM 1, and I've been holding off working on
them till I add some features to the PFME that will make texture alignment
and difficulty tuning bearable.
For difficulty tuning I recommend editors add a feature where you can "grey
out" things according to their flags. This way you could grey out all things
except those that appear on single-player wuss level and start tuning your
level.
David Damerell <djsd100@hermes.cam.ac.uk> ,in message <Pine.SOL.3.91.9502170224
04.14603B@hammer.thor.cam.ac.uk>, wrote:
> It feels very much like DEU. Very, very much indeed. DME is a lot more
> original, IMHO.
Original isn't necessarily good. Often it's a good idea to shamelessly rip
off a popular editor to capitalize on its user-base's expertise with that
editor. When DEU 5.3 comes out I'm going to try to bring mine into line with
it. "C++: as close to C as possible, but no closer." :)
> For a start, I'd make the screen display crisper.
It looked pretty damn crisp at 1280x1024.
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Fri, 17 Feb 1995 10:06:27 EST
Subject: Re: Radical new thread...
Jason Hoffoss <hoffo002@gold.tc.umn.edu> ,in message <Pine.3.89.9502162246.A273
93-0100000@gold.tc.umn.edu>, wrote:
>
>
> On Thu, 16 Feb 1995, John Wakelin wrote:
>
> > R_DrawPlanes: Visplanes Overflow (129)
> >
> >From what I know, visplanes are x-y parallel planes, so not lines, but
> floor/ceiling areas in view. Each sector, I think, that has a visible
> floor and/or ceiling will require it's own visplane. So, you basically
> have too many sectors in view
So, like, should Tom Neff (or do I have the wrong name from the wrong
mailing list) stick this in the level editing FAQ?
------------------------------
From: John Wakelin <johnw@datametrics.com>
Date: Fri, 17 Feb 95 10:44:22 -0500
Subject: RE: Radical new thread...
> From: D.Casali@rea0808.wins.icl.co.uk
> Reply-To: doom-editing@nvg.unit.no
>
> I had exactly the same problem, a visual plains overflow, or
> sometimes I would get "No more visual plains" I know it is due
> to having too many sidedefs/sectors in view at once, as I has a
> complex area to a level that would crash out when your view
> reached it, otherwise the level was fine. I found no way around
> it other than placing a huge 1SD wall infront of the feature
>
>
> (which of course ruined the entire effect) so I just gave up and
> removed that bit. It'd be great to find out there is some way of
> overcoming this though...
>
> Dario.
>
Ok, I think I've figured it out...
This is something that needs to be added to the gotcha list (along
with Medeusa and HOM etc.). Some experimenting will need to be done
to determine exactly what is going on but, here is what I have so
far.
Apparently, there is a limit to how many ceiling and floor textures
you can see at one time. My WAD with it's many small sectors had
four places from which you could view long stretches containing many
sectors. Many of the sectors had the same ceiling and floor heights.
This meant that DOOM had to process a texture for each one that was
in veiw. The fact that the ceiling in the whole WAD is F_SKY1 could
also be playing a role in the problem but this is beyond my
capability to determine. Anyway, after reading Jason's response I
got to thinking and tried to remove some of the ceiling planes from
view. The easiest way to acomplish this, of course, was to raise the
ceiling. After a couple of tries with different heights I found that
tripling the height of the ceiling removed the crashing.
I do not profess that any of the speculation above is correct but, I
have found a way to make it work. I thought it would be appropriate
to post the problem and solution in case any one else was having the
same difficulty. I will be releasing SIC_EM.WAD and SIC_EM2.WAD
(DOOM I and DOOM][ versions) on tuesday or soon after. If you are
interested in seeing the whole mess it will be available then.
Thanks to both Jason and Dario for the input,
Have agood day,
John
__________________________________________________________
#include <stupidstuff.h>
#define USER "johnw" /* John Wakelin */
/* Johnw@datametrics.com */
main() /* (703) 385 7700 */
{
while (isstupid(USER)) ignore(USER);
}
------------------------------
From: Andrew Dowswell <Dowswea@AA.WL.COM>
Date: Fri, 17 Feb 1995 10:37:15 -0400 (EDT)
Subject: Doom editing question
I know that this is the wrong list for this question (since it doesn't
include the obligatory editor x is better than editor y), but I was fooled
by the list name into sending it here.
I am just finishing a wad now. The flow of the level is fairly sequential
due to different teleporters becoming available after certain actions are
taken. My question involves how to make this a suitable wad for
deathmatch. My dm experience is extremely limited, but I don't expect that
people would be willing to run through the level to "open it up" before
really getting into the dm play. I would like some thoughts on an idea I
had: Having dm starts spread around the level that are "one-way" rooms
(you can get out but not back in) that would have a set of switches, or
even line triggers between you and the door, that would take care of making
all of the teleporters available immediately. This would also allow
players
to restart in an enclosed hidden area with weapons, armor, and whatever
other goodies readily available. Does this sound reasonable? Any
additional
hints to make sure that it would be playable as a dm level? Any hints for
a
fair distribution of weapons, armor, and health in the start rooms so that
everyone starts nearly level, but still have a number of different weapons
available? Like maybe:
shotgun and megasphere
chaingun and blue armor
plasma gun and green armor
rocket launcher only
??? ??? ???
obEditor_Flamebait_Bullshit_Remark : Personally I use DCK 2.0, DEU 5.21,
and Edmap 1.31 (for the variety of features each has) and I think that
anyone that uses *only one* editor is a complete and total idiot that
should
be forced to use an enhanced version of edlin. :^)
Andy (Dowswea@aa.wl.com)
Disclaimer: The opinions of Parke-Davis are not necessarily my own, they
should not be construed as mine and no flames should be
directed at me for something Parke-Davis has said or done.
------------------------------
End of doom-editing-digest V1 #164
**********************************
