Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 590
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #590
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Monday, 26 February 1996 Volume 01 : Number 590
Re: Flame thrower addendum
The 1000-clip answer, again
More on system-related bit 4 failures
Re: Thing limits, crashes, etc...
A sincere open letter to LummoxJR concerning bit 4.
Re: Flame thrower addendum
Re: The 1000-clip answer, again
Re. The 1000-clip answer, again
[none]
[none]
----------------------------------------------------------------------
From: LummoxJR@aol.com
Date: Sat, 24 Feb 1996 22:47:47 -0500
Subject: Re: Flame thrower addendum
>Well, until you posted this, I didn't know there WERE any new graphics.
>You didn;t include and install program, so I just applied the .deh file
>and saw the same old plasma gun. I'll check them oout, but you really
>should have taken the time to whip up a quick little install.bat or even
>just instructions.
So, Mike, you didn't read the FLAMETHR.TXT file then, did you?
It says quite specifically that you need to use NWT or WinTex or some other
tool to put it in. Since tools vary from system to system, and I don't want
to distribute an entire program with my WAD, adding a batch file would be
kind of difficult.
Lummox JR
just love those crazy text files
------------------------------
From: LummoxJR@aol.com
Date: Sat, 24 Feb 1996 22:46:51 -0500
Subject: The 1000-clip answer, again
Drake, apparently you're failing to get the point here.
The "series of identities" I wrote tried to be (although you're probably
right here) more like a series of methods most likely used by Doom to handle
the different cases. And as to the rest, you don't seem to understand that it
actually IS the answer to your question.
>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.
One more time:
When you shoot, the game has to MAKE UP A SHORT LIST of items that are in the
way, and then sort through it to see what's actually being shot at.
Overflowing the stack or whatever holds the list would cause the crashes.
When you walk over a pile of items, the game only needs to check against a
collision list, and can go through the EXISTING LIST (hence no overflow) at
leisure, picking up gettable items that are there.
Thus, walking over 1000 clips will work, because the game doesn't have to
make up an overflowed list in the meantime to do it. Shooting over 1000
clips, though, makes a list expected to be short and temporary into a long
list, causing memory overwrites and all sorts of ghastly errors.
I stated all that very clearly in the letter, and it very concisely answers
your original question.
Here's that section again, and let's actually read it this time, shall we?
>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.
Note the first sentence: Items already determined to be in the line of fire.
In other words, a list is made of items in the way of a shot. THEN the
shootable bit is checked, THEN position and distance are checked.
Excuse what may be interpreted as flames, Drake, but you really need to pay
attention to what people are saying here, since it does answer what you
asked.
Lummox JR
didn't I just say that?
------------------------------
From: LummoxJR@aol.com
Date: Sat, 24 Feb 1996 22:46:53 -0500
Subject: More on system-related bit 4 failures
>Glad you tried it out. The only problem I had was the same one
>you had, the BFG Hits piling up on top of each other. But I fixed
>that in AD3. I suggest people try AD3 out if they'd like to see
>how it's supposed to work.
>Also, Lee, you shouldn't really have been surprised that it worked
>if you had played AD3, which has gettable projectiles, shootable
>projectiles, exploding ammo boxes, and several other things you've
>said are impossible. What's stopping you from looking at it? It
>really has a lot of stuff in it, take a look, you could probably
>learn a lot from it.
It's the gettable projectiles, Mike. They don't work, and there's no point
taking time to download the whole thing when parts of it are going to lock up
my system.
>I noticed in your last letter that you said several other people have
>reported crashes with the gettable projectile patch. Who? I haven't
>gotten any, and you haven't forwarded any to me. I of course don't
>include the one person who modified the patch and added it to the
>weapons patch they made as they screwed up my patch causing their own
>crash. And the only other crash reported was due to 150+ ammo clips
>being in the same place (which was made impossible in the last version
>of the patch sent out to this list). Not a single person except you
>has reported the crash you did in which the game would crash 30 secs
>to 2 minutes after the first ammo clip showed up. If anyone does get
>this crash, or if you have any mail from people who have reported it,
>let me know. But until then, you're still the only one with this
>problem.
What do you mean, you haven't heard anything like that? What about the letter
a while back about the same patch, changed to be soulspheres instead of ammo
clips, causing the lockup? Your reply was that straying from the original
patch invalidates the results, but that's not it at all- bit 4 is at issue
here, and there has indeed been a report of a crash similar to mine in Doom
I. Most of the reports of "working" patches came from Doom II users.
Oddly enough, Greg Lewis has tested it quite extensively in Doom I, and found
nothing wrong. Given that the patch works in Doom II for everyone but, for
some people, not in Doom I, I'm inclined to believe that there is a quirk in
the Doom I engine that varies from system to system, sometimes having a
problem and other times not.
Some have speculated on why this might be, since the same versions of Doom I
& II have practically identical EXEs. Nevertheless, there are changes; Doom I
does nothing when you run over a megasphere (if you put it into a level and
add sprites for it), but Doom II reacts. Doom II has its own special startup
text, Doom I has different text. It's entirely possible that such things as
stack length and other low-level information is also different between
versions, but not different in a way that would affect the length of the EXE
file.
Since it's been demonstrated that Doom I and Doom II do have minor
differences, even between files of the same version number, then it's likely
that there's something different about Doom I that makes it uneasy with
certain bit 4 alterations on some systems.
It can't be TSR's that do it, because I've been trying the patch with minimal
TSR's loaded, with no luck. It might be related more to disk cache size or
hard drive brand name or something equally trivial. I don't know.
The whole point is that the gettable projectiles patch can't be used in Doom
I on a wide-distribution basis because it is unreliable. Some people (perhaps
most) have no problems, other have big problems.
Lummox JR
yes, it really does crash!
------------------------------
From: Michael Gummelt <gummelt@pegasus.montclair.edu>
Date: Sun, 25 Feb 1996 01:12:49 -0500 (EST)
Subject: Re: Thing limits, crashes, etc...
Here's a personal request:
For any further messages concerning anything to do with the topic
of crashes due to thing overloads (1000 Revenants, Clips, or whatever),
could you please put the following in the Subject heading:
WARNING: YET ANOTHER INSIGNIFICANT EXERCISE IN EGO-BASHING UNDER THE
GUISE OF DOOM-EDITING: PLEASE DELETE IMMEDIATELY!!!
Thanks,
Mike
------------------------------
From: Michael Gummelt <gummelt@pegasus.montclair.edu>
Date: Sun, 25 Feb 1996 01:41:17 -0500 (EST)
Subject: A sincere open letter to LummoxJR concerning bit 4.
Lee, I reiterate:
> >I noticed in your last letter that you said several other people have
> >reported crashes with the gettable projectile patch. Who? I haven't
> >gotten any, and you haven't forwarded any to me. I of course don't
> >include the one person who modified the patch and added it to the
> >weapons patch they made as they screwed up my patch causing their own
> >crash. And the only other crash reported was due to 150+ ammo clips
> >being in the same place (which was made impossible in the last version
> >of the patch sent out to this list). Not a single person except you
> >has reported the crash you did in which the game would crash 30 secs
> >to 2 minutes after the first ammo clip showed up. If anyone does get
> >this crash, or if you have any mail from people who have reported it,
> >let me know. But until then, you're still the only one with this
> >problem.
Your response:
>
> What do you mean, you haven't heard anything like that? What about the letter
> a while back about the same patch, changed to be soulspheres instead of ammo
> clips, causing the lockup? Your reply was that straying from the original
> patch invalidates the results, but that's not it at all- bit 4 is at issue
> here, and there has indeed been a report of a crash similar to mine in Doom
> I. Most of the reports of "working" patches came from Doom II users.
Lee, you are a stubborn, stubborn man...
Do you actually READ my letters? Hello? If someone modifies the patch,
any crashes that result are invalid. This SINGLE REPORT of a crash similar
to yours was due to unwise and negligent tampering. This certainly cannot
be used to back your position. Anyone can take a perfectly good patch
and screw it up by changing a single bit, you should know that.
> Oddly enough, Greg Lewis has tested it quite extensively in Doom I, and found
> nothing wrong. Given that the patch works in Doom II for everyone but, for
Nothing odd here, it works.
> some people, not in Doom I, I'm inclined to believe that there is a quirk in
> the Doom I engine that varies from system to system, sometimes having a
> problem and other times not.
Not from system to system, on YOUR system.
> Some have speculated on why this might be, since the same versions of Doom I
> & II have practically identical EXEs. Nevertheless, there are changes; Doom I
> does nothing when you run over a megasphere (if you put it into a level and
> add sprites for it), but Doom II reacts. Doom II has its own special startup
> text, Doom I has different text. It's entirely possible that such things as
> stack length and other low-level information is also different between
> versions, but not different in a way that would affect the length of the EXE
> file.
This is true, but does not explain why ONLY YOUR DOOM CRASHES.
> Since it's been demonstrated that Doom I and Doom II do have minor
> differences, even between files of the same version number, then it's likely
> that there's something different about Doom I that makes it uneasy with
> certain bit 4 alterations on some systems.
No, not likely. ONLY YOUR DOOM CRASHES. The problem is NOT bit 4. You
treat bit 4 like it's the plague, but it can be tampered with. I have proof
that it works, and my proof, quite frankly is much more convincing than
yours, especially from a scientific viewpoint. I have many cases of
success, you have only ONE of failure. Any logical person would be able to
conclude that the problem would be local rather than global- meaning the
problem is in your computer, not the patch.
> It can't be TSR's that do it, because I've been trying the patch with minimal
> TSR's loaded, with no luck. It might be related more to disk cache size or
> hard drive brand name or something equally trivial. I don't know.
Who knows? Something's screwy with your copy of Doom.
> The whole point is that the gettable projectiles patch can't be used in Doom
> I on a wide-distribution basis because it is unreliable. Some people (perhaps
> most) have no problems, other have big problems.
Wrong. It is completely safe to distribute on a wide basis. I'd say
I've heard from at least 30 people who have used one of my gettable
projectile patches (Aliens vs Predator or Insane Weapons, or the ammo
depot patch) and only ONE person has reported the crash. That's YOU.
The problem is not with the patch, the problem is with YOUR DOOM.
I'd appreciate it if you would kindly STOP incorrectly referring to the patch
as "unstable" and "unreliable" based on one flawed Doom version's crash. You
are not the world, you are not "most people". I'm sure if ANYONE out there
has had the same crash as you, I would have heard about it. And I
specifically asked DOOM I players to report success or failure, so your
claim that "mostly Doom ][" players have reported success is false, as is
your claim that it doesn't work for "some people" with Doom I. The correct
statement would be, it does not work for ONE person with Doom I.
Please do me a favor and do not post anything about my patch or my other
work unless you have actual valid proof of your statements. You slander
my reputation as a patchmaker and disseminate disinformation. Let my work
speak for itself for each individual person who uses it. And if anyone else
ever DOES report the same crash, I guarantee you, you will be the first
person I inform.
I want no ill feelings, Lee. I respect you and your work, and I understand
your position. But please understand that on this issue, you are alone in
your convictions. As a favor, I sincerely ask you to refrain from defaming
my work unless you have proof outside of your system. If I AM wrong, I
welcome correction. But if I am right, you are doing both me and any
potential DeHackErs a great disservice by being blindly defensive and
unprofessional in your assertions.
Again, no malice meant, I just want to get on with other ideas.
Michael Gummelt
------------------------------
From: Michael Gummelt <gummelt@pegasus.montclair.edu>
Date: Sun, 25 Feb 1996 01:43:44 -0500 (EST)
Subject: Re: Flame thrower addendum
On Sat, 24 Feb 1996 LummoxJR@aol.com wrote:
> >Well, until you posted this, I didn't know there WERE any new graphics.
> >You didn;t include and install program, so I just applied the .deh file
> >and saw the same old plasma gun. I'll check them oout, but you really
> >should have taken the time to whip up a quick little install.bat or even
> >just instructions.
>
> So, Mike, you didn't read the FLAMETHR.TXT file then, did you?
Oops, nope. Sorry there.
> It says quite specifically that you need to use NWT or WinTex or some other
> tool to put it in. Since tools vary from system to system, and I don't want
> to distribute an entire program with my WAD, adding a batch file would be
> kind of difficult.
I stand corrected. However, if you intend this to be a serious patch,
(open to the public, like on ftp.cdrom.com or something) you really should
consider taking the time to write a batch file and including dehacked and
deusf.
Mike the text file skipper!
------------------------------
From: John Minadeo <jminadeo@nforce.com>
Date: Sun, 25 Feb 1996 01:45:38 -0500 (EST)
Subject: Re: The 1000-clip answer, again
I don't mean to seem premenstral here (no offense meant to any females)
but I for one (not that I'm anyone...) am getting a little tired of
discarding a bunch of ego to get to some raw data in some of these
responses... All of you fellas know a hell of a lot more about the
inner-workings of DooM then I and I greatly appreciate your revelationary
work with de-hacked patches and the like but I tend to think of this list
as a polling of information, processing it and coming up with plausible
explanations/solutions to problems. Seeing as how none of us worked on
Doom (aside from the occasional appearance of Romero) we don't know and
our guesses are only that... I mean, sure "laws" of good programming
apply but sometimes you have to sacrifice "Good Coding" to get something
to work (especially if under a deadline...) Anyway, I apologize for this
off thread response. Please drop the ego, people who contribute accurate
data and whose work is dedicated do not need to toot there own horns,
their work is recognized and respected, Really! (I promise!)
Sorry if I offended anyone, it was not my intention. On to another thread!
- -- Random note: C sharp.
- -> John Minadeo jminadeo@nforce.com
- -> TeamTNT - http://starbase.neosoft.com/~teamtnt
------------------------------
From: "Drake O'Brien" <a13231@mindlink.bc.ca>
Date: Sun, 25 Feb 96 01:25 PST
Subject: Re. The 1000-clip answer, again
Recall that problems occur with as few as 145 items aligned in the vector of
a shot.
>One more time:
>When you shoot, the game has to MAKE UP A SHORT LIST of items that are in the
>way, and then sort through it to see what's actually being shot at.
>Overflowing the stack or whatever holds the list would cause the crashes.
>When you walk over a pile of items, the game only needs to check against a
>collision list, and can go through the EXISTING LIST (hence no overflow) at
>leisure, picking up gettable items that are there.
>Thus, walking over 1000 clips will work, because the game doesn't have to
>make up an overflowed list in the meantime to do it. Shooting over 1000
>clips, though, makes a list expected to be short and temporary into a long
>list, causing memory overwrites and all sorts of ghastly errors.
If I walk over 1450 overlaid megaspheres (like to change the numbers
occasionally) doom has to check all items at a POINT for any with an
obstacle bit set. No obstacle bit is set so I sail across (actually I pause
for a sec, then jump forward as the whole clump vanishes, whereas with clips
I'll just sail across with no pause, but no matter). Seems to me that the
only difference when I shoot across the 1450 megaspheres is that doom is
checking all items on a VECTOR. I don't understand this concept you're
explaining, about how there's a short list in the case of checking along the
vector whereas there's no short list when checking at a point. I honestly
don't (I'm not being deliberately obtuse just to cause a fight).
Furthermore, the case of 145 overlaid (or aligned) objects in a large open
space is near a limiting point for the doom engine (with respect shooting).
There're 2 facts:
1. Shooting them FROM SOME AREAS of the open space will cause the player to
go into a no-clipping state, whereas shooting them from other areas causes
no problem - the game plays as normal. And like I said, no other player
action causes a problem.
2. Occasionally a 'shooting a clump' crash won't freeze the game or send
the player into noclipping but will dump the player into dos with a (eg.)
R_subsector: ss 2147450878 with numss = 4
message.
There seems to be a resonance between these facts which your concept of
'short lists' doesn't account for (unless I'm missing something).
>Note the first sentence: Items already determined to be in the line of fire.
>In other words, (1) a list is made of items in the way of a shot. (2) THEN the
>shootable bit is checked, (3) THEN position and distance are checked.
[numerals inserted by me, for reference]
When walking (1) a list of items must be made at the location of the player,
(2) then the obstacle bit must be checked. (3) NOW there's a difference
because position and distance of the player don't have to be checked, since
they're known. So step (3) isn't required. On the other hand, this is my
original question, since I asked why it would be that, when the shootable
bit ISN'T SET there's a crash, since if the shootable bit isn't set step (3)
isn't required.
This was the whole point of my post - that is, this was the whole reason why
I was puzzled enough to meantion it to the list.
>Excuse what may be interpreted as flames, Drake, but you really need to pay
>attention to what people are saying here, since it does answer what you
>asked.
I don't mind sharp talk, at least, when the sharp talk stays focussed on
doom & has a specific direction. I engage in sharp talk myself. I'm going
to leave this matter here. I'm not satisfied with your answer - it's one
that I thought of myself and rejected before posting the original question
(tho' I didn't have the tech language).
------------------------------
From: owner-doom-editing@nvg.unit.no
Date: Sun, 25 Feb 1996 20:37:33 +0100
Subject: [none]
------------------------------
From: owner-doom-editing@nvg.unit.no
Date: Sun, 25 Feb 1996 21:43:51 +0100
Subject: [none]
------------------------------
End of doom-editing-digest V1 #590
**********************************
