Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 516
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #516
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Friday, 15 December 1995 Volume 01 : Number 516
Re: WadAuthor v1.11
Re: DHE q's
Re: Yet another dehacked question...
Re: add sprites
SCRIPT lump (was WadAuthor v1.11)
RE: add sprites
Re: Hexen scripts - ???
Re: Sprites Replacements in HeXen: DeuSF 3.8 available
[none]
Re: Hexen scripts - ???
Re: WAD cut & paste (was Re: WadAuthor v1.11)
Re: Sprites Replacements in HeXen: DeuSF 3.8 available
Re: WAD cut & paste (was Re: WadAuthor v1.11)
RE: add sprites
RE: SCRIPT lump (was WadAuthor v1.11)
ExMxINFO or MAPxxINF lumps (was SCRIPT lump (was WadAuthor v1.11))
Re: SCRIPT lump (was WadAuthor v1.11)
----------------------------------------------------------------------
From: bmorris@islandnet.com (Ben Morris)
Date: Wed, 13 Dec 95 17:22 PST
Subject: Re: WadAuthor v1.11
> >welll - when dos turns into a multitasking system of any kind, i'm sure
> >we'll update the dos editors to take advantage of its new DDE features ;)
>
> It already has. It's called Windows 95. Check it out.
huh, huh, huh.
shoulda seen that one a mile away!
;)
- -/-
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: Greg Lewis <gregl@umich.edu>
Date: Wed, 13 Dec 1995 21:16:01 -0500 (EST)
Subject: Re: DHE q's
> From: Pandion-Knight <s337239@student.uq.edu.au>
>
> Yeah hi all.. i've been working on a deh patch that turns various
> monsters into marines, complete with sound and all..
The big problem with using DHE v2.2 is that that version doesn't come
with the monster -> marine patch that I've already made. :) Get DHE
v3.0a and check out DMARMY3.DEH, which sounds like exactly the same thing
that you are trying to create. v3.0a is also cool for editing the code
pointers, which you will probably have to do.
> 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...
Nope, can't be done (as far as I know). I tried, I really did. :)
> 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 *think* DMARMY3.DEH does this. I wasn't able to test it for too
long, but every time I went near one of the Barons and they fired a BFG, I
got hit by the line-of-sight view (not the ball itself). Someone can
verify this for me if they want.
> 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.. :)
I've got the whole works... punch, pistol, shotgun, (fake) DB shotgun,
chaingun, rockets, plasma, and BFG. No chainsaw or true DB shotgun is
present.
Limitations: It is not really possible to simulate the reload time of
the player's weapons without making the monsters look really stupid. So
they fire too quickly sometimes. Also, the monster AI is still monster
AI, so they sort of wander around (quickly) in random directions... which
is a dead giveaway that they are not players.
Still, it is hellish fun to play in deathmatch. :)
> ------------------------------
> From: gummelt@pegasus.montclair.edu (Michael Gummelt)
>
> 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 ? ...
Greg
------------------------------
From: Michael Gummelt <gummelt@pegasus.montclair.edu>
Date: Thu, 14 Dec 1995 01:37:44 -0500 (EST)
Subject: Re: Yet another dehacked question...
I am posting this to hopefully clear up some confusing mixed
up and conflicting advice concerning turning monsters into
marines.
First, let me say anyone attempting this may want to check
out DEHARMY3.deh by Greg Lewis (right?) THE DeHackEr himself.
It's very good. Also, the Flamer patch is quite nice.
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.
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
(in theory0 i haven't tried this) by changing the archvile
flame into a BFG Hit and have the BFG shot fire one when it "dies".
The only adverse side effect is that the BFG shot will ALWAYS
hit you, even if you are not in the monster's line of sight at the
time of impact (the BFG shot is NOT an area-effect blast, it
creates a BGH Hit on anyhting shootable in the monster's
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,
and would be fun for another player to try to find your GODSPHERE,
deactivate it (by shooting it), then take it for himself! (this is
done in Doom I by making the thing gettable, make the regular
sprites the MEGA sprites, and the death frames use the (for
example) CELL sprites- this way you can only pick it up when
it's deactivated and it can be re-used). Okay, I've killed this
particular line of speculation, on to the next.
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).
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,
especially if you have 24 different fake marines (6 of each color)
each with a slightly different combination of movement and attacks
as well as health and speed! Another thing to consider (while
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.
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.
The main problem with making monsters look like marines is one Greg
Lewis just said in a recent post: no matter what you do, the
monsters still hunt you down in that kind of "wandering aimlessly"
method that they do, a dead giveaway. Maybe you couldincrease the
number of movement frames and decrease the duration to 1 each, but
even then, I don't think they would be that much better (and that
would eat up a LOT of frames!). Aside from that limitation, though,
there are TONS of possibilities (thanks to Greg- DeHackEd is the
most powerful Doom editing tool ever!)
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!
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!
Mike Gummelt
Aliens Doom 3: Aliens vs Predator maker, formally had a life.
------------------------------
From: Raphael.Quinet@eed.ericsson.se
Date: Thu, 14 Dec 1995 09:26:12 +0100 (MET)
Subject: Re: add sprites
Edwin Razafi <edwin@worldnet.net> wrote:
> what is the best way to add sprites:
> -a pwad with all the sprites.
> -a .bat which change sprites in doom2 and restore the originale at the end.
> Tell me (i have wintex).
The best way to add sprites is to have a PWAD with all the sprites, _but_ you
are not allowed to distribute such a WAD because it will contain id Software's
artwork (the sprites that you didn't modify).
The only legal way to do it is to distribute a WAD which contains only your
sprites and include DeuSF in the same package, as well as a batch file which
appends all missing sprites to your WAD. There is no other choice (well, of
course you could use NWT instead of DeuSF, but that's not the point here).
- -Raphael
------------------------------
From: Olivier <montanuy@lsun80.lannion.cnet.fr>
Date: 14 Dec 95 10:53:44+0100
Subject: SCRIPT lump (was WadAuthor v1.11)
>While I'm on the subject, Oliver (sp?) suggested that editor authors embed
Spelling is bad :)
>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).
> 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
Oli
------------------------------
From: Olivier <montanuy@lsun80.lannion.cnet.fr>
Date: 14 Dec 95 11:26:07+0100
Subject: RE: add sprites
>what is the best way to add sprites:
> -a pwad with all the sprites.
No, it's illegal and much too big! 6 meg in HEXEN!!!
>-a .bat which change sprites in doom2 and restore the originale at the end.
you mean deusf -merge sprite.wad?
it's the fastest way, and is secure provided you have enough disk space.
The way proposed in WinTex 4.1 beta is to generate a .bat file to
append all the sprites at the end of the PWAD.
This is very long and takes a lot of disk space, but at least it doesn't
modify the IWAD.
I'm still looking for a better method, but there seems to be none.
Even HEXEN cannot handle PWAD with S_END at the end of a partial sprite list.
(This would be the ideal solution, as demonstrated by GRENADE2.WAD and others)
>Tell me (i have wintex).
Use only WinTex 4.1 beta and DeuSF 3.8 (included).
the other versions have a minor bug that could cause trouble if you have
wall patches in your WAD.
Oli
------------------------------
From: Drsleep00@AOL.COM
Date: Thu, 14 Dec 1995 05:16:31 -0500
Subject: Re: Hexen scripts - ???
In a message dated 95-12-12 22:23:59 EST, you write:
>I've created two new almost identical scripts for a level I'm working
>on. ACC gives me no errors after compilation, but when I play the game,
>nothing happens. I've come up with two possible reasons: 1) Heth doesn't
>support new scripts or does not save them correctly or 2) Hexen does not
>allow new scripts.
John --
HETH allows insertion of compiled scripts into the BEHAVIOR directory. This
has been a standard and stable feature of HETH since v1.00. You must save
your compiled script with a .RAW extension, and give it a prefix of at least
six letters: eg, SCRIPT.RAW.
The steps are:
Start HETH
r WADNAME.WAD
i SCRIPT.RAW BEHAVIOR
r BEHAVIOR.WAD
g OUTPUT.WAD
This will insert your script into a BEHAVIOR.WAD, <r>ead in the BEHAVIOR.WAD,
and then <g>roup your BEHAVIOR.WAD with your WADNAME.WAD into a single
OUTPUT.WAD. The names of the output.wad are otpional, of course.
Haven't had any complaints so far<g>.
- - John
- --------------------------------------
John W. Anderson
dr_sleep@cis.compuserve.com
------------------------------
From: Denis <d.moeller@rendsburg.netsurf.de>
Date: Thu, 14 Dec 1995 12:06:49 +0100
Subject: Re: Sprites Replacements in HeXen: DeuSF 3.8 available
Hi!
> Sprite replacement still doesn't if you use S_END (you would need to
> modify the sprite names in hexen.exe, and there's not dehacked for it yet).
> So the only option is to use DeuSF or NWT (I didn't test NWT), and it
> still waste a lost of disk space.
I dunno. I never tried NWT with Hexen - I can imagine that it will suck
big time. Besides this, I wonder why they didn't use the texture-stuff
as much as in Doom or Doom 2 - there are no textures with more than 4 patches...
> No previous DeuSF version will work on HeXen, because of misc bugs that
> I had to fix, and because of an old limitation in the size of the directory.
> (The WAD directory of HeXen is now more than 64k).
This one wasn't funny at all. Thanks Raven & id! ;)
> Note that DeuTex won't be updated to work with HeXen, it's too complicated.
I'm working on NWT Pro...again...
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.geopages.com/Hollywood/2299/ []
------------------------------
From: "David A.R. Wallace" <dwallace@ccs.neu.edu>
Date: Thu, 14 Dec 1995 11:30:11 -0500 (EST)
Subject: [none]
info doom-editing
------------------------------
From: "J. Kugelman" <kugelman@mnsinc.com>
Date: Thu, 14 Dec 95 12:04:41 PST
Subject: Re: Hexen scripts - ???
>> You must save your compiled script with a .RAW extension,
>> and give it a prefix of at least six letters: eg, SCRIPT.RAW.
I'll try this, but why 6 characters min? Mine was 5,
so I guess that was the problem. But NWT has been doing
it fine, too. Now I can get my scripts working, but I
can't seem to make a proper switch. It looks to me that
all of the switches in Hexen run with scripts, fine. But
when I make one (with SW_OL1, a bit different), I have
to do some pretty wierd things to get them working. I
tried to copy map05, by using a type of Script I.D. (121)
instead of Run Script (90). But nothing happens. I'm
trying to get a switch working, like Raven's, and that
don't make the player grunt, which is kinda wierd.
------------------------------
From: us018032@interramp.com
Date: Thu, 14 Dec 1995 11:47:34 -0500
Subject: Re: WAD cut & paste (was Re: WadAuthor v1.11)
>Err... I should have explained this in a better way. DEU 6.0 will hopefully
>be available on several platforms at the same time: DOS, Windows, OS/2, UNIX
>and Mac (many people are waiting for MacDEU). What I meant is that DEU 6.0
>should be able to convert its internal data into a format that can be stored
>in the native clipboard of each system (e.g. the Windows clipboard when DEU
>runs under Windows).
That's really great. I wish the Microsoft cross-platform pack for Visual
C++ wasn't so blasted expensive ($2000 last time I checked). If it didn't
cost so darned much, I'd be able to offer WadAuthor on the Mac.
>Good point. I forgot to explain that situation. If you cut sector 'b', the
>only thing that your editor has to know is that 'b' was included in another
>sector, but the actual reference to 'a' is not needed. I used a simple
>solution which doesn't break the WAD format: I replace all references to
>sector 'a' with -1. Note: these are the sector references in the sidedefs,
>not the sidedef references in the linedefs (i.e. the sidedefs are still there).
Isn't this a problem with one-sided linedefs? As I understand it, a
one-sided linedef's "other" sidedef should have a sector reference of -1.
Doesn't this conflict with your method?
>If you paste this structure into an existing sector, all references to sector
>-1 will be replaced by the new sector number. For example, if you put the
>object back into sector 'a', all references will be restored.
>
>If you paste it outside the map (outside any existing sector), the sidedefs
>which have a reference to sector -1 will be deleted. As a result, you will
>get a new sector containing only what was inside 'b' and everything will be
>correct.
This is basically what my format is doing. I mark a linedef for sector
resolution and then do the fixup when pasted. The other primary reason I'm
using a custom format is to best support the Windows clipboard. It's a
little known fact (and one not guarenteed for future releases), but by using
the clipboard viewer, one can save templates for pasting into WadAuthor maps.
I intend to provide this ability as a direct feature in future versions of
WadAuthor if I get the time. I think it would be a really neat way to speed
up wad creation.
>> Can DEU paste Hexen architecture into a DOOM map or vice versa?
>
>Not for the moment. This is still on my "to do" list... Alas. :-/
I haven't found any good way to map the linedef types to specials and vice
versa, nor have I found a good way to map things. I'll grant that
WadAuthor's support for complete conversion is pretty poor, but the general
architecture does come across quite well.
>Well, the discussion with Jason about template files stopped before we could
>get all details right, because neither of us had actually implemented the
>templates functions at that time. Basically, these template files are
>standard WAD files with one or two changes: some sidedefs can have a reference
>to sector -1 in order to be able to paste the object into an existing sector,
>and the floor or ceiling height of some sectors can be negative (for relative
>heights). The details on which we didn't agree are about the sector heights:
>when should they be relative to the floor or ceiling of the external sector?
I've been doing sector floor, ceiling, and lighting values as strings to
allow for three different modes of operation. Let me provide an example:
Ceiling height string What it means
- --------------------- -------------
+10 Absolute: ceiling is at an altitude of 10
++10 Offset: ceiling is 10 units above what
it used to be.
+++10 Relative: ceiling is 10 units above the
floor.
I haven't added support for clipboard use of these yet, but when I add the
whole templates idea, it should go a long way toward allowing complex
architectural features to be described in an economical format. Perhaps if
I get this working I will make the source code for reading/writing public.
Please make an announcement when you've got the template stuff working in
your editor. If we work together on this, I can make very sure that
WadAuthor correctly reads/writes your format. Thanks in advance.
John
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Thu, 14 Dec 1995 09:49:56 EST
Subject: Re: Sprites Replacements in HeXen: DeuSF 3.8 available
Olivier <montanuy@lsun80.lannion.cnet.fr> ,in message <9512131734.042C1C@lat119
2.lannion.cnet.fr>, wrote:
> No previous DeuSF version will work on HeXen, because of misc bugs that
> I had to fix, and because of an old limitation in the size of the directory.
> (The WAD directory of HeXen is now more than 64k).
Hoo boy, is it large. PFME had a ScrolledList widget for the sprite
viewing window. There were so many entries that the subwindow exceeded 32K
pixels in height, resulting in some mighty strange behavior.
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Thu, 14 Dec 1995 10:51:12 EST
Subject: Re: WAD cut & paste (was Re: WadAuthor v1.11)
us018032@interramp.com ,in message <199512131833.NAA28482@smtp2.interramp.com>,
wrote:
> Hmm.. Ok, let me provide an example. Consider the following ASCII art:
>
> +-----------+
> | a |
> | +---+ |
> | | b | |
> | +---+ |
> | |
> +-----------+
>
> What I have tried to depict is a sector 'a' having a smaller sub-sector 'b'.
> If the linedefs of 'b' are all two sided, then they reference the sector
> number for sector 'a'. How do you handle it if the user copies sector 'b'
> to the clipboard, then pastes into an un-populated section of the map? How
> about pasting into a different sector? What if the user creates a new empty
> map and pastes into that?
I will excerpt from the PFME manual:
``
Sectors: Cutting sectors stores a copy of all target sector
information with all associated sidedefs, linedefs and vertices. When
pasted new sectors are created in the target mission with the
attributes from the sectors in the cut buffer.
''
Since this isn't crystal clear, here's the code. Basically, you grab all
sidedefs that refer to the sector you're cutting, grab all supporting
linedefs (but don't include extra sidedefs), and then grab all supporting
vertices
code:
[snip: lots of luscious lines of code chopped by list admin. Sorry. It's
not that I have a natural aversion to C (I do) just that I think there's a
bit much of it for the list. I'm sure RF will be delighted to forward
copies of the code to anyone who asks *him* (not the list) nicely ;)
Sorry, Bob. And no, I dunno why all your mails to DOOM-editing are bouncing
either! -Steve]
------------------------------
From: Jacob Roberto <jroberto@on-ramp.ior.com>
Date: Wed, 13 Dec 1995 20:01:57 -0800
Subject: RE: add sprites
>what is the best way to add sprites:
> -a pwad with all the sprites.
Not many people would download a WAD that big and it would be illegal to =
distribute Id's sprites. [This would be the best if you don't plan to =
distribute your WAD.]
> -a .bat which change sprites in doom2 and restore the originale at the =
end.
That would suck.
>Tell me (i have wintex).
Distrubute your WAD with DeuSF and an .bat that calls DeuSF (I forget =
the syntax.)
------------------------------
From: MIKE <e5rs010@boe00.minc.umd.edu>
Date: Thu, 14 Dec 1995 08:22:21 EST
Subject: RE: SCRIPT lump (was WadAuthor v1.11)
how do I unsuscribe to this?
mike
------------------------------
From: Raphael.Quinet@eed.ericsson.se
Date: Thu, 14 Dec 1995 12:25:37 +0100 (MET)
Subject: ExMxINFO or MAPxxINF lumps (was SCRIPT lump (was WadAuthor v1.11))
Olivier <montanuy@lsun80.lannion.cnet.fr> wrote:
> > 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
Some time ago, I proposed to use ExMyINFO and MAPxxINF for storing
additional info, like the type of game for which a level was designed,
the name of the level, the address of the author(s), and so on.
It would be nice if all editors could support something like this.
Even if an editor is not able to parse or display the MAPxxINF entry,
it should at least save it with the level, like if it was a part of it
(THINGS, VERTEXES, LINEDEFS,...). The editor should also take care of
renaming the entry if a map is moved to another level. For example, if
the map moves from E1M3 to E4M2, the E1M3INFO field should be renamed
E4M2INFO. This will ensure that the ***INFO entry is always associated
with the right map, and will also allow you to have one entry for each
level in a multi-level WAD (which would not be possible if the entry
was simply called MAPINFO).
- -Raphael
------------------------------
From: "Luc Cluitmans" <L.J.M.Cluitmans@ele.tue.nl>
Date: Thu, 14 Dec 1995 13:26:51 MET-2DST
Subject: Re: SCRIPT lump (was WadAuthor v1.11)
> >While I'm on the subject, Oliver (sp?) suggested that editor authors embed
> Spelling is bad :)
> With the DEACC decompiler by Luc Cluitman, embeded in both Wad Author and
Spelling is bad Too :-).
> WinTex, those behavior just look like text!
> The only thing you lose is the names of variables (which might be a pain).
Of course DEACC is good in decompiling hexen scripts (that is what it
is for). Be aware however that it is possible to create scripts that
will not be decompiled correctly by DEACC (but this will be rare).
> > 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
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'.
Luc
------------------------------
End of doom-editing-digest V1 #516
**********************************
