Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 586
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #586
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Thursday, 22 February 1996 Volume 01 : Number 586
Re: so try to answer this, gurus
New WadAuthor Release!
Re: so try to answer this, gurus
Re: DEU source??
Re: so try to answer this, gurus
145imp.wad-->no-clip crash - 145imp.zip [1/1]
MM2, looking for FTP-site
Re: Gettable projectiles update
Re: Thing limits- A programmer's perspective...
Re: 145imp.wad-->no-clip crash - 145imp.zip [1/1]
New WadAuthor Release!
Flame thrower patch now online
Gettable Projectiles Redux
----------------------------------------------------------------------
From: "Drake O'Brien" <a13231@mindlink.bc.ca>
Date: Wed, 21 Feb 96 02:54 PST
Subject: Re: so try to answer this, gurus
Lummox now:
>Actually, Mike was probably entirely correct here. (And yes, my retort to the
>array idea was in keeping with logic, since any programmer worth his salt
>could tell you he wouldn't write a game that way.)
>Typical game logic for something like bullets, which have to be handled
>internally to function properly, would be to check all objects in the
>player's line of sight, then see which ones are shootable and which aren't
>(it's a lot quicker than checking for shootability first, then checking
>line-of-sight later). The closest shootable thing gets the bullet. If there
>were a whole mess of items in a bullet path, it might freeze the game.
>This is another situation where a fixed-length array would actually be
>appropriate, but judging by reports is not the case. My guess is that the
>game makes up a list of targets, and math calculations get royally screwed up
>when about 200 items are in the same place. It's also possible that there is
>a fixed-length table involved, and no one bothered to put in a limit because
>there is almost no way such a thing as 200 items in the bullet path would
>happen- SPAWNING 200 items, however, is different. Game objects are usually
>handled in a way that makes tables impractical.
>Lummox JR
>kind of sick of defending the obvious
Perhaps... As I said earlier, I'm not a programmer so have no way of
evaluating this kind of theory. I'm just passing on info.
I can add some info here, if anyone's interested. In my tests (repeated)
doom handled 148 objects in a shot's line of sight but crashed at 149. The
message was:
R_subsector: ss 2147450878 with numss = 4
This draws up the idea that vector arithmetic of the shot might be a factor
(maybe in conjunction with others) that doom isn't handling? I dunno.. We
can eliminate the overlaying of objects or, in this case, of the spawning of
objects as factors.
Now, if I got a bit ticked off there it was because I found some responses a
bit condescending, and Mike a bit proprietary of subject matter which
reaches beyond the strict bounds of his thread about a dehacked patch.
In any case, I believe the 'answer' gets closer as product of testing - to
eliminate overlay/spawning, for example. If this was 'obvious' to some of
you, fine, but I'm happy to admit I actually learned something new.
Re. Mike Gummelt's last note:
>In answer to the question you aksed about why Doom crashes if it has to
>check if what you're shooting at is shootable, but why doesn't it crash
>if you try to walk through all of the ammo clips. Simple: When firing,
>the engine would have to check all the things in front of you INSTANTLY,
>but when walking, it only has to check the thing(s) you're walking
>over - maybe 10 at max. Not all 1000 or so. Try making a level with
>1000 ammo clips in one spot, then walk over it.
But I said in the original post, 1000 is precisely the number of
revenants/clips I had overlaid, and so is precisely the number of clips I
did walk over and that doom did check instantly. Doom will pull out a blue
key or etc. layered in there, for example, instantly.
Now consider: I had imps in clumps of 50,40,30,20,5,4 exactly aligned in
this last test. Shooting pistol exactly down the line crashed doom; shooting
anywhere else was OK. Standing offline and shooting with the BFG didn't
crash doom, so I concatenated the clumps into two of 50,49 close together
and in that case the BFG from the side caused crash. So it's interesting
that doom checks out the vectors of the multi-shot, sees only 148 objects
aligned and doesn't crash, or sees 149 objects aligned and does crash. That
is, doesn't doom have to know that the 149th object is aligned? And then,
doom'll crash regardless of whether the 'shootable' bit is set on that 149th...
Well, it's all still a bit puzzling to me but this's my last post on the
topic.
------------------------------
From: "John B. Williston" <us010832@interramp.com>
Date: Wed, 21 Feb 1996 07:55:23 -0500
Subject: New WadAuthor Release!
WadAuthor v1.20
- ---------------
Williston Consulting is pleased to announce the release of WadAuthor
v.1.20. This release adds some new features, enhances existing
features, and fixes all known bugs.
WadAuthor is a state-of-the-art editor for DOOM, DOOM II, HERETIC,
HEXEN, and any other wadfile based game. The following paragraphs
highlight some of WadAuthor's capabilities.
Windows, Windows, Windows
- -------------------------
. A single 32-bit executable is supplied. This single executable runs
under Windows 3.x, Windows95, and Windows/NT (Microsoft's Win32s
is required to run the 32-bit version under Windows 3.x).
. WadAuthor takes advantage of the Windows environment to provide
direct point and click manipulation of all objects within a map.
Multiple selection, drag and drop, and other typical Windows
features are all supplied. The interface just "feels right".
. Full keyboard support is available for those users who simply do
not like the mouse. Every command, and every operation can be
performed directly from the keyboard.
. Clipboard cut, copy, and paste -- even across games -- allows
users to quickly reuse existing architecture. Want to use
architecture from a DOOM map in HEXEN? Copy and paste -- that's
all there is to it!
. Full printing support for all Windows output devices. Print
preview lets you make sure it's right *before* you waste
the paper.
. Graphical wall, floor, ceiling, and thing selection makes
guessing a thing of the past. Special performance tuning for
all color depths makes WadAuthor graphics faster than most
DOS-based editors.
. The status bar keeps you up-to-date on exactly what's happening.
Information about anything in the map is displayed as the
cursor moves or current object is changed.
. Multiple dockable toolbars for your favorite commands. Don't
like my toolbar layout? Change it! Dock them where you want
them, float them, or even combine them (only available in the
32-bit version).
Detailed Help
- -------------
. A complete context-sensitive help system provides the new user
with help on every dialog, every menu item, every keypress, and
every element of the WadAuthor interface. Press F1 for help on
the current context, or press Shift+F1 and click anywhere.
. A detailed step-by-step tutorial is provided to walk new users
through the creation of a new map one step at a time. Simple and
advanced wadfile editing concepts are explained and illustrated.
. A complete reference section lists every command, every dialog,
every menu item, every keyboard mapping, and every mouse mapping.
Power Tools
- -----------
. Raw data editing capabilities allow editing gurus to set the
actual bits saved to the wadfile if necessary. No other editor
for Windows sports this kind of power and simplicity in the same
package.
. Map checking, explanation, viewing, and fixing of errors helps
avoid the common and unusual errors in wadfile design.
. User defined tools are the ultimate in customization. If you
have a favorite tool for wadfile design, WadAuthor will let
you keep it *very* handy.
. Property editing for multiple objects lets you change any number
of parameters for any number of map objects with one operation.
. Unlimited undo lets you undo all of those changes in one step
for those little mistakes we all make.
. Full development environment for Hexen scripts. Compiling,
error checking, and editing are all available in a single window.
WadAuthor makes it easy to write Hexen script code.
. Decompilation for Hexen scripts provides source code for maps
which do not otherwise provide it. This feature makes it much
easier to begin learning how to best use the new scripting
features introduced with Hexen.
. Near-perfect stability and capacity in the node-builder gives
the user confidence that losing work is a thing of the past.
No more corrupted wadfiles because the map is too big.
. Full support for third-party node builders. If you don't like
WadAuthor's node building, or simply have a faster tool, you
can use it.
. Full support for custom graphics in the current wadfile or
within an external wadfile.
These are only a few of WadAuthor's best features. WadAuthor also
provides sector scaling and rotation, texture alignment, motif
creation and application, automatic door and stair conversion, a
simple to use tagging tool, and a long list of other great features.
WadAuthor is a shareware product written by Williston Consulting,
a small consulting company with years of experience. WadAuthor
is shareware you will be happy to register. In exchange for that
registration, you'll receive technical support, access to future
updates, and access to the WadAuthor Value Pack -- a collection
of wadfile editing utilities.
I highly recommend that you take the time to evaluate WadAuthor
as an editor. It isn't perfect, but it is a great tool. Please
feel free to email me with any questions or comments. Thanks
in advance for trying WadAuthor!
John B. Williston
- --
http://ourworld.compuserve.com:80/homepages/williston_consulting/
___ ___
\ \ ____ / / Williston Consulting
\ \/ \/ / _____________ "Software worth buying"
\ /\ / / _________/
\_/ \_/ / / 70541.1335@compuserve.com
/ /_________ us018032@interramp.com
/_____________/
------------------------------
From: Rudy XIII <rudolphw@odysseus.gonzaga.pvt.k12.dc.us>
Date: Wed, 21 Feb 1996 10:44:53 +1130
Subject: Re: so try to answer this, gurus
At 05:43 PM 2/18/96 PST, you wrote:
>1st, to Lummox JR, I explained both circumstance and kind of crashes I got
>in my posts, which were pure test-info (WHAT, not WHY).
>
>Now here's a curiosity. Overlaying 1000 or so revenants is OK, doom2 plays
>and the revenants look and sound strange, and when I get close they pack one
>hell of a punch. I can fire anywhere in the level but when I fire at the
>revenants the game freezes. Well, any idiot might speculate as to why THAT
>happens. But there's more.
>When I change all revenants to clips, so everything is identical except now
>there's just a clump of clips, the identical thing happens. Doom plays
>alright and I can shoot anywhere and pick up clips from the clump when I run
>outta ammo, but if I fire over the clump of clips the game freezes. Odd,
>isn't it?
>
>
Well actually it isn't. In doom2, as with most runtime games, its the
players interaction with generated objects that you have to keep in mind.
Even though objects have a "width" and "hieght", in the universe the programmers
have created, the y axis goes on forever. Thus, you can't put a sector over
another.
This also means that if you fire over or under an object you are still
interacting
with it. The width of an object appears to be an actual width. The hieght is
another case. In doom2, it just means its relative hieght. So if you shoot
over a
sprite, you are still coming in "contact" with the sprite, but the program
says that
that sprite is a cerstain hieght and is under your fire. Then you get that
effect
of being able to hit things on all levels(your on a building and sprite is
45% below you
yet you still hit it). This another reason sprites can be put on top of
each other, the
program couldn't decide what to shoot at. To answer you question, you were
interacting
with the sprite you shot at. In the case of the revenants, you hit the
visual version of
the sprite within its height and width. In the case of the clips. You were
still
interacting with the sprite, except this time, the program has to tell
itself that
the bullets simply fly over. In all cases, you asking the program and your
computer
to do a lot of things at the same time. This would slow down or freeze most
computers.
- -Rudy
------------------------------
From: Rudy XIII <rudolphw@odysseus.gonzaga.pvt.k12.dc.us>
Date: Wed, 21 Feb 1996 12:56:10 +1130
Subject: Re: DEU source??
At 04:29 PM 2/20/96 +1100, you wrote:
>
> Hello guys,
>
> Where is the quickest and best place to get the DEU source for
> Windows or DOS, in particular Raphael Q, can you give me any
> earlier, not as complex versions of the code as I wish to
> make a world editor for my simple engine based on Doom style
> world.
>
> Thanks,
>
>
I suggest you check out ftp://cdrom.com . If not there then check out
compuserve's Game Developers' Forum. So far there are sources for WinTEX a
DHE in their library.
- -Rudy
(in the world?? yeah right!)
------------------------------
From: Rudy XIII <rudolphw@odysseus.gonzaga.pvt.k12.dc.us>
Date: Wed, 21 Feb 1996 13:10:50 +1130
Subject: Re: so try to answer this, gurus
At 03:47 PM 2/19/96 PST, you wrote:
>>Clips may not be shootable, but the Doom engine may still have to
>>check every single one of those things to see if they're shootable
>>or not.
>
>Oh oh, ego alert!
>
>Hey, you don't absolutely have to try to answer the question. Your guesses
>aren't covering the ground asked for in the subject header. After all, now
>the question becomes "then why doesn't the game freeze when the player
>passes over the clump of clips, as doom has to check every single one to see
>if it's an obstacle or not". Now, don't answer again until you can come up
>with something a guru might say. We don't want this thread to turn into
>another interminable bore.
>
>Half the reason why I asked the question is because there's been a bit of
>sneering at a certain idea, eg. "This is total rubbish (flame not intended),
>despite a lot of people
>supporting its logic. Doom is an advanced game, programmed to make the best..."
>and "The array idea seemed silly to me too, Id would have made a limit to the
>number of things spawned if they knew it would crash at too many.", whereas
>this clump of clips thing doesn't obviously fit in to the 'Id is God'
>scenario. If the array idea is rubbish and silly because it isn't advanced
>enough for you, how do you reconcile that with "the Doom engine may still
>have to check every single one of those things to see if they're shootable
>or not"? As for the array idea, it at least attempts to explain the
>observable facts.
First off I gotta tell you I never have believed that "Id is God". You see
a real God would of never of worked with that unmentionable crappy company
on Wolf3d. Anyways, we all know that Doom itself has to have errors. All
programs have errors, even if playtested and such for ever. In Doom 2's
case, Id probably did not put a limit on the number of sprites. On the
other hand, they probably know what that limit is, but any smart game
designer would tell you, what's the point. When they were creating this
game they weren't thinking about a bunch of people sitting around computers
making programs that could edit their game into everything from starwars to
xxx pornos. They built the program in way that would let them create a game
that could be played by most people. So I believe that Doom 2, even though
the program might have its own limits based on structure, has no limits to
the number of sprits. I'm quite sure that if my 486 dx2 66 with 8 megs of
ram could produce a max of 700 clips per level, then a Pentium 150 with 16
megs could probably produce a max of close to a thousand. And one could
imagine that Quake will probably be able to do double that. It all has to
do with the program and the machine.
- -Rudy
------------------------------
From: a13231@mindlink.bc.ca (Drake O'Brien)
Date: Wed, 21 Feb 96 10:07:14 PST
Subject: 145imp.wad-->no-clip crash - 145imp.zip [1/1]
- --*-*-*- Next Section -*-*-*
Content-Type: Text/Plain; charset=US-ASCII
Well I promised not to post more on the old subject header so I changed it.
Because I had an 'non-verbal idea'... ha ha, suffer!
It turns out that the 'shoot the clump of things' crash isn't exactly as
precise as the 148/149 difference I saw in my test yesterday. Here's a
small wad (.5K UUencoded zip) with 145 overlaid imps. Walk around the
level, bump into walls and shoot, then shoot at the imps. You go into a
kind of no-clipping mode (not quite identical). The imps unravel and begin
a far attack, the fireballs are no-clipped and don't hurt, but the close
attack hurts. OK, now load the wad in an editor and delete 2 imps. When
you shoot this time all you get is the 'pain'. You don't go into
no-clipping. Now add 1 imp and shoot. The imps start to unravel, you start
to go into no-clipping, then the game freezes.
Change the imps to soulspheres. 144 and 145 soulspheres produce the same
result: shoot and go into no-clipping, no crash to dos. But 143
soulspheres causes no problem, you stay in normal mode.
This doesn't make the thing any the less puzzling to me.
- --*-*-*- Next Section -*-*-*
Content-Type: Application/Zip
Content-Transfer-Encoding: x-uue
begin 755 145imp.zip
M4$L#!!0````(`()*52`EFMKYGP$``$L)```*````,30U24U0+E=!1.V3,4L#
M01"%W^9RB:!86%F(14`018@DH@A"8K(QT9@+=X?:*5:6*2W3"9:V_@<K"^U2
M^CNTL;2TT?/-[JJ(40(V%K>7VWG?S.SMW.RENU^MCP.X'`/6DCM,*H4\YO&8
MG.%V/%6I2E6J4O5?%:!XV9$D"IXC1?*00=:0V(SQRO!,S'?DDWS&+>5(DFLI
M3Q*[Y'9XMU%<#>-JI_35.UKTW0[WCK96_;KVC]'77H)7J"9Z29-;G=*>FBWY
MJ]ALZ?-G-]G90<9H,_<]IVDKMI/2;;BSD%YCX!MM3J6?<UKN+)KFP3U6('4(
M21VLH*_Z8+31#H*P?+A6TZUVZ7`%B2WIY\CSRTF2XX-G4<`</YU%%%'&C+E6
ML8X-IRNHH8%M[**+"`>`.WS/V.^SO&#.*-]9.+_U_>11Q@Z;Y3,5E?W(E;%;
M[1:7:2=X7[-O<;/5V8IL#X_I:[<ZNJX;48%]?")'K;KA*?X[ILE[.HSU@8X6
MR$<2U[(:.">/"4>Z%@=A=$&>(7>"NI:$*W+9Y)LP[O/VR$.]30_P0+XA;[:#
MV@Z+?`-02P$"%``4````"`""2E4@)9K:^9\!``!+"0``"@```````````"``
F````````,30U24U0+E=!1%!+!08``````0`!`#@```#'`0`````
`
end
- --*-*-*- Next Section -*-*-*--
------------------------------
From: Denis <d.moeller@rendsburg.netsurf.de>
Date: Wed, 21 Feb 1996 21:18:43 +0100
Subject: MM2, looking for FTP-site
Hi there...
since Memento Mori became so cool and famous, we are about to work on
Memento Mori 2. All we need is someone with a ftp-site (fast would
be cool), who wants to lend us some space to upload/download MM2
stuff that is under construction.
It would be cool, if anyone here could help us. Oh, and btw, don't
forget to reply to ME, not to this list. Thanks.
cya
Denis
[] Denis Moeller, author of NWT v1.3 and TiC's WAD Reviews. []
[]------------ E-Mail: d.moeller@rendsburg.netsurf.de ------------[]
[] For Doom, Hexen, Quake-Links, Good WADs List & Memento Mori(!) []
[] check this out: http://www.geocities.com/Hollywood/2299/ []
------------------------------
From: Robert Fenske Jr <fenske@rgfpc.electro.swri.edu>
Date: Wed, 21 Feb 1996 14:22:43 -0600 (CST)
Subject: Re: Gettable projectiles update
On Tue, 20 Feb 1996 LummoxJR@aol.com wrote:
> As far as I've tested it in Doom II, it works. This does not come as a shock
> to me; in fact, with the exceptions of Mike Gummelt and Greg Lewis, I have
> yet to hear from another person for whom it worked in Doom I.
> Trying a variant of the patch in Doom I, I managed to keep it running for a
> minute or two, which was a big improvement over instant lock-up. Still, it
> did eventually crash, as did a shootable projectiles patch I was told about
> and had to test (I expected it to crash right away, but it remained stable
> for quite a long time).
> Thus, my conclusion: The patch is unstable in Doom I, with system-specific
> results. Anything that turns off bit 4 is unusable there.
Since the v1.9 executable is the same for DOOM I & II, I am puzzled
that it would act differently (for this case) depending on the WAD file you
are using. But now is it really the bit 4 that is the cause of the problem?
Do these patches remain stable if everything is the same except that bit 4
is turned on?
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 Fenske Jr <fenske@rgfpc.electro.swri.edu>
Date: Wed, 21 Feb 1996 14:36:33 -0600 (CST)
Subject: Re: Thing limits- A programmer's perspective...
On Tue, 20 Feb 1996 LummoxJR@aol.com wrote:
> Yes, but most of those limits can be easily handled by just ignoring cases
> beyond the 128 or 256 or whatever. A thing limit would be far easier to
> handle, and only the worst of programmers would not only put in a
> fixed-length array, but forget to watch out for limit violations.
> As I said, no matter what you may think of ID's programming, they can't be
> THAT bad.
My point was that having a thing limit would be consistent with
having all these other limits. Anyway, id's programming abilities and the
merits of various ways of implementing concepts don't really matter. The
DOOM engine does what it does regardless of how good or bad we think its
methods are. The goal is to find out what it does, how it does it, and
what the limits are.
As I see it, there's been mostly speculation (including mine) about
possible thing limits and if they exist do they contribute to the instability
of the patches. Of course speculation leads to testable hypotheses--it's
just there hasn't been much specific testing reported, other than Drake's
Imp Mobs (which I think are pointing to a different limit(s) since his test
haven't been with spawned things).
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: jelson@l1.conline.com (Jim Elson)
Date: Wed, 21 Feb 1996 15:03:56 -0600
Subject: Re: 145imp.wad-->no-clip crash - 145imp.zip [1/1]
At 10:07 AM 2/21/96 PST, Drake O'Brien wrote:
>It turns out that the 'shoot the clump of things' crash isn't exactly as
>precise as the 148/149 difference I saw in my test yesterday. Here's a
>small wad (.5K UUencoded zip) with 145 overlaid imps. Walk around the
>level, bump into walls and shoot, then shoot at the imps. You go into a
>kind of no-clipping mode (not quite identical). The imps unravel and begin
>a far attack, the fireballs are no-clipped and don't hurt, but the close
>attack hurts.
I find this very interesting since I've seen this happen before with
"normal wads". Well, not that normal since the wad in question is
map04 of H2HMudFE.wad (previously H2HMudDX.wad, map01)
On at least 2 occassions while recording lmps for the competition, I
suddenly found both myself and the monsters (not sure how many were
active, but probably around 150) in the same "no-clip" mode which
Drake just described.
Also, a few other competitors have told me they experienced the same
phenomenum on one of the other FE levels.
At the time I just chalked it up to the nodes having been built with
DoomEd and the strange effects it sometimes resulted in on FE's map04.
On the basis of the reports I've been reading here, I think it supports
the idea about number of objects. The most dramatic instance occured
at a point in the wad were I was rocketing about 100 monsters crowded
around the bunker I was holed up in. And suddenly everything starts
coming thru the walls at me. Talk about getting freaked out! :)
This was definitely an anomoly since I had run the same strategy
well over a hundred times before without this occuring. I'm not sure of
the significance of this for the issue being discussed, but I've decided
to share it nonetheless since it might provide another additional clue.
- --H2HMud
P.S. I believe I still those lmps somewhere. I'll check and see if the
anomoly is still reproduced when the lmp is played or not.
============================================================================
H2HMud NorthAmerican DeathMatch Tourney
Promo/Marketing Coordinator for "The New Technology: Evilution"
- ----------------------------------------------------------------------------
jelson@conline.com; WEB page ==> http://www.conline.com/~jelson/index.html
------------------------------
From: matt.tagliaferri@pcohio.com (Matt Tagliaferri)
Date: Wed, 21 Feb 1996 16:56:00 -0500
Subject: New WadAuthor Release!
WadAuthor Question: how do you handle sector references using cut&paste?
I believe we've had this discussion before, but consider the example of
wanting to copy one teleporter sitting inside sector x and pasting it
inside sector x. You would want all the RIGHT sidedefs to remain sector
x, but all the LEFT sidedefs to become a NEW sector (number
CurrentMaxSectors +1). Is this possible, or does WadAuthor assume ALL
sector references will be new?
I don't ask this to criticize, I'm looking for a good way to put
cut/paste in dCAD...
matt tagliaferri
_ _ ---------------------------------------------------------------
|_|_| PC-OHIO PCBoard OIS pcohio.com HST 16.8: 216-381-3320
|_|_| The Best BBS in America Cleveland, OH V34+ 33.6: 216-691-3030
---------------------------------------------------------------
------------------------------
From: LummoxJR@aol.com
Date: Wed, 21 Feb 1996 19:10:29 -0500
Subject: Flame thrower patch now online
Announcement:
A new, totally cool flame thrower graphics/DHE patch for Doom I & II is now
available at:
http://members.aol.com/LummoxJR/doomfile.html
Check it out- it's great!
Lummox JR
now I do graphics
------------------------------
From: Michael Gummelt <gummelt@pegasus.montclair.edu>
Date: Wed, 21 Feb 1996 19:35:26 -0500 (EST)
Subject: Gettable Projectiles Redux
Here is a repost of the gettable projectiles post. I don't
know why the last one didn't go through.
This will work with Doom I and ][ (contrary to LummoxJR's claims).
In fact, when applied properly, this patch will work fine with
any version of Doom. The only person who's reported a problem with
it is LummoxJR. So I ask everyone out there to try it out. Let me
(and Lee) know if it works, particularly in Doom I (any version).
If you save this as a text file, delete everything before the
asterixes (****...) and gibe it a ".deh" extension, you can
just "l"oad it up into DeHackEd. If you have a different version
of Doom, just type in the changes manually. It may work fine if
you load it into any version, though, I think so.
What to expect:
1. Imps do not move or attack on their own.
2. When injured, imps throw ammo clips at you that you can pick up.
3. the clips will fly at you then drop to the ground (if they hit
you, they'll drop also). They'll stay there for a short while
and if you don't pick it up, it will disappear (avoiding the
too many things crash).
Note: if you're too close to an imp when you shoot, it will claw you,
this is because I used the imp fireball attack for the ammo clip throw.
This patch is made for demonstration purposes only, it is to illustrate
that gettable projectiles are possible. I have used it to make things
such as self-healing guns (Insane Weapons) and a medic that heals the
player (insane 3 and Aliens Doom 3).
The crash Lee has reported is this: the game crahses 30 seconds to 2 minutes
after the first ammoclip is thrown. So far, he is the only one to report
this. Note that if you modify the patch in any way or combine it with other
patches, your findings are inadmittable. Only test and report findings
on the unmodified patch that follows.
Let's put this issue to rest once and for all.
Mike Gummelt
***************************************************************************
Patch File for DeHackEd v3.0
# Note: Use the pound sign ('#') to start comment lines.
Doom version = 19
Patch format = 6
Thing 12 (Imp)
Hit points = 5000
Injury frame = 452
Pain chance = 256
Close attack frame = 0
Far attack frame = 0
Speed = 0
Mass = 999999999
Thing 32 (Imp Fireball)
Initial frame = 869
Alert sound = 0
Death frame = 869
Death sound = 0
Speed = 1966080
Width = 1310720
Height = 1048576
Missile damage = 0
Bits = 66561
Frame 868
Duration = -1
Next frame = 0
Frame 869
Sprite number = 78
Sprite subnumber = 0
Duration = 100
Next frame = 0
Frame 870
Duration = 1
Next frame = 870
------------------------------
End of doom-editing-digest V1 #586
**********************************
