This section contains various slightly random notes intended to assist people that wish to hex edit and 'hack' the game. Everything here is entirely at your own risk - I strongly suggest you copy anything you intend to change...

U2.04 Memory Address Map, based on the writings of flap:

"In this note, I explain where the game stores its data while the game is running." A full text could be found at Zedo's old forum, but that source is no longer available. I've edited this down to critical game-specific information. Note this is relevant to U2.04, and incomplete. All values can theoretically be edited without crashing the game, unless indicated as "***".

Fixed Addresses:

Pilot Addresses:

"Consider that 0 is the base address of the pilot. For the player, it is for example the one given at 00 54 71 E4. Add the value to address to go to the address you want:" (values are decimals)

Command Addresses:

"One command is made of 6 Dwords (D for double - a word is made of two bytes), the first one tells what command it is. The commands follow each other. I don't know how many you can have." ("-" means it doesn't matter.) (Also see Duncan's AI Plans/Orders notes.)

Goods Addresses: (all *** )

Crater Addresses: (all *** )

Weapon Addresses:

Buildings Addresses:

Laser Turret: (precise location unknown)

U3 Beta 4 Savegame Format, from Duncan:

"In order of appearance:

AI Occupation notes, based on the writings of smurph:

"AI 'profession' is encoded by a single byte in the save game file. Open up the save game in a hexeditor, and search for the pilot name as an ANSI string. About 45 bytes from the start of the pilot name you will see the following set of bytes ab,cd,00,00,xy where xy codes for the 'profession'. If you edit a save made right at the start of day 1 ab,cd is 10,27. The codes (xy) for pilots in existance at the start of the game in b4 are:"

"Codes 05 and 0B can be interchanged with no problems and some interesting effects. 0B pilots are more active (i.e always hunting for enemies) in the game (at least in b5)."

Unfortunately, changing careers does not automatically change the 'plans' for pilots - Duncan writes: "Pilots with new professions but behaving like their old days still have their old plans list. Clearing this list won't help, because as soon as no order is finished anymore, no new ones are going to get in. Normal beta 4 game example: Start as Admin as a dealer. Fly around a little, soon 2 shady pilots will target you and fire their devastators in your bud. If you are killed you will end up on foot in your hangar. Blag a moth, board and launch. You will notice that the bloke responsible for your early death is still hanging around doing nothing. When you look at the savegame you will notice the lack of plans. By the way these pilots have the profession 0F - it's missing in smurph's list, and 20 Devastators. This could of course also be the 0F order module not generating new plans."

AI Equipment notes, based on the writings of Eight:

Shown as address - hex dec - item:

Pirate

Scavenger

Trader

Unknown

List of items (hex dec item)

Max notes: "Start of ~'case block' 0x50996 - first item assignment, end ~0x50EED."

U3 Beta 5 AI Starting Gear notes, based on the writings of Nazgutek:

"Open up the exe [hardwarW.exe] and starting at the following addresses, replace the 5 bytes with 0x90 (that's 90 HEX, not 90 decimal). These will remove various items from starting NPC types:"

Pirates:

Scavengers:

Traders:

"Example: We wish to remove the pirates' laser turrets, so we would go to file offset 50D12 (which is in hex), and change the byte there and the next four to 0x90,0x90,0x90,0x90,0x90.

* Pirate Missile Note: The code seems to randomly choose either Sprats, Groundbase, Underkill or Fireburst. The hack address above will remove any missile install. If you feel adventurous, you can not apply the above hack, and instead change the four missile entries to other items: just before the above no missile hack address, you will find BA28000000, BA31000000, BA34000000, BA35000000. Keep the BA there, but the next four bytes are the item ID (stored in little endian format, as per all intel asm). To make them only have sprats, change the 31/34/35 to 28.

I noticed that pirates (and to an extent the faction patrol/guard moths) that don't have a laser turret exhibit some strange behaviour... upon entering a crater where their Kill/Rob target is, they'll sit there, pointing at it until the target either docks or enters a tunnel to another crater. If the target didn't dock, the 'hunter' will continue this impotent behaviour.

I'm concluding that the AI isn't coded to purchase upgrades for the moth, except for a few items, namely flares, sprats and plasmakannons."

AI Plan/Orders notes, based on the writings of Duncan:

"There are Pilot IDs in the game, the Hangar ID in the game and the place to find the destination of the pilot. These IDs change (sometimes) each time you start Hardwar. To make this a little more trackable I will use a relative byte position. Therefore I will call the bytes E8 03 byte 0 and 1. E8 03 is a few bytes before the bytes coding for the name of the pilot. Example: 78 FC 5F 02.

Some 72 bytes before E8, directly before the whole bunch of FFFFs, that seem to separate each pilots block, is the ID of that pilot. It's 3 bytes, always followed by 02. With Hangars also an ID can be found, if you take the E8 03 before a hangar's name and you go back some 44 bytes you will find the code for that hangar. Example D4 4B C3 02. These bytes are preceded by FF 7F 00 00."

Based on 'Downtown Trader 3' in U3 beta 4: "The byte E8 (in E8 03) is used as the reference position and numbered 0.

starting at pos.4 - name of the pilot

Starting at pos.+300 are the orders/plans of the pilot. A row of 24 bytes stands for 1 order. The first byte identifies the order.

In this case Downtown Trader will go to the Mines crater, fly to Prison Mine, buy in total 16 units of ore and sell 8 units at Bargain Moths and 8 units at Shears Yard."

Other plans codes (plans as they appear in the terminal using exec [pilot],plans):

"A limited number of syntaxes are used for the plans rows. There's a syntax for doing something with a hangar - like 02 and 10. Something with goods like buy, sell, collect and dump. And something with coordinates - like FlyPos. Furthermore there are codes that are only present in these orders which function I do not know. They're not obligatory if you command a pilot.

Basically, if you want to command another pilot, you have to start a plan row with the necesary command, and add the basic requirements being e.g. the hangar to fly to or the type and amount and place to buy/sell/collect/dump goods.

Coordinate system example:

82 00 00 00 { 9B 92 86 *02* 52 B8 09 *00* 22 01 A7 *02* 03 } 00 00 00 2B 36 C8 0F

82 - FlyPos: This position is coded between the brackets. 2B36C80F can be left out. The stared (*) bytes separate the Y,Z and X coordinate (in that order). The three bytes that code for a coordinate are combined to form one hexadecimal number. Attention: start reading from the right. So 86929B and 09B852 and A70122. If you increase the X coordinate say from 00 00 90 to 22 01 A7 then the position is further in the North (or direction heading 000). If you increase Y - more east.

Got the altitude more accurately now, studied a couple:

This is not the entire altitude range of course. If you want to intrapolate or extrapolate you can recalculate the hexadecimal numbers to decimal and make a linear regression. Use the function for the line to calculate the decimal number and convert it back to hexadecimal."

Hangar header notes, based on the writings of smurph:

"Here is the structure of the first 3 lines (at line width of 24 bytes) of the hangar entries for the betas (and probably for 2.04 as well)."

Skip preformatted data

aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
00 00 00 00 00 00 00 00 bb bb 00 00 cc 00 00 00 dd 00 00 00 ee ee 00 00
ff 00 00 00 gg 00 00 00 hh hh hh hh ii 00 00 00 jj 00 00 00 kk 00 00 00

Solidox notes: "From memory, jj and kk are lighting and turrets thus why it only appears on faction buildings. There are two private/public fields, one is a bitmask inside the menu options field. The other, ii, is a hard lock which overrides the other one, it is used in the Abandoned Terminal and also is the reason you can't get into Colony HQ when you've purchased it."

U3 Beta Hangar notes, based on the writings of Wez:

Hex edit a savegame. The header block for each hangar can be identified from a four-character code followed by the full current name of the hangar. The four letter codes never change. They are:

Below the header is a series of data for each item. Each cell is 1 hex byte, so 4 bytes are used per property (long integer). The format is:

Skip preformatted data

HEX  Stock       Sell Price  Buy price   Max buy     Unknown     Produce Qty
Item ST ST ST ST SP SP SP SP BP BP BP BP MB MB MB MB ?? ?? ?? ?? PM PM PM PM

Item codes follow the same order as listed in Eight's AI Equipment notes above, except that Wez appears to starts the list at 1 rather than 0.

The footer block takes the form:

Skip preformatted data

?? ?? ?? ??|?? ?? ?? ??|?? ?? ?? ??|hangar cash|?? ?? ?? ??|?? ?? ?? ??
?? ?? ?? ??|?? ?? ?? ??|?? ?? ?? ??|?? ?? ?? ??|moth @ bay1|moth @ bay2
moth @ bay3|moth @ bay4|moth @ bay5|moth @ bay6|

UIM map, from Flap:

Data Structures, from Ciaran Gultnieks:

Moth data structure

typedef struct
{
D ObjType; // Object type when not fitted.
B Name[32];
B FragName[32];
D Mass; // Mass in kg.
D DragFactor;
B ArticName[13]; // Base of artic name. (e.g. "MOTH1")
D NumWeapPoints; // Number of weapons points. (In artic data!)
D PassengerSeat; // One if has a passenger seat, else zero.
ResID ArticID;
// D Structure; // maximum structure rating 0-0x4000
D Struc2;
D Value; // Base value of a moth built out of this frame.
ResID Frag[4];
} Frame;

Object data structure

typedef struct
{
B TName[32]; // Name used in terminal commands
B Name[32]; // Original 'game' name
D Value;
D Properties; // Properties - see OP_xxxx in OBJECT.H
B CompShapeName[16];
B Description[256];
D Mass; // Mass per unit in kg.
} ObjDef;

Master object type list

The properties applied to an object type are defined as a bitmask. They're as follows:

Engines data structure

typedef struct
{
ObjType Type; // Object type when not fitted.
D MaxThrust; // Thrust provided at max power.
D CThrust; // Control thrust provided.
D IdleUsage; // Power usage when idle - includes power used
// to defy gravity!
D ThrustUsage; // Power usage per second at max power, on top
// of IdleUsage.
D ControlUsage; // Power usage per second for control thrust.
D Mass; // Mass in kg.
} Engine;

This is the actual data:

Engine EngineList[EngineNum+1]=
{
OT_None, 0, 0, 0, 0, 0, 0, // 0 - Not a valid engine.
OT_Engine1, Metre*70, Metre*40, 200, 2000, 200, 400,
OT_Engine2, Metre*95, Metre*50, 300, 2500, 200, 600,
OT_Engine3, Metre*115, Metre*60, 150, 3000, 200, 800,
};

Cell data structure

typedef struct
{
ObjType Type; // Object type when not fitted.
D MaxPower; // Power held when fully charged.
D ChargeRate; // Recharge rate at max light, per second.
// If zero, recharges to full all the time. (Fusion!)
D Mass; // Mass in kg.
} PowerCell;

And the data...

PowerCell PowerCellList[PowerCellNum+1]=
{
OT_None, 0, 0, 0, // 0 - Not a valid cell.
OT_Cell1, 2000000, 410, 10,
OT_Cell2, 4000000, 810, 20,
OT_Cell3, 2000000, 1010, 40,
OT_Cell4, 1500000, 610, 50,
OT_FCell, 2000000, 0, 30,
};

D=DWORD and B=BYTE.

Scale-wise: