Yadex 1.0.1 (1999-01-02)
Warning : this document is unfinished, ill-structured and incomplete.Contents :
More specifically, Yadex expects that
ctype.h accept the range
CHAR_MIN through UCHAR_MAX,
nanosleep() system call is supported.
/usr/local/bin
/usr/local/etc
/usr/local/share/games/
What's more, as PseudoColor displays typically have 256 colours (at least on PC), which is less than the number of colours needed, Yadex might have to assign the same physical colour to different logical colours. If it happens, it will try to render the colours of the game accurately at the expense of the application colours.
Monochrome displays might work but they have not been tested.
Executive summary: if you can, use a TrueColor
or DirectColor display and a depth of more
than 8 bits per pixel (E.G. by launching X
with "startx -- -bpp 16").
A 640x480 screen is okay though, of course, a larger display is better.
README.
Don't forget to tell Yadex where your iwads are
by changing the lines "iwad1 =",
"iwad2 =" and "iwad3 ="
in /usr/local/etc/yadex.cfg.
If there is an iwad you don't have, you can just
comment out the corresponding line.
For the sake of discussion, we'll assume you want to edit MAP01 of Doom II. From the shell, type :
$ yadex -g doom2
(of course, you don't have to type the "$" !)
You should see a couple of messages
and then the Yadex prompt, which looks like this :
[? for help]
At this prompt, type :
[? for help] e map01
(once again, don't type the "[? for help]" !)
The editor window opens.
On top of the window, there is the menu bar. I assume you know what a menu bar is. On bottom of the window, there is the info bar. It displays some information about your current status : the name of the level you're editing, whether it has changed since last saved, in which editing mode you are, etc.
Try to move the pointer around. Note that the info bar shows the position of the pointer in map coordinates.
If you move near the edge of the window, or press [Left], [Right], [Up], [Down], [Home], [End], [Page-up] or [Page-down], the map scrolls.
You can also zoom in and out by pressing [+] and [-].
What if you want to change the properties of a thing ? Double-click on it or highlight it and press [Return]. A menu pops up in the top left corner of the window. Select the property you want to change and yet another window pops up. Enter the new value of the property and that's it.
You can drag things around ; click on the thing and, without releasing the button, move the pointer to where you want to move it to and then release the button. If you want to move a group of things, select them all, and drag one of them. All selected things follow.
To select several things, you can either hold [Ctrl] down and click on each of them in turn or select them all at once with a selection box. To do that, click on an empty spot and, without releasing the button, move the pointer to where you want the other corner of the box to be. Then release the button ; all the things within the box are selected.
Note that when you start a selection box, everything else is unselected. If you don't want that to happen, hold [Ctrl] down while you draw the box. Thus you can add the contents of the new box to the selection.
You can also create a new thing under the pointer by pressing [Ins]. If, at the moment you press [Ins], there is a thing highlighted, the new thing will be created with the same properties as its "model". Else, it will have the default properties as defined in the Preferences.
The other modes work like the things mode except that you operate on different types of objects.
I want you to save the modified level to a pwad
named mywad.wad so that you can test
it with Doom.
To do that, press [F2].
Don't worry, it will not overwrite your iwad.
Individual levels are always saved to a pwad.
You are prompted for a file name.
Enter mywad.wad.
Before when go on, here a few things worth mentioning :
.wad extension is not
automatically appended.
In addition, if you used to be a DOS/Windows user,
remember that Unix treats file names case-sensitively
so you'd better think twice before using names like FOO.WAD.
.wad file is changed,
a backup is made in the same directory and with the same name
but with the extension .bak.
Now press [Esc].
The editing window closes and
you are returned to the Yadex prompt.
From there, use the "e" or "c" commands
to edit another level
or use the "q" command to really quit Yadex.
There are several nodes builders around. One of the best is BSP 2.3. Lee Killough kindly allowed me to include it with the Yadex distribution. To build the nodes on your level with BSP and then test it with Doom, type something along the lines of :
$ bsp mywad.wad -o final.wad $ doom -file final.wad
.wad extension). E.G. :
$ yadex -g doom2 mywad
That's it ! You've been through an entire edit-build-test-edit cycle. Doubtlessly the first of thousands :-).
-".
Some options take an argument.
The argument must be separated from the option by some whitespace.
Constructs like "-othingy" are not recognized.
You have to type "-o thingy".
The "-file" option takes a variable number
of arguments. It uses all the non-options up to the next option.
The options that take no argument can be negated by using
a "+" instead of a "-".
For example, "+sb" will undo the effect
of a "swap_buttons = true" directive in the config file.
In general, if you specify the same option more than once,
the last occurrence overrides the previous ones.
For example, "yadex +P -P"
is equivalent to "yadex -P".
Similarly, "yadex -i1 foo.wad -i1 bar.wad -i1 baz.wad"
boils down to "yadex -i1 baz.wad".
The "-pwad" (or "-pw") option,
however are additive.
Each occurrence will add to the previous ones.
For instance, "yadex -pwad foo.wad -pwad bar.wad"
is equivalent to "yadex foo.wad bar.wad".
Any command line argument that is not an option is treated as the name of a pwad to load. You can put as many names of pwads on the command line as you wish (or none at all). The details of specifying pwad names are discussed there.
$ yadex -help
You'll get this:
-f -config_file string Config file -d -debug Debug mode -e -expert Expert mode -fc -fake_cursor Fake cursor -fn -font string Font name -g -game string Game -h -height integer Initial window height -? -help Show usage summary -i1 -iwad1 string The name of Doom IWAD -i2 -iwad2 string The name of the Doom II IWAD -i3 -iwad3 string The name of the Heretic IWAD -pw -pwad string Patch WAD file -P -no_pixmap No pixmap, saves memory, more flicker -q -quiet Quiet mode -qq -quieter Quieter mode -s0 -select0 Automatic selection of 0th object -sb -swap_buttons Swap mouse buttons -td -text_dot DrawScreenText debug flag -v -verbose Verbose mode -w -width integer Initial window width -z -zoom integer Initial zoom factorYou might wonder what the "
-file",
"-pw" and "-pwad" options are for
since it's so simple to just put the names of the pwads
on the command line. The answer is that they're only here
for compatibility with previous versions of Yadex/Yade/DEU.
Don't use them. They might go away one day.
By default, the game used is the one specified by the
"game=" directive in the configuration file.
If you want to override the default, use "-g game".
r command,
or as a command line argument,
you don't always have to spell it all out.
.wad extension can be omitted,
it will be added automatically.
For example, specifying the name "foo"
is equivalent to specifying "foo.wad".
An unfortunate consequence of this convention is
that it's impossible to load a wad that would be
really called "foo".
Though, under DOS, you can still work around this limitation
by specifying the name with a trailing dot,
("foo.").
/usr/local/share/games/game,
/usr/share/games/game,
/usr/local/share/games/wads,
/usr/share/games/wads,
On the other hand, if you give an absolute file name,
that is one that begins with a "/",
the standard directories will not be used.
Yadex will only try to open the file
of the exact name you specified.
For example, if you type "yadex -g doom2 foo/bar",
Yadex will look for the following files in order :
~/foo/bar.wad,
/usr/local/share/games/doom2/foo/bar.wad,
/usr/share/games/doom2/foo/bar.wad,
/usr/local/share/games/wads/foo/bar.wad,
/usr/share/games/wads/foo/bar.wad,
But if you type "yadex -g doom2 /foo/bar"
(note the leading slash),
Yadex will try to open "/foo/bar.wad", period.
The philosophy behind those standard directories is that :
Gotcha: those shorthands can only be used when reading a pwad. When writing to a pwad, you always have to specify the exact name, with the full path and extension.
DISPLAY
YADEX_GAME
game parameter in the config file,
is overridden by the -g command line option.
Flats should be placed between FF_START and F_END.
The pwads produced by Deutex are fine
except that they have an FF_END marker after the flats.
You can make them usable by Yadex and Doom
by replacing FF_END by F_END
with a binary editor.
You don't need Deusf.
Replacing other resources may or may not work.
PLAYPAL very probably does,
sprites probably don't.
.yl,
that file will be used to keep track
of the time you spent editing that level.
At the end of the editing session,
Yadex will append a line to the .yl file
with the name of the level and the number of minutes spent on it.
Note that if the .yl file does not already exist,
it is not created.
This is to prevent the creation of a large number of small
useless files when browsing through a collection of wads.
Thus, if you want to enable logging,
you need to manually create the log file first
with a command such as "touch name.yl".
?" at the Yadex prompt.
scroll_less in the
configuration file.
[Page-up], [Page-down],
[Home] and [End] scroll more
at a time, by default 90% of the screen/window width
or height. You can change the exact amount by setting
the variable scroll_more in the
configuration file.
You can fine tune autoscrolling by changing the
variables autoscroll_amp and
autoscroll_edge.
Autoscrolling is disabled near the menu bar items so that the map does not scroll when you're reaching for the menu.
You can disable autoscrolling completely by setting
autoscroll to false in
the configuration file.
vi,
with mmark-name, 'mark-name
and `mark-name.
For the moment, if you press ['], the map scrolls so that its centre is at the centre of the screen/window.
If you press [`], the map scrolls so that its centre is at the centre of the screen/window and the zoom factor is adjusted so that the whole map is visible and almost fills the screen/window.
Scale:".
It is shown in pixels per map units.
The indication "Scale: 1/2"
means that one pixel of the display
corresponds to 2 map units.
You can zoom in by pressing [+] or [=] or the 4th mouse button or by moving the mouse wheel "up".
You can zoom out by pressing [-] or [_] or the 5th mouse button or by moving the mouse wheel "down".
You can also set the zoom factor directly with the keys [0] through [9].
When you insert or drag objects, they are snapped to grid.
That is Yadex prevents you from placing them off the grid.
You can toggle the snap_to_grid flag by pressing [y].
The grid step is always a power of 2, E.G. 128, 64, 32, etc.
You can get a finer grid (dividing the grid step by 2)
by pressing [g].
Conversely, pressing [G] multiplies the grid step by 2.
If you press [g] when the grid step is already at
its minimum value, it will be set to its maximum value.
And conversely.
The minimum and maximum values are set in the configuration
file with grid_min and grid_max.
When you change the zoom factor, Yadex automatically changes the grid step to make it what it thinks is best for the new zoom factor. If you want to lock the grid step to its current value, press [z]. To unlock it, press that key again.
You can hide the grid by pressing [h]
(but this doesn't disable snap_to_grid).
Press that key again to make the grid visible again.
You can also use [H] to reset the grid step.
If an object of the same type is highlighted at the moment you press [Ins], the properties of the new object are copied from the highlighted object. In other words, the highlighted object serves as a "model". Else the properties of the new object are set to default values.
| Object type | Property | Value if there is a model | Value if there is no model |
|---|---|---|---|
| Linedef | Start vertex | Like the model | If there are two selected vertices, the first. If not, you are prompted for a vertex number. |
| End vertex | Like the model | If there are two selected vertices, the second. If not, you are prompted for a vertex number. | |
| Flags | Like the model | Impassable | |
| Type | Like the model | 0 (normal) | |
| Sector tag | Like the model | 0 (none) | |
| First sidedef | FFFFh (none) | FFFFh (none) | |
| Second sidedef | FFFFh (none) | FFFFh (none) | |
| Thing | Coordinates | Like the pointer | Like the pointer |
| Type | Like the model | default_thing
| |
| Flags | Like the model | D12 D3 D45 | |
| Angle | Like the model | 0 (east) | |
| Sector | Floor height | Like the model | default_floor_height
|
| Ceiling height | Like the model | default_ceiling_height
| |
| Floor texture | Like the model | default_floor_texture
| |
| Ceiling texture | Like the model | default_ceiling_texture
| |
| Light level | Like the model | default_light_level
| |
| Type | Like the model | 0 (normal) | |
| Tag | Like the model | 0 (none) | |
| Vertex | Coordinates | Like the pointer | Like the pointer |
This can be useful in certain occasions, such as when you want to compare two sectors that have other sectors between them.
The key [x] is a shortcut to this function.
The new linedef goes from the first selected linedef to the second selected linedef. The new sector is on the second sidedef of the new linedef.
There is a bug in this function ; if the sector contains other sectors, some sidedefs are given the wrong sector number. Jim Flynn has recently fixed this in DETH.
The key [w] is a shortcut to this function.
It sets the I flag, clears the 2 flag and sets the second sidedef to -1.
If the linedef is not long enough, the length of the nook is one third of the length of the linedef.
Here is how it works : all sidedefs that are used on the first side of any linedef in the selection and on any side of any linedef not in the selection are duplicated and the first side of the concerned linedefs in the selection is set to use the copy instead of the original.
Gotcha : note that the selected linedefs are not "unlinked" from each other. They are only "unlinked" from any other (i.e. non-selected) linedefs. Thus, if you have n linedefs that you want to unlink from each other, you have to unlink every one of them separately. This is so that, if you have, say, two square pillars (2 x 4 linedefs that all use the same sidedef), you can easily unlink one pillar from the other while still having its 4 linedefs all use the same sidedef.
The choices made in the Preferences menu override all others but they are lost when you exit Yadex.
The command line options override the environment variables which in turn override the configuration file.
The details of command line options and environment variables are explained elsewhere.
The settings entered through the Preferences menu are lost when you exit Yadex.
-f" on the command line,
Yadex tries to open the following files in order :
./yadex.cfg
~/yadex.cfg
install_dir/yadex.cfg
/usr/local/etc/yadex.cfg
/etc/yadex.cfg
The first file found is used.
If you use "-f file"
and "file" is an absolute name
(i.e. it starts with "/"), only that name is used.
If "file" is a relative name,
the standard directories will be searched for a file of that name
instead of "yadex.cfg".
For example, if you specify "-f foo/bar",
Yadex will try to open
"./foo/bar", "~/foo/bar", and so on.
The first line of the configuration file must contain exactly the following string :
"# Yadex configuration file version 2"
If it doesn't, Yadex will print an error message and bail out. The reason for being so fussy is to avoid headaches when the configuration file format changes and there are old configuration files lying around in your directories.
The configuration file is self-documenting. Look at the sample configuration file in the Yadex distribution to see what options are available.
-g foo,
it in fact means that Yadex should use the game definition file
named "foo.ygd".
As of this release three games are supported :
"doom", "doom2" and "heretic"
(though, as I'm not familiar with Heretic editing,
heretic.ygd might contain errors and omissions).
To open the game definition file, Yadex tries those names in order :
./game.ygd
~/game.ygd
install_dir/game.ygd
/usr/local/share/games/game.ygd
/usr/share/games/game.ygd
"# Yadex game definition file version 1"
If it doesn't, Yadex will print an error message and bail out. The reason for being so fussy is to avoid headaches when the game definition file format changes and there are old game definition files lying around in your directories.
The contents are pretty self explanatory.
fixed" a.k.a. "6x13").
But you can use the font of your choice by
using the "-fn font_name" option
or setting "font = font_name"
in yadex.cfg.
You should use a fixed-width font
and not one that is too large for the size of your Yadex window
or the display will look ugly.
You can get a list of all available fonts on your system
with the command xlsfonts.
TODO for a complete list
of things to fix.
Yadex is derived from DEU 5.21. So if you're used to DEU 5.21, you might find this list useful.
1. SIGNIFICANT CHANGES
[v1.6]".
heretic.ygd".
SWITCHES and ANIMATED
Here are the credits from the DEU 5.21 documentation :
* Everybody at id Software for making such great games!
* Brendon Wyber (b.wyber@csc.canterbury.ac.nz)
The first version of this program was written by Brendon Wyber.
Map display, Things editor.
* Raphaël Quinet (quinet@montefiore.ulg.ac.be)
Much of this program was written by Raphaël Quinet.
New interface (mouse, menus, etc).
Ability to edit Vertices, Linedefs, Sidedefs, Sectors, and last
but certainly not least an AUTOMATIC NODES BUILDER.
Even if I rewrote nearly 90% of the code, this editor still has its
strong DEU roots... :-)
* Matt Fell (matt.burnett@acebbs.com)
Author of the great Unofficial Doom Specs. Making this program
would have been impossible if the Specs didn't exist.
* Steve Bareman (bareman@hope.cit.hope.edu)
Rewrote the documentation (this file and DEU.TXT)
Author of the DEU tutorial (look in the TUTOR directory).
Constant promoter of including source code with the editor.
For a good FTP...
anonymous @ hope.cit.hope.edu (198.110.98.2)
(Registered DOOM patches, DEU, and various doom utils for
Registered DOOMers only.)
* Trevor Phillips (rphillip@cc.curtin.edu.au)
Textures viewer in 256 colors
Many, many suggestions and improvements to the DEU code.
* Alistair Brown (A.D.Brown@bradford.ac.uk)
* Chris Phillips (chrisp@halcyon.com)
* Colin Reed (colin@argonaut.co.uk)
* Dylan Cuthbert (dyl@cix.compulink.co.uk)
Lots of infos about the Nodes objects.
They fixed the bug(s) in my Nodes builder.
Looking for cute Doom add-ons? Get BSP and ZAMBONY!
* Dewi Morgan (D.Morgan@bradford.ac.uk)
Drop-down menus and menu bar.
Rewrote and reorganized part of this file.
Numerous improvements and suggestions.
Now working on a GIF support for DEU.
* Will Ellett (wellett@cs.uah.edu)
Configuration file (DEU.INI) and better command line parsing.
Lots of suggestions for DEU.
* Barry Bloom (barry@noc.unt.edu)
Maintainer of the official DEU distribution site for the USA:
the best DOOM FTP server: infant2.sphs.indiana.edu
(DOOM add-ons and utils, collection of WAD files, ...)
Also sent some useful suggestions and bug reports.
The first martyr of the DOOM cause: his first ftp site (ocf.unt.edu)
has been closed by short-minded academic authorities. <sob!>
* Sven Neuhaus (sven@lilly.ping.de)
* Billy Chow (billy.chow@engineering.oxford.ac.uk)
The most efficient beta-testers! They keep on finding bugs that
most other people never see...
* Jeremy Blackman (ranma@eskinews.eskimo.com)
* Brian Downing (bdowning@ncsa.uiuc.edu)
* Ted Vessenes (tedv@geom.umn.edu)
* Ed Boling (edb9140@tamsun.tamu.edu)
* Greg Grimsby (no more E-mail address <sob!>)
* Michael Emmons (ie78hc0z@solix.fiu.edu)
* Ryan Budney (rybu@jazz.math.ualberta.ca)
* Cameron Newham (cam@iinet.com.au)
Numerous comments, suggestions for improvements, and bug reports.
They were amongst the first to have faith in DEU and support it.
* Tom Neff (tneff@panix.com)
Not only a good beta-tester, but also the author of the WIF Specs,
a text interchange format for Doom levels, based on the DWD files
used internally by id Software.
* Dietrich Hempelmann (avatar@uni-paderborn.de)
Designed the "DEU 5" logo in DEU.TXT. Great ascii-art...
* Jean-Serge Gagnon (jsg8a@acadvm1.uottawa.ca)
Helped Steve with the docs and improved the DEU tutorial.
If you want to see a good WAD file, get FOREST.WAD...
* Sean Malloy (malloy@crash.cts.com)
Updated the docs for the stairs, sent some interesting suggestions
and bug reports. Improved display of the LineDef flags, etc.
* Christian Johannes Sladetsch (s924706@yallara.cs.rmit.oz.au)
Better texture display, XMS support (memory swapping).
* Craig Smith (bcs@cs.tamu.edu)
Ideas for improvements in the memory allocation routines.
* Tim Dedischew (kfdedisc@vela.acs.oakland.edu)
Working on a realistic 3D previewer for DEU.
* Tobias Ringström (d2rinto@dtek.chalmers.se)
Added the code to distribute floors and ceiling heights.
* Robert Hodkinson (R.J.Hodkinson@bradford.ac.uk)
Texture alignment (X offset).
* Per Allanson (c91peral@und.ida.liu.se)
Ported DEU 5.x to GCC + GO32 (DGJPP).
* Per Kofod (per@ollie.dnk.hp.com)
Added the code to display the pointer coords. Sent some bug reports
and suggestions for improvements.
* Jim Pitts (pitts@mimosa.astro.indiana.edu)
Maintainer of the 'infant2' FTP site. Our salvation when the UNT
authorities closed the 'ocf' DOOM-only FTP site. Thanks, Jim!
* Andy Sherwood (enigma@indirect.com)
Patch for Cirrus Logic cards: use the hardware cursor for the mouse.
* "Dino" (s.sproston-se2@cs.bham.ac.uk
Found 35 new LineDef types! New ways to raise or lower floors, etc.
* Hank Leukart (ap641@cleveland.freenet.edu)
Author of the DOOM FAQ. Publisher of Matt's Unofficial DOOM Specs.
He was (and still is) one of the best promoters of DOOM on the net.
youngest" perl script.
<d3095027@bohm.anu.edu.au> (BD)
<joekoperski@hotmail.com> (JK)
<joshray@prodigy.net> (JRR)
<jan.van.der.veken@village.uunet.be>
(JVDV)
Thanks for your feedback !
-file"
option. And releasing the source code.
Dave Taylor for porting Doom to Unix against commercial logic.
The people who created Unix and X
for giving us one of the best platforms around.
The thousands who worked on GNU, Linux, *BSD and all the free software
for giving me a chance to actually use that platform.
Colin Reed and Lee Killough for writing BSP,
releasing its source code and kindly allowing me to include it.
Udo Munk and Colin Phipps for Xdoom and Lxdoom.
TeamTNT for Boom.
The authors of the FAQs, specs and tutorials
from which I learned.
The makers of the internet for connecting us all.
The right way to typeset it is with a capital Y and the rest in lower case. Think of it as of a proper noun.
André Majorel <amajorel@teaser.fr>
The web page is :
http://www.teaser.fr/~amajorel/yadex/