Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 517
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #517
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Friday, 15 December 1995 Volume 01 : Number 517
Avatar, where are you?
Re: DHE q's
Re: Yet another dehacked question...
Re: SCRIPT lump (was WadAuthor v1.11)
Re: DeHackEd help offer
Re: Yet another dehacked question...
Re: Yet another dehacked question...
Re: SCRIPT lump (was WadAuthor v1.11)
Hexen Scripts: Loops, numbers
Re: SCRIPT lump (was WadAuthor v1.11)
Re: Quake [or is it?]
Floor_Waggle parameters
Re: Yet another dehacked question...
Re: SCRIPT lump (was WadAuthor v1.11)
Hexen Scripts: FOR loops
Re: Yet another dehacked question...
----------------------------------------------------------------------
From: Michael Gummelt <gummelt@pegasus.montclair.edu>
Date: Thu, 14 Dec 1995 14:50:04 -0500 (EST)
Subject: Avatar, where are you?
Hi, I'm looking for Avatar (Mackey?), the maker of
the OMF theme patch called DMF. I tried to contact him
at the e-mail adress in the .txt files that came with
the .wad (avatar@widomaker.com) but he's no longer a user
there. Anyone know where I can reach him?
Mike Gummelt
------------------------------
From: Gene Franzen <gfranzen@tenet.edu>
Date: Thu, 14 Dec 1995 17:46:55 -0600 (CST)
Subject: Re: DHE q's
On Wed, 13 Dec 1995, Greg Lewis wrote:
> > If you
> > try to use a player weapon with a monster- I've noticed that the projectile
> > will originate from some fixed point on the level! Very very strange.
>
> This I didn't know! Very intereesting... I assume it is probably from
> location 0,0 on the level ? ...
I've had this experience as well. It does originate from the exact
center of the level. I believe I've also had the phenomenon when trying
to modify some player frames to fire things that I know I can't put in
the weapons frames - like the mancubus fireballs. Each time I fire, they
appear at the center of each level and also (I'm not positive about this)
in a set direction instead of wherever I'm pointing when I fire. This,
of course, makes sense since I couldn't place any monster aiming code
pointers on the player frames. I just wanted to see what would happen.
------------------------------
From: Gene Franzen <gfranzen@tenet.edu>
Date: Thu, 14 Dec 1995 21:46:27 -0600 (CST)
Subject: Re: Yet another dehacked question...
Some clarifications on my previous message to Michael Gummelt:
Perhaps I misunderstood the problem with the BFG9000 being stated here.
Let me offer some definitions first.
1. Whenever I say BFG shot, I'm talking about the large green ball that
is fired.
2. Whenever I say BFG hit, I'm talking about the "area-effect" of the BFG
- - in other words, when the BFG *shot* explodes, the BFG hit is the damage
done to creatures by the 20 BFG tracers (if you don't know what I mean by
tracers, read the BFG FAQ.) Yes, I know the BFG hits are not an
area-effect. That's just the generic term I used.
Now, the problem.
Is the problem that when a monster fires the BFG shot and the shot
explodes when it hits a wall, that the player doesn't get hit by the BFG
hits (area-effect)? I'm obviously not talking about the BFG shot itself
- - that always works like any other projectile. If this is the case, then
I've never had this problem. My monster fires the BFG, it explodes, I
see the BFG hit and get hurt by the tracers. What more do you want? I
did no gimicks or anything. If you have the problem and have to solve it
by doing some odd-ball thing with another creature like the archvile,
then I'll tell you what I did to create my BFG shooting monster effect in
step-by-step instructions.
------------------------------
From: "James S. Blachly" <stew@intellinet.com>
Date: Thu, 14 Dec 1995 15:54:49 -0600
Subject: Re: SCRIPT lump (was WadAuthor v1.11)
>>While I'm on the subject, Oliver (sp?) suggested that editor authors embed
>>the script code for Hexen wads within the file as a SCRIPTS resource. I did
>>this with WadAuthor, and I was wondering if you and other authors were
> I support this too in WinTex but... it's now almost totally useless!
>
> With the DEACC decompiler by Luc Cluitman, embeded in both Wad Author and
> WinTex, those behavior just look like text!
> The only thing you lose is the names of variables (which might be a pain).
As well as comments, and certain loop-like structures. The comments thing
would get me, at least, 'cause If I come back the next morning and look at
some code I wrote the previous night, I'll say WHAT was I thinking!
>> If a different de facto standard is brewing, I'd like to adopt it.
> Ben Morris proposed to use the MAPxx header to store various data,
> unfortunately this header is now used in HEXEN and UDOOM: It contains
> some version string. So there's no other standard
>
I say mess around with the MAPxx header. I haven't tried it, but I was
wondering if it really HAS to be 12 bytes, or if we couldn't slap a couple
of nulls and then append our editor information at the end of the entry?
Just a couple of thoughts.
- -james.
James S. Blachly(R) is a registered trademark of God. Design is
(c)Copyright 1980 God. All rights reserved.
------------------------------
From: LummoxJR@AOL.COM
Date: Thu, 14 Dec 1995 16:23:59 -0500
Subject: Re: DeHackEd help offer
>> HI Mike,
>> I have created a 1.5 times the size mega cyberdemon with a rocket launcer
>> on each arm. How do I make him fire two rockets at once or at least the
>> second one a split second behind the first? He's big and he's bad so I
want
>> him to act accordingly!
[clip]
>If you want him to fire two at the same time, change the mancubus fireball
>into a rocket, and use the mancubus fire code pointers. there are three,
>each one fires 2 shots simultaneously (one fires left & center, one fires
>two center , and the other fires center and right). Here you have the
>potential to fire SIX rockets at once!
This is the best suggested use of the mancubus code pointer I've heard yet-
and it's the best way to do what you want. That is, as long as you don't mind
sacrificing the mancubus fireball to do it. The left-and-right mancubus
attack pattern should be good enough, but if you want 6 rockets going at
once, or almost all at once, you'll have to trim those frame durations to 1.
Also one note on the cyber attack: it has 6 frames, 3 for making attack
sounds and 3 for firing rockets. The attack sound, though, is unused, so
those 3 frames (684, 686, and 688) can be used for your own nasty purposes
(heh heh heh).
>What would also be cool would be to throw in a revenant-missible tracking
>behaviour. Unfortunately, you need to use the revenant-fire code pointer
>to shoot one, and the missile must have the revenant missile code pointers
>for the tracking to work. So you could still make the cyberdemon fire two
>tracking in a row, OR you could make the cyberdemon fire two non-tracking
>rockets slightly off-center (using the center-fire mancubus code P. which
>will fire the mancubus fireball), followed IMMEDIATELY by a tracking
>rocket shot straight from the center (using the revenant-fire code P. which
>will fire a revenant fireball).
Also an interesting thought. But indeed, the revenant code pointer must be
used to fire a missle that has revenant-missle tracking.
>This all may sound confusing, but it's pretty simple. If you have any
>further
>questions, let me know. Also, make sure you're using deHackEd 3.0a, it is
>much
>better than earlier versions.
Definitely use DHE 3.0. If you're using an earlier version, some cool effects
are still possible, but not nearly as cool as all of these!
Lummox JR
a concise second opinion
------------------------------
From: LummoxJR@AOL.COM
Date: Thu, 14 Dec 1995 16:23:53 -0500
Subject: Re: Yet another dehacked question...
s337239@student.uq.edu.au wrote:
>But im off the main subject. Im looking for a way to make a shotgun guy,
>or any monster for that matter, shoot DOUBLE BARRELED shotguns... if i need
>dehacked 3.0 for this please tell me since i've been neglecting to ftp it
>as i reckoned deh 2.2 was good enough.
Trust me: Download 3.0. I was using 2.2, until I found the code pointers
hack. 3.0 has code pointers, cheat code alteration, and much more.
Still, a double-barrel shotgun can't be actually done for monsters, as there
is no code pointer for them to use that effect. Heck, even the sergeant's
regular pointer (shotgun) is less potent than the player's. You would have to
use something like Mike's suggestion: use several shots in rapid succession.
Not very asthetic, but it will be more damaging.
>Is there a way to do it ? Any help would be appreciated. Also is it
>possible to make a monster that shoots bfg ?? not the wimpy balls mind
>you.. the one that affects you like a player does... even if it misses
>you you get hit (etc etc.. like deathmatch). I saw a hack once
>(revenge.deh - fun but too hard :) that made the cyberdemon fire bfg but
>it only hurt with a direct hit so that sucked...
There does seem to be some connection with the BFG actually being fired and
the area damage effect, although that may be an illusion. I'm not sure
whether it works or not if the player did not create it. The problem you
mention about it having to be a direct hit may be more related to how the
weapon works, though: your own shots don't hurt you when they make the area
hit effect, after all, so why should any others (except in DeathMatch)? Odds
are, it does indeed create the desired effect, but it does nothing to the
player.
>Ps i already got chaingun (spiderdemon) rocket (cyberdemon) and plasma
>gun (modified arachnotron) monsters. All i need is double barrel/bfg..
>but im running out of colors... besides the map is hard enuf single
>player and is so much like deathmatch.. its really good practice.. :)
Like Mike said, don't worry about colors: Just repeat some. It'll be more fun
that way, anyway.
If you're working on ultra-realistic fake marines, you'll want to try some of
the following:
1. In attack frames, use the line-of-sight pointer for repeating attacks, and
add in a frame that uses the moving code pointer (176 or the archvile's
special 243). That way, they won't stop moving when they attack. Just make
the frame durations extremely short (like 1), give them identical sprites,
and loop them around so that the attack repeats (if necessary).
Example:
Frame 184 (trooper's attack frame):
Sub-sprite 6 (I think- maybe 5; whatever matches 185)
Duration 1
Code pointer 176
Frame 185:
Duration 2:
Frame 186:
Sub-sprite 6 (or whatever matches 185)
Duration 1
Next frame: 184
Code pointer 618 (line-of-sight check)
That'll give you a chaingun-toting trooper that doesn't stop when he attacks.
}:)
2. Another possibility is to set the attack frame's duration to 1, and make
the attack go directly to that frame and then directly back to the moving
frames. This will bypass attack sound generation (in most cases, it's
redundant anyway, if it's set at all), but it will prevent monsters from
stopping when they shoot. This one should not be used for repeating attacks.
That ought to give you some ideas. Mike's letter's full of good stuff, too.
Lummox JR
the DHE idea man
------------------------------
From: Gene Franzen <gfranzen@tenet.edu>
Date: Thu, 14 Dec 1995 17:40:45 -0600 (CST)
Subject: Re: Yet another dehacked question...
On Thu, 14 Dec 1995, Michael Gummelt wrote:
> The following is in response to some stuff Gene Franzel said
> in his letter concerning the discussion I and Chris were having
> on this topic.
Let's clear this right off the bat. It's Franzen, not Franzel. =]
> 1. Gene, you said you had not problem creating the area-effect
> when a monster-fired BFG hits. neither did I. The problem seems
> to be that the monster-fired BFG shot will not effect the PLAYER.
> In other words, a BFG Hit thing will not be spawned on the player
> unless another player fires the shot. This is easily fixable
I see - I seemed to have misunderstood the problem. I never noticed this
discrepancy before, but I'm sure you're right. I didn't bother to check
to see if the visual effect was there.
> line-of-sight when it hits. I made avery strange thing once where
> you could place a "GODSPHERE" in a safe hiding place (you only get
> one) and from then until the GODSPHERE is found and destroyed,
> everything you looked at bursts into flames! Deathvision! Cool,
Very intriguing! I'll have to try that.
> 2. Gene said a fake marine will stop moving when it fires. This
> is true, UNLESS you do the following: Make the marine's firing
> frames very short (duration=1), make the next frames use the
> firing sprites, but movement code pointers. This will make him
> look like he fired whilst still on the go. Also, the lost soul/
> firing loop works too (see the next note).
I'm not entirely convinced this will work as well with a marine that uses
a chaingun or plasma gun - it seems to me he might be moving a little
"choppily" as he stops when he fires for an instant, moves a little bit,
stops and fires for an instant, etc... Although I may be wrong - maybe
the pause is small enough to be indiscernable.
> 3. Apparently Gene didn't quite get what I was trying to say
> when I discussed making marines have different close/far attacks.
> Here's an example: the close attack is, say, an ersatz DB shotgun
> (made by using two-rapid-succession regular shotgun shots- the
> wide dispersal effect will be missing, though). The far attack
> follows this sequence: 1-Fire a rocket, 2-Lost soul attack that leads
> IMMEDIATELY into 3-Fire a chaingun until the player is out of the
> marine's line-of-sight. This will have the effect of the marine
> looking like he is charging/strafing while firing at you. Keep
> in mind that the lost soul attack movement will be continuous
> until it hits a wall, another monster/player, or is injured or
> killed. And if the marine DOES hit you, it will whip out it's
> shotgun and nail you up close. This seems realistic enough to me,
This appears to be exactly what I thought you were saying before -
perhaps you didn't understand my last reply. In deathmatch, players
almost never switch weapons like that. I have never seen someone who
is using a chaingun with plenty of ammo and whips out a shotgun and
shoots just because he got close. Besides, if the marine is charging at
you and firing with the chaingun, he wouldn't be able to have enough time
to whip out a shotgun when he gets close. This would look especially
weird if he's coming at you firing the chaingun, shoots you with a
shotgun when he comes close enough for his close attack frame, and when
you back away starts up with something else - either his chaingun or a
missile launcher again. Finally, as I said before, the "strafing" effect
that you're talking about only happens when he runs at you and goes past
you, turning to fire as he goes. Now, I don't see a whole lot of
deathmatches where someone starts playing joust with you like that, so
I'd deem it a little unrealistic.
> on the speed topic) is making marines that move slowly or not
> at all until they see you or are injured. This could be a little
> disconcerting to find a marine that looks like it's hiding then
> rush out at you. You would do this NOT by using the speed bit, but
> by using different durations for the movement frames. Have a very
> long duration (or -1) for that, then when the marine goes to attack,
> or is injured, have it return to a movement loop with SHORTER
> durations! This should have a nice effect and would be a cool
> surprise.
I haven't done any editing on the durations for the regular walking
frames for anybody, but I have the impression that this would just make
the frames move really fast. In other words, the monster always moves at
the speed defined by the speed bit, and the durations for the movement
frames are just there so the PICTURE of the monster walking is going at a
realistic speed (isn't swinging it's arms and legs too rapidly.)
> 4. As for the issue of fake marines not jumping over cliffs, I
> didn't raise this issue because I figured the solution was rather
> elementary. Just turn on the "goes over cliffs" bit, that's all.
> The "floating" bit is not needed fot this effect, it will only create
> the odd behaviour bug Gene mentioned he had encountered. The "floating"
> bit is for use with the "no gravity" bit to create a flying monster.
> So, Gene, just turn off that bit on your marines and your patch
> should work more like you expected it to.
Unfortunately, wrong - unless you want marines INSTANTLY falling to the
ground as they walk off platforms, you absolutely need to set the
floating bit. What the floating bit does is cause the marine to drift to
the ground. Otherwise you get a "teleportation" sort of action as the
fake marine switches its altitude immediately when it enters a new sector.
Of course, you're right - it does fix the problem of marines walking into
walls, thinking they could fly over, but again, not realistic to have
them falling like that.
> Gene, I hope this cleared up some stuff, and maybe you can fix that
> problem you had, too. If you get a chance to try out my beta,
> feel free to write me with any questions of suggestions!
Likewise - I'll be sure to check out the beta.
> My beta is at:
> ftp.cdrom.com/idgames/themes/aliens/aliendm3
> it's called "ad3.zip" and, yes, it's 5.3 MB! Upcoming betas will be
> smaller and more efficient, trust me!
Heh. I sure hope so. =]
------------------------------
From: "Luc Cluitmans" <L.J.M.Cluitmans@ele.tue.nl>
Date: Fri, 15 Dec 1995 13:01:35 MET-2DST
Subject: Re: SCRIPT lump (was WadAuthor v1.11)
> > With the DEACC decompiler by Luc Cluitman, embeded in both Wad Author and
> > WinTex, those behavior just look like text!
> > The only thing you lose is the names of variables (which might be a pain).
> As well as comments, and certain loop-like structures. The comments thing
> would get me, at least, 'cause If I come back the next morning and look at
> some code I wrote the previous night, I'll say WHAT was I thinking!
You are correct when you say DEACC cannot recover comments and
variable names (which is indeed a good reason to have the original
ACS sources at hand).
However, DEACC (v1.1) perfectly well reconstructs all loop-like
constructs. The only weird thing are constructs that are functionally
exactly equivalent like:
do
{
if (FOO)
{
BAR;
continue;
}
BAZ;
} while (THINGY);
which will be decompiled as
do
{
if (FOO)
{
BAR;
}
else
{
BAZ;
}
} while (THINGY);
(for both variants ACC will generate exactly the same code).
Luc.
------------------------------
From: Jim Davis <JAD7084@tntech.edu>
Date: Fri, 15 Dec 1995 08:35:44 -0600 (CST)
Subject: Hexen Scripts: Loops, numbers
A couple questions... How many actively running scripts can the Hexen
engine handle? 255? But what about scripts on other levels? Are scripts
run on other levels actually run when they're told to, or do they start
running when that level's entered?
What's the format of the for() loop? I can't seem to get it to work as the
specs say... I tried DEACCing all the levels, but DEACC makes whatever
loops were used into while()s...:)
Jim
------------------------------
From: us018032@interramp.com
Date: Fri, 15 Dec 1995 09:38:55 -0500
Subject: Re: SCRIPT lump (was WadAuthor v1.11)
>> With the DEACC decompiler by Luc Cluitman, embeded in both Wad Author and
>> WinTex, those behavior just look like text!
>> The only thing you lose is the names of variables (which might be a pain).
>As well as comments, and certain loop-like structures. The comments thing
>would get me, at least, 'cause If I come back the next morning and look at
>some code I wrote the previous night, I'll say WHAT was I thinking!
I just wanted to set the record straight: WadAuthor only uses the decompiler
as a fallback. If a SCRIPTS lump is available, it is used. Thus, if you
write some code the previous night, all of your original comments and such
will still be there the next morning. The decompiler is only used when the
SCRIPTS lump is not present.
>>> If a different de facto standard is brewing, I'd like to adopt it.
>> Ben Morris proposed to use the MAPxx header to store various data,
>> unfortunately this header is now used in HEXEN and UDOOM: It contains
>> some version string. So there's no other standard
>>
>I say mess around with the MAPxx header. I haven't tried it, but I was
>wondering if it really HAS to be 12 bytes, or if we couldn't slap a couple
>of nulls and then append our editor information at the end of the entry?
I haven't seen any reason that we couldn't mess with the header, but at
the same time, I'd hate to start overloading something for which Id/Raven
already have a use.
Thanks for the thoughts, however -- I really like your sig too!
John
------------------------------
From: bmorris@islandnet.com (Ben Morris)
Date: Fri, 15 Dec 95 08:28 PST
Subject: Re: Quake [or is it?]
Err .. I only sent that message, like, 10 days ago.
That's some major propagation time!
- -/-
Ben Morris: Irritant at large bmorris@islandnet.com
SavanTech/Zerius/C++/Rush/DCK http://www.islandnet.com/~voltaire
Watch for DCK and HexenCK 3.0 real soon now, eh! Real soon! Yeah!
------------------------------
From: bmorris@islandnet.com (Ben Morris)
Date: Fri, 15 Dec 95 08:49 PST
Subject: Floor_Waggle parameters
Floor_Waggle( sectag, range, speed, offset, duration );
sectag: hmmm.
range: the "range" of the waggle - the start height of the floor is the
centerpoint, and this number is divided by two and added/subtracted
to the centerpoint to make the high/low ranges.
speed: hmmm!
offset: the start "offset" of the waggle - if you want to do it to a bunch
of floors, vary this value if you don't want them synchronized.
duration: number of seconds to waggle, or 0 for perpetual motion.
Notes:
- - this special only works from scripts, as far as i was told. not tested.
- - when the floor starts waggling, it "fades in" so as not to jump right
into the motion. when the duration is up, it "fades out".
- -/-
Ben Morris: Irritant at large bmorris@islandnet.com
SavanTech/Zerius/C++/Rush/DCK http://www.islandnet.com/~voltaire
Watch for DCK and HexenCK 3.0 real soon now, eh! Real soon! Yeah!
------------------------------
From: Michael Gummelt <gummelt@pegasus.montclair.edu>
Date: Fri, 15 Dec 1995 11:30:38 -0500 (EST)
Subject: Re: Yet another dehacked question...
Lee has some good advice there about moving-while-
attacking monsters, and he's much more clear and
concise than I. One thing I want to mention,
though, is that I've gotten a fairly nasty
crash now and again by putting the movement
code pointer (from frame 176) in the attack
sequence. I think what happens is it reads
that code pointer in the movement sequence,
goes to attack, then sees that same code pointer
again in the attack sequence, so it attacks...
but it's already attacking- so it goes to
attack, sees the movement code p. AGAIN and,
well, crashes. I guess it gets confused. Of
course, there may have been something else
I had done wrong to make it crash (that's
certainly possible) and I trust Lee's advice
any day, so try it. If it works, let me know,
I'd like to use that too.
Refresher: Lee said to use the movement
code pointer in the attack sequence of a monster
to prevent it from stopping while shooting.
Mike Gummelt
------------------------------
From: bmorris@islandnet.com (Ben Morris)
Date: Fri, 15 Dec 95 08:38 PST
Subject: Re: SCRIPT lump (was WadAuthor v1.11)
> Has anyone contacted Raven/Id whether these MAPxy entries have/will
> have any real function except being a kind of comment? If not, it
> could be used for some kind of script storage. However to be
> compatible with existing maps a tag has to be prepended before the
> script to be able to recognize it as a script instead of a random
> comment. I suggest prepending a line containing just '//SCRIPT'.
i talked to ben gokey about this yesterday. here's what he told me: if
the version string is kept intact, we should be able to append whatever we
like after it.
i'm writing up a standard proposal that includes, among other things, a
[Script] section. briefly, the proposal suggests using a WIN.INI-style
text block following the version string that contains several general
sections - one for information about the Author, one for Comments, and one
for the Script source, so far. hey! - it'd be cool to have another one
that lists the names of each of the script functions in the BEHAVIOR
block, including the names of each of the parameters. this information
could be automatically updated by a utility-program whenever the script is
changed, and read in quickly by an editor-program that could use the info
to simplify script usage within line and thing specials.
getting back to the format:
the idea would be to make the text-block readable by any utility program,
and to allow utility programs to add their own sections - so if the
program _reading_ the text block doesn't understand the name of one of the
sections, it can just skip to the next until it finds something it can
work with.
anyway, i should have the doc up a bit later. hope this works!
- - ben
- -/-
Ben Morris: Irritant at large bmorris@islandnet.com
SavanTech/Zerius/C++/Rush/DCK http://www.islandnet.com/~voltaire
Watch for DCK and HexenCK 3.0 real soon now, eh! Real soon! Yeah!
------------------------------
From: bmorris@islandnet.com (Ben Morris)
Date: Fri, 15 Dec 95 09:51 PST
Subject: Hexen Scripts: FOR loops
Ben Gokey told me the other day that, in fact, for() loops aren't
supported by the compiler.
Hey, the specs Raven gave me said that ACC _did_ support for() - anyway,
it's gone from the next release of the specs, and that's that :(
- - ben
- -/-
Ben Morris: Irritant at large bmorris@islandnet.com
SavanTech/Zerius/C++/Rush/DCK http://www.islandnet.com/~voltaire
Watch for DCK and HexenCK 3.0 real soon now, eh! Real soon! Yeah!
------------------------------
From: gummelt@pegasus.montclair.edu (Michael Gummelt)
Date: Fri, 15 Dec 1995 12:55:25 -0500
Subject: Re: Yet another dehacked question...
> Let's clear this right off the bat. It's Franzen, not Franzel. =]
Oops! Sorry! :D
> > 2. Gene said a fake marine will stop moving when it fires. This
> > is true, UNLESS you do the following: Make the marine's firing
> > frames very short (duration=1), make the next frames use the
> > firing sprites, but movement code pointers. This will make him
> > look like he fired whilst still on the go. Also, the lost soul/
> > firing loop works too (see the next note).
>
> I'm not entirely convinced this will work as well with a marine that uses
> a chaingun or plasma gun - it seems to me he might be moving a little
> "choppily" as he stops when he fires for an instant, moves a little bit,
> stops and fires for an instant, etc... Although I may be wrong - maybe
> the pause is small enough to be indiscernable.
Yeah, as Lee said in a recent post here in response to this discussion,
it would look kind of wierd with the constant-fire monsters. Maybe, I
haven't tried it out, maybe it looks okay. Of course, you could always
use the lost-soul attack/constant fire idea I proposed. I know Gene doesn't
like that idea, but it's worth a shot (more later in this letter).
> This appears to be exactly what I thought you were saying before -
> perhaps you didn't understand my last reply. In deathmatch, players
> almost never switch weapons like that. I have never seen someone who
> is using a chaingun with plenty of ammo and whips out a shotgun and
> shoots just because he got close. Besides, if the marine is charging at
> you and firing with the chaingun, he wouldn't be able to have enough time
> to whip out a shotgun when he gets close. This would look especially
> weird if he's coming at you firing the chaingun, shoots you with a
> shotgun when he comes close enough for his close attack frame, and when
> you back away starts up with something else - either his chaingun or a
> missile launcher again. Finally, as I said before, the "strafing" effect
> that you're talking about only happens when he runs at you and goes past
> you, turning to fire as he goes. Now, I don't see a whole lot of
> deathmatches where someone starts playing joust with you like that, so
> I'd deem it a little unrealistic.
Well, the marine couldn't change weapons while strafing, the constant-fire
loop will keep him firing the same weapon as long as he doesn't stop "running".
Even if he gets close (but doesn't hit you), he will continue to fire the
same weapon (the chaingun or the plasma gun).
This does bring up another thing Lee (or was it Greg?) said about the problem
with making fake marines pause long enough to make it look like they had
to switch weapons without making them look stupid. Of course, there are a
LOT of things that you can't overcome with fake marines that give them away:
1. They wander aimlessly
2. They don't run out of ammo
3. They can't throw switches or trip lindefs (although they CAN open certain
kinds of doors (DR?), and I think it depends on how fast they are.
4. And, of course, the going over cliffs thing (more later).
> I haven't done any editing on the durations for the regular walking
> frames for anybody, but I have the impression that this would just make
> the frames move really fast. In other words, the monster always moves at
> the speed defined by the speed bit, and the durations for the movement
> frames are just there so the PICTURE of the monster walking is going at a
> realistic speed (isn't swinging it's arms and legs too rapidly.)
No, actually. If you make the duration shorter, the monster WILL move
faster (and track you better and attack more often). To remedy
the "fast-motion" look of the sprites, you need more frames for the
movement phase. So instead of, say, 4 frames with a duration of 3 each,
use 12 frames with a duration of 1 each. The extra frames don't NEED to
be movement code pointers, they don't have to have ANY code pointer (or put
something in there of your own). But if only every 3rd frame has the movement
code pointer, you'll get the same tracking ability and attack frequency as
the 4frame 3duration setup (which may be desirable), but you would still get
the speed increase.
> Unfortunately, wrong - unless you want marines INSTANTLY falling to the
> ground as they walk off platforms, you absolutely need to set the
> floating bit. What the floating bit does is cause the marine to drift to
> the ground. Otherwise you get a "teleportation" sort of action as the
> fake marine switches its altitude immediately when it enters a new sector.
> Of course, you're right - it does fix the problem of marines walking into
> walls, thinking they could fly over, but again, not realistic to have
> them falling like that.
EEP! Gene is absolutely right here. I had noticed that the monsters in
my patch that could go over cliffs would drop instantly, looking a bit awkward.
I had nopticed that when they die and fall off a cliff, they "fall" down,
though. Anyway, I thought there was no way around this, but Gene has found
a way. Unfortunately, what he said about the monsters not going around
objects that have any "air" gap between the cieling and floor is also
absolutely true. (Like Gene said, the idiots think they can fly!) So they
just walk into the wall until you show up. I tried the "slides along walls"
bit, but like Greg said, it's useless. So I had to take that "floating"
bit off. It looked nice, but played bad. One consolation, though... I
have a few monsters that I turned "semi-no-clipping" on for, and it looks
nice with them (they go OVER areas with gaps without actually flying).
I just had another idea that may go well with the DeathVision thing I
mentioned before- A gun that shoot health potions! This way you could store
up health you find, and shoot out some when you need it! Here's how it would
be done:
1. Make one of the player's projectiles a health potion or stimpack or what
have you (in image only- use the proper sprite with a -1 duration, or a long
enough one to pick it up- be sure to make the death frame the same frame).
2. Set the projectile to be gettable.
3. Set the speed to something like 3 and turn off the "no gravity" bit. This
will have the effect of making the health kinda "drop" onto the floor in
front of you. Make sure the missile damage is 0.
4. Make the ammo for that weapon look like some sort of health kit.
An alternate way to do this is to leave "projectiles" off and make the
speed 0, and leave the no gravity on. This way, the health couldn't leave
your body and you would just see your health rise as you "fire" the weapon.
I think you would have to move while doing this, though, or they'll just stock-
pile up and you'll pick them, all up when you do move. I suggest using the
health potion for this effect (either variation) since you can continue to
pick them up even if you are at full health, plus you can get up to 200% with
them (or whatever you set the max health to). If you use stimpacks or medikits
you can only get up to 100%, and after that, if you shoot 150 of them, they'll
just sit there (unless you give them a duration like 20 or so) and slow the
game to a crawl.
Mike Gummelt
------------------------------
End of doom-editing-digest V1 #517
**********************************
