Backups are a very good thing. Having several backups is what separates a sensible person from a silly person.
In Thief 2 the maximum number of objects that can exist in your level is 2400. This can be increased via dark.cfg, but that doesn’t really give you unlimited objects. For example, there is an overall brush limit, which is somewhere in the region of 7000. Note that this limit only matters if you’re going to portalize/optimize in the future. This is why it’s a good idea to place all of your terrain brushes before you start adding other things.
Then there is the command resize_obj_id_space. This can be increased, but only up to 4000. It’s worth noting that objects created in game (e.g. things fired from EmitterTraps, flinders etc) count towards this limit as well as the objects you’ve created yourself.
Therefore it is best to minimise your object count. It is up to you whether you do this as you build or only if you approach the object limit.
There will be many objects in your level that don’t interact with anything (as far as scripting is concerned), for example tables, chairs etc. Less obvious are TrolPts. They may be linked to other TrolPts, but they don’t actually interact with anything, not even with patrolling AI (all the work is done by the AI).
It may not be obvious, but lights can also be used as scripting objects - but only if they are not animated. If a light is animated, it will respond to TurnOn/TurnOff messages and thus will be unsuitable for most forms of scripting.
Conversely, there will probably be many objects that deal with scripting but are not rendered, and whose location is irrelevant. RelayTraps for example, and in fact most things in the fnord section of the Object Hierarchy.
So, for the ‘scripting’ object, make a note of all the scripts, properties and links it uses. Then find an otherwise inactive object and add to it the scripts, properties and links that the scripting object used. Then change the name of that object so that you know what it does. That final step is optional, but highly recommended. You can then delete the scripting object.
It’s clear that you should not do this with things like TeleportTraps, but you also should not do it with DestroyTraps because once they’ve been activated and destroyed their target, they will destroy themselves.
This requires the use of a 3D object editing program, such as Anim8or, 3DSMax etc. Say you’ve got two tables that are right next to each other. You could import the table object into the object program, then place a copy of the mesh next to the original, like so:
After exporting the new object to your obj folder, in Dromed you can replace the two tables with one table using the new model. That’s saved an object without affecting the appearance of your mission.
You can be even more ambitious. Say you’ve got a BigTable with 8 chairs dotted around it. You can import the table and chair models into your object program, then place the chairs around the table. You’d then be able to export just one object that looks like 9. Lots of objects (even if it’s merely the illusion of lots of objects) can help to make missions look more real.
There are two further advantages of grouping objects besides reducing the object count:
There are only two objects in the above image. The six at the back of the group are one object, and the two crates and two footlockers at the front of the group are also just one object. Obviously this means the footlockers cannot open.
Of course before you consider grouping objects, make sure you know whether or not you’ve previously given them scripting tasks to perform.
There is an object poly-count limit of around 2000. In a lot of cases it’s unlikely that a grouped object will exceed that limit, but some custom objects (for example a lot of objects from the Enhancement Pack) already have high poly counts and a group of them would probably exceed it. It this case you have two options:
The choice you make should depend on how desperate you are to reduce the object count, and how many objects you could save.
For object shadows to affect the light gem, the object must have the property Renderer → Runtime Object Shadow set to True. However, if the polycount of the object is too high, this will make the entire object become dark.
Using custom scripts can be a very good way of reducing the number of objects needed to perform various tasks. For example, adding a link between two objects without using custom scripts requires a conversation, which in turn requires an AI, which will probably have to be hidden away so that it cannot come to harm. Using the NVLinkBuilder script allows you to use just one object. You could actually use no extra objects, since the script can be made to refer to its own object. Therefore you could put the script on one of the objects to be linked.
Using any or all of these methods, you can seriously reduce object count without having a visible effect on the mssion.