Creating the flying-casting-moving building thingamijig:

Utilities...

Utilities/tools that are useful (and are necessary) include ICE, Stargraft, and Arsenal 3 for the .dat editing; a file/hex editor will be useful. For editing or creating GRPs, I used RetroGRP to bind/unbind the GRP files, and Paint Shop Pro 6 for the resultant BMP editing - although MS Paint can be used as well. For .TBl editing, either the TblEdit program built into stardraft patch editor and another text editor will do, or use an alternative tbl editor such as Shadowflare's - this has much of the necessary functions for tbl editing.

I assume you know the relationships between the various .dat files, and how they work with each other (if not, i suggest you read some tutorials on this ... such as in SCEB). We ideally want use unused entries in each .dat file, if we want to create a new unit.

Unit GRP graphics

A typical building has a building, idle, active and damaged (blood / fire) animations. Mobile [terran] buildings have a landing, lift-off and moving sequence. Turrets (cannon, colonies) have an attacking animation. In general, buildings are not rotating units, thus they only need one copy of the animations. As the Colosseus is a ship, it needs to be able to rotate, and so, needs 16 images of the ship in various directions. As it is also classed as a mobile building, it will also need the landing /liftoff / damaged / building / etc... images ... and these images are not rotational!

So here, we have a unit that rotates, but wants to be a building... in that case, we need a GRP that has the relevant moving animations - and in the right order - this will help and simplify things when editing the iscript for this image.

Firstly, the graphic for the unit has to be set-up - i used Retrogrp to extract the BMP images from Wind of the Past's ship GRP.The images are duplicated, and reordered - thus, we end up with a GRP file (after grp 'ing it with retro) organised (theoretically) like this:

Frames (0 - 20)

0-15	(idle) rotational anim. Also attacking and moving poses
16-17	Building (in-construction frames)
18-20	lift off / land

The idle animation will also be used for moving and spell casting.

IScript.script

Being too lazy to hex edit iscript, I used ice v2 instead (which is also far quicker than manual editing), with its ability to add new headers. None of the existing iscripts cater for this unit, so I just created a new one. The headers are obvious in what animations they are for, although the spells and unknowns will not be so obvious.

There is only one relevant spell header to use - 'Spells 2'; the other spell headers: i don't know what they do; and afaik, no-one else knows, at the moment. Correct me if I'm wrong.

For the unknowns in ICE 2:

Unknown 2	building in progress frame (i.e. being built)
Unknown 3	Building completed
Unknown 4	Landing
Unknown 5	Lift off
Unknown 6	Working (i.e. building is researching / constructing)

The script in spell casting2 consists of setting the graphic to the relevant orientation (Show 0), and calling order 2. The 'unknowns' just set the graphic to the relevant frame(s) (animating when necessary).

The attack animations are interesting; for each "Atk with weapon x" call, the unit will attack once; thus, a script with

"Atk with weapon 1";
"Atk with weapon 1";
"Atk with weapon 0";
"Atk with weapon 1"

will lead to the unit attacking 4 times, in one call, first with weapon 1 twice, then with weapon 2, and finally, one more of weapon 1. Ideally for the full visual effect, 'Wait x' are placed between each 'Atk...' command, so that it does not appear to be like a single strike - so thus:

Atk with weapon 1
Wait 3 tick
Atk with weapon 1
Wait 3 tick
Atk with weapon 0
Wait 3 tick
Atk with weapon 1

The death animations are even more interesting. The explosions are usually caused by the command 'Place active overlay x'; it causes a new graphical animation to be started, complete with its own iscript. I gave the Colosseus a standard medium terran-orange explosion - complete with sound effects - with a few ticks later, another overlay - a protoss explosion is placed - hence the orange-yellow-blue effect.

Finally, it is important that the iscript header is given a unique ID - so it doesn't conflict with the other headers; this has to be noted down, as it will be bound to the grp in images.dat. (The ID # used for this iscript is 420).

Once the unit graphics (grps) and iscripts are prepared / finished, the next stage would be to implement them through .dat editing.

Images.dat and Images.tbl

Assuming that the graphic is to be added into the system, and not to replace existing grps, the first step would be to append the filename to images.tbl - which contains the list of all the grps in starcraft. The filename would correspond to what the graphic is stored as in the mpq I am to use to patch into SC. The name of the graphic i am using is 'colos.grp'.

By default, the images.tbl would have prefixed every file with 'unit\', so as to expect all grps to be found in the directory 'unit\' of the mpq. For sake of neatness, I stored the graphic (and other associated files) as 'unit\terran\colos.grp' so thus, the entry in images.tbl is 'terran\colos.grp'. The index (or line) number must be noted - for reference in images.dat (here, the grp is index/line no. 930). The other relevant 'lo?' files are also included here. Without editing SC to increase the number of entries there are in images.dat, a spare - unused image slot has to be found - the entry I used is (ID) #353 (named 'unused' in Arsenal 3).

The images.dat contain various settings of relevance to the images.tbl file, the grp and the iscript. For each setting:

File: refers to the grp entry number in images.tbl - set to 930;
Gfx Turns: specifies whether the graphic is rotatable / turns. Ticked.
Shadow Turns: specifies whether the shadow turns; ticked
Unknown: not sure what it is, but most active-units (those that are not shadows eg.) seem to have this set; so therefore, set.
Float: whether the image floats over stuff or not; set.
Palette type & Palette: standard unit with standard colours, and so is set to the default settings ('Unit default' and default (0) palette)
IScriptID - correspond with the appropiate iscript; set to 420;
Shield Overlay - the shield image to use when it is struck... set to 2.
Overlay 3, 5 and 6 each correspond to a different '.lo?' file, and has the associated file entry number as such.

The shadow image is, or can, also (be) set-up in another unused entry... this uses the same grp as above, but the palette is set to a shadow palette; and the iscript ID is set to the shadow iscript - used by other shadows - of 275.

Sprites.dat

The various parameters used for a unit when it is selected are specified here - parameters such as unit hitpoint bar length, selection circle size etc... As with image.dat, an unused entry has to be found - one such is at sprite entry no / ID #282.

The main parameter - Sprite: corresponds to the image.dat ID# - here, for this mod, set to 353.
The others are either unknown, or just aethestics in how cursors and circles are displayed.

Flingy.dat

Contains speed / movement data for the units; unit.dat also refers to this dat for the images. I also, at present, know only of 1 spare entry - id #121. Obviously, i would use this for the colosseus sprite.

Most of the parameters are obvious (in Arsenal 3 anyway); and as the colosseus is based as a building, the move control parameter is set to partially mobile.

Units.dat:

As the graphic used is large in area size, I used the unit slot #110 - this is named 'Unused - was Starbase' in Arsenal 3 - this unit by default has the medium-large size. Arsenal 3 cannot edit the width and heights of the units - this has to be done via hex editing (although the offsets has to be known / found to change the sizes this way). The unit number is important - this will be used in Stargraft.

Most settings are obvious, and set accordingly to match the unit specification, however...

In advanced settings (of arsenal 3), the parameters: is building, flying building, spellcaster, attack, and huge unit - are all set; the rest are unset.
The appropiate sight range, size, and movement flags are set to reflect the unit specification.
As the unit is based on a ship, it is given the armor upgrade type of Terran Ship.
The sprite is set to the flingy ID used for the image; however, arsenal 3 does not allow direct ID entry, so hex editing is more useful for inputting the specific numbers.

Stat_txt.tbl and Strings:

Before using Stargraft, it may be a good idea to modify and append to the strings tables. Stat_txt.tbl contains pretty much most, if not all, of the label, text and name string references. Generally, it is possible to use the TblEdit built into StarDraft, and use the export/import Ascii functions to add extra lines to the tbl. Alternatively, I could have used TblPad which includes the ability to add and remove lines.

However it was added, these are the lines appended:

c<1>Build <3>C<1>olosseus<0> Requires Science Facility<0>
v<3><3>V<1>omit<0>
r<2><3>R<1>esearch Warp ability<0>
r<3>Wa<3>r<1>p Units<0>
d<2>Research <3>D<1>isruption Barrier Field<0>
d<3>Generate <3>D<1>isruption Barrier Field<0>
b<2>Research <3>B<1>iological Disruptor<0>
b<3>Generate <3>B<1>iological Disruptor<0>
c<3>Initiate mobile S<3>c<1>anner Sweep<0>
u<4><3>U<1>pgrade Shield Strength<0>
_s1<0>
_s2<0>

stat_txt.tbl Label Format:

Certain strings - labels - in the table follows a simple format: ( number of characters ):

shortcut key (1)
Label type (3)
Label (... until <0> )

The label type is in the format '<x>' where x is one of the following:

0 - Command/Order Label
1 - Label with Mineral/Gas/Supply cost - construction
2 - Upgrade label (usually with mineral / gas cost)
3 - Spell label (may have mana cost)
4 - Research (with gas/mineral costs) Label

So e.g.:

t<3>Do this do <3>t<1>hat

would indicate that:

t is the shortcut key;
It is a spell label;
The first letter of 'that' is highlighted in yellow.

Stargraft labels:

Due to slight differences with the text strings in Stargraft and stat_txt.tbl, there would be problems if they were interchanged. Instead, a seperate file - initially a copy of data\text.dat (of the Stargraft folder) is used - and the extra stat_txt.tbl / text.dat lines are appended in a text editor. This is then loaded into stargraft using the Load Strings function.

Stargraft

Here, a new button group, or two, must be added. The tech. requirements must also be modified to enable the spells and research in the colosseus unit.

Button Groups

The new button group is constructed from a mobile building's group - e.g. the science facility. There should be these buttons for when the unit is not lifted-off: (hence, a requirement is 'Building has landed')

(1,2,3) Spells - warp, disruption web, maelstrom

(7) Research spells menu - Action 'Change Displayed buttons'

(9) Liftoff - Action variable is this unit number (i.e. '#119')

For the unit lifted off: (hence the requirements for the buttons include 'Building has lifted-off and can move'):

(1-5)	Move, Stop, Attack, Patrol, Hold - standard moving actions
(7)	Yamato Gun - 'Use Technology'; action var. is the Yamato Gun.
(9)	Land - with the act. variable as the unit number (119)

The button list will have to be set up so i.e. those in position 1 have to be before any position 2 buttons... the buttons commands must be placed in order, or else starcraft will do weird things with what or which button appears.

After the button the group has been set up, this will have to be assigned to the unit which will own these buttons ... hence unit #119 - which corresponds to the unused Starport - are assigned these buttons in the Unit page.

The tech. research button group - which is triggered by the Research Spells button ( the action var. pointing to this button group ) are basically copies of other spell research buttons - where the typical format is:

(Position and icon are aethestics... but the button positions must be in ascending order)

Requirement:	Tech/Spell not researched
Action:	Research Technology
Requirement Variable:	Tech. number
Action Variable:	Tech. number

There is also a 'Cancel' button which changes to a 'blank' menu -

Requirement:	Always
Action:	Change Displayed buttons
Requirement Variable:	n/a (i.e. any)
Action Variable:	#228 (Blank)

The final stage would be to assign this button group to an unused unit - in the Unit page. This is as the 'Change Displayed Buttons' action used in both button groups (and i.e. in the Basic Building menu buttons) refers to the unit number for the variable. For the Colosseus research button group, this was assign to the unused 'Mining Station', number #182.Hence the action variable of 'Research...' in the main Colosseus button group is #182.

The SCV Construction Menu

So far, the above steps are concerned with the Colosseus command menus. At the moment, there is no way this can be built, as there is no button concerning this. As the original intention was for it to be built by an SCV, and the only button space left is in the Terran Advanced Buildings group, a button is created here... this is in a similar style to other terran buildings:

Position	5
Requirement	Can create unit/building
Action	Create building (Terran)
Req. Var	119 (unit.dat ID, Unused - starbase)
Action Var	119

The 'Advance Terran Building' entry in the Unit page should also be updated to reflect the increased number of buttons.

Technology Requirements

If we run the patch as it is, several things may occur:

the buttons may not appear at all;
Buttons appear, but they do nothing.

Mostly, it is due to the Requirements not being set. The Requirements page show certain 'rules' which describes what is needed for a certain unit to be built, technology to be researched, or spell for it to be cast, e.g.

There are several things to remedy here:

allow the SCV unit to build the Colosseus.
enable the 4 techologies to be researched by the Colosseus;
enable the 4 techologies to be used by the Colosseus;

(1) requires the Units section in Requirements;
There is currently no entry for the Colosseus; a new entry will have to be added. Hence the menu 'Add -> Requirement'. The resulting pop-up window would show a list of all the units - and we will have to use the original name for the unit that the Colosseus is using - 'Unused - was Starbase'. Whether we create the requirements from scratch, or use an existing Terran Building requirement does not really matter, as long as it ends up with the requirements we want, but obviously, being lazy is less hard work ;).

Hence, the Colosseus unit requirements, in order, are:

Flag	Current Unit is [next requirement...];
Unit	Terran SCV
Flag	Current Unit must not be constructing
Unit	Terran Science Facility ; (shows that the facility is needed before it can be built)

For the spell requirements, certain requirements are only added to the existing technologies - ideally, they are placed just before 'Current unit is not training or upgrading';

Flag	[previous requirement] or [next requirement]
Flag	Current Unit must be [next requirement]
Unit	Unused - was starbase

The same can be applied to the Tech. Use requirements, but can usually be placed at the end of the requirement list.

Note:

When working with Stargraft, it may be a good idea to save different versions of the patch as you go along, as SG may have occasional tendancies to disrupt the data, or cause a execution fault, which causes it to crash/quit when you've just done a lot of editing.... it's happened at least once at least 3 times in a row, wasting me a good hour... and if you've ever found strange unexpected results (such as missing buttons) in a patch, you would be glad that you've saved other revisions of the patch.

MoPaQ?

Once all the files are ready, the next step would be to archive them all together into an MPQ (except for the stargraft files). For a number of reasons, I will be using a copy of patch_rt.mpq, renamed to 'colos.mpq'.

Using MPQ2k is easy, if you know how to use the DOS command line interface, and archivers such as pkzip. In general, I created a script which allows me to recompile an entire MPQ on demand.

Firstly, the files should ideally be arranged/organised into their respective folders - i.e. *.dat files go into arr\; 'iscript.bin' in scripts\, and so on. This enables a short & simpler script for mpq2k:

O D:\Starcraft\colos.mpq
a arr\*.* arr\
a rez\*.* rez\
a scripts\*.* scripts\
a unit\terran\*.*
C

This assumes the command is executed in the same root folder as the file - hence:

mpq2k s myscript.script

Finally, in order to use the altered mpq, I created a copy of starcraft.exe, renamed colos.exe. I then used StarExeHack to modify this copy to load 'colos.mpq' instead of 'patch_rt.mpq'. This enables the standard starcraft setup is left alone; running this patch only needs a double click on the modified executable.

Last notes: I haven't gone into detail about the .lo? files, b/c frankly, I know sh*t about what they do. Also I just hope this has answered more questions than has been created, and hence, was actually of some help ;)

Programs and files:

Stardraft, Stargraft, ICE, Arsenal 3 - www.Camsys.org

StarExeHack, TblPad, LoEdit - - Shadowflare's Page

Mo'Pa'Q 2000 - www.campaigncreations.com/starcraft/mpq2k/

RetroGRP - www.infoceptor.com/ somewhere... ?? Anywhere?

Hex Workshop v3 - www.bpsoft.com/