Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 588
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #588
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Saturday, 24 February 1996 Volume 01 : Number 588
Flame thrower addendum
BFG hit and bit 4: Unexpected success
Re: 145imp.wad followup
----------------------------------------------------------------------
From: LummoxJR@aol.com
Date: Thu, 22 Feb 1996 23:48:47 -0500
Subject: Flame thrower addendum
Apparently, the idea has been spread around that under certain circumstances,
a properly used code pointer 801 will create explosions that never end.
Well, here's the whole story:
1. Endless explosions WILL happen when code pointer 801 is used in the rocket
death sequence, because code pointer 801 itself calls the rocket death
sequence (the actual death frame of thing #34).
2. In situations where the ceiling is very high, explosions caused by code
pointer 801 are likely to continue for a longer time, but will go out
eventually (statistics just about demand it). Random explosions happen along
the floor-to-ceiling height of the location where the code pointer goes off,
and they continue until one of them gets close enough to the ceiling. In very
tall rooms, like Doom II's Map 30, the effect is that the explosions seem to
go on forever- but they will go out once the ceiling is reached.
3. The beginning and intermediary explosions are not harmful, but they do
make noise. The final explosion is the one that does the real damage. There
is no way to change the earlier explosions, in noise or effect, since the
game seems to make up its frames on the fly. (Most likely, Doom has room for
more than the standard 967 frames, and uses some of the overflow as a sort of
clipboard- what gets copied to the clipboard, though, is out of our control.)
The results reported from using the flamethrower patch in Doom II Map 30,
similar to what happens sometimes when you shoot at too many things in the
same line of fire, are probably related more to too many monsters (I've seen
it- not difficult to achieve) and the very high ceiling height making the
explosions continue for a long time.
What does everyone think of the patch, anyway? Graphics? Weapon power? Any
reactions?
I've noticed a conspicuous lack of mail lately, even after my last letter on
the thing limit debate (not that I actually want to hear any more about that
subject, thank you very much).
I'd especially like to hear what you think about the graphics, since I've
never done graphics for Doom before, and certainly not weapons. Any comments
would be greatly appreciated, especially as I'm thinking about coming up with
some good new weapon ideas and giving them their own look.
Lummox JR
just another harmless fanatic
------------------------------
From: LummoxJR@aol.com
Date: Fri, 23 Feb 1996 01:04:21 -0500
Subject: BFG hit and bit 4: Unexpected success
Well, to all of you who've been following the gettable projectiles thread, I
have a new wrinkle.
Mike Gummelt mentioned "fires" in one of his patches, created by the BFG
effect; they are made shootable and bit 4 is turned off, so they "die out"
eventually by producing the explosion effect (code pointer 127) over and over
again.
Given the previous lack of success with patches that alter bit 4, I didn't
expect it to work.
The results were this: A secondary BFG hit, acting as described above, did
not cause a lock-up. In most cases, several BFG hits were created in the same
spot (no doubt because the hit is itself shootable), seemingly based on how
many other targets were also hit (with a max of 20, the less targets I had,
the more BFG hits were in the same place). And because they are shootable,
the BFG effect can be used on them again, spreading them out even more!
Keep in mind, this is in Doom I, where the gettable projectiles patch and any
other shootable projectile patch has failed.
My guess? This is what I think:
Patches that turn off bit 4 to make a projectile reworkable are unstable in
Doom I, producing no effect on some systems, lockups on others; the whole
thing seems to be system-related. Thus, you'll never see me distribute such a
patch for Doom I, because its effects are unknown. (Mike's been insisting
gettable projectiles work in Doom I, and I have no doubt that they've worked
for him and for Greg Lewis, and for some others, but the fact that others
have also reported crashes points to an effect that is different for every
computer system. As for Doom II, they appear to work just fine there; but
why, no one can guess, as the EXEs are pretty much identical, even in
length.)
This patch may not cause a problem because the BFG hit is not created as a
projectile, but rather as a completely separate kind of entity. Turning on
bit 4 may not have had any meaning at all, except to remind the programmers
that it was an object not created by normal processes.
If anyone DOES have a problem with this kind of patch, though, I think we
should all hear about it. The only problem I had was that repeated BFGing of
these byproduct flashes created a whole mess of the suckers, causing the game
to slow down.
I tried to produce an infinite recursion by putting code pointer 119 in the
BFG hits, but no such luck- it requires a direction to work, and I think BFG
hits would need to have a nonzero speed setting to use it.
If you want to try the patch yourself, just go into DHE and do this:
1. Copy frames 123-126 to 241-244 (Doom I, using unused archvile frames).
2. Alter the "next frame" entries for 241-244 to read 242, 243, 244, and 241.
3. Change 126's next frame to 241.
4. Give frames 242-244 code pointer 188 (play injury sound- does nothing
here).
5. Give frame 241 code pointer 127.
6. Alter the BFG hit so that bit 4 is turned off and bit 2 is turned on.
Lummox JR
quite surprised
------------------------------
From: "Drake O'Brien" <a13231@mindlink.bc.ca>
Date: Thu, 22 Feb 96 22:57 PST
Subject: Re: 145imp.wad followup
Lummox sez:
>I thought we'd pretty much cleared this up, but as long as it's not about the
>other stuff....
Both you and Mike have 'answered' the question a few times, but none of the
'answers' take account of the actual terms of the question.
>Basically there are different things that happen with each of those bits.
>For the obstacle bit, this is used when a monster or player is moving, most
>likely running a collision test to interpret who's going to walk through
>whom, and whether they can or not.
>For the gettable bit, a collision test tells the game that if one object that
>can pick up items (i.e., the player) is moving onto another object that is
>gettable, the gettable thing needs to be checked to see if it can be picked
>up.
Well yes, this is in effect a series of identities. Nobody is asking what
'gettable' means.
>I don't know whether walking over a clump of 1000 items would crash the
>game or not, then, since it all depends on how Doom handles the collision
>list.
This is what I mean about you and Mike being unaware of the terms of the
question you're trying to answer. I meantioned in my original post that I
had overlaid 1000 revenants, played the area and all was fine until the game
froze when I shot at them. Then I changed the 1000 revenants to 1000 clips
and all was fine, I could walk over them & fill my ammo bag, pick up a blue
key layered in there, and all was fine until the game froze when I shot at
them. Those were the original terms which I've repeated now for the 4th
time. Anyone can easily repeat these tests, and anyone doubting the truth of
my statement and yet wanting to answer the question should repeat the tests.
>For the shootable bit, though, this is used to see if items that have already
>been determined to be in the line of fire are actually hittable, and if so
>which one should be the main target, and how high or low the shot should be
>made to hit the target. The reason for the crashes and the weird behavior is
>that the first step, determining what items are in the line of fire, fails
>when too many items qualify; the items in question need not have the
>shootable bit on to be included in the list, they merely have to be in the
>way.
Yes, this is what I said. Now my question was why this should be so, since
after all, doom has no problem with walking over 1000 items. It's only when
a shot is fired that the problem occurs. Repeating one term of the question
and ignoring the others does not answer it.
>Those are, of course, all educated guesses. Based on the evidence, they're
>the best possible theories as to what's going on right now.
Guesses? You stated a series of identities, that a 'gettable' item was
'gettable', etc., showed how you were unaware of 1/2 the terms of my
question & restated the other 1/2 as if they were an answer. How is that a
'theory'?
>Lummox JR
>why yes, I am a programmer
You may be a programmer, but you didn't answer the question.
The followup note that you are now answering explains that if you enlarge
145imp.wad you only get a game freeze when shooting from a certain set of
angles. You say:
>The reason for the crashes and the weird behavior is
>that the first step, determining what items are in the line of fire, fails
>when too many items qualify
What really puzzles me, now, is why you AREN'T puzzled, and why you ignore
the very posts you claim to be answering. In the 145imps followup you're
answering I stated that the angle (hence ssectors the vector of the shot
traverses) makes a difference, that you only go into noclip mode when you
shoot from certain angles when the play area is enlarged. Yet your 'answer'
totally ignores this new data, focussing solely on the number of items. Of
course, my question states that number of items is a factor, but this has
also been shown to be only 1 factor - and the POINT of the followup message
you're trying to answer was to relate this data which you're ignoring.
And again, you even ignore the original terms of the question, stated before
the additional data was known: why, if you change the imps to clips so the
'shootable' bit is no longer a factor, so any confusion about primary target
or whatever can't be a factor, does the game freeze when the other bits
cause no problem.
Anyhow, screw it. You and Mike succeeded in derailing the idea.
------------------------------
End of doom-editing-digest V1 #588
**********************************
