The attributes panel allows you to set the general characteristics of an object.
The attribute flags menu, the build flags menu, and the order flags menu require considerable explanation, so they each have their own section. The rest of the fields will be described here, staring with the leftmost column.
The object's base class. All objects which can receive orders should have a class. Generally speaking, this means any ship. For each race, there should be one and only one object with a given class.
All other objects should have a class of -1.
The class of an object is used in to allow similar objects across races to have a single reference.
When a planet (or any base object which can build) is defined in a scenario, the ships it is allowed to build are defined by class. When a planet is given a build order, it looks at the race of the player which owns it and the class of the object it has been requested to build. The actual object that gets built is determined by the first object in the scenario data that is found with the same class and race. To avoid unpredictable results, don't let multiple objects have the same class within a single race.
In a network scenario, initial objects are defined by references to particular base objects, not by class. If multiple races are allowed for a given player in a network scenario, and an initial object does not have the "fixed race" flag set, and the player who owns the initial object is not of the same race as the base object specified by the initial object, the class of the base object is used to find a matching object for the player's race.
The major factory ship classes are set up as follows:
| ship type | class | vel | max vel | thrust | warp out | mass | health | price | build time |
| fighter | 100 | 0.500 | 6.000 | 0.097 | 0 | 0.796 | 100 | 600 | 600 |
| cruiser | 200 | 1.000 | 5.000 | 0.156 | 9,734,400 | 1.000 | 1000 | 1000 | 1000 |
| heavy cruiser | 250 | 1.000 | 5.000 | 0.156 | 13,505,625 | 1.000 | 1000 | 1500 | 1500 |
| gunship | 300 | 1.500 | 4.000 | 0.039 | 9,734,400 | 1.199 | 3000 | 2200 | 2000 |
| heavy destroyer | 450 | 4.000 | 1.500 | 0.078 | 22,503,164 | 1.449 | 2000 | 6500 | 6500 |
| carrier | 500 | 4.000 | 3.000 | 0.007 | 22,503,164 | 2.000 | 5000 | 4500 | 6000 |
| transport | 800 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
| assault transport | 860 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
| engineering pod | 850 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
(major factory ships continued)
| ship type | offense | target | friend | build ratio | scale | lr size | lr shape | energy | danger |
| fighter | 0.500 | 1 | 0.000 | 0.750 | 4096 | 3 | tri | 600 | 2.000 |
| cruiser | 1.000 | 3 | 0.000 | 1.000 | 4096 | 4 | tri | 1000 | 1.000 |
| heavy cruiser | 1.000 | 3 | 0.000 | 0.796 | 4096 | 4 | tri | 1000 | 1.000 |
| gunship | 1.500 | 5 | 1.000 | 0.347 | 4096 | 5 | tri | 2000 | -10.000 |
| heavy destroyer | 4.000 | 7 | 2.000 | 0.097 | 4096 | 6 | tri | 2000 | -20.000 |
| carrier | 4.000 | 7 | 2.000 | 0.097 | 8192 | 8 | dia | 5000 | -20.000 |
| transport | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
| assault transport | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
| engineering pod | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
In a particular scenario, you may wish to have an ship which looks just like another ship, but behaves in a different way. For example, you may want to have the player rendezvous with a disabled gunship. To achieve this, you could duplicate the standard gunship, and change its velocity and attribute flags to make sure it's incapable of doing anything. It cases like this, make sure you give the special ship a slightly different class to ensure that the Ares engine doesn't confuse it with the real object. In this example, you could give the disabled gunship a class of 301.
All objects which can receive orders should have a race. Missiles and shots do not need to have races. For objects which do not need races, enter -1 for race.
The race of an object must match one of the races specified in the race editor. For any given scenario, make certain you define all possible ships that that scenario may require for its legal races.
All objects which can receive orders should have an offense value, an arbitrary value which helps computer player determine the offensive capacity of a ship. Generally speaking, the value should be relative to all the other ships in a given race. For example, in the factory scenarios, both Gaitori and Audemedon cruisers have an offensive value of 1.000.
This is a target class. It is only used by the computer player to determine whether or not one ship should escort another: the computer player will never assign a ship to escort another ship of a equal or lower class. Generally, the target classes should mirror the base class -- that is, if an object A's base class is greater than object B's base class, then object A's target class should also be greater than object B's target class. However, you may have objects of different base classes which you want to give equal target classes, in which case the different objects would never escort each other.
When the computer player is deciding whether or not one ship should escort another, it compares their target. It will never set a ship to escort another ship of equal or lower class. In the factory scenarios, for example, cruisers have a target class of 3 and carriers a target class of 7. The computer player will consider assigning a cruiser to escort a carrier, but never the other way around.
The initial velocity of an object when it gets created. Any object which can be built at a planet should have an initial velocity capable of moving it away from the planet's center before it is capable of stopping itself.
The speed at which an object travels when it's superlight boosters are engaged.
The distance at which a ship controlled by the computer (or the human player's ship when on autopilot) should disengage the autopilot in order to avoid overshooting a target object. This value can be computing automatically by clicking the "Calc Warp Out Now" button, but you may need to adjust it by hand for certain ships if you find them coming out of warp too late or too soon.
The maximum velocity at which an object can travel. This is only enforced if the object applies thrust -- an object's initial velocity may exceed it's maximum velocity.
The required resources to build an object.
A non-negative value specifying a random additional velocity for an object. For example, if an object's initial velocity is 2.000 and it's velocity range is 1.000, then the object will have a random initial velocity between 2.000 and 3.000. If the velocity range is 0.000 then the object will always have the same initial velocity.
Mass has a minor influence on what happens when two objects collide. The physics of a collision in Ares are not based on reality: when two objects collide, the directions of both of their vectors are absolutely changed, regardless of mass. The more massive an object, the less velocity it will have on its new vector after a collision. Mass should be relatively low (a cruiser, for example, has a mass of 1.000; a carrier has a mass of 2.000).
The amount of thrust an object can apply to its velocity. Thrust is always absolute, either on or off.
The "hit points" of an object. When an object is damaged by an impact or by a specific action, the damage amount is subtracted from its health. When its health is less than zero, the object executes its destruction sequence and removes itself from existence (unless it's "don't die when destroyed" flag is set).
The damage an object will inflict on another object if they collide.
The energy reserves of an object. Energy gets used automatically when the superlight boosters are activated. Energy can also be explicitly altered by an action sequence, and used up by a ship's weapons.
The initial age of an object determines how long it will exist after it is created, in 1/20ths of seconds. For objects which will exist indefinitely, the age should be -1.
The initial age of missiles determine their range (range = velocity * time).
When an object has lived passed its age (unless its age is -1) it will automatically execute its expire actions and remove itself from existence.
Make as few objects with indefinite ages as possible. If you made debris which did not automatically time out, for instance, you would quickly reach the maximum number of objects allowed in a scenario.
A non-negative value specifying a random additional quantity to add to an object's age when it is created.
This field also has a special function for destination objects (bases). Destination objects should never have ages that aren't set at -1, so the age range has to function for them. For destination objects, then, the age range determines the object's required occupancy count to switch owners.
For example, in the Ares factory scenarios, the bunker stations have an occupancy count of 5. When five EVATs from any one player enter the station, that player becomes the station's new owner.
So, for bunker stations in the Ares factory scenarios, the age range is actually set at 5.
An object's "skill numerator" and "skill denominator." The denominator must be a non-zero, positive value greater than or equal to the numerator.
Whenever a thinking object controlled by the computer wants to change the virtual keys it is pressing (for example, if it wants to press its virtual "turn clockwise" key to turn and face its target) it creates a random number between 0 and the denominator - 1. If that number is less than the numerator, then the virtual key press is successful. If that number is greater than or equal to the numerator, then the key press does not occur.
The closer the numerator is to the denominator, the more accurate the object will be in doing what it wants to do.
The color of the object's shields. Good choices include gray, indigo, and gold.
The scale of the object's sprite, where 4096 equals 1:1. Sprites, like carrier sprites, which are doubled in size would have a scale of 8192.
The sprite layer
the object's sprite should be drawn in. The "bases"
layer is the back-most layer. Planets and stations should be put
in that layer. The "Ships" layer is the middle layer.
Objects in the ships layer will appear to be on top of objects
in the bases layer, but behind objects in the shots layer. Finally,
the "shots" layer is the front-most layer. Missiles
and explosions should be in the shots layer.
The size of an object's long range symbol. The actual size in pixels will be about twice the value you enter here.
The shape of an object's long range symbol. Bases should be square. Fighting ships smaller than heavy destroyers should be triangles. Fighting ships the size of heavy destroyers and larger should be diamonds. Transports and ships with special purposes should be pluses.
The initial direction of an object. Should be zero except in special circumstances.
A non-negative value specifying a random additional quantity to add to an object's direction when it is created. For ships and objects which get built, should be 360. For shots should be 0.
A value which tells the computer player how many escorts to assign to this object. A value of 2.000, for example, would tell the computer player that this object would like escorts with an offense value totaling 2.000 to escort it.
A value which helps the computer player evaluate how much trouble an object is in when it is near enemy objects. For powerful objects, this value should be negative. For weak objects, this value should be positive.
A value which helps the computer player how often to build an object. The computer player adds all the build ratio values of all the objects it can build together. The object's general chances of being chosen for construction are equal to it's build ratio divided by the sum of all the build ratios.
The time it takes to build an object in 1/20ths of a second.