Each class can define attributes, which are of the usual basic types (int, string, boolean, objects, lists of objects), but can also declare devices, which are basically "contained objects", and appear as of a generic type "object".
Attributes and devices are by default private to the class, i.e. are not accessible from within other classes' code.
One can modify the other object's accessibility to a single attribute by specifying wether the attribute is "readable" by others, "writable" or both.
Attributes behave differently from automatic variables, i.e. variables declared in the body of a method (action, command or routine). The latter behaves in the usual way, modifications take effect immediatly, and so on.
As we have already seen, scalar attributes are "synchronized", that means that they cannot be manipulated directly with the usual assignment operator, but one must use "inc to" or "inc by" to mean that the change will take place at the end of the current phase/event, in parallel with every other eventual modification.
When referencing an attribute one reads the value as it is before any modification (if scalar). One can also access the "updated" value, that reflects the ongoing changes on the attribute via "dec" "inc" "set" etc.. that will affect the actual attribute only end of the current phase.
The constructs available for attributes are:
3.1.1 constructs for numeric attributes
set
sets the ATTRibute to the specified value in EXPRession.
The effect of multiple sets in the same phase over the same attribute is unpredictable. One should avoid such situations.
Deprecated construct, use it only for strings and booleans;
inc/dec <ATTR>
to <EXPR>
increments/decrements the ATTRibute until the value of EXPRession is reached.
Effects are not cumulative, the higher/lower value is set.
inc/dec
Effects are cumulative, i.e. if two "inc
by" are present in the same phase,
Designers should avoid using it in conjunction with "inc to" and/or "set", in order to avoid complex behaviours.
The order of execution of these constructs in each phase, on every attribute is the one given above:
Designers should be very careful when using more than one of such constructs on the same attribute.
3.1.1.2 future value of (numerical) attributes
#
This construct works with any kind of attribute (numerical, scalar, list of scalars, obejct, list of objects) but it is really useful only with scalar (especially numerical) values that can be modified via "inc", "dec"...
It returns the value of the attribute as it is NOW, counting every modification made since the beginning of the phase:
//prior to the phase, attribute a=4
int b=a; //automatic variable b=4
inc a by 5;
int c=a; //c=4
int d=#a+3; //d=(4+5)+3=12
c=a; //c=4
inc a by 6;
int f=#a; //f=15 ((4+5)+6)
3.1.2 constructs for strings and booleans
set
3.1.3 lists of scalars as attributes
If you modify the same list in twice or more during the same phase the effect is unpredictable. One modification will occurr as the last one, and the attribute will maintain this value. One should avoid such a situation.
If you declare attributes of type "object" or as list of objects, you can modify them in the ordinary manner via the "=" operator.
The meaning is the same as:
set objectRef to newRef;
Please remember that multiple assignments of the same attribute (of the object type) have unpredictable results.
Every object has a set of default attributes, present even if they are not declared in any PbML file.
They are:
| string OWNER | name of the player who owns the object |
| int X,Y,Z | coordinates of the object |
| int MASS | mass of the object (weight) |
| int VOLUME | volume of the object (how much space does it take up) |
| object parent | parent object. In devices points to the container object, otherwise is null |
Devices are used to maintain objects (and lists of objects) contained in a parent object.
The relationship between an object belonging to a class with devices and its devices is "PART_OF".
Devices are actual components of the main object, they are NOT REFERENCES to other distinct objects, as are attributes of type object, or automatic variables of the same type!
Each object has a default read-only attribute "parent" that points to the container object.
For devices it is set to point to the object that contains actually the devices.
lease note that object attributes are just references to objects, so this doesn't mean that an object who is an attribute of a second one has the "parent" field pointing to the second obejct. In fact, the "parent" attribute has a not null value only in devices.
3.2.2 EMERSION OF DEVICE COMMANDS
The main characteristic of device is that they enrich the set of commands exported by the parent object with their own commands.
For example if there is a class Radar with the command DoAScan, and a class Airplane with commands TakeOff, Steer, Land, Raise, and an instance of Airplane has its radar device set to an actual Radar object, then the player owning this Airplane will have available a new command for its Airplane, the DoAScan command.
Example:
class Airplane
device radar;
commands: TakeOff, Land, Steer, Raise
class Radar
commands:
DoAScan
if the device 'radar' of the object "B747United" (of class Airplane) is null, then the owner of the 'B747United' will be able to issue only the following commands:
TakeOff, Land, Steer, Raise.
If at one point the player purchases a Radar object 'radar001', and installs it in the 'B747United', (setting the device radar to point to 'radar001') then he will be able to issue the following commands to its aeroplane:
TakeOff, Land, Steer, Raise, DoAScan.
Obviously this is one of the techniques that can be used to design add-ons for existing objects. Please see chapter 6 on Plug-ins/add-ons.