Версия для печати :: Документация по X-System

Да-да, эта та самая неизвестная система Blood, по которой до настоящего времени не было никакой информации, но которую можно вызвать в MapEdit'е через клавишу Tab в режиме 2D. :) Сразу предупреждаю - документация здоровая, целиком не лезет, выложу по кускам. :up:

Итак, оригинал:

This file documents the XSystem used in Blood. The XSystem is a system of
communication between dynamic world objects. A firm grasp of the XSystem is
crucial for Blood level designers. The XSystem provides basic building blocks
for creating simple doors, switches, and platforms, as well as the
flexibility for building extremely complex scenarios and puzzles.

==============================================================================
Overview
==============================================================================

XSectors, XWalls, and XSprites

The XSystem is based on extending the three simple object types used
in the Build engine: sectors, walls, and sprites. The extensions to
these are referred to as XSectors, XWalls, and XSprites, or
collectively as XObjects. Internally, the XSystem manages a list of
each of each XObject and maintains links between its related object.
The links are stored in the extra field, which you cannot edit in
MapEdit, but can view with the Tab key in 2D mode.

State

Fundamental to every XObject is the concept of state. In the XSystem,
state is a simple boolean condition: ON or OFF. The meaning of state
changes within different contexts, and can mean such things as open
or closed for a door, alive or dead for a creature, or moving or
still for a platform. For some types of XObjects, the implementation
of state is hardwired, i.e., the meaning of ON and OFF are fixed. In
most cases, however, you are free to manipulate the meaning of the
two states as you see fit. Nevertheless, consistency and protocol
will go a long way towards creating maintainable maps that are easy
to debug. For example, it is recommended that you create doors such
that ON is open, and OFF is closed, but this is by no means enforced.

There are many sector effects that are implicitly tied to state. The
two most commonly used effects, lighting and panning, are both by
default directly controlled by sector state, and you will need to
understand state in order to make full use of these effects.

Simply put, the effect is active when the state is ON, and the effect
is inactive when the state is OFF. This means that the water in a
sector could be made to flow or be still, depending on the sector's
state. In the same way, a sector's lighting effect can be made to go
on and off by changes in the state of the sector. The lighting wave
form (if any) and amount of lighting (positive or negative) are
independently configurable, which means the implementation of ON and
OFF are still up to you.

Switches are XSprites that work by changing their state in response
to some stimulus, such as being pressed by the player, or impacted by
a projectile. Nearly every XObject can change state in this fashion,
although you can also effect state changes through the use of
messages transmitted from one XObject to another.

Triggers

All changes in state ultimately originate as a result of some
physical event, usually an action by the player. These events are
known as triggers, and XObjects can be made sensitive to triggers by
setting the appropriate trigger flags:

[x] Push
[x] Impact
[x] Explode
[x] Pickup
[x] Touch
[x] Sight
[x] Proximity
[x] Enter
[x] Exit
[x] WallPush

The Push trigger flag can be set for all XObjects, and is activated
when the player presses the action key while facing the XObject. The
player must be within a certain distance (currently 64 pixels) in
order to activate the trigger. However, if the player is in an
XSector that has the Push flag set, the trigger can be activated if
no other XObject within push range has the Push flag set. Push
triggers have many uses, such as switches that control other
XObjects, swinging doors, or walls the player can push back.

An Impact trigger is generated when the XObject is hit by a vector
weapon, such as the shotgun or the tommy gun, regardless of whether
the source of the vector was a player or a creature. The Impact
trigger flag can be set for all XObjects. Use the Impact trigger flag
to make glass windows change state (and break) when shot.

The Explode trigger is similar to the Impact trigger, except it is
created when the XObject is affected by an explosion. All XObjects
can have Explode triggers. Explode triggers can be used for walls
that can be demolished with TNT.

The Pickup trigger flag can only be set for XSprites. This trigger is
generated when an item is picked up by a player. If you use the
Pickup trigger, you should use the XSprite to send out a message to
another XObject, since it will be deleted immediately after being
triggered. The Pickup trigger makes it easy to create an ambush
where picking up a crucial item causes doors to open exposing hordes
of enemies. This differs from DOOM, which requires that the player
step into a sector that actuates a trigger. Use of the sprite Pickup
flag is preferable to using an XSector's Enter flag where the intent
is to trigger another XObject when a special item is picked up.

The Touch trigger is generated when the player is standing on (and
being supported by) a particular XSprite. Only XSprites can use Touch
triggers. A good use for Touch triggers is to create a break away
floor section using floor sprites that drops the player into some
other hazard.

The Sight trigger flag allows XSprites to generate a trigger when a
player is visible from the XSprite's location. The visibility test is
computationally expensive, so use this trigger flag very sparingly!

The Proximity trigger flag can be set for XSprites to allow them to
trigger when a Dude (not just players) is within a finite distant
from the XSprite. The dude must be with 64 pixels AND be visible from
the location of the XSprite. The visibility test ensures that
proximity triggers don't get generated for Dudes that are on the
other sides of walls. Proximity triggers are used automatically for
player placed proximity bombs, but you can create preset proximity
bombs with this trigger flag.

XSectors can generate triggers when a player enters and exits a
sector by using the Enter and Exit trigger flags. It is not yet
determined whether teleporting from or dying in a sector constitute
leaving, so be careful when using these flags together not to create
potential deadlocks.

The WallPush is an XSector flag that is the equivalent of setting the
Push trigger flag for all of the outward facing walls of a sector.
Setting the WallPush trigger flag makes it easy to trigger red sector
doors. This Flag may be used in conjunction with the Push flag in
sectors where the intent is to have the player activate the XSector
from the inside or outside.

For most XObjects, the effect of a physical trigger is to toggle the
state of the object. This is not always the case, however, and the
implementation of an XObject's response to a physical trigger is
dependent on the type of XObject. In the descriptions of each
specific XObject type, you can assume that a physical trigger toggles
state unless explicitly stated otherwise.

Keys

You can limit what triggers the player is able to generate by
specifying a key requirement. There are up to 7 different keys that
the player can acquire each level. If the key field is set to a value
other than 0, the XObject will not generate a trigger unless the
player possesses the appropriate key. For example, a wall tile might
possess a key hole. If the player has the silver key, pressing the
action button while facing the wall will open the adjoining door (via
a command message to the door). If the player does not have the
silver key, the door will not open.

(Добавление)
Messages

The XSystem enables you to create highly interactive and complex
environments, and the primary mechanism for accomplishing this
complexity is the message system. Every XObject has the ability to
send and receive messages to and from other XObjects. Communication
between XObjects is what allows a wall switch to open a door, a trap
to open upon entering a secret area, or a combination lock to
activate a teleporter.

Communication takes places in the form of commands which can be
broadcast on any of 1023 different 'channels'. Each XObject has a
separate transmit and receive channel, called txID and rxID,
respectively. These can be set to the same channel, but usually they
will be different. Think of the receive channel as the channel that
the XObject is listening to. A message will have as many receivers as
there are listeners. If a command is broadcast on channel 200, then
every other XObject with an rxID of 200 can react to that message.
Different types of XObjects can be listening to channel, and each
react differently on reception of a message.

The conditions for when to transmit a message are defined by an
XObject's Send Mask, which is described later.

Commands

The primary reason for sending a message to an XObject is to alter
the state of the recipient. To that end, there are several different
commands that a message may encapsulate:

OFF
ON
state
toggle
!state
link
LOCK
UNLOCK
*LOCK

The simplest of these are the OFF command and the ON command. As you
would expect, these force the recipient to the specified state. To
turn an XObject ON, send an ON command on the channel to which it is
listening. To turn it OFF, send an OFF command on the same channel.

For example, a wall switch could transmit an ON message on channel
142 when the player presses the action key on the front of the
switch. An XSector with an rxID of 142 would change from OFF to ON
when receiving the message. If the XSector had a lighting effect
defined, it would be activated by the change in state. This is how
you would create a room with a light switch on the wall.

The state command allows an XObject to transmit an OFF or ON command,
depending on what its current state is. If the XObject is OFF, it
transmits an OFF command. If it is ON, it transmits an ON command.
The state command provides a convenient way to synchronize the states
of two or more XObjects.

Any XObject receiving a toggle command will invert its state. Use
this command when you don't care what the original or resulting state
will be, and you just want to ensure that the receiving XObject
changes state.

The !state (read "not state") works similar to the state command,
except the state of the sender is inverted. If it is OFF, it
transmits an ON command. If it is ON, it transmits an OFF command.

The link command is used to synchronize the state of two or more
XObjects at a more fundamental level than the state command, and is
described in detail under "Linking".

Locking

The LOCK and UNLOCK commands alter the state of the recipients locked
status. When an XObject is locked, it will ignore any physical
triggers sent to it. It will still respond to any messages it
receives. The *LOCK command will toggle the locked state of the objects
recieving the message.

System Channels

Channels 0 - 99 are system channels and are reserved for certain global
tasks. Some of these should be transmitted on to trigger global events,
and others can only be received.

Here are the uses of the system channels:

0 Null channel. No commands are ever sent on channel 0.
1 RESERVED
2 RESERVED
tx я3 Voice/text over
tx 4 End level A
tx 5 End level B
tx 6 Lightning
rx 7 Called at startup
rx 8 Called at BloodBath startup
rx 9 Called at Coop startup
10..89 RESERVED
90..99 Used internally for remote detonators
tx/rx 100+ Miscellaneous level channels

Channels from 100 to 1023 are free and should be used by the level
designer for communication between XObjects. The uses of the system
channels is further described in the section on System Triggers.

Send Flags

XObjects broadcast messages as a result of a state change. You can
specify which state changes will cause the XObject to transmit by the
send flags:

[x] going ON
[x] going OFF

When the state changes from OFF to ON, a message will be broadcast if
the "going ON" flag is set. When the state changes from ON to OFF, a
message will be sent if the "going OFF" flag is set. If neither flag
is set, the XObject will not broadcast any messages as a result of
state changes. If both flags are set, it will broadcast at any state
change.

For example, suppose you want to use a lever to control a portcullis.
When the lever is pulled one way, you want it to raise the
portcullis, and when it is pulled the other way, you want to lower
the portcullis. You would set the command to "state" and set both
send flags, so the level would send an ON or OFF command every time
the lever is moved.

If, on the other hand, you wanted to use two switches to control the
portcullis, you might have switch A raise the portcullis when it is
turned on, and switch B lower it when turned off. In this case you
would set switch A's "going ON" send flag and set its command to
"ON"; and switch B's "going OFF" send flag and set its command to
"OFF". Switch A would then send an ON command only when its state
changed to ON, and switch B would send an OFF command only when its
state changed to OFF.

The Busy state

For many XObjects, such as doors or lifts, state is used to indicate
one of two spatial positions that it can move between. By definition,
however, transitions between the two states cannot occur
instantaneously, but must progress over some finite period of time.
In this case, the state change will not be considered complete until
the object reaches its destination.

While the object is undergoing a state change, the state field will
remain unchanged, but an internal variable, called "busy" will track
the progress of the state change. The busy value is a binary fraction
that ranges from 0 (OFF) to 1 (ON). You can control how long the
state change takes (for the appropriate XObject types) by specifying
a value for busyTime in 1/10ths of a second. A door with a busy time
of 50 will take 5.0 seconds to open or close. The current maximimum
busyTime is 25.5 seconds, though this may be raised to accommodate
the longer waitTimes used with Momentary Switches.

Once the object reaches its goal state, the state field is changed,
and a message is broadcast, depending on the send flags. The effect
of delaying the state change until transition is complete allows
actions of objects to be sequenced.

For example, imagine what is necessary to move a boat through a set
of locks. First one door opens, and when the door is completely open,
it sends a message to the boat to move it through the door. When the
boat reaches it's destination, it sends a message to the door, which
starts closing. Once the door is closed, it sends a message to the
sector, which raises the water level. When the water reaches its
desired level, it sends a message to the other door, etc.

(Добавление)
Callbacks

For many of the XObjects in a level, you will want them to be reset
after a period of time. For example, you might want to create a
vertical door that closes automatically after being open for 10
seconds. The XSystem supports this through the use of callbacks.
Callbacks are a special message type that is generated internally and
gets delivered to the XObject after a time period that you specify.

You control the generation of callbacks through two fields, the
waitTime and the restState. If waitTime is 0, the XObject will not
generate a callback, otherwise it specifies the delay in 1/10ths of a
second between a state change and receiving the callback. The
restState is either OFF or ON, and indicates the default "resting"
state for the XObject. It will post a callback when changing away
from the restState, and when it receives the callback message, it
will set its state to the restState.

In the above example of a vertical door that closes after 10 seconds,
you would create a door such that OFF is closed, and ON is open. Set
the waitTime to 100, and the restState to OFF. Whenever the door
opens, changing state from OFF to ON, it will post a callback message
to itself. After 10.0 seconds, the callback is delivered, and the
door will close.

Unlike broadcast messages which are sent out on a particular channel,
callbacks are delivered directly to the XObject which generated them,
and are not concerned with rxID or txID. Callbacks also work
irrespective of the XObject's send flags. This allows callbacks to
work independently of any other messaging you might involve the
XObject in. You can still broadcast messages on a state change,
regardless of whether that state change occured as a result of a
physical trigger, a command message, or a callback message.

In most cases you will want to leave restState at its default value
of FALSE. There are a few cases where having a restState of ON can
solve some rather unusual design problems, but a description here
would only be confusing. It will suffice to say that you'll know when
you need to change it.

Linking

Imagine opening the door to a dark closet, and as the door opens, the
interior of the closet gets brighter. Imagine raising a flood gate,
and as the gate opens, the water downstream begins to move, slowly at
first, but them more rapidly as the gate gets higher. These are some
of the effects you can accomplish with link messages.

The link command essentially allows an XObject, a master, to
broadcast its busy state. It is not necessary to set send flags for
the link command. The link command will be sent out continuously as
the master changes state. This will cause any XObjects receiving the
link commands, slaves, to synchronize with the master by copying the
master's busy value. When the master finishes its transition, its
state field will change, and so too will that of all the slaves.

The interpretation of the busy value will depend entirely on the type
of XObject receiving the command. Certain sector attributes, such as
lighting amplitude and pan velocity are by default controlled by
state, and therefore busy value. Sending link commands from a door
XSector to a room XSector is an easy to synchronize the illumination
of the room with how far the door is open.

The XSystem makes no checks for slaves starting out in the same state
as masters. If a slave is ON and the master is OFF when a map is
loaded, and the master broadcasts a link command as it changes state
from OFF to ON, the slave will seem to 'pop' to OFF when it receives
the first link command, and then slowly change to the ON state
simultaneously with the master. You should avoid this by ensuring
that slaves start out in the same state as masters.

Decoupling

Each XObject can be thought of as having several components: a
component which handles state and the sending and receiving of
messages, a component which interprets and implements state in an
object specific way, and a part which detects physical triggers.
Normally, these components all function as a single unit. When an
XObject is triggered, its state is modified, the physical
representation changes, and a message may be sent out. This 'unit'
functionality is intuitive, and it makes creating the most common
types of XObjects quite simple.

Suppose, however, that you want to control the lighting in a room
with a wall switch, but you also want to be able to detect when a
player enters the room in order to trigger some sort of trap. You
might set up a static lighting effect controlled by state, so that
when the sector is ON the room is bright and when it is OFF the room
is dark. Pressing a wall switch could send a toggle command to the
room XSector, turning the lights on and off. If you simply set the
Enter trigger flag in the sector, then a player entering the room
would toggle the state of the sector, turning the lights on or off.
And any message sent out would have to depend on a state change,
which would mean it would be triggered not only by physical
triggers, but by state changes caused by the light switch.

Fortunately, there is a way to isolate the functioning of the
XObject's physical trigger component from its state mechanism. The
decouple bit, when set, causes physical triggers not to affect the
XObject's state, and to directly generate a physical trigger message.
This message is broadcast on the txID channel, and causes the
physical trigger to be applied to all receiving XObjects. In other
words, to any XObject receiving the message, the trigger will be
handled exactliy as if it were generated by that XObject itself.

(Добавление)
==============================================================================
XSPRITES
==============================================================================

Data1 .. Data3

The data fields are a catch all storage area for miscellaneous data
with no place to go. Their use is type dependant.

Difficulty

This specifies at what difficulty level the object appears. Level 0
is the easiest, and level 3 is the hardest. Not yet implemented.

Detail

Not yet implemented.

Map flags

( ) when seen
( ) never
( ) initial
( ) secret

These allow you to specify the conditions under which the object will
be visible on the players 2D map. The default is "when seen", which
means that it must be first seen in 3D mode before it will be
displayed on the map. XSprites marked as "never" will be invisible
in 2D map mode. To have an XSprite start on the map, use "initial".
"Secret" is not yet defined.

Sound kit

Not yet implemented. See Ideas section.

Respawn flags

Not yet implemented. See Ideas section.

XSprite types

Markers

None implemented yet.

Switches

Toggle Switches:

The most basic of all switch types. It will display as one of two
pictures in 3D mode, depending on the state. The picnum should be set
to the OFF state picture. The ON picture (picnum + 1) will be displayed
when the switch is on. All physical triggers toggle the state of the
Toggle switch.

Momentary Switches:

Like the Toggle switch, except physical triggers can only change its
state to ON. You'll need a callback or a message from another XObject
to reset the switch to the OFF position.

Combination Switches:

Combination switches are multi-way switches which change to an ON state
when they are set to a certain combination. These switches can be used
for combination locks, or even counters, as I will demonstrate. Their
behavior is controlled through 3 data fields:

data1 Current value ( 0 <= x < N-1 )
data2 Key value
data3 Number of values (N)

The switch can have a value from 0 to N-1, where N is specified in the
data3 field. If data3 = 5, for example, the switch can have a value
from 0 to 4, for a total of different values, or positions. Each value
is represented by a different tile. You specify the base tile, which
is the picture it will have when value = 0. For example, if you pick
tile 2300 for the switch, and data3 = 5, the switch will cycle through
tiles 2300-2304.

The current value for the switch is specified in the data1 field.
Normally value is manipulated by the program, but you can set the
initial value so when the map starts a switch will be in a particular
position.

If you enable a trigger for a combination switch, such as the Push
trigger, whenever the trigger occurs the value (data1) for the switch
will increment, wrapping around if it reaches N (data3). In this way
you can cycle continuously through all the different combinations for a
particular switch.

You can also control a combination switch with messages. By sending an
ON command to a combination switch, it will cycle UP. By sending an
OFF command to a combination switch, it will cycle DOWN. In this
manner, you can create a counter. The switch will have a value equal
to the number of ON messages it has received, minus the number of OFF
messages, assuming it starts out with a value of 0 and you don't have
any physical triggers enabled.

The real power of combination switches comes from the ability to set a
key value in the data2 field. The switch will changes its state
depending on whether data1 = data2. In other words, data2 is the
"combination" of the lock. If data2 = 3, whenever the switch cycles to
3, its state will change to ON, and whenever it cycles away from 3, its
state will go to OFF.

With this knowledge, you can create a combination lock consisting of
multiple switches like the example in the hallway of FXTEST.MAP. This
combination lock actually consists of 4 combination switches: 3 used as
tumblers, and one used as a counter. The tumblers as set up pretty
much as you would expect. For each, data3 specifies the number of
tiles to cycle through, and data2 specifies the key value for each.
Each tumbler sends State to the counter. Unlike the tumblers, the
counter does not have any physical triggers set, so it is only cycled
by messages it receives from the tumblers. Since each tumbler sends a
State command to the counter, it effectively "counts" how many of the
tumblers are in the correct position to open the door.

Since the door should open only when all three tumblers are in the
correct position, the counter switch has data2 = 3. Thus, when it
reaches a value of 3, it will go to an ON state, and send a message to
the door to open. The data3 field for the counter is set to a
arbitrary high value to prevent the switch from cycling around to 0
before it reaches 3. I just checked the code, and it will work just as
well if data3 = 0. So, if you don't want a counter to "wrap around",
just store a value of 0 in data3. In the example, the counter is
visible so you can see how it works, but you should probably hide it in
the real game maps.

The multi-way door setup in the outside area of FXTEST.MAP is only
slightly more complicated than the combination lock. In this setup,
there are also 4 switches, but 3 of them are hidden by embedding them
in the wall next to each door. The combination switch in the center of
the pool is a Master switch, and the 3 hidden switches are slaves. The
master switch sends Link commands to the 3 slaves. The Master switch is
the only one which responds to physical triggers, in this case, a Push
trigger. Whenever the Master switch cycles to a new value, it sends a
Link command to all the slaves, and they all change to the same value.
The value of data2 is irrelevant for a Master switch, and the value of
data3 is irrelevent for a Slave.

Each slave switch has a key value (data2) set so that whenever the
Master (and all the slaves) cycles to a certain value, it will go ON
and send a message to the door it controls to open. In the example in
FXTEST.MAP, the slaves have key values of 1, 2, and 3, in clockwise
order starting with the west most slave.

There is no limit to the number of Slaves switches you can tie to a
Master. They simply all receive on the same channel the Master
transmits on. There is also no limit to the number of tumblers you can
use in creating a combination lock.

(Добавление)
Weapons

Ammo

Keys

Items

Dudes

Creatures can use their state to indicate whether they are alive or
dead. Thus, they can send commands when they are killed. It is also
possible for creatures to respond to command words to change their
state -- ergo, they can be killed and brought back to life by remote
control. Creatures can, of course, have many more states than can be
represented by a simple binary state variable. The state bit here can
be considered to mean active/inactive. For example, a creature could
start out life as an inactive statue, and become animated when the
player reaches a certain location. This has the potential for some
really neat stuff.

A creature with a non-zero value in the key field will drop a key of
the specified ID upon death.

Generators

Timer events are used to generate triggers at regular or semi-regular
intervals.

txID command is broadcast on txID channel at each interval, and
optionally going on or off depending on the sendWhen
parameter.

rxID used to turn the generator on or off.

state on = triggers every busyTime +/- data1 tenths of a second.
off = no triggers generated

command used for trigger generation, and normal messages

sendWhen used only for normal messages, ignored for trigger generation

busyTime trigger interval in tenths of a second.
If busyTime is zero then the object will activate only once
for each trigger on.

waitTime time before shutting off

data1 random interval, added or subtracted from data1.
data2 reserved for specific generator types (see kGenFireball)
data3 used internally as callback semaphore to prevent multiple callbacks

What all this means is that the kGenTrigger type, and future
generator types, support being turned on and off by other triggers
(like switches), or OFF by its own waitTime.

The specified command is sent on the specified txID at specified
(busyTime +|- data1) intervals while the kGenTrigger object's state is
ON, regardless of what the sendWhen parameter is set to.

The kGenTrigger will also send the specified command on the specified
txID when the state is turned ON or OFF, if one or both of the
sendWhen fields are set.

kGenFireball
data2 == 0 : no animation, shoots fireball immediately
data2 == 1 : gargoyle "green man" sequence triggers fireball
data2 == 2 : gargoyle "bat face" sequence triggers fireball

kGenSound
soundID == Sound ID

kGenWaterDrip & kGenBloodDrip
The falling object will automatically determine which splash
and sound to make based on the impacted surface type.

Q. What should these be used for?
A. Almost any event that you want to be triggered repeatedly and
regular intervals. In future versions, specific kGen??? types will be
added to generate blood drips, water drips, fireballs, etc. These
will work in much the same way as kGenTrigger except that they will
spawn a special sprite at each interval instead of sending a message.

Q. What should these NOT be used for?
A. DO NOT use the kGenTrigger object to simulate any continuous
motion. We will be adding a continuous motion feature to some of our
sector effects in the near future. If you use the kGenTrigger feature
to simulate this, you will only be hurting your map and wasting
precious time.

Tricks and traps

Tricks/Traps/Hazards

80 TNT barrels - large barrels of explosive material. Will blow
up after receiving a certain amount of damage. Blowing up is
considered a state change. You can also blow them up with
command messages.

81 Floor spike - sort of like a sharp stalagmite. Does damage
when touched. Damage once or continuous.

82 Falling rock trap - several rocks fall to the ground. Needs
to be triggered via command.

83 Gas emitting statue - when triggered, emits a cloud of
poisonous gas.

==============================================================================
XWALLS
==============================================================================

Panning

Types

==============================================================================
XSECTORS
==============================================================================

Shade effects

Wave forms
Period
Amplitude
Phase

Panning effects

pan floor
pan ceiling
velocity
angle

Water depth

Underwater

Types

==============================================================================
SYSTEM TRIGGERS
==============================================================================

Voice/Text overs

You can specify one of several messages to display during the game by
sending a message on system channel 3. To choose which message is
displayed, set the XObjects Command field to a user ID from 0 to 63.
Corresponding messages must be defined in the map definition (.DEF)
file for each map. Up to 64 messages may be declared in a .DEF file,
using the syntax defined below.

The idea is to provide the ability to present some sort of plot
element during game play. The message would be associated with a
sound effect which would be played on top of the rest of the
music/audio (like Katarn's voice in Dark Forces). This is NOT the way
to create a sound effect that is supposed to come from some location
in the map.

Perhaps we could create a a level definition file (INI file, perhaps)
that would allow level designers to specify the text of messages and
associated sound resource, rather that having a fixed set for the
game.

Using the data field has some problems, since it is needed for some
specific XObject types, such as combination switches.

==============================================================================
LEVEL DEFINITION FILES
==============================================================================

A level definition file is used for each level to store information that is not
easily editable with the map editor. The definition file is a plain text file
with a format similar to that of INI files. There is only one anonymous
section, and it consists of various keys.

Author=string

This is where you get to put your name.

Description=string

The long name of your map. Be creative.

Song=string

The name of the music (midi) file for the level. Do NON include
the extension.

Message?=string

Messages generated by voice over triggers. ? is a value 0 to 63.

(Добавление)
==============================================================================
Experimental
==============================================================================

This section describes new features of the XSystem that are being tested. The
implementation of these is subject to change, so while you are encouraged to
experiment, please do not rely heavily on them heavily.

Fog:

By adding the line "Fog=1" to your level definition file, you can cause
a level to use fog depth cueing instead of the normal light
diminishing. Having fog enabled will dramatically limit the number of
shade levels available. Fog is global for the level, so you will
probably want to consider using it only for an all outdoor level.

Linking:

Sector linking is now working. To link two sectors place an upper link
marker in one, and a lower link marker in the other. The upper link
goes in the sector where you move upward to end up in the other sector,
and the lower link goes in the sector where you can move downward to
enter the other sector. If this seems backward to people, I can change
it.

The markers are paired by specifying a unique value for the data1
field. This value is shown in 2D mode in the editor. There should be
exactly 2 markers for each value, an upper and a lower marker.

When linking two areas, you should either place them very far apart on
the map, or overlap them properly in the XY plane. This will allows 3D
sound effects to either be out of ear shot, or heard correctly,
respectively.

==============================================================================
Ideas
==============================================================================

Damage:

Sector damage:
Damage frequency (every n.nn seconds)
[ ] in sector
[ ] on floor
DAMAGE DESCRIPTOR

Damage descriptor
Damage period (every 1/10th seconds)
[ ] Damage on floor only
[ ] Damage only when ON

Damage Descriptor

Type:
Pummel Punch, pummel, impact or crush
Burn Burn from heat or fire
Bullet Bullets or other piercing projectile
Cut Cutting or cleaving from a blade or sharp edge
Stab Stabbing or impaling
Explode Explosion concussion
Gas Poison gas
Drown Lack of air underwater
Sonic
Psyche
Spirit
Magic

Amount:
# hit points

Sound effects

Each sound effect will have the following properties:

Sample length
Sample rate
Looping flag

Sound Kits

Since it would be difficult, if not cumbersome, to assign sounds for
each possible sound effect that an object might make, sound kits
provide a predefined collection of sounds for object state changes.

(0) -> 1
0 (->) 1 (loop)
0 -> (1)

(1) -> 0
1 (->) 0 (loop)
1 -> (0)

Respawning

permanent // 0=not permanent, 1=permanent (respawn ignored)
respawn // 0=never, 1=always, 2=optional never, 3=optional always
respawnTime // 0=instant, >0=time in tenths of a second,
launchMode // 0=all, 1=bloodbath, 2=ally, 3=ally&bloodbath,

Surface Kits

Surfaces are used to describe the way that materials react to damage,
object collisions, and interaction with the player.

Surfaces have the following properties:

Footfall sound
Impact sound
Impact effect

Predefined surface types are:

Stone
Wood
Dirt
Metal
Water
Lava
Air

Miscellaneous

a boat

mine cart

mausoleum - door opens, and a platform slides out with a body on it

moving platforms, such as one in ShadowWarrior

You walk by a window and hear the sound of rain coming from outside.
Occasionally, the sky flashes, and then you hear the sound of thunder
from far away.

Floor lightning: Connect a bunch of floor sprites together to create
a lightning-like effect. Imagine a guy pounding a staff on the ground,
and lightning radiates outward on the floor from his staff. When it
hits the player it does damage.

Elevators:

At each floor, there is a call switch for the elevator. Pressing the
switch will illuminate a light, which will stay lit until the elevator
arrives. Above or to one side of the elevator is a panel which
displays the current floor the elevator is on. When the elevator
arrives, a door splits open to allow access to the elevator interior.
Once inside the elevator, the player can press one of several floor
buttons.

Elevator is open on same level as player. Player enters. Player
presses action bar => elevator closes, moves to next floor. Player
presses action bar => elevator opens.

Rachel

She will appear, walk towards her target location (a marker sprite),
and then disappear. Any actions you wish her to perform should be
accomplished with the initial trigger.

Sound generator

Place one of these where you want to create a custom sound, e.g., a
creaky floor or mysterious laugh. When it gets triggered, it will
play the sound id specified in its data field. The sprite's waitTime,
if non-zero, specifies that the sound generator is self triggering,
and determines the average period between sounds in 1/10 seconds. The
interval will vary by +/- 50%.

Wall traps

Force field wall. Blocks all movement when energized (including
bullets).

Crushing wall - moves forward until it meets another wall, crushing
anything and anyone in between. Use two opposing walls to make a nice
sandwich.

Swinging pendulum trap. A large bladed pendulum swings out of a niche
in the wall.

Guillotine - huge blade drops from above.

For flexibility, the blade and projectile wall traps are not
self-triggered. You need something else to trigger them. This allows
you to adjust their timing to suit your needs. For example, you can
trigger the razor doors by placing a player-cross trigger (see below)
a short distant before the blade wall. Adjust the distance so that a
player walking at a normal pace gets sliced neatly in two!

Kinetic effects:

warp to marker sprite
warp to sector
stair case sectors
Sinusoidal floor heights
Sinusoidal walls
Collapsing stairs
[x] Drag objects

Container effects:

Teleport
Relocate
Sinking through floor
Linking

Upper linked sector
Lower linker sector

Upper linked water
Lower linked water

Linked sectors are combined vertically so that the ceiling of one is
the floor of another. This means it is possible for the player to move
between them, and to partially be in both.

Teleport when enter once to target location
Teleport when enter always to target location

Combination Switches:

* Counter switches cycled by messages from something other than a
combination switch. For example, you can keep track of the number of
times a Player enters a sector. On the 10th time -- Zap!

* Combination locks with more than one set on combinations. You could
do this by have a set of tumblers which are used as Masters, controlling
several sets of Slaves each with their own combinations. In this
manner, you could have a combination lock which causes one action when
one combination is entered, and another action for a different
combination.

* Combine tumblers with a momentary switch so the Player needs to enter
a combination and then press a switch to perform an action. The
momentary switch would send state when going ON and OFF just like the
tumblers, but would provide an extra value to the count.

* Lots of other cool stuff. These things are really powerful -- there's
an almost unlimited potential in using hidden switches that nobody's
using yet. If you have something you want to try, but can't figure out
how to do it, just tell me and I'll try to create an example for you. I
welcome any challenges!

==============================================================================
TROUBLESHOOTING
==============================================================================

WHY DON'T MY DOORS WORK?

Make sure the doors are receiving triggers. If they are triggered externally,
you need a matching txId->rxId pair. If they are triggered internally, check
your trigger flags. Make sure the sector is not decoupled.

WHY DO DOORS START IN THE WRONG POSITION?

Remember that you must draw your doors in the OPEN position, but set their
state to reflect how you want the door to first appear in the level.

WHY DOES A TEXTURE STRETCH ON A SLIDING DOOR?

You may have an extra wall tagged for movement. If not all your walls move,
then at least some of the wall textures will stretch. Try to make them hidden.

WHY DO DOORS 'POP' FROM OPEN TO CLOSED?

Make sure that busyTime is non-zero.

MOMENTARY SWITCHES DON'T RESET.

Momentary switches do not automatically reset, although you can cause any
XObject to reset to a rest state after a period of time by setting the
waitTime.

XSYSTEM Documentation.

Вот и вся документация. Всё, что раскопалось.

С уважением, Blackwinged from -<<NEPTUNE TOWERS>>- :)

(Отредактировано автором: 26 Октября, 2005 - 02:15:38)

Отредактировано администратором: Slava, 28 Октября, 2005 - 18:49:02