I will be listing a bunch of problems I can think of here now, and editing this first post to include any other problems and solutions as people bring them up.
>>My level is broken! Help!
Be sure to run GeomAdd in verbose mode and pay attention to the dialog boxes. They will tell you if you need to watch for some possible error in your import. You can always run the Verify Level function to get an end-report without modifying a level. However, the vast majority of possible errors are NOT caught by GeomAdd. You must be extremely careful and make constant backups if you are new to modding Tres. You'll eventually get a feel for when it's important to do it - which is still pretty damn often.
>>GeomAdd tells me my TPM version is not supported.
It always does that. I'm not sure what version it thinks it's looking for but ignore this (also, I suggest not using the "old TPM format" allowed for by TresEd - I've no idea what its differences are, and I don't think anyone uses it, so it will be difficult to help you, and I'll bet it was changed for good reason).
>>GeomAdd says that it can't find my values file.
Sometimes you don't actually need a values file. This counts for any visible object that will not be physical or have any other special properties. An object with no values has the following (and other) assumed values:
GeomAdd will also import no-value objects as GeometryType 2.
Code: Select all
string Class = "CInstance" string Type = "Box" bool Visible = true bool Shadow = true bool Tangible = false bool AI = true
Also sometimes of course, you DO want a values file, and one is not being used. Make sure that its name matches the TPM file you are importing.
>>GeomAdd warns me about importing 24-bit textures.
And for good reason. There are some bugs with it - use only 24-bit textures for gradual transparency requirements such as windows, steam animation, clouds etc., and then only in moderation as Trespasser was not meant to deal with many at once (in Software mode it can actually cause frequent crashes; it's more stable in Hardware mode). When you need to use them, you should first offset them 8 pixels to the left (and if you want, shift the first column of pixels down by 1 pixel, though this is usually unnoticeable).
>>GeomAdd says my filenames don't match.
If you have just renamed your level, this is actually normal.
>>GeomAdd says there were multiple class CSky found.
The level should still load. Retail and beta IJ have two skies - the first CSky instance loaded will be used.
>>GeomAdd says one of my values is wrong, but it's from the retail!
There are a surprising number of developer typos in retail Trespasser levels (you'd think they have an automatic spellchecker like TresEd..). We can know what values are and aren't "read" by the engine by looking inside it, as Big Red has done. The GeomAdd Known Values file included with Trespasser CE uses the values stated by Big Red as usable by the engine.
>>My object has no physics / is has only a box-shape in physics.
Trespasser objects get their physics from boxes only. The two types are Box (default) and Compound (lots of boxes, using up to 10 assigned submodels). Physics can also be "given" to an object by placing invisible instances in the same spot as them - in any number of boxes - but these boxes will not move with the object you've "given" them to. There is a way in TresEd-only to assign non-submodel physics to an object, using the following format (applied to "master" object):
This can, however, get very tedious to assign if you are using dozens or more invisible instances, which does happen. If you want to use this feature, it's a good idea to do it when you first start using each object. Otherwise your level will be filled with objects which don't do this and you'll decide it's not worth the trouble.
Code: Select all
string ext_Model00d = "(name1)" string ext_Model01d = "(name2)" string ext_Model##d = "(name*)"
>>My object has no physics ingame, but they are there in TresEd!
There are multiple possible causes. First make sure your object is using the proper Geometry Type:
GEOMETRY TYPE GUIDE:
- Visible Objects ~ 2
- Spherical/Point Triggers (Bounding Volume 0) ~ 1
- Box Triggers (Bounding Volume 1) ~ 2
- Water Entities ~ 2
- Compound Models ($ubobjects) ~ 2
- Compound Models for CAnimal ~ 1
- Invisible Instances ~ 1
>>The shape of my physics object is not the same in TresEd as it is in BONES mode when playing.
The exact dimensions of a physics object are based on the farthest vertex distance in each direction (X, Y, Z) from the pivot. To have an object appear the same in TresEd as it will be physically in Trespasser, the pivot must be exactly centered. Take note that this cannot be achieved using 3DS Max's "Center pivot to object" feature to to a long-surviving bug. The mesh must be manually centered on the pivot.
>>The textures I see in Hardware mode are all very blurry.
Yes they are. You'll need to go into the registry for retail, or the tpass.ini file for a stand-alone engine, and change the "Max Recommended Tex Dim" from 128 to 256. Trespasser unfortunately does not support textures larger than 256x256. It's also true that while Software mode has its graphical limitations, the pure-pixel graphics it renders are often crisper than you'll get with the Hardware renderer.
>>The texture I just imported is all messed up!
Are you sure that both dimensions are a power of two?
2, 4, 8, 16, 32, 64, 128, 256
>>How do I put new textures on the terrain?
Trespasser renders terrain by making a composite texture based on all the CTerrainObj objects in the level, casting their texture directly along the world Z-axis onto the terrain surface. Turn on Terrain Objects in TresEd to see these instead of the terrain.
>>My terrain objects appear fine in TresEd but with freaky colors ingame.
When Trespasser loads a level, it uses a single palette for the entire rendered terrain. This palette is taken from the first-loaded (lowest number) instance, which can be selected in the Terrain menu. You should make sure that all terrain objects use the same terrain before you import them - and you should choose your terrain palette carefully based on what colors you'll be needing for your specific level. To change the palette of a terrain texture you've just exported from someplace, the easiest way to convert it to the proper palette is to export a terrain object which is known to work from the destination level, open its texture, paste your new texture into this one, and save-as ontop of the original (you may wish to back it up first). Note that different graphics applications will yield different results when "forcing" an image into the palette of an open 8-bit paletted BMP.
>>How does fog thickness work?
Fog can be a tricky thing. I have never found a stable, consistent explanation. The best I can offer you is my fog testing level, fog~zone, for examples. Setting both fog values to 0.0 will create a near-zero-fog environment in Hardware mode but not Software mode.
>>How do I make my object "pop" out of a LOD sprite sooner?
Use the following two values:
float Culling (Don't draw if object is further away than this.)
float CacheMul (Default = 1.0; Cache object at further distance than normal (eg. 2, 3, 4).)
*Rebel made a full description of this and I've forgotten where it is - if someone can find it or describe it him/herself, please post below.
>>My CBackdrop object is black.
GeomAdd does not import this class of object correctly. Probably something to do with lighting. There are currently no work-arounds for this great type of object - we hope to solve that eventually with a new level editor. For now, I hope you like the color Black.
[[[Crashes during level-load]]]
This topic needs some careful observation-recording. Certain senior members at TresCom seem to have identified various points int he level-load bar which indicate different types of errors - I have occasionally but also occasionally don't remember. I can tell you that when an object referenced in by the value file of another object is missing, the level will stop loading about an 8th of the way to the end, and crashes early in level-loading often indicate serious errors that often require reimporting or recovering from a backup. A level which does not make ANY progress in the level-loading bar is in serious trouble, unless it is because the level uses the name of a retail level and is loaded in a demo engine without the called-upon loading image.
[[[Crashes during gameplay]]]
I'll get to this in due time...
>>When I load my level in TresEd, it has funky colors everywhere!
>>When I load my level in TresEd, it's not the same as the version I've been working with!
>>When I play my level in my stand-alone engine, it doesn't have any of the changes I've made!
TresEd was designed to seek out the \data folder referenced by your Trespasser registry. If any one of the level file names for the level you've opened from ANY location is found in this \data directory, TresEd will use it, regardless of what you tried to open. For this reason, I suggest not putting any custom levels in your retail directory, and if you want to load a modded retail level (or which shares a retail level name) from somewhere other than your retail data folder, you'll need to move those level files into a separate folder (such as a "LevelStorage" folder within \data). The funky colors you see can be caused by an incorrect SWP file (modded) being loaded by TresEd (since the retail data folder, by default, has no SWPs) and the rest of the files being loaded from the retail's data folder.
>>The level I've been working with was working great, but now all of the new textures appear blue!
If you are modding a retail level, you must be SURE that the SPZ is completely tucked away so that it does not get loaded by Trespasser, if you're working in the retail engine (which I don't suggest). What can happen is the game may read the SPZ instead of your modded SWP and actually overwrite the SWP you were using while you made the level. Don't let this happen!
~~~~~BASIC DOS AND DON'TS WHEN MODDING TRESPASSER~~~~~
- Moving Submodels >Submodels ("$") move along with their master instance in TresEd, if one is assigned. If you have both a parent instance and a submodel of it selected and then move them, TresEd will compound the movement of both the master and submodel for each of those submodels, moving them twice the distance. Ugly results - don't do this. Submodels, however, can be moved by themselves just fine.
- ******-00 >Trespasser likes objects to be named in a scheme where the object ends in a dash "-" followed by an instance number, where the parent instance (first, from which the others are referenced) ends in "-00". This is not required for Trespasser to work, but the engine WILL get upset at you if you begin making clones (-01+) of an object which does not end in -00. Not necessarily right away, but perhaps when you start cloning OTHER objects which don't end in -00. It's messy business - just put -00 at the end of the name for ANY object which you can IMAGINE might eventually be cloned. Objects which are not likely to be cloned are submodels, unique scenery/buildings, and the vast majority of triggers. Don't bother putting -00 on those, you'll be fine.
- Safe to Rename >You can safely rename an object in Trespasser following conditions:
- Ending numbers (-##) may be edited to anything you want as long as there are no duplicates. Trespasser will even recognize non-numerical values in this spot but TresEd will not, and won't be able to look up the parent-relation and values. Not including a -00 instance of a given model seems to be accepted by the engine (just the same, don't do it), and sometimes you may accidentally have this present in your level if you've imported things from someplace else and selected only clones. You can actually rename any of the present instances to end in "-00" to solve this problem.
- You can edit the full name of any object in your level, as long as it has no clones. If it does, you're going to have problems - That isn't allowed to do! Also, if you do rename an object in TresEd, DO NOT copy its mesh without first reloading the level! For some reason, TresEd will crash. If you, for example, make a trigger called "Trig_OpenDoor", and you want to instead have two triggers for this operation called "Trig_OpenDoorA" and "Trig_OpenDoorB", first copy the mesh into one called "Trig_OpenDoorB", then go back and rename the object you just copied.
- Do not put a dash "-" at any place in an object's name except do reference the "number" of that object clone. As noted above, anything after a dash in the Trespasser engine will be counted as a clone of the first object to have the name which comes before that dash. Use "_" instead.
- As a general note, TresEd monitors certain string values in the level for object names, and will update references within script value tables when an object name is changed - sometimes.
- Variables >CVariableTrigger is a great way to keep track of logical flow in a scripted level event; however, its "Value" value is unfortunately not recorded by savegames. They are still okay to use for single-time events, and/or a series of actions which take place in quick succession if the end result puts the variables back to the way they are at level startup. If you need a variable monitor to last in a savegame, try to set up your event so that it instead monitors the fired-state of a given trigger, since trigger states are included in savegames.
- Volume >The Volume setting for certain audio actions in Trespasser levels is not so great actually. Even when giving it ridiculous values, the volume does not go up that high. When used in the retail, it was always set to -5. I would advice only going as high as 5 - if that's not loud enough, you will probably need to alter the sound itself.
- They Don't Know Their Names >DO NOT rename a level by renaming the files. There are all sorts of other aspects which must be properly renamed - use GeomAdd to rename a level, but it is ALWAYS a good idea to get your level name chosen and final in the earliest stages of development.
- Retail Modding >It is generally not a good idea to mod retail (or beta) levels. There are all sorts of little special things going on in them that we may not fully understand. The worst thing you can do is to actually DELETE any instance from a level - if you really MUST be about the business of retail modding (as does inevitably happen), don't delete anything, but just move it out of the way, or something. Importing can also be tricky, just make frequent backups (even more than usual).
- Bumpmaps >We do not yet have the technology to import new bumpmaps into Trespasser. It takes lots of research, and the original creator of our tools has left this region of space. You can mod a retail level and retain its bumpmaps - however, if you import an object which uses a texture that is bumpmapped in the level, this object will NOT use the bumpmapped texture (unless you do some serious hex-editing instead - ask machf). It's just as difficult to replace the diffuse map used by a bumpmapped texture - possible, but good luck (unless your a master-hexer, I guess).
- Mipmaps >The mipmap (smaller) textures made by GeomAdd are not as good as those found in Trespasser. If you are modding a retail level, try not to replace a perfectly good texture with an identical one, lest you replace these awesome mipmaps with shitty ones.
- Time Of Day >No, I'm afraid the Sky texture cannot be animated, and I'm pretty sure the ambient light can't be changed ingame, either. Fog can be (including fog color I'd guess, if you are in Software mode), but that will only get you so far. And Trespasser does not support skybox textures.
- Poly/Detail Limit >The theoretical polygon (mesh-triangle) limit for Trespasser is 2048 (and 1024 for CAnimal). Models above this limit have been used but can create unstable levels, and either way, it's just more than Trespasser was designed to handle. When making a new model for Tres, try to keep it generally below 1024 unless you have a damn good reason (larger objects, for example, can survive with higher poly counts since they take more area of the screen). Small visible polygons are also going to mipmap much faster and turn "whitish" ingame, which doesn't look so hot. Objects which there will be many of (trees, for example) should be kept in the 700-or-lower range (preferably closer to 300), as the number of polygons on screen will start going up very quickly and can easily lead to crashes.
- Terrain Limits >Trespasser terrain quads can be divided seemingly infinitely. There does not seem to be a division level at which a level will crash; however, the overall terrain detail of a level terrain will affect game stability and can lead to lower framerates and crashes. Increased terrain detail also seems to decrease the number of water entities that can be active.
- TresEd Terrain >AVOID IT AT ALL COSTS! TresEd-generated terrain, which uses a greyscale monocolored bitmap for the heights, is not created properly and leads to many, many terrain bugs, the most annoying of which is terrain height in TresEd which is entirely inconsistent with what you see ingame (these effects get more obvious as total terrain size increases). Use a retail terrain (such as the flattened terrain with the Trespasser CE StartLev) as a base and go from there using Terrain Edit Mode. In the rare case that your level REQUIRES a massive terrain larger than 1024x1024 units (meters), be warned that these problems will arise and consult modders who have found ways to deal with it when necessary (such as myself or to a degree Sam).