Welcome to the Klingon Academy.com Modding Tutorial Page. Here you will find instructions and links for the information to get you started on making your own mods for Klingon Academy. For a breakdown of the tools you will need to mod for Klingon Academy, please refer to Question #14 in the Klingon Academy.com Modding FAQ.

Here are detailed instructions of how to make a Shield Object File and apply the Shield Utility Processor to it.

Step 1 - Make a Shield Bubble

This tutorial assumes one has the basic understanding of using Lightwave Modeler. Using said program, create a bubble to the shape that one desires. Name the appropriately corresponding polygons with the following surface names:

ShieldAftShieldBottomShieldForeShieldPortShieldStarboardShieldTop

Save the object with the name of:

Shld_1_0.lwb

To clear up some of the mystery surrounding the LWB file extension, it is no different than an Object File with a LWO File Extension so you have a choice of either naming it with the LWB Extension during the File Saving process or renaming the LWO to LWB afterwards.

Alternatively, one does not have to name the Shield Object File "Shld_1_0.lwb". It can be any name you like up to 8 characters, so long as the entry in the SHP file matches the Shield Object File name as shown in the following line:

Shieldname:shld_1_0

NOTE: It does not contain the file's extension.

I would advise everyone to use the name above for simplicity's sake and maintaining a Common Modding Language.

In Lightwave Layout, load the Shield Object File and apply any texture you wish to it.

NOTE: As a short cut, if you like the way a particular ship's shields look in game and you want yours to look the same, then copy that ship's Shield Object File and reshape it to your liking or load your new LWB file in Lightwave Layout, then load the Shield Object File of the Ship you like and watch the textures instantly be applied to your Shield Bubble. Hit the "Objects" button at the top and then hit the "Save All Objects" Button and your finished with textures. One does not need to save the Scene since you've saved the Object.

Instructions are as follows:[list=1][*]Go to the dos prompt.
[*]Change to the directory your Shld_1_0.lwb file is in. The Sprocess.exe and Dos4gw.exe files must be in this directory as well. Does everyone remember their DOS commands?
[*]Type in >>> sprocess Shld_1_0.lwb Shld_1_0.sld[*]That's it. You should notice that the program has made a new Shld_1_0.sld file. Copy these to your ship folder.[/list=1]

Since I think DOS is a pain in the butt, I have since made a BAT file to avoid all the DOS work.

As before, ensure all the Shield Utility Processor Files and the LWB file are in the same directory. Click/double click (depending on your computer settings) on the BAT file and voila...it saves you from doing all the switching to DOS prompt and change to the directory crap.

So...you've been hooked by the modding bug and you find it consuming every free minute you have.

You've built the model, done the ship stats, weapons and she's in game but she looks, well, bland, dry and lifeless. Why? (Pun intended!!) She can probably stand to use some lighting to bring out her finer points, subsequently, adding realism and giving her a sense of scale. It can also change and/or set the tone of the ship ranging from something ominous to industrial or organic.

Lighting is like the icing on the cake. It's the finishing touch that redefines a good mod into a masterpiece. Modding Klingon Academy is a bit of an art, only in the sense that you make whatever you envision and there are no limits to your imagination!!!

There are 3 main types of lighting. They are texture, polygon and point based. Each method has their strengths and weaknesses. Examples of each method's strengths are as follows but not necessarily limited to:

Texture: Impulse engine core glow, warp nacelle core glow, windows.

Polygon: Impulse engine core glow, warp nacelle core glow.

Point/Source: Ambient glows, casting from a defined source.

In this tutorial, I will cover how to create lighting via polygon and point. I hope from this that you will have a better understanding of how these methods work.

A polygon from a Lightwave Object can be made luminous (bright and/or glow). The surface for candidate polygon(s) needs to have the following setting applied to it in Lightwave Layout under the Surface Palette.

Luminosity = 100% (or anything greater than 0 depending on your need)

You can tie the luminous polygon(s) to a System Resource so that it will increase and decrease in luminosity (eg. Impulse Engine Core, Warp Nacelle Glow, Photon Torpedo Tube). You must add the name of the Resource it is related to, to the surface name. Surface naming convention is as follows:

XXX = 3 numbers that represent the model number. They can be anything numeric. I always use 001. These numbers can be used as a tool for sorting Surface Names.

Dxx = the Resource Number that directly corresponds with the Resource number(s) in your SHP File. It is alpha numeric and is the letter D followed by a number(s). Eg. D10. Refer to the SHP File Tutorial by BSM-Amram for more information.

FIXED or BROKEN or nothing = Tells the game engine that the subject Surface is either rendered in game under undamaged, destroyed or always visible conditions.

Surface Name = Can be anything, alpha or numeric or both, typically a logical name of your choosing.

[Resource Abbreviation] = Name of the Resource the Surface will be tied to. System Definitions are as follows:

You can create Point/source and Spot Lights by using Single Point Polygon(s) instead of Luminated Polygons or Textures. I will be honest with you, this method, while the most rewarding, is also the most difficult to get right.

Once you've initially set it up, it can prove to be a laborious process of fine adjustments and reloading (not regenerating ATK's per say) to get the light(s) to perform as intended. There are other hindrances to consider if all is not going well. Having said all that, the intent is not to discourage, but encourage as this method is my favorite of the 3. Point/Source and Spot Lights used in partnership with the other two are a deadly combination that will make your mod stand out amongst the rest.

CREATING A SINGLE POINT POLYGON (SPP)

Lets get some of the mystery surrounding Single Point Polygons cleared up. SPP's in Klingon Academy have many uses. They vary from Lighting, Weapons, Debris, Fighter Launch to Camera for exterior view. In short a Single Point Polygon is exactly as it's name implies.

To make a Single Point Polygon, open Lightwave Modeler, select the Polygon Tab at the top, then on the left menu, select Points (or + button). Pick a location to
make a point and then hit Enter. You should now notice a new point and at the bottom menu right next to the volume button, the 0 changed to a 1. This means that 1 point is selected. We now have to change the point into a polygon. The simple method is to hit the P button or on the left hand side menu, deselect the Points (or + button) and then hit Make (or P button). That's all there is to it. You can now give that Single Point Polygon a surface name just like the rest of your model has.

For all SPP Lighting, the format of the light names, as read by the Klingon Academy engine is as follows:

XXX = 3 numbers that represent the model number. They can be anything numeric. I always use 001. These numbers can be used as a tool for sorting Surface Names.

Dxx = the Resource Number that directly corresponds with the Resource number(s) in your SHP File. It is alpha numeric and is the letter D followed by a number(s). Eg. D10. Refer to the SHP File Tutorial by BSM-Amram for more information.

FIXED or BROKEN or nothing = Tells the game engine that the subject Surface is either rendered in game under undamaged, destroyed or always visible conditions.

Surface Name = Can be anything, alpha or numeric or both, typically a logical name of your choosing.

[Resource Abbreviation] = Name of the Resource the Surface will be tied to as outlined above.

Color = You tell the engine the colour of the light here by specifying the Red, Green and Blue values in the format 255,255,0 (for yellow).

Distance = The distance in metres of the radius of the light (eg. 1 would be for a one meter radius). I have used numbers with decimal places (eg. 2.5).

Behavior = Tells the game how the light behaves (eg. On/Off, duration and ramp up and down time, random flickering). Codes are as follows:0 = Always on.1 = Light flickers randomly.2 = On 1/8 of a second, off 7/8.3 = Ramps up 1/2 second, ramps down 1/2 second, off for 1 second.4 = Light flickers randomly.5 = Light flickers randomly.6 to 15 = I have not experimented with these.

Intensity = How bright the light is. 0, none to values over 100 can be used.

Cone Angle = This is the angle in which the light fans out. The cone angle has to be 360 for Point/Source Lights and 90, 45, 23, or 12 degrees for Spot Lights.

Remember that each section is separated by a ":" and each set of numbers within a section is separated by a ",".

SPOT LIGHTS

Create two separate, SPP's, one for the light source and the other for the direction the light is pointing. Think of it kind of like weapons Start and Dir Points.

The naming is generally the same as above with the addition of "-d" for the source light as shown in the following example:

eg. 001_D03_FIXED_!IMPULSE_GLOW[Impulse]-d:255,75,0:6:0:30:90

Notice that the angle cannot be 360 degrees.

The Direction SPP is named with a "-D", without the parameters and is shown in the following example:

eg. 001_D03_FIXED_!IMPULSE_GLOW[Impulse]-D

Note that for this system to work, the Source and Direction Point Surface Names must be identical.

As a rule of thumb to start, create and/or place the SSP at half the distance specified in the surface name away from the actual surface/polygon you are trying to light up. Alternatively, one can measure the distance in LW Modeler and double it's value for the surface name. Taking the above example, 6 = 6 metres, therefore you would try to place the SSP 3 metres away from the actual surface/polygon you are trying to light up. Once the light works in game, you can adjust the distance physically and change the Radius and Intensity via Surface Naming to suit your needs.

TYPICAL PROBLEM SOLVING FOR POINT/SOURCE & SPOT LIGHTS

Now that you know how to make Point/Source and Spot Lights, your no doubt going to try it for yourself. Great!!! Here are a few standard problems I've encountered and some possible solutions.

No light is cast onto the model in game.

Is the SSP light apart of the same Object file as the surface/polygon you are trying to light up?You can't get away with a separate OBJ file for light points like you can for Debris Points. If you should have multiple OBJ files and you are trying to light up a part of a ship that is broken down into more than one OBJ file, you must add a SSP light to each relevant OBJ File.

Is the Radius larger than the measured distance from the SSP to the surface/polygon you are trying to light up?

Is the Intensity high enough?

Is your in-game lighting too bright?

Is the Lighting Direction point (if your using one) pointed in the right direction? You may have to reconstruct polygons by a more systematic and geometric convention. Flipped/Mirrored polygons can sometimes be troublesome.

There is no fade-off to the light.

Is your intensity too bright?

Is your specified radius in the Surface Name too large?

Two lights near each other do not properly light the hull as compared to when there is just one light.

Do the specified radius of the lights overlap one another?

Are the Intensities too bright?

Should you encounter any other problems, email or PM me and I will post a solution, that is if there is one!

(It is implied that you have a fundamental knowledge of how to mod KA)

You can go from a FIXED to a PAINT Surface the same as with a FIXED to a BROKEN Surface. What PAINT is actually telling the game engine is that a PAINT/BROKEN surface is a FIXED surface for another damage resource. It will force a broken part to stay until another resource is killed.

Example, a warp nacelle where you can blow off the front or back and still have it attached to the pylon, then when you destroy the pylon, the whole warp nacelle is destroyed.

Lets use for example, the TOS Connie nacelle with the rotating boussard ramscoop set as D01 and the remaining nacelle and pylon set as D02.

Now you want the process to be in this order, D01 to kill the boussard ramscoop, then D02 to blow the whole warp off. Here’s how you name them.

Name the fixed surface for the boussard ramscoop like this:
001_D01_FIXED_!nacelle_frontl

Then for the broken surface:
001_D01_PAINT_D02_FIXED_!nacelle_frontl

What this does is even after resource D01 gets destroyed/murdered, the game will still leave the ginsued part visible until resource D02 gets destroyed/murdered.

Now for the second part, the pylon and the rest of the warp nacelle will be named as conventional ginsu with a FIXED and BROKEN Surface. For example:
001_D02_FIXED_!warp

And of course the broken surface to match as:
001_D02_BROKEN_!warp

This effectively ties the physical polygons together, good for damaging parts the in the end completely blowing them off. You still have to undertake the proper SHP File entries for Resource Hitpoints, Murder/Suicides, etc.

Now, what is generally not known and may be of real importance to some of the modders out there is that the PAINT Surface is displayed all the time since it functions as a FIXED Surface for the second resource.

In the example above, the D01 FIXED and PAINT Surfaces are both visible from the get go. Once D01 is destroyed/murdered, then the FIXED Surface vanishes and the PAINT Surface remains until D02 is destroyed/murdered.

This represents a problem, specifically in my case because I like to use a second set of bmp's to show a scorched hull. These "scorched bmp's" will show up from the get go. This is not a problem for stock KA ships nor to those modders that use un-scorched textures for the BROKEN Surfaces.

The easiest fix/work around that I am using is to have the PAINT Surface physically hidden underneath the FIXED Surface. The only downside is that 9 times out of 10 you will be increasing the point count of the model because you can no longer share points for the FIXED and PAINT Surfaces like you can for the FIXED and BROKEN Surfaces. The increase may not be significant but if you plan on using this technique extensively, point count is something you should be conscious of.

I hope that may clear up some of the mistyque behind this technique and that this tutorial will encourage more modders to use this wonderful Ginsu Option/Alternative.

Textures can be animated on a polygon in Klingon Academy, using a sequence of up to 16 bmp's and pcx's.

These can be composed following the same guidelines as other textures in the game, however they require a naming convention for the game to recognise that they're supposed to be displayed on the surface in a given sequence:

Cy#xxxxx.bmp

or

Cy#xxxxx.pcx

The "Cy" tells the game that this is part of a sequence of textures that are to be "cycled". The "#" is the number of that particular texture, starting from 0 and running through 9, and continuing from a to f for a total of 16 textures. The "xxxxx" is your identifier for this sequence, and should remain the same for all of the textures you make for any given sequence. Otherwise the "xxxxx" can be named anything you want.

Only the first texture in the sequence (Cy0xxxxx) is applied to the surface. Both a bmp and pcx can be applied (if a transparancy or lightmap is needed), and is applied the same way as other textures. Here is a template list of the texture names in their proper sequence:

The DAT File Extractor is a must have tool for the die-hard KA Modder. It opens the doorway to all the nitty gritty files for Star Trek, Starfleet Academy and Klingon Academy.

The following is a list of files that this tool will decompile:

From Starfleet AcademyINSTALL.DAT DATA.DATMUSIC.DAT

From Klingon AcademyDATA.DATPATCH.DAT 1.01PATCH.DAT 1.02

It is suggested, well urged that you decompile in a temporary directory. This way you do not overwrite any installed mods. Also you should have at least 510MB (size of all the files extracted from the Klingon Academy DAT file) of free HD space and 128MB of RAM.

Manual Instructions[list=1][*]Unzip the contents into your working folder.
[*]Copy the DAT file into your working folder.
[*]Go to the DOS Prompt.
[*]Change to the working directory.
[*]Type in >>> Attrib *.dat -r -a then hit enter.[*]Type in >>> extract -e data.dat then hit enter.[*]The files and folder structure should extract into the working directory.[/list=1]

Alternatively, just click on the runme.BAT file and viola, your done.

Credits:
Original Documentation
John Addison AKA SupremeVortex (remember that name!)
James Burrows

This tutorial covers how to generate palette (PAL) files for graphic type items such as menus, buttons and load screens in Klingon Academy using the Klingon Academy Palette Utilities.

How to create the pictures and what to name them will not be covered here. All of KA's menus and buttons can be found under the game's "Gfx" folder. If you haven't already, extracting the game data from the "data.dat" and "patch.dat" files with the DAT File Decompiler Utility will afford you the oppurtunity to browse through and find out what file names you need to overwrite with your new graphic type items. At this time, it is not known if additional graphic type items can be added to the stock items.

Menu graphics and load screens in Klingon Academy are always 8-bit files (256 colours) with a maximum size of 640x480 pixels. If converting from a 24-bit file (full colour) make sure you use "Error Diffusion" dithering for the best results.

Please note that KA uses one palette for each screen so if different elements such as buttons or load-status bars appear onscreen, they have to use the same palette as the background picture/graphic, and vice-versa, or their colours will not display properly. Make sure all elements for that screen conform to one palette, or one set of 256 colours.

Alchemy.exe will generate the raw palette file (filename.pal) for the pcx. It cannot be used in KA's format quite yet as the colours will display improperly. The standard convention for the program is:

Alchemy -[option] inputFile [outputFile] (-h for help)Typing Alchemy -h will give you a substantial help menu. I encourage you to explore it. Note: The control, -o will allow you to overwrite previously created PAL Files.

Invcmap.exe will correct the colours in the PAL file. The standard convention for the program is:

invcmap -n -c [source.pal] [destination.pal]

Included in the Palette.zip file is a BAT utility that saves you from going into DOS. Make sure that all the exe's and PCX files are in your working directory and double click on it. In order to function properly, your working PCX will always have to be named 1.pcx. You will have to subsequently rename both the PCX and PAL files to your liking after processing.

The PCX is placed in the "Gfx" folder, and the PAL is placed in the "Palettes" folder. Both are found under your "Klingon Academy" directory. If these folders don't appear there, you can create them.

Credits:
Special thanks goes out to Kt'Hyla for taking alot of his free time to experiment with this tool and providing the basic instruction as seen above for this utility. A true professional that continues to demonstrate his commitment to this communtiy.
John for passing the tool along to Kt'Hyla and I for release to all of you.
Some additional support can be found here.

NOTE: This tutorial will evolve over the next few weeks as I am writing this on the fly.

This tutorial assumes you have good working knowledge of Lightwave 5.6 and is based on creating a scene file for a Constitution Class Starship.
[list=1][*]Open Lightwave Layout.
[*]On the left hand menu, CLICK and HOLD Add then select Load Object File.
[*]Select from your computer, the LWO (model/object) that represents the Primary Hull (Disk). You will notice at the bottom middle next to "Selected Item", that this object file name is showing and truly means that this object is selected.

We will consider this to be the PARENT object although no special coding/setting change is required.

[*]Repeat #2 and load the object file that represents the Secondary Hull. You will notice at the bottom middle next to "Selected Item", that the object file name has changed to that which represents the Secondary Hull, which is now "selected".
[*]Select from the left hand menu, the forth button from the bottom, Parent.
[*]Select the file name that corresponds to the Primary Hull and then CLICK OK.

What you have just done is told the scene file that there is a relationship between the Primary Hull and the Secondary Hull. In this case, the Primary Hull is the Parent of the Secondary Hull. It is good to get into the habit of establishing relationships in your scene files as that is key in making more complex scenes which will be covered in Tutorial 7b and 7c.

[*]Repeat Steps 4, 5 and 6 until all parts are in the scene.
[*]CLICK and HOLD bottom middle Button next to "Selected Item", select the file that corresponds to the PARENT object which in this example is the primary hull in order to select it.
[*]Directly below that, CLICK Create Key and another menu should pop up.
[*]Ensure that "Create Key at" = 0 and "Create Key for" = All Items.
[*]Repeat #9.
[*]Ensure that "Create Key at" = 1 and "Create Key for" = All Items.
[*]Save the Scene to whatever name that corresponds with the SHP file.[/list=1]

The following is a list of different error messages and crash conditions that you may encounter when trying to load a newly built mod in Klingon Academy. This should help you narrow down the source of problems when creating a new ship. “Debug / Error during execution: Couldn’t load ship…“

This error is quite distinctive, since it is generated by KA itself. This means that KA couldn’t find any ships matching the QBShips line that was selected. Check the QBShips line against the ‘Name’ entry in the shp file and make sure they match exactly.<o =""> [size=100]Game freezes while the Green Loading Bar is advancing:

No need to worry about this one. What is happening is KA is generating a new ‘.atk’ file for your ship. This may take anywhere between a few seconds to 20 minutes on more complex ship setups. This file enables KA to calculate different values such as hit points, weapons strength, etc, and how they interact with one another in the game.

Game crashes to desktop without error message:

This may be that there is a line in the _def.lws file that doesn’t have a matching .lwo object to load. Check your .lws file to make sure that the name in the ‘LoadObject’ line is spelled the same as the .lwo that it’s trying to load, and that the .lwo itself is in the proper folder. Also check to make sure the corresponding line in the shp file matches the name of the lws if you've changed the name of the ship.

“This program has performed an illegal operation and will be shut down.”

This appears as a generic Windows Error Message pop-up. This can occur under a number of different circumstances:

One of your textures may exceed 256 pixels. Check the size of any textures you may have applied lately to make sure they’re under this limit. It’s also a good idea to keep the sizes in multiples of 4 (32, 64, 128, etc), otherwise other odd visual effects can occur on the model in the game.

If the game crashes and produces this error message when you try to fire weapons, it means that there is something wrong with your weapons setup. Check to make sure all weapon points on the model have matching resource lines in the .shp file, and that all weapon point surface names and weapon resource lines are spelled correctly.</o>[/size]

Basic troubleshooting skills are paramount when building any mod. Murphy’s Law governs Klingon Academy, just as everything else. “If something can go wrong, it will.” It doesn’t matter if you’re a complete newbie or a three-year modding veteran, you will miss at least one detail that will cause a crash.

The first thing is to make sure you’re breaking down the modding process into digestible segments. As soon as your mesh is made, set up a basic .shp file and QBShips line to get it in-game. By basic, I mean stripped down of any weapons resource lines. You shouldn’t have added any textures or weapons points yet. If this new mesh loads okay, then move onto texturing the model. Load it up in the game every so often to make sure you haven’t made a mistake. This way, if something does go wrong you’ll still have what you’ve done recently fresh in your mind so you can narrow down what’s wrong. If the ship continues to load okay after all your textures are applied, then continue on to adding weapons.

Weapons are the most finicky part of modding, and should be added last to keep problems with them isolated. 95% of crashes happen at this stage, oftentimes from improper naming of weapons points or their matching resource lines. The easiest method of finding the proper names and lines is to simply copy/paste them from existing .lwo and .shp files that are from ships that operate okay.