Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 281
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #281
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Wednesday, 17 May 1995 Volume 01 : Number 281
Re: looking for "normal" graphics
LMP in PWAD
Disappearing wall
Re: WQ: Save Game and Other File Formats!
Re: Announce: GRINDER1.WAD
[Q]: BSP *bulding* details
BLOCKMAP special effects?
RE: [Q]: BSP *bulding* details
Re: visplanes error
Re: Another WAD Error
Re: BLOCKMAP special effects?
Re: [Q]: BSP *bulding* details
Re: visplanes error
Re: BLOCKMAP special effects?
[Q] BLOCKMAP packing?
Re: visplanes error
Re: BSP builder question/improvements?
Re: Announce: GRINDER1.WAD
----------------------------------------------------------------------
From: ANTHEM X <MEMKEN@ewu.edu>
Date: Tue, 16 May 1995 17:59:27 -0800 (PST)
Subject: Re: looking for "normal" graphics
;hiya,
;
;I'm working on a series of levels that will be set in this day and
;time, more or less. I wanna replace a lot of graphics with "normal"
;things like tables and chairs and maybe a car or few. I am trying to
;decide the best way to do this. Should I draw 3D models and render
;them and capture diff rotations of an object like a table and replace
;some sprites I am not using, like the Wolf3d ones? OR shall I search
;other wads to rip graphics from if it has already been done? OR shall
;I finagle with flats and such to fake such objects?
;
;any opinions?
;
;thanks,
;Steve
I like the 3D modeling and screen capturing idea, but it seems like you
could get the same, or perhaps better quality if you drew the nine different
positions on a pad then scanned them into Adobe or something like that.
Although there is the 3d Studio religious sect over there in the corner...
Just an opinion... If you could change the pink demons into Pintos that run
you down then explode when you shoot them that would be fairly original.
M.
------------------------------
From: John.Orazem@horizon.tor250.org (John Orazem)
Date: 16 May 95 23:10:00 -0500
Subject: LMP in PWAD
How can I put an lmp into a PWAD? What program will do it?
- --
| Fidonet : John Orazem 1:250/348
| Internet: John.Orazem@horizon.tor250.org
------------------------------
From: John.Orazem@horizon.tor250.org (John Orazem)
Date: 16 May 95 23:13:00 -0500
Subject: Disappearing wall
Have any of you ever noticed that if you look at some walls from
a certain angle, you can see through? No noticable messed up graphics,
is just makes it look like the corner is closer than for real.
- --
| Fidonet : John Orazem 1:250/348
| Internet: John.Orazem@horizon.tor250.org
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Wed, 17 May 1995 09:34:13 +0200
Subject: Re: WQ: Save Game and Other File Formats!
>get my hands on the file formats for the SAVED GAMES (mainly at this point).
The save game header info of DOOM 1.2 is included in the UnOfficial DOOM
Specs Errata, available on www, at
http://www.nero.uni-bonn.de/~bernd/uds
If you don't have www, it might be available by ftp on ftp.cis.ufl.edu
(haven't the location at hand). Mail me if both doesn't work.
If you use this info with 1.666 or above, please send me mail about any
confirmation - I have only checked the info with 1.2. If you intend to
determine the level/thing state dependend data structure in the DSG,
please let me know. I'd like to include any data in the "Errata" file.
> DOOM vs. Heretic palette
The Heretic palette has been reported to be different from DOOM's. Just
look at the PLAYPAL lump data (as well as COLORMAP, for lighting related
index mapping). The DOOM PLAYPAL/COLORMAP in a PWAD should work with
Heretic. I haven't checked any of this, as I don't care about Heretic.
If you want to combine DOOM and Heretic graphics, you'll have to deal with
RGB space minimum distance color mapping and index level flat/picture
lump conversion (and with copyright infringement problems :-/).
B.
------------------------------
From: gala@cris.com (Gala)
Date: Wed, 17 May 1995 03:37:41 -0400
Subject: Re: Announce: GRINDER1.WAD
>For ALL DM ONLY wimps:
^^^^^
Sorry in advance to people who don't want to hear this, but... --
***FLAME MODE ON!*** };)
>Oh, Jeez. Yet ANOTHER useless friggin deathnatch level.
>C'mon folks - if you can't program a complete level, leave the damn
>things alone!!!!!
>Deathmatch programming is for those who have neither the brains nor the
>balls (not to mention seriously deficient programming skills) to do a
>FULL level.
WRONG. There are MANY more things you have to consider to make the level
attractive to the Deathmatch crowd. A few examples are making it easy to
run through quickly (ie. Ledges, MAP07) which means making most corners
'curved', figuring out good places for the weapons...
>Who gives a flying fig if you can blow a buddy away. WWWWHHHHHEEEEEE.
>99% of the people who play the game have better thing to do than plan
>their day around 'Doomin' their Buds.' Like work and families.
Wow, you work too? Blow my mind!
Every monster in DOOM has 1 weapon (claws not counting), move in a predictible
pattern, and are QUITE easy to blow away. They don't run, hide, think, nothing.
You can never predict what a good DeathMatcher will do.
>If these levels are so damn good, PROVE IT! Create levels
>ALL players can use, not just that 1% who haven't got anything better to
>do. Jeez. Do it right or get a life.
No, you're the 1%. The only reason DOOM/DOOM ][/Heretic thrive so well in
the PC game market is due to multiplayer. Go look at how fast Dark Forces
faded!
I LOVED that game! The weapons were very original and well done... but no
multiplayer...? Who's going to stay around and shoot drones while we could
be chainsaw'ing our landlords/bosses/in-laws?
Single player is good once in a while (see the Monastery series, Dark
Forces, Aliens/OMF TCs etc.) but after going thru them once... back to
Multiplayer.
Maybe you're mad because you aren't used to things dodging?
- -Gala- gala@cris.com
Just DEU it!
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Wed, 17 May 1995 10:41:49 +0200
Subject: [Q]: BSP *bulding* details
I've got a question to all those on this list who have dealt
with the several node builders for WAD's (programming, debugging,
bug fixes, porting, but **NOT** usage).
With upright dismay, I had to realize that the SSECTORS entries
are far from being convex polygons. In fact, there are several
SSECTORS containing only 1 SEG. I somehow expected that the
edges created along partition lines might be missing (although,
earlier on, I assumed that floors and ceilings are rendered as
convex SSECTORS, not non-convex SECTORS), but in this case each
SSECTOR needs at least **2** SSEGS (allowing for either 1 or two
gaps, due to missing partition line edges).
Problem is, for some reasons I need to create convex polygons from
SSECTORS. I figured out a way to guess the missing partition line
edges, assuming that anything else is already there.
Question: what's missing? Partition lines usually separate
SSECTORS that belong to the same SECTOR. No two subsequent
edges might be created due to partition lines, as each
partition line edge has at least one vertex that's used
by SEGS, but not by LINEDEFS, but **both** vertices are on
some LINEDEFS (no vertices are created within a SECTOR during
BSP generation). Thus the sequence is e.g.
SEG1 - edge along partition line - SEG3 - SEG2 -+
^ |
| |
+---------------------------------------------+
**NOT** e.g.:
SEG1 - edge - another edge - SEG2 -+
^ |
| |
+--------------------------------+
Assuming that only SEGS with *visible* parts are included within
a SSECTOR, there's the possibility of LINEDEFS that separate
two adjacent SECTORS with equal floor and ceiling height (no
upper, no lower) being fully transparent (no middle). Different
floor/ceiling textures do *NOT* matter, as floors/ceilings have
to be done per SECTOR (wonder if there's even a need to depth sort
the SECTORS, despite the BSP?).
Thesis: the missing edges in each SSECTOR are LINEDEFS w/o middle,
upper and lower - nothing to draw for walls, no need to keep them
within the BSP.
Am I right?
Iff the missing parts are only LINEDEFS of a certain type, I'll still
be able to track down the missing edges. But chances are that even
some of those LINEDEFS are split during BSP building. But those
splites aren't saved (the VERTICES might, but the SEGS can't, right?).
In case this doesn't work out, I'd like to know if there's a BSP builder
source available that:
- is not based on idbsp
- works with Linux
- allows for some tweaking, to generate the missing edges
I don't care about speeed, or quality of result. Lots of comments,
a readable source, and perhaps some helpful hints from the author
are much more valuable at the moment. Any volunteers please contact
me via private email.
Thanks a lot.
B.
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Wed, 17 May 1995 13:44:20 +0200
Subject: BLOCKMAP special effects?
I recently read the manual to RMB (I'd like to recommend both :).
Dealing with BLOCKMAP stuff, I just wondered if there've ever
been any special effects done with manipulating BLOCKMAP? There
*are* passable lines in WADs already ;-). I just thought of
combinations of LineDef attributes that does not work for the
common "walkthrough/shoothrough" lines. If a long LineDef is
present in several blocks, it might be possible to introduce
"gaps" by removing the LineDef from one block. Don't know about
any "player in sector" or "noclip/step height" related
effects - most of them are likely to be bugs of some kind.
Just far out speculation. Any thoughts?
B.
------------------------------
From: Olivier <montanuy@lsun75.lannion.cnet.fr>
Date: 17 May 95 14:53:22+0200
Subject: RE: [Q]: BSP *bulding* details
>With upright dismay, I had to realize that the SSECTORS entries
>are far from being convex polygons.
normal. they are convex SETs of SEGS. I mean in the sets, all the segs
must be on the same side (left side, I think. the main side, actually)
of any given SEG in the set.
A SSECTOR with just one SEG is trivialy convex :-)
and blatantly inefficient.
> I somehow expected that the edges created along partition lines might
> be missing (although, earlier on, I assumed that floors and ceilings
> are rendered as convex SSECTORS, not non-convex SECTORS), but in this case
> each SSECTOR needs at least **2** SSEGS (allowing for either 1 or two
> gaps, due to missing partition line edges).
> Problem is, for some reasons I need to create convex polygons from
> SSECTORS. I figured out a way to guess the missing partition line
> edges, assuming that anything else is already there.
>Question: what's missing? Partition lines usually separate
>SSECTORS that belong to the same SECTOR.
- IDBSP doesn't take SECTOR reference into account. BSP and DEU do, but
this is an unecessary feature. (but maybe a very nice one. I'm still wondering)
- partition lines cut just any sector that they manage to go through.
a given SIDEDEF can be cut by to partition lines, and thus end-up as
a single-SEG node.
> Different floor/ceiling textures do *NOT* matter, as floors/ceilings have
>to be done per SECTOR (wonder if there's even a need to depth sort
>the SECTORS, despite the BSP?).
no, floors/ceilings are obviously generated by the linedef seen in
each columns. this is clear when you play a level in IDCLIP.
> Thesis: the missing edges in each SSECTOR are LINEDEFS w/o middle,
> upper and lower - nothing to draw for walls, no need to keep them
> within the BSP.
> Am I right?
Check, but I bet NOT!
>In case this doesn't work out, I'd like to know if there's a BSP builder
>source available that:
DEU 5.3
the BSP works fine, thanx to Renaud Paquay!
I'm currently studying BSP for fun, and I'd be glad to discuss
more with Berned or anyone, about this kind of problems.
hint: within 10 months, we better be able to create a real 3D BSP fully
optimised. For Quake :-)
Olivier Montanuy
The Arrogant Frog
------------------------------
From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Wed, 17 May 95 09:22:16 CDT
Subject: Re: visplanes error
>> (is this already part of "Bob's consistancy checker"?)
>
> No. Neither is the 128|256-something HOM limit. Errors that are
>intermittent and vaguely understood or NP-complete are not good candidates
^
^
Uh oh. Trying to inject real computer science into the discussion.
I thought this group was just for editor wars, impossible EXE hacks, "let's
build a 100-level WAD", and the occasional newbie flamebait.
>for automatic consistency checking.
(I don't think any line-o'-sight computation would actually be NP-
complete since I think it would be a polynomial time computation.)
My current theory for the cause of the visplane error is either
DooM has to include more than 128 node entries or more than 128 segs (not
lines) to compute the view. It's still a real mystery to me as to why it's
not a consistent error. Sometimes you can swing through a view and not
have DooM crash, and sometimes you can't.
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: Wed, 17 May 95 09:46:47 CDT
Subject: Re: Another WAD Error
>> Ok. I am full of WAD errors these ays :). Here is this one:
>> I have a level I am maing that spans a lot of coordinates. The
>> leftnost X coordinate is in the -6000s and the right most is in the
>> +4000s. Top most y is about +2000, bottom most y is like -3000s.
>[...]
>> without sidedefs. I cannot track the error down. 1) What is causing it
>> and 2) What do I do to fix and avoid this error in the future? Thanks!
>
>It looks like a BLOCKMAP error. Get your favorite editor and look at
>the size (number of K) of the BLOCKMAP entry that was created by the
>BLOCKMAP generator that you are using. If it is larger than 64K, Doom
>will crash. Well, at least the DOS version will crash. Maybe the UNIX
>ports of Doom would work. That would be interesting. :-)
Unless the level is a forest of lines from one end to the other, I
don't think it is big enough to cause a BLOCKMAP overflow (to be clear:
the BLOCKMAP has a 64K *word* limit). However, if it is a BLOCKMAP problem
running the WAD through my WARM v1.3 or Jason's DMAPEDIT--which both do
BLOCKMAP packing--should fix the problem without resorting to having to
change the level.
Have you ruled out all the things that can cause a crash at the
start: line with no sides, more than 64 animated lines, etc?
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: Wed, 17 May 95 10:15:56 CDT
Subject: Re: BLOCKMAP special effects?
Special manipulation of the BLOCKMAP is an interesting idea, but
right now I can't think of anything you could do that you can't already
do with LINEDEF flags. But there still could be something use in trying
such manipulation.
Now if we could have *runtime* manipulation of the BLOCKMAP ...
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: Wed, 17 May 95 10:06:32 CDT
Subject: Re: [Q]: BSP *bulding* details
>With upright dismay, I had to realize that the SSECTORS entries
>are far from being convex polygons. In fact, there are several
>SSECTORS containing only 1 SEG. I somehow expected that the
Just think of a 1-SEG sector as a degenerate convex polygon. Or you
can think of an SSECTOR as a region in which a line joining any points on any
pair of SEGS does not cross another SEG, and certainly any SEG can see itself.
>Thesis: the missing edges in each SSECTOR are LINEDEFS w/o middle,
>upper and lower - nothing to draw for walls, no need to keep them
>within the BSP.
There is nothing missing. All the sides of each LINEDEF have a
corresponding SEG (or more than one if the line was split) somewhere in the
SEGS list.
You can probably use the partition line and/or the bounding x,y
coordinates associated with each node to help with drawing those SSECTORS
that aren't closed.
>In case this doesn't work out, I'd like to know if there's a BSP builder
>source available that:
>
> - is not based on idbsp
> - works with Linux
> - allows for some tweaking, to generate the missing edges
You can certainly look at my WARM v1.3 which readily compiles on
Linux, but I believe that the NODES/SEGS/SSECTORS data in any WAD already
has all the info you need to draw the subsectors.
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: John Wakelin <johnw@datametrics.com>
Date: Wed, 17 May 95 11:27:23 -0500
Subject: Re: visplanes error
> From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
> Reply-To: doom-editing@nvg.unit.no
> My current theory for the cause of the visplane error is either
> DooM has to include more than 128 node entries or more than 128 segs (not
> lines) to compute the view. It's still a real mystery to me as to why it's
> not a consistent error. Sometimes you can swing through a view and not
> have DooM crash, and sometimes you can't.
A month or so ago I produced a WAD that will consistently produce the
error. In the released version there is a point where I cut a corner
so that the player couldn't get back far enough to see enough to
cause the crash. If you stand in that corner facing into the room,
idclip, and move backward, the game will exit to DOS with the visplane
error. If you would like to see what I am talking about, I can mail
you the WAD or you can pick it up from cdrom. It is small (~17k
zipped) so it shouldn't be a big deal to send.
Have a great day,
JohnW
__________________________________________________________
#include <stupidstuff.h>
#define USER "johnw" /* John Wakelin */
/* Johnw@datametrics.com */
main() /* (703) 385 7700 */
{
while (isstupid(USER)) ignore(USER);
}
------------------------------
From: Jens Hedegaard Hykkelbjerg <hykkelbj@daimi.aau.dk>
Date: Wed, 17 May 1995 17:37:06 +0200 (MET DST)
Subject: Re: BLOCKMAP special effects?
Bernd Kreimeier writes:
>I recently read the manual to RMB (I'd like to recommend both :).
So can I ;)
>Dealing with BLOCKMAP stuff, I just wondered if there've ever
>been any special effects done with manipulating BLOCKMAP?
First of all I'd like to say that RMB and the associated manual
deals with REJECT map special effects, and has nothing to do with
BLOCKMAPs (Just to make sure no-one makes a mistake)
I've never heard of any BLOCKMAP special effects
or any tools that could be used to create them.
If you come up with either I'd like to hear about it for my
special effects WWW page.
I think BLOCKMAP special effects at best would be difficult to use
unless you REALLY know what you're doing!
I've just finished the descending stairs part, and I have forgotten
who it was that posted the DNSTAIRS wad. Can you help me?
I'm very grateful for all the help I received from this list so far.
If you want to get WWW info about RMB, special effects
or other editing pages, take a look at
http://www.daimi.aau.dk/~hykkelbj/doom/
With kind regards,
Jens Hykkelbjerg
- --
Jens Hykkelbjerg | "Civilisation began with the felling
Aarhus Universitet | of the first tree; and, it will end
Email: hykkelbj@daimi.aau.dk | with the felling of the last."
WWW: http://www.daimi.aau.dk/~hykkelbj/index.html
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Wed, 17 May 1995 17:43:53 +0200
Subject: [Q] BLOCKMAP packing?
> through my WARM v1.3 or Jason's DMAPEDIT--which both do
> BLOCKMAP packing--should fix the problem without resorting to having to
> change the level.
What's that? Using one "empty" block definition for all those blocks which
does not contain a line (same offset)? Or even using the same block
definition for all blocks containing the same lines? Please explain
(or am I missing some RTFM?).
B.
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Wed, 17 May 1995 17:38:53 +0200
Subject: Re: visplanes error
> Robert Fenske wrote:
> My current theory for the cause of the visplane error is either
>DooM has to include more than 128 node entries or more than 128 segs (not
>lines) to compute the view.
Two months ago I posted my own favorite guesswork on this topic (repost
below, still too long :-(.
Besides my assumption that floor/ceiling rendering is done by SSECTORS
instead of SECTORS (which is wrong, see BSP related post), I still
think that "visplane" overflow is related to limited stack space
storing possibly visible SECTORS (now :), until front-to-back
traversal of BSP tree is aborted as soon as every screen column has seen
a middle texture or upper/lower overlap (top == bottom counter of already
stored *wall* pixels). No check done so far on my "range of view"
hypothesis ;-).
>It's still a real mystery to me as to why it's
>not a consistent error. Sometimes you can swing through a view and not
>have DooM crash, and sometimes you can't.
If it's truly random (read: the direction of view and viewpoint position
is exactly the same for all frames during the "swing") my nice little
hypothesis is wrong. Sigh.
I don't think will ever get to any definite solution. BTW, no Id employees
are currently on this list (have they ever been ?), thus they won't
(haven't) read anything on "visplanes". We might get some other "no cheats
with DOOM network play possible", "QUAKE will rule" or "had to stir up the
pot" messages (sorry, couldn't resist), but I doubt they'll bother to reveal
the "visplane error" mysteries to us - at least until we ask them ;-).
B.
==============================================================================
From bernd Wed Mar 29 12:01:13 1995
To: doom-editing@nvg.unit.no
Subject: Drawing order and visplanes?
>Ted Vessenes wrote:
>It had drawn some of the
>walls farther back and was in the middle of-- get this-- drawing the green
>slime pit surrounding the rocket launcher. Only when it's done repainting,
>the green slime pit is overpainted.
I recently had a discussion with a contributor to the BSP-FAQ on www about
using the BSP to render floors/ceilings. We both agreed on a front-to-back
traversal determining visible parts of wall columns. Do book-keeping on the
top/bottom index of already seen pixels for each screen column. As soon as all
columns are do not have a "middle" gap, stop BSP traversal.
However, he proposed a back-to-front (painters algorithm) traversal for
the floors and ceilings. I wasn't entirely convinced, but the observation
quoted above confirms he's right.
Note that you will have to store floors/ceilings "already seen" within
some stack-like buffer, until front-to-back BSP traversal is finished. (As
my adviser pointed out, you will have to store visible wall slices as well).
Now every *Subsector* that is partly within the viewing angle (even
those completely hidden by other walls/ceilings/floors) will have to be
present in this buffer. The number of sectors doesn't matter, as some of <<<<< OOOUUCH
us already concluded. I think the visplane "overflow" error indicates
that the renderer runs out of buffer space (fixed size array, probably)
during the front-to-back BSP lookup. Thus the occurence of this error
should depend on:
- level complexity (amount of subsectores needed for non-convex sectors)
- viewpoint position (amount of subsectors partly within current view)
- "range of view" (how far does the LineOfSight has to go at max,
in terms of subsectors touched)
Only the latter has not been mentioned already, I think. One really
small window allowing for one single ray to cross a lot of subsectors
"far away" should therefore provoke a "visplane overflow".
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Wed, 17 May 1995 18:43:18 +0200
Subject: Re: BSP builder question/improvements?
I wrote:
>>Thesis: the missing edges in each SSECTOR are LINEDEFS w/o middle,
>>upper and lower - nothing to draw for walls, no need to keep them
>>within the BSP.
Robert Fenkse wrote:
> There is nothing missing. All the sides of each LINEDEF have a
>corresponding SEG (or more than one if the line was split) somewhere in the
>SEGS list.
Olivier Montanuy wrote:
> Check, but I bet NOT!
Yep. You're right - should have used that display right at the beginning.
The splits are there. Now I know partition lines might cross ;-) there's
no need to look for missing LineDefs in the BSP.
Hmmm. Let's do it the other way round: is there an opportunity for
further improvement of BSP building - or this the "unecessary feature"
of DEU/BSP you mentioned?
Another question: if partition line crossings create single SEG subsectors,
and creating a larger tree (maybe not very balanced, too) is there a way
to check for the number of such crossings within the bounding box, and
reject splits during BSP building?
B.
------------------------------
From: thekid@ornews.intel.com (Brian Kidby)
Date: Wed, 17 May 1995 09:26:04 -0800 (PDT)
Subject: Re: Announce: GRINDER1.WAD
Hi folks,
Look, I'm terribly sorry for the noise my announcement caused on this
list. When I was more active here (6+ months ago), add-on announcements
were ok. Rest assured that I've been sufficiently repremanded by the
moderator. :)
I won't be pulled into a flame-war. Let me simply say that multi-player
support (Co-Op AND DeathMatch) is THE reason Doom/DoomII/Heretic
are still wildly popular. Also, multi-player is THE reason behind ID's
next offering: QUAKE.
Also, I hope no one got the impression that I was "raving" about my level,
because I worded the announcement very carefully to avoid sounding like
that. Everyone's got their own ideas of what makes a good DM level, and
what may be "the ultimate" for some may be a waste of time for others.
The moderator has asked that this thread be closed, so if you want to
continue this discussion with me, please do so via personal e-mail.
My address is given below.
Brian K.
- -------------------------------------------------------------------------
The Kid My thoughts and actions are strictly my own.
thekid@ornews.intel.com Do not hold my employers responsible.
- -------------------------------------------------------------------------
------------------------------
End of doom-editing-digest V1 #281
**********************************
