FreeSpace Wiki - User contributions [en]

Command-Line Reference

2005-11-14T08:55:30Z

152.3.76.154:

==Launcher Flags==
The following command-line options can be chosen from the launcher.
===Graphics===
====-spec====
Enables specular mapping. Only polygons mapped with textures for which a shinemap exists will recieve specular lighting. Specular maps are specified with the base map name plus "-shine" (i.e. TCov3A-shine.pcx).
====-glow====
Enables glowmapping. Only polygons mapped with textures for which a glowmap exists will be glowmapped. Glow maps are specified with the base map name plus "-shine" (i.e. TCov4A-glow.pcx)
====-jpgtga====
Enables the use of TGA and JPG file formats for image files. If a ship is showing up partially invisible, select this option.
====-pcx32====
<color = "red">'''WARNING - HIGH MEMORY USAGE'''</color>

Enables PCX files to be loaded into 32-bit memory. This will not imporove the rendering of any ships in-game, and is usually more of a burden on performance than is worthwhile. Use at your own risk.
====-cell====
Enables cell shading. This will make graphics appear more "cartoonish". For use with media in mv_cell.vp. Not considered a standard enhancement.
====-mipmap====
Enables mipmaping.
====-nomotiondebris====
Disables motion debris.
====-2d_poof====
Applies nebula poofs in 2d, effectively preventing them from forming intersections with ships.
====-noscalevid====
Disables scaling of video clips.
====-cache_bitmaps====
Caches bitmaps between missions, which will ideally reduce the load-time from one mission to another.
====-img2dds====
Converts all images to DDS (compressed) format. Decreases memory usage but potentially reduces image quality.
====-no_vsync====
Disables vertical sync.
===HUD===
====-dualscanlines====
Adds a second pair of scanning lines to the target window when scanning an object.
====-targetinfo====
Displays target info, such as name and class, beside the targeted object.
====-orbradar====
Enables 3D radar (the Orb). 3D radar will replace the standard 2D version.
====-ballistic_gauge====
Adds an ammo gauge to the HUD when armed with a ballistic weapon.
===Gameplay===
====-nobeampierce====
Causes beams to hit (and damage) shields before they impact a ship's hull. This is a global flag, but this behavior can also be modified in weapons.tbl.
====-smart_shields====
Enables "smart" shield recharging. Shield recharge rate is distributed across all damaged quadrants only, so each quadrant will recharge faster if not all are damaged.
====-ship_choice_3d====
Use ship and weapon models in ship selection and weapon loadout. Completely disables the standard ANI interface on those screens.
====-3dwarp====
Use full geometry for the subspace warp effect.
====-warp_flash====
Enable a flash at warp in and warp out.
====-UseNewAI====
Tells the game to use new AI routines. This argument alters mission balance and is not considered a standard feature.
====-tbp
Enable feature set for The Babylon Project
====-wcsaga====
Enable feature set for The Wing Commander Saga
===Audio===
====-snd_preload====
Preload mission sounds. Useful in preventing game stuttering when sounds are played for the first time.
====-nosound====
Disables all sounds.
====-nomusic====
Disables music only.
===Multiplayer===
====-standalone====
Creates a standalone server.
====-startgame====
'''''What does this do?'''''
====-closed====
'''''What does this do?'''''
====-restricted====
'''''What does this do?'''''
====-multilog====
'''''What does this do?'''''
====-clientdamage====
'''''What does this do?'''''
====-mpnoreturn====
Disables return to the flight deck screen after a mission completes.
===Troubleshooting===
====-fixbugs====
<color="red">'''Obsolete Argument'''</color>

Originally used to disable certain crashing behavior as a stop-gap measure. This feature is not available in current builds.
====-nocrash====
<color="red">'''Obsolete Argument'''</color>

Originally used to disable certain crashing behavior as a stop-gap measure. This feature is not available in current builds.
====-oldfire====
'''''What does this do?'''''
====-nohtl====
<color = "red">'''WARNING - VERY SLOW'''</color>

Reverts to software rendering mode. Does this work any more?
====-no_set_gamma====
Disables the gamma settings in the options screen.
====-nomovies====
Disables all video playback.
====-noparseerrors====
Disables some parsing warnings and makes other parse errors non-fatal. Do not rely on this when creating new tables, the errors are there for a reason.
====-safeloading====
Loads missions the old way. Typically safer, but slower.
====-query_speech====
Determines if the current build includes text-to-speech.
====-d3d_bad_tsys====
Enable inefficient texture system.
====-novbo====
Disables OpenGL VBO.
====-noibx====
Disables IBX caching of model geometry data. This will dramatically increase load times, but will help troubleshoot a model if one is working incorrectly.
====-loadallweps====
Load all weapons, even those not used.
===Experimental===
====-env====
Enables environment mapping. Direct3D only. Environment mapping intensity will be determined from the intensity of specular maps.
====-alpha_env====
Enables alpha environment mapping. Direct3D only. Environment mapping intensity will be determined from the alpha channel of specular maps.
====-decals====
Enables damage decals.
====-ingame_join====
Enables ingame joining in multiplayer. FIXME: Host option?
====-tga16====
Converts all TGA images to 16-bits. Reduces memory footprint at the expense of image quality.
===Development Tools===
====-fps====
Displays current frames per second.
====-pos====
Displays current position coordinates of camera.
====-window====
Runs the game in a window. No check to make sure that resolution is no higher than your desktop resolution, so be careful.
====-timerbar====
Displays a timing bar across the top of the screen. Timebar format varies by build.
====-stats====
Shows statistics.
====-coords====
Shows coordinates of the mouse cursor.
====-show_mem_usage====
Shows memory usage.
====-pofspew====
'''''What does this do?'''''
====-tablecrcs====
'''''What does this do?'''''
====-missioncrcs====
'''''What does this do?'''''
====-dis_collisions====
Disables all collisions.
====-dis_weapons====
Disables weapons rendering.
====-output_sexps====
Outputs SEXPs to sexps.html.
====-output_scripting====
Outputs scripting to scripting.html.
====-nograb====
Unix only. Disables focus grabbing in a window.
==Other==
The following options are not available as checkboxes in the launcher. Many require parameters, which follow the flag seperated by a space. The prototype for use in this case is "-option argument"
===Graphics===
====-ambient_factor====
Reduces the ambient lighting levels.

Takes one argument decimal. The range is specified as a percent, so 0 is no ambient lighting, 100 is default levels.
====-spec_exp====
'''''What does this do?'''''

Takes one argument decimal.
====-spec_point====
'''''What does this do?'''''

Takes one argument decimal.
====-spec_static====
'''''What does this do?'''''

Takes one argument decimal.
===="-spec_tube====
'''''What does this do?'''''

Takes one argument decimal.
====-clipdist====
Changes the distance from the viewpoint for the near-clipping plane.

Takes one argument decimal specifying the distance to the near-clipping plane.
===Gameplay===
====-mod====
Specifies a higher priority game directory.

Takes one argument string, the name of the directory in which the target mod is contained. Explicit use of this command line should be unnecessary as the launcher has MOD options, though multiple mods are supported and do require manual entry.

Data precidence with -mod is as follows (mod directory "moddir")
#moddir/data/(appropriate directory)/
#moddir/data/
#moddir/
#Freespace2/data/(appropriate directory)
#Freespace2/data/
#Freespace2/
====-fov====
Specifies the Field of View for the player eyepoint.

Takes one argument decimal specifying the angle of the viewing cone. FIXME: Is this a solid angle, or a width? Is it radians or degrees? What is the valid range of inputs?
===Multiplayer===
====-gamename====
Specifies the name of the game to be created by a stand-alone server.

Takes one argument string, the name to be assigned to the game being created.
====-password====
Specifies the password for a stand-alone server.

Takes one argument string, the required password for the game being created.
====-allowabove====
Specifies a player's minimum rank for joining a game on a stand-alone server.

Takes one argument integer, the points ranking above which a player must be to enter the game.
====-allowbelow====
Specifies a player's maximum rank for joining a game on a stand-alone server.

Takes one argument integer, the points ranking below which a player must be to enter the game.
====-port====
Specifies the port on which to run for a stand-alone server.

Takes one argument integer, the port which the game should use to connect.
====-connect====
'''''What does this do?'''''
====-clientdamage====
'''''What does this do?'''''
====-timeout====
'''''What does this do?'''''

Styxx's POF Conversion plugin for 3D Studio Max

2005-11-13T20:22:54Z

152.3.76.154: /* Things that still need improvement */

Still a Work In progress, Styxx has created a plugin for 3d Studio Max versions 4 through 6. Available here: [[http://www.hard-light.net/forums/index.php/topic,26260.0.html]]

Despite being available for well over a year, not many people actually know how to make this plugin work correctly. To that end, the following is intended to be a complete walkthrough of using the plugin to create a simple ship that makes use of all of the plugin's features.

==A Comprehensive 3dsMax->POF conversion tutorial==
Please note that this is not a tutorial for actually creating models. There are plenty of Max tutorials out there that have far better information in them than what can be provided here. It is, however, a guide to getting a model out of 3ds Max and into the Freespace 2 object format, POF, with minimal complications.

This tutorial is for the current exporter version as of November 13, 2003.

To start off, load all of the components of your model into a single Max scene file, and make sure that everything is unlinked so that you have no heiararchy to start off with. If you have already set up a heirarchy, go back and unlink it, as having things grouped too early may cause trouble later. From here, preparing the geometry for conversion involves a specific sequence of actions.

===Geometry Preperation===
# Orient everything so that the front of the ship points towards the top of the screen in "top" view mode.
# One by one, select each subobject and assign it a conversion name. Certain subobjects require specific naming conventions. Level of detail (LOD) objects are named detail-0, detail-1, etc, where detail-0 is the parent geometry for LOD0, detail-1 is the parent for LOD1, and so on. Do not skip levels. Debris chunks are similarly named debris-0, debris-1, ... debris-n, where n is one less than the total number of debris chunks. Again, do not skip numbering, as the converter parses these in order and will break if a number is missed. For all other subsystems, any name is valid as long as Freespace can parse it from the POF chunk (so no Cylinder,3) but remember that what you name the subobject will be what it is called in the POF itself. The shield mesh should be named "shield" (and similarly, any and all geometry not supposed to be a sheild should not be named "shield"). Models should only have one shield. As you pass through your list of objects assigning them names, also change them to editable poly mode, as the converter seems to work best with poly models. The following is a personal convention for naming other objects:
#* Turrets are named turretXX, where XX is a number between 01 and 99 that corresponds to the turret number that this model represents.
#* Live debris, the ugly chunks of stuff left over when a turret is destroyed, are specified by naming the subobject for the destroyed component the same as the healthy version but with an added "-destroyed" on the end.
#* Geometry that's acting as a "standard" Freespace subsystem should be named according to the final subsystem name. A physical Comm system would be "communications", a physical hanger would be "fighterbay", and so on.
#* Geometry representing non-standard displaying subsystems should be given the name you want them to appear with.
#* Hidden subobjects should be given a name that's meaningful to their function, such as hangerdoor for a hanger door.
#* No subobject should ever be converted with it's max-generated default name.
# Assign properties to physical subobjects. Turrets are the most common case, but rotating subobjects like radar dishes and geometry representing a game subsystem like engines also need some extra data. To assign text properties to an object, open the object properties dialogue (right-click on the object, and select properties) and go to the "User Defined" tab. All objects that will be subsystems will need "$special=subsystem" added to their user-defined properties tabs. Turrets (turret bases) should have "$fov=XXX" where XXX is the field of view for the turret (0-180) and "$name=gunturret" added at the end. Other subsystems also need the $name=somename" field, but only turrets require "gunturret". Rotating objects need "$rotate=X" where X is rotation time in seconds. Negative values indicate reverse rotation.
# Position the primary model where it is supposed to be in the converted file so that its pivot point is at the origin. If you were converting the colossus, you would put the model in such a location that the middle of its rear engines, the point about which it rotates in-game, at (0,0,0). When the ship is in the exact place you want it, select the Heirarchy tab, click "Affect Pivot Only" and make sure that the pivot is at location 0,0,0. The location of the pivot on the root geometry for a level of detail MUST be at the origin, and this is important, so do not skip this step.
# Position all turrets and other subobjects where you want them in relation to the detail-X object that they will be attached to (this will almost always be detail-0), making sure to follow Freespace conventions in terms of turret orientation. Topside multipart turrets should face forward with their barrels pointing straight up, multipart turrets on the bottom of the ship should face towards the ship's rear and their barrels should point straight down. Default resting positions can be assigned in tables, so don't try to do anything fancy with these in the model. Barrels (and any other object consisting of more than one connected element) should be one object, not several, so attach multiple barrels together with the attach tool.
# Glass, transparency-blended nameplates, and other transparent textures should come last in the model. An easy way to accomplish this is to select all faces that use the material of your glass texture and detach them from the model, select the original model and re-attach them with the attach tool, select the faces near the edge (all faces in the model may be appropriate) and perform a vertex weld with a threshold of 0.01. This will move the transparent faces to the end of the model's face list and will ensure proper rendering in-game. If you have a single map that is partially transparent, do this on the specific faces that will end up transparent. All transparent textures should be part of the root geometry (detail-0), without exception. Faces behind transparent textures, such as a pilot, are more likely to work correctly when it is a subobject.
# All faces on all geometry '''except the sheild''' must have a texture assigned to them. Missing this on as little as a single face will cause the plugin to crash.

===Paths===
Create your paths using the create line tool and modify the editable splines to suit each path you want in the model. Typically, the paths needed for a "complete" model are paths for each subsystem (main subsystems and turret subobjects) so it's usually a good idea to know in advance where things like the weapons subsystem will be defined. All editable splines will become paths on conversion, but name them according to the Freespace convention anyway. Subsystem paths should be named $pathXX (XX is a number) and fighterbay paths should be named $bayXX. The only exception is the dock paths, which must have "dock" in the name, so $dockXX is preferable. Paths are ALWAYS defined toward the ship, so the first point (where you first click when you start an editable spline with the create line tool) should be the most distant from the ship, and the last the closest. Turret and subsystem paths are fine with just two points, fighterbay and dock paths typically have more (docks should have at least 4). Dock paths should have $name=somename, where somename is the display name of the dock in FRED, added to their user-defined properties tab.

===Reset X-Form===
This is the step that has given people the most trouble. Now would be a good time to make a backup of the scene, so that you can restore to the un-rigged state if something goes wrong.

Select all objects in the scene and open the Utilities tab. Select the "Reset X-Form" tool in the rollout that appears. Click the button of the same name to reset the transforms on all objects in the scene. If something in the scene moves in a strange way when you perform this action, there was still heirarchy set up in the scene so load up the backup and unlink the object(s) that moved from whatever they are attached to with the schematic editor. Then update the backup and try Reset X-form again, repeating as necessary.

===Turrets===
Most turret issues have already been covered, but there is one additional step that must be done for each turret. To define a turret's firing points, place point helper objects in the scene at the desired location for these points. It's a good idea to name these points something meaningful (if it's a firepoint for turret03, perhaps call it "turret03fp") so that you can figure out what goes where when rigging. For now, just create the points, we'll put the turrets together shortly.

===Rigging the Scene===
Now that all geometry and paths are set up properly, it's time to start putting things together. Setting up the heirarchy is done through the Schematic view, so go ahead and open that up. If you can't make out anything, try zooming in; Max does a particularly poor job of initially displaying a large number of objects in this view.

Objects are connected in a heirarchy with the link tool. To link one object to another, select the link tool, click on the to-be child object and drag to the intended parent.

====Turrets, again====
It's usually a good idea to set up turret groups before linking the turret itself to its parent.
*The standard button turrets consist of the turret geometry, with the turret path and the firepoint(s) attached as children.
*Multipart turrets are assembled with the turret base as the parent and with the firepoint(s), path, and barrels all attached as children.

====Heirarchy Matters====
The connection heirarchy is essential to making the game display your model correctly. Child objects cannot be rendered if their parent is not rendered, so keep this in mind when setting up your heirarchy groupings. Child objects also rotate with their parents, so if you are setting up an animated model you must keep this in mind. In general, all subobjects that the game can access as a submodel get assigned as direct children of detail-0, unless it's some strange case involving rotation. Turret barrels, however, are '''always''' children of their base, even if you don't intend to use autogeneration to set the turret up for you.

====Putting it All Together====
#Using the link tool in heirarchy view, one by one attach each turret base, physical subsystem, and extra subobjects intended to be direct subobjects of detail-0 to their parent LOD.
#Additional LODs should be set up the same way, though in most cases all lower LODs will have no child objects. LODs should themselves be at the top level of the scene, not attached to any other piece of geometry or helper.
#Debris pieces be at the scene root as well, not attached to any parent object.
#The shield mesh (if one is being used) should also be at the top level of the scene.
#All paths not assigned to a turret or subobject (subsystem paths for non-geometry subsystems, fighterbay paths, and dock paths) should be at the root level of the scene.

It is recommended that you attempt an export with only "detail levels", "debris objects", and "glows" checked. "glows" will obviously not do anything yet, but for some reason the exporter seems to crash when it is not selected. If If it converts and everything is in the right place afterwards, then the geometry is sound and you can be sure that later errors were not caused by geometry issues. See the converting section for details and debugging info.

===Of Points and Dummies===
If you prefer editing all subsystem, turret, gun/missile point, dockpoint, engine glow, and glowpoint data in PCS, you can safely skip this section. However, as this is perhaps the greatest strength of the MAX converter, it is strongly recommended that you actually use these features.

All of the resulting structures should be left at the root level of the scene.

====Weapon Banks====
Two components are necessary for each gun and missile bank that you want to add. One is the points themselves; these are defined as point helper objects places where each specific firepoint should be. The other is a container dummy object. The location of the container dummy does not matter, so it can be dropped down anywhere. However, to prevent serious oddities in conversion, it is strongly recommended to define '''all''' dummy objects in either a top-down or perspective view. That rule applies to more than just weapon banks as well. To create a weapon bank, place all of the firepoints where they belong (naming them something representative of their bank is helpful if you do multiple banks at a time) and add a dummy helper to the scene. The dummy must take the name gunbank-X, if it is to be a gun bank, or missilebank-X if it is to be a missile bank. X in both of these is the number of the bank, so start with zero and work your way up for both. The count of gunbanks is not related to the count of missilebanks, so start both at 0 and don't skip numbers.

In the Schematic view, attach all firepoints for a particular bank to the container dummy helper as children.

====Dock Points====
Dockpoints are specified using a editable spline object and two point helpers. Place one point helper where you want the dockpoint, and place a second point helper a short distance away towards the "top" of the dock. If you want an argo to dock in a certain alignment, the second point should be above the first from the orientation of the argo. The spline should have been set up already and named $dockXX, and its final point should come very close to the first dockpoint. In the schematic view, attach the two dockpoints, in their creation order, to the dock path as children. The dock point normals will be set as the direction from the dockpoints to the first point in the path, which is often wrong, but this must be corrected after the fact.

====Special Subsystems====
To create the standard subsystems used in FS2, create a dummy object at the location and with the size of the special point you want to create. This point should have a name starting with '$' and should be named what you want the point to display as otherwise.

====Engine Glows====
Engine glows are created from dummy helpers attached to an engine subsystem. Place the dummies centered where the engine glows should be and set their size to the size of the glow. Glows associated with an engine subsystem should be linked to that subsystem as children.

====Glowpoints====
Glowpoints are very similar to gun/missile banks in setup, except that instead of point helpers for each point, they use dummys. The size of each individual dummy will determine the size of the glowpoint it creates. Glow banks are specified with a container dummy helper (which has multiple dummy helpers attached to it as children) with the name glow-X where X is the number of the glow bank (start with 0 and don't skip numbers). The string "$glow_texture=texturename" should be placed into the user properties tab for the parent helper.

====Insignia====
Insignia's don't work properly, so this tutorial will not address them.

===Converting===
Converting is a relatively simple process in comparison to actually setting everything up. It is, however, not foolproof and actually quite failure prone. It should be as simple as doing a file->export, choosing Freespace 2 POF as your export filetype, and selecting only the components that you actually have in your scene. The only exception is the glows box, which must always be checked or a crash will result.

====What can go wrong====
The simple answer is a lot. The converter will crash if you skipped a number in any sequence that requires a -X at the end. Debris is the most common place for this to occur now, though there are other places that it may also come up. The converter will crash if it encounters polygons on any mesh other than the shield that have no texture. The converter will also always crash if the glow box is unchecked, though there isn't any good reason for this. Finally, the converter will occasionally crash for no reason whatsoever, so always save before you convert and load it up and try again if it fails once. Failing twice in a row is usually indicative of a real problem.

===Things that still need improvement===
There are still some things that the POF converter cannot do properly. For one thing, it makes a mess out of the header; the mass values are about two orders of magnitude higher than they would be for an equivalent stock model. For another, the Moment of Inertia is a complete mess and doesn't output anything useful. Both of these values should be changed before the model is used in game. Unfortunately, if glowpoints were used, there is not a good mainstream way to correct the MoI data without losing the glow chunk, and PCS won't import glows, so you're sort of stuck unless you are willing to copy it by hand. There is a third issue that most people rarely notice; the converter miscalculates the radius of the model by approximately a factor of 2, which creates some strange behavior during subspace warps and when viewing externally from the model. Again, there is not a good way to correct this, so it may just be something you have to live with. If the radius problem becomes an issue, please contact the user StratComm through the HLP PM system for assistance.

Styxx's POF Conversion plugin for 3D Studio Max

2005-11-13T08:09:52Z

152.3.76.154: /* Converting a fighter: A Comprehensive 3dsMax->POF conversion tutorial */

Still a Work In progress, Styxx has created a plugin for 3d Studio Max versions 4 through 6. Available here: [[http://www.hard-light.net/forums/index.php/topic,26260.0.html]]

Despite being available for well over a year, not many people actually know how to make this plugin work correctly. To that end, the following is intended to be a complete walkthrough of using the plugin to create a simple ship that makes use of all of the plugin's features.

==A Comprehensive 3dsMax->POF conversion tutorial==
Please note that this is not a tutorial for actually creating models. There are plenty of Max tutorials out there that have far better information in them than what can be provided here. It is, however, a guide to getting a model out of 3ds Max and into the Freespace 2 object format, POF, with minimal complications.

This tutorial is for the current exporter version as of November 13, 2003.

To start off, load all of the components of your model into a single Max scene file, and make sure that everything is unlinked so that you have no heiararchy to start off with. If you have already set up a heirarchy, go back and unlink it, as having things grouped too early may cause trouble later. From here, preparing the geometry for conversion involves a specific sequence of actions.

===Geometry Preperation===
# Orient everything so that the front of the ship points towards the top of the screen in "top" view mode.
# One by one, select each subobject and assign it a conversion name. Certain subobjects require specific naming conventions. Level of detail (LOD) objects are named detail-0, detail-1, etc, where detail-0 is the parent geometry for LOD0, detail-1 is the parent for LOD1, and so on. Do not skip levels. Debris chunks are similarly named debris-0, debris-1, ... debris-n, where n is one less than the total number of debris chunks. Again, do not skip numbering, as the converter parses these in order and will break if a number is missed. For all other subsystems, any name is valid as long as Freespace can parse it from the POF chunk (so no Cylinder,3) but remember that what you name the subobject will be what it is called in the POF itself. The shield mesh should be named "shield" (and similarly, any and all geometry not supposed to be a sheild should not be named "shield"). Models should only have one shield. As you pass through your list of objects assigning them names, also change them to editable poly mode, as the converter seems to work best with poly models. The following is a personal convention for naming other objects:
#* Turrets are named turretXX, where XX is a number between 01 and 99 that corresponds to the turret number that this model represents.
#* Live debris, the ugly chunks of stuff left over when a turret is destroyed, are specified by naming the subobject for the destroyed component the same as the healthy version but with an added "-destroyed" on the end.
#* Geometry that's acting as a "standard" Freespace subsystem should be named according to the final subsystem name. A physical Comm system would be "communications", a physical hanger would be "fighterbay", and so on.
#* Geometry representing non-standard displaying subsystems should be given the name you want them to appear with.
#* Hidden subobjects should be given a name that's meaningful to their function, such as hangerdoor for a hanger door.
#* No subobject should ever be converted with it's max-generated default name.
# Assign properties to physical subobjects. Turrets are the most common case, but rotating subobjects like radar dishes and geometry representing a game subsystem like engines also need some extra data. To assign text properties to an object, open the object properties dialogue (right-click on the object, and select properties) and go to the "User Defined" tab. All objects that will be subsystems will need "$special=subsystem" added to their user-defined properties tabs. Turrets (turret bases) should have "$fov=XXX" where XXX is the field of view for the turret (0-180) and "$name=gunturret" added at the end. Other subsystems also need the $name=somename" field, but only turrets require "gunturret". Rotating objects need "$rotate=X" where X is rotation time in seconds. Negative values indicate reverse rotation.
# Position the primary model where it is supposed to be in the converted file so that its pivot point is at the origin. If you were converting the colossus, you would put the model in such a location that the middle of its rear engines, the point about which it rotates in-game, at (0,0,0). When the ship is in the exact place you want it, select the Heirarchy tab, click "Affect Pivot Only" and make sure that the pivot is at location 0,0,0. The location of the pivot on the root geometry for a level of detail MUST be at the origin, and this is important, so do not skip this step.
# Position all turrets and other subobjects where you want them in relation to the detail-X object that they will be attached to (this will almost always be detail-0), making sure to follow Freespace conventions in terms of turret orientation. Topside multipart turrets should face forward with their barrels pointing straight up, multipart turrets on the bottom of the ship should face towards the ship's rear and their barrels should point straight down. Default resting positions can be assigned in tables, so don't try to do anything fancy with these in the model. Barrels (and any other object consisting of more than one connected element) should be one object, not several, so attach multiple barrels together with the attach tool.
# Glass, transparency-blended nameplates, and other transparent textures should come last in the model. An easy way to accomplish this is to select all faces that use the material of your glass texture and detach them from the model, select the original model and re-attach them with the attach tool, select the faces near the edge (all faces in the model may be appropriate) and perform a vertex weld with a threshold of 0.01. This will move the transparent faces to the end of the model's face list and will ensure proper rendering in-game. If you have a single map that is partially transparent, do this on the specific faces that will end up transparent. All transparent textures should be part of the root geometry (detail-0), without exception. Faces behind transparent textures, such as a pilot, are more likely to work correctly when it is a subobject.
# All faces on all geometry '''except the sheild''' must have a texture assigned to them. Missing this on as little as a single face will cause the plugin to crash.

===Paths===
Create your paths using the create line tool and modify the editable splines to suit each path you want in the model. Typically, the paths needed for a "complete" model are paths for each subsystem (main subsystems and turret subobjects) so it's usually a good idea to know in advance where things like the weapons subsystem will be defined. All editable splines will become paths on conversion, but name them according to the Freespace convention anyway. Subsystem paths should be named $pathXX (XX is a number) and fighterbay paths should be named $bayXX. The only exception is the dock paths, which must have "dock" in the name, so $dockXX is preferable. Paths are ALWAYS defined toward the ship, so the first point (where you first click when you start an editable spline with the create line tool) should be the most distant from the ship, and the last the closest. Turret and subsystem paths are fine with just two points, fighterbay and dock paths typically have more (docks should have at least 4). Dock paths should have $name=somename, where somename is the display name of the dock in FRED, added to their user-defined properties tab.

===Reset X-Form===
This is the step that has given people the most trouble. Now would be a good time to make a backup of the scene, so that you can restore to the un-rigged state if something goes wrong.

Select all objects in the scene and open the Utilities tab. Select the "Reset X-Form" tool in the rollout that appears. Click the button of the same name to reset the transforms on all objects in the scene. If something in the scene moves in a strange way when you perform this action, there was still heirarchy set up in the scene so load up the backup and unlink the object(s) that moved from whatever they are attached to with the schematic editor. Then update the backup and try Reset X-form again, repeating as necessary.

===Turrets===
Most turret issues have already been covered, but there is one additional step that must be done for each turret. To define a turret's firing points, place point helper objects in the scene at the desired location for these points. It's a good idea to name these points something meaningful (if it's a firepoint for turret03, perhaps call it "turret03fp") so that you can figure out what goes where when rigging. For now, just create the points, we'll put the turrets together shortly.

===Rigging the Scene===
Now that all geometry and paths are set up properly, it's time to start putting things together. Setting up the heirarchy is done through the Schematic view, so go ahead and open that up. If you can't make out anything, try zooming in; Max does a particularly poor job of initially displaying a large number of objects in this view.

Objects are connected in a heirarchy with the link tool. To link one object to another, select the link tool, click on the to-be child object and drag to the intended parent.

====Turrets, again====
It's usually a good idea to set up turret groups before linking the turret itself to its parent.
*The standard button turrets consist of the turret geometry, with the turret path and the firepoint(s) attached as children.
*Multipart turrets are assembled with the turret base as the parent and with the firepoint(s), path, and barrels all attached as children.

====Heirarchy Matters====
The connection heirarchy is essential to making the game display your model correctly. Child objects cannot be rendered if their parent is not rendered, so keep this in mind when setting up your heirarchy groupings. Child objects also rotate with their parents, so if you are setting up an animated model you must keep this in mind. In general, all subobjects that the game can access as a submodel get assigned as direct children of detail-0, unless it's some strange case involving rotation. Turret barrels, however, are '''always''' children of their base, even if you don't intend to use autogeneration to set the turret up for you.

====Putting it All Together====
#Using the link tool in heirarchy view, one by one attach each turret base, physical subsystem, and extra subobjects intended to be direct subobjects of detail-0 to their parent LOD.
#Additional LODs should be set up the same way, though in most cases all lower LODs will have no child objects. LODs should themselves be at the top level of the scene, not attached to any other piece of geometry or helper.
#Debris pieces be at the scene root as well, not attached to any parent object.
#The shield mesh (if one is being used) should also be at the top level of the scene.
#All paths not assigned to a turret or subobject (subsystem paths for non-geometry subsystems, fighterbay paths, and dock paths) should be at the root level of the scene.

It is recommended that you attempt an export with only "detail levels", "debris objects", and "glows" checked. "glows" will obviously not do anything yet, but for some reason the exporter seems to crash when it is not selected. If If it converts and everything is in the right place afterwards, then the geometry is sound and you can be sure that later errors were not caused by geometry issues. See the converting section for details and debugging info.

===Of Points and Dummies===
If you prefer editing all subsystem, turret, gun/missile point, dockpoint, engine glow, and glowpoint data in PCS, you can safely skip this section. However, as this is perhaps the greatest strength of the MAX converter, it is strongly recommended that you actually use these features.

All of the resulting structures should be left at the root level of the scene.

====Weapon Banks====
Two components are necessary for each gun and missile bank that you want to add. One is the points themselves; these are defined as point helper objects places where each specific firepoint should be. The other is a container dummy object. The location of the container dummy does not matter, so it can be dropped down anywhere. However, to prevent serious oddities in conversion, it is strongly recommended to define '''all''' dummy objects in either a top-down or perspective view. That rule applies to more than just weapon banks as well. To create a weapon bank, place all of the firepoints where they belong (naming them something representative of their bank is helpful if you do multiple banks at a time) and add a dummy helper to the scene. The dummy must take the name gunbank-X, if it is to be a gun bank, or missilebank-X if it is to be a missile bank. X in both of these is the number of the bank, so start with zero and work your way up for both. The count of gunbanks is not related to the count of missilebanks, so start both at 0 and don't skip numbers.

In the Schematic view, attach all firepoints for a particular bank to the container dummy helper as children.

====Dock Points====
Dockpoints are specified using a editable spline object and two point helpers. Place one point helper where you want the dockpoint, and place a second point helper a short distance away towards the "top" of the dock. If you want an argo to dock in a certain alignment, the second point should be above the first from the orientation of the argo. The spline should have been set up already and named $dockXX, and its final point should come very close to the first dockpoint. In the schematic view, attach the two dockpoints, in their creation order, to the dock path as children. The dock point normals will be set as the direction from the dockpoints to the first point in the path, which is often wrong, but this must be corrected after the fact.

====Special Subsystems====
To create the standard subsystems used in FS2, create a dummy object at the location and with the size of the special point you want to create. This point should have a name starting with '$' and should be named what you want the point to display as otherwise.

====Engine Glows====
Engine glows are created from dummy helpers attached to an engine subsystem. Place the dummies centered where the engine glows should be and set their size to the size of the glow. Glows associated with an engine subsystem should be linked to that subsystem as children.

====Glowpoints====
Glowpoints are very similar to gun/missile banks in setup, except that instead of point helpers for each point, they use dummys. The size of each individual dummy will determine the size of the glowpoint it creates. Glow banks are specified with a container dummy helper (which has multiple dummy helpers attached to it as children) with the name glow-X where X is the number of the glow bank (start with 0 and don't skip numbers). The string "$glow_texture=texturename" should be placed into the user properties tab for the parent helper.

====Insignia====
Insignia's don't work properly, so this tutorial will not address them.

===Converting===
Converting is a relatively simple process in comparison to actually setting everything up. It is, however, not foolproof and actually quite failure prone. It should be as simple as doing a file->export, choosing Freespace 2 POF as your export filetype, and selecting only the components that you actually have in your scene. The only exception is the glows box, which must always be checked or a crash will result.

====What can go wrong====
The simple answer is a lot. The converter will crash if you skipped a number in any sequence that requires a -X at the end. Debris is the most common place for this to occur now, though there are other places that it may also come up. The converter will crash if it encounters polygons on any mesh other than the shield that have no texture. The converter will also always crash if the glow box is unchecked, though there isn't any good reason for this. Finally, the converter will occasionally crash for no reason whatsoever, so always save before you convert and load it up and try again if it fails once. Failing twice in a row is usually indicative of a real problem.

===Things that still need improvement===
There are still some things that the POF converter cannot do properly. For one thing, it makes a mess out of the header; the mass values are about two orders of magnitude higher than they would be for an equivalent stock model. For another, the Moment of Inertia is a complete mess and doesn't output anything useful. Both of these values should be changed before the model is used in game. Unfortunately, if glowpoints were used, there is not a good mainstream way to correct the MoI data without losing the glow chunk, and PCS won't import glows, so you're sort of stuck unless you are willing to copy it by hand. There is a third issue that most people rarely notice; the converter miscalculates the raduis of the model by approximately a factor of 2, which creates some strange behavior during subspace warps and when viewing externally from the model. Again, there is not a good way to correct this, so it may just be something you have to live with. If the radius problem becomes an issue, please contact the user StratComm through the HLP PM system for assistance.

Styxx's POF Conversion plugin for 3D Studio Max

2005-11-13T08:09:23Z

152.3.76.154:

Still a Work In progress, Styxx has created a plugin for 3d Studio Max versions 4 through 6. Available here: [[http://www.hard-light.net/forums/index.php/topic,26260.0.html]]

Despite being available for well over a year, not many people actually know how to make this plugin work correctly. To that end, the following is intended to be a complete walkthrough of using the plugin to create a simple ship that makes use of all of the plugin's features.

==Converting a fighter: A Comprehensive 3dsMax->POF conversion tutorial==
Please note that this is not a tutorial for actually creating models. There are plenty of Max tutorials out there that have far better information in them than what can be provided here. It is, however, a guide to getting a model out of 3ds Max and into the Freespace 2 object format, POF, with minimal complications.

This tutorial is for the current exporter version as of November 13, 2003.

To start off, load all of the components of your model into a single Max scene file, and make sure that everything is unlinked so that you have no heiararchy to start off with. If you have already set up a heirarchy, go back and unlink it, as having things grouped too early may cause trouble later. From here, preparing the geometry for conversion involves a specific sequence of actions.

===Geometry Preperation===
# Orient everything so that the front of the ship points towards the top of the screen in "top" view mode.
# One by one, select each subobject and assign it a conversion name. Certain subobjects require specific naming conventions. Level of detail (LOD) objects are named detail-0, detail-1, etc, where detail-0 is the parent geometry for LOD0, detail-1 is the parent for LOD1, and so on. Do not skip levels. Debris chunks are similarly named debris-0, debris-1, ... debris-n, where n is one less than the total number of debris chunks. Again, do not skip numbering, as the converter parses these in order and will break if a number is missed. For all other subsystems, any name is valid as long as Freespace can parse it from the POF chunk (so no Cylinder,3) but remember that what you name the subobject will be what it is called in the POF itself. The shield mesh should be named "shield" (and similarly, any and all geometry not supposed to be a sheild should not be named "shield"). Models should only have one shield. As you pass through your list of objects assigning them names, also change them to editable poly mode, as the converter seems to work best with poly models. The following is a personal convention for naming other objects:
#* Turrets are named turretXX, where XX is a number between 01 and 99 that corresponds to the turret number that this model represents.
#* Live debris, the ugly chunks of stuff left over when a turret is destroyed, are specified by naming the subobject for the destroyed component the same as the healthy version but with an added "-destroyed" on the end.
#* Geometry that's acting as a "standard" Freespace subsystem should be named according to the final subsystem name. A physical Comm system would be "communications", a physical hanger would be "fighterbay", and so on.
#* Geometry representing non-standard displaying subsystems should be given the name you want them to appear with.
#* Hidden subobjects should be given a name that's meaningful to their function, such as hangerdoor for a hanger door.
#* No subobject should ever be converted with it's max-generated default name.
# Assign properties to physical subobjects. Turrets are the most common case, but rotating subobjects like radar dishes and geometry representing a game subsystem like engines also need some extra data. To assign text properties to an object, open the object properties dialogue (right-click on the object, and select properties) and go to the "User Defined" tab. All objects that will be subsystems will need "$special=subsystem" added to their user-defined properties tabs. Turrets (turret bases) should have "$fov=XXX" where XXX is the field of view for the turret (0-180) and "$name=gunturret" added at the end. Other subsystems also need the $name=somename" field, but only turrets require "gunturret". Rotating objects need "$rotate=X" where X is rotation time in seconds. Negative values indicate reverse rotation.
# Position the primary model where it is supposed to be in the converted file so that its pivot point is at the origin. If you were converting the colossus, you would put the model in such a location that the middle of its rear engines, the point about which it rotates in-game, at (0,0,0). When the ship is in the exact place you want it, select the Heirarchy tab, click "Affect Pivot Only" and make sure that the pivot is at location 0,0,0. The location of the pivot on the root geometry for a level of detail MUST be at the origin, and this is important, so do not skip this step.
# Position all turrets and other subobjects where you want them in relation to the detail-X object that they will be attached to (this will almost always be detail-0), making sure to follow Freespace conventions in terms of turret orientation. Topside multipart turrets should face forward with their barrels pointing straight up, multipart turrets on the bottom of the ship should face towards the ship's rear and their barrels should point straight down. Default resting positions can be assigned in tables, so don't try to do anything fancy with these in the model. Barrels (and any other object consisting of more than one connected element) should be one object, not several, so attach multiple barrels together with the attach tool.
# Glass, transparency-blended nameplates, and other transparent textures should come last in the model. An easy way to accomplish this is to select all faces that use the material of your glass texture and detach them from the model, select the original model and re-attach them with the attach tool, select the faces near the edge (all faces in the model may be appropriate) and perform a vertex weld with a threshold of 0.01. This will move the transparent faces to the end of the model's face list and will ensure proper rendering in-game. If you have a single map that is partially transparent, do this on the specific faces that will end up transparent. All transparent textures should be part of the root geometry (detail-0), without exception. Faces behind transparent textures, such as a pilot, are more likely to work correctly when it is a subobject.
# All faces on all geometry '''except the sheild''' must have a texture assigned to them. Missing this on as little as a single face will cause the plugin to crash.

===Paths===
Create your paths using the create line tool and modify the editable splines to suit each path you want in the model. Typically, the paths needed for a "complete" model are paths for each subsystem (main subsystems and turret subobjects) so it's usually a good idea to know in advance where things like the weapons subsystem will be defined. All editable splines will become paths on conversion, but name them according to the Freespace convention anyway. Subsystem paths should be named $pathXX (XX is a number) and fighterbay paths should be named $bayXX. The only exception is the dock paths, which must have "dock" in the name, so $dockXX is preferable. Paths are ALWAYS defined toward the ship, so the first point (where you first click when you start an editable spline with the create line tool) should be the most distant from the ship, and the last the closest. Turret and subsystem paths are fine with just two points, fighterbay and dock paths typically have more (docks should have at least 4). Dock paths should have $name=somename, where somename is the display name of the dock in FRED, added to their user-defined properties tab.

===Reset X-Form===
This is the step that has given people the most trouble. Now would be a good time to make a backup of the scene, so that you can restore to the un-rigged state if something goes wrong.

Select all objects in the scene and open the Utilities tab. Select the "Reset X-Form" tool in the rollout that appears. Click the button of the same name to reset the transforms on all objects in the scene. If something in the scene moves in a strange way when you perform this action, there was still heirarchy set up in the scene so load up the backup and unlink the object(s) that moved from whatever they are attached to with the schematic editor. Then update the backup and try Reset X-form again, repeating as necessary.

===Turrets===
Most turret issues have already been covered, but there is one additional step that must be done for each turret. To define a turret's firing points, place point helper objects in the scene at the desired location for these points. It's a good idea to name these points something meaningful (if it's a firepoint for turret03, perhaps call it "turret03fp") so that you can figure out what goes where when rigging. For now, just create the points, we'll put the turrets together shortly.

===Rigging the Scene===
Now that all geometry and paths are set up properly, it's time to start putting things together. Setting up the heirarchy is done through the Schematic view, so go ahead and open that up. If you can't make out anything, try zooming in; Max does a particularly poor job of initially displaying a large number of objects in this view.

Objects are connected in a heirarchy with the link tool. To link one object to another, select the link tool, click on the to-be child object and drag to the intended parent.

====Turrets, again====
It's usually a good idea to set up turret groups before linking the turret itself to its parent.
*The standard button turrets consist of the turret geometry, with the turret path and the firepoint(s) attached as children.
*Multipart turrets are assembled with the turret base as the parent and with the firepoint(s), path, and barrels all attached as children.

====Heirarchy Matters====
The connection heirarchy is essential to making the game display your model correctly. Child objects cannot be rendered if their parent is not rendered, so keep this in mind when setting up your heirarchy groupings. Child objects also rotate with their parents, so if you are setting up an animated model you must keep this in mind. In general, all subobjects that the game can access as a submodel get assigned as direct children of detail-0, unless it's some strange case involving rotation. Turret barrels, however, are '''always''' children of their base, even if you don't intend to use autogeneration to set the turret up for you.

====Putting it All Together====
#Using the link tool in heirarchy view, one by one attach each turret base, physical subsystem, and extra subobjects intended to be direct subobjects of detail-0 to their parent LOD.
#Additional LODs should be set up the same way, though in most cases all lower LODs will have no child objects. LODs should themselves be at the top level of the scene, not attached to any other piece of geometry or helper.
#Debris pieces be at the scene root as well, not attached to any parent object.
#The shield mesh (if one is being used) should also be at the top level of the scene.
#All paths not assigned to a turret or subobject (subsystem paths for non-geometry subsystems, fighterbay paths, and dock paths) should be at the root level of the scene.

It is recommended that you attempt an export with only "detail levels", "debris objects", and "glows" checked. "glows" will obviously not do anything yet, but for some reason the exporter seems to crash when it is not selected. If If it converts and everything is in the right place afterwards, then the geometry is sound and you can be sure that later errors were not caused by geometry issues. See the converting section for details and debugging info.

===Of Points and Dummies===
If you prefer editing all subsystem, turret, gun/missile point, dockpoint, engine glow, and glowpoint data in PCS, you can safely skip this section. However, as this is perhaps the greatest strength of the MAX converter, it is strongly recommended that you actually use these features.

All of the resulting structures should be left at the root level of the scene.

====Weapon Banks====
Two components are necessary for each gun and missile bank that you want to add. One is the points themselves; these are defined as point helper objects places where each specific firepoint should be. The other is a container dummy object. The location of the container dummy does not matter, so it can be dropped down anywhere. However, to prevent serious oddities in conversion, it is strongly recommended to define '''all''' dummy objects in either a top-down or perspective view. That rule applies to more than just weapon banks as well. To create a weapon bank, place all of the firepoints where they belong (naming them something representative of their bank is helpful if you do multiple banks at a time) and add a dummy helper to the scene. The dummy must take the name gunbank-X, if it is to be a gun bank, or missilebank-X if it is to be a missile bank. X in both of these is the number of the bank, so start with zero and work your way up for both. The count of gunbanks is not related to the count of missilebanks, so start both at 0 and don't skip numbers.

In the Schematic view, attach all firepoints for a particular bank to the container dummy helper as children.

====Dock Points====
Dockpoints are specified using a editable spline object and two point helpers. Place one point helper where you want the dockpoint, and place a second point helper a short distance away towards the "top" of the dock. If you want an argo to dock in a certain alignment, the second point should be above the first from the orientation of the argo. The spline should have been set up already and named $dockXX, and its final point should come very close to the first dockpoint. In the schematic view, attach the two dockpoints, in their creation order, to the dock path as children. The dock point normals will be set as the direction from the dockpoints to the first point in the path, which is often wrong, but this must be corrected after the fact.

====Special Subsystems====
To create the standard subsystems used in FS2, create a dummy object at the location and with the size of the special point you want to create. This point should have a name starting with '$' and should be named what you want the point to display as otherwise.

====Engine Glows====
Engine glows are created from dummy helpers attached to an engine subsystem. Place the dummies centered where the engine glows should be and set their size to the size of the glow. Glows associated with an engine subsystem should be linked to that subsystem as children.

====Glowpoints====
Glowpoints are very similar to gun/missile banks in setup, except that instead of point helpers for each point, they use dummys. The size of each individual dummy will determine the size of the glowpoint it creates. Glow banks are specified with a container dummy helper (which has multiple dummy helpers attached to it as children) with the name glow-X where X is the number of the glow bank (start with 0 and don't skip numbers). The string "$glow_texture=texturename" should be placed into the user properties tab for the parent helper.

====Insignia====
Insignia's don't work properly, so this tutorial will not address them.

===Converting===
Converting is a relatively simple process in comparison to actually setting everything up. It is, however, not foolproof and actually quite failure prone. It should be as simple as doing a file->export, choosing Freespace 2 POF as your export filetype, and selecting only the components that you actually have in your scene. The only exception is the glows box, which must always be checked or a crash will result.

====What can go wrong====
The simple answer is a lot. The converter will crash if you skipped a number in any sequence that requires a -X at the end. Debris is the most common place for this to occur now, though there are other places that it may also come up. The converter will crash if it encounters polygons on any mesh other than the shield that have no texture. The converter will also always crash if the glow box is unchecked, though there isn't any good reason for this. Finally, the converter will occasionally crash for no reason whatsoever, so always save before you convert and load it up and try again if it fails once. Failing twice in a row is usually indicative of a real problem.

===Things that still need improvement===
There are still some things that the POF converter cannot do properly. For one thing, it makes a mess out of the header; the mass values are about two orders of magnitude higher than they would be for an equivalent stock model. For another, the Moment of Inertia is a complete mess and doesn't output anything useful. Both of these values should be changed before the model is used in game. Unfortunately, if glowpoints were used, there is not a good mainstream way to correct the MoI data without losing the glow chunk, and PCS won't import glows, so you're sort of stuck unless you are willing to copy it by hand. There is a third issue that most people rarely notice; the converter miscalculates the raduis of the model by approximately a factor of 2, which creates some strange behavior during subspace warps and when viewing externally from the model. Again, there is not a good way to correct this, so it may just be something you have to live with. If the radius problem becomes an issue, please contact the user StratComm through the HLP PM system for assistance.