Oddlot of Information

Don Mazur -Febuary 5th 2002
Some Odds and Ends and helpful Dromed related bits (mostly deals with coplanar and other errors).

My intent with this text is to help to prevent missions from being scrapped, as I personally believe that some of the ideas mentioned below may have been factors into missions dying.

Multibrushing bugs:
—————————————————————–
*I want to mention a few things about the multibrush process and a flaw or two. In short it’s best not to use doors and lights like torches in a multibrush, because weird errors can occur. Such as coplanar case errors with doors and some weird phenomenom with the linkage for objects like torches.
*Also even terrain brushes can have some weird results. The vsnap function (came from a post from Rob Camino$ an ex lgs employee) added to your user.cfg is not fool proof and is not to be trusted. Best to manually snap each individual brush by hand after inserting terrain into your level via multibrush.
*To be precise of what I mean is this: I started missX by adding a multibrush of a previously done level’s terrain into a new file, then added my terrain to that as well. The coplanars occured whenever I inserted *new* terrain brushes coplanar to these previously inserted terrain brushes. Fixing it was simple by just hand snapping the old inserted multibrushed terrain. If you don’t add new terrain you may or may not see the errors occur, which is why this may never have been mentioned before.
*Also, the highlight do snap thing doesn’t help with this situation. Trust me when I say that manually snapping is a key to an error free level with multibrushed terrain.
*A tip for handsnapping multitudes of terrain brushes is to filter out everything aside for terrain then use the tab key to cycle to the next. Shift + mouse click hold + move then let it snap then go to the next via tab. Also while I’m at it, becareful of that shift move proccess as it’s easy to mistakingly make another multibrush because of that.
I wish there was another key instead of shift that would be used to move brushes. This is where that whacky clone effect stems from, where people have duplicated brushes all over. But I guess that can be changed if you are inclined to figure out how.
*But vsnap isn’t entirely useless as it’s handy for getting the total brushes “close” to where you want them to be. Just don’t assume that a hilight do snap will be 100% effective.
—————————————————————–

Coplanar case optimization errors due to doors and other coplanar issues:
———————————————————————*Also another strange occurance happens with doors. Doors have an associated blackable brush (which helps the cell area in the doorway) when inserted, and seemingly it (or the portal) can create coplanar errors in certain situations. For instance: if you make a doorway airbrush, portalize, add door, then alter the doorway brush thereafter. Or if adding lets say some trim solid brushes coplanar to that airbrush. Very often coplanars happen like this. Easy to correct if you simply move the door out first then replace it after the next portalize. Or if you have the error and simply forgot about it, just clone the door and place it back and delete the old door.
*Another pesky thing about doors is how ai’s deal with double doors. Often double doors will confuse pathfinding. Use show-cell or even show_cells to see what the situation is. A sneaky tip here: If the cells are causing the ai’s to have issues, add some strategic blockable brushes to alter the cell structure. But be forewarned that as the build progresses the terrain may be reordered in *time* a little bit by the engine. So it’s best to save that for last. This process unfortanetly requires lots of trial and error and tinkering.
*Also keep in mind that the irregular terrain shape’s edges can cause issues like coplanars if they approach the coplanar edge of a regular shape. And worse can happen the infamous polyhedron error can cause a crash of Dromed.
*Also keep in mind when searching for coplanar instances while using area brushes can be a touch and go thing:
#1 Sometimes extended terrain outside of an -area brush me only’d- space can in itself cause a coplanar.
#2 In the afore mentioned multibrush/highlight do snap thing above using area brushes seemingly shows the build to be coplanar free which is not the case. A full level Optimize often continues to show coplanar instances, while zoning in with area brushes may not show any. If this is the case consider handsnapping every single terrain brush before you decide to scrap that level.
#3 Avalon states that using nice rounded off dimensions for the area brushes themselves can prevent coplanars caused by the area brush configurations.
—————————————————————–

Portal-cells intersecting sphere thing and your monolog and you:
—————————————————————–
*This is a lighting/complex scenery thing. Your only clue of where it happens and the only warning exists in your monolog. Add the word monolog into your user.cfg (I cannot stress how useful this feature is). A monolog.txt will be created and written to as you do your build, pathfinding and portalization all illustrates useful things here as well as from game mode. Keep in mind that not everything in here indicates errors. Much of it simply is to report what’s going on.
Now if you have a light source that goes toward infinity (no radii input) and it intersects an area with too much complexity your monolog will warn you of this. Even the builders of the OM’s apparently didn’t heed their monologs as I’ve found plenty of occurances of this happening throughout all OM’s. In some circumstances when the player walks over the area in question the framerate will be a virtual crawl. To avoid this give your lights radii and avoid letting the light spillover the complex areas.
*Also this occurs if you carve out a section that is tight. For instance I made a very small hole and placed omni light brushes in them for the light to peer out from. So instead of the omni brush, I used a hacklight object from the hierarchy and placed a radius on it. In fact after dealing with this issue, I’ve learned to prefer using these over the omni brush lights now as I have more control over them. The drawback is that they count towards the obj limit, however that limit isn’t a problem like it was with T1 anyways. Also there isn’t an equivalent to the omni brush, but the animiated one works the same way.
*If you’re wondering why a space seems to drag on frame rate more so then you think it should (polys, cells, objects in view, and backfaces aren’t out of hand), then lighting might be the culprit. Check the lighting in that area and their radii. In cityscape architecure when using windows to spill light out towards the streets, consider the hack lights in their place. You’ll be suprised by how much the frame rates drop and truthfully, they shouldn’t go towards infinity as it’s unrealistic. Light tends to weaken and spread over spans.
*A simple method of locating portal cell- intersecting sphere troubled areas is to refer to your monolog after an optimization. Next create a marker and simply move it to the area in question by keying in the numbers.
*Another thing about complexity is the fact that the error “scene complexity” can occur while portalizing it’s not singular to the game mode occurance. As a mission’s build size increases it may reach a point at which a full level portalize is impossible and simply running Optimize in it’s place will keep the build alive. Personally I believe that portalize is obselete and I rarely run it with the exception of doing small area brushed spaces and focusing on alignments. However after reaching a point of complexity errors, I’ve never turned back and I always run Optmize when doing the full level.
*It’s been brought to my attention that there is a way to get around the game mode scene complexity error by doing a save and reopening of the file. But beware that the portal cell-intersecting sphere effect isn’t routed by that process and the lighting can still wreck havoc on the frame rate.
*Also the bad cret position occurance that monolog will spew relates to ai’s having trouble negotiating the terrain. Sometimes it’s simply a matter of the player being on the “outskirts” of the ai’s range for it to be active and might hang up because it can’t get around. But that’s not always the case. The terrain itself may in itself by the problem and may require drastic change to help the ai. It’s a trial and error proccess which is slow and tedious but hell, if you’ve worked with dromed what isn’t?
*We’ve all experienced the bad cret issue while playing FM’s and OM’s alike, When the game seems to virtually drag onto a crawl it’s usually the culprit. Possibly a simple save of the game and reload clears it, but sometimes an ai needs a knock on the head. *Also whenever you do spew commands it often reports it to mono (monolog) check that txt after a spew command.
*A list of all the dromed commands can be seen in a txt file named ‘dump_cmds.txt’ without quotes. To view this simply type ‘dump_cmds dump_cmds.txt’ again without quotes. The file magically appears in your thief folder just like monolog will after placing it in your user.cfg.

A list of things used in user.cfg (from Rob Camino$’s post that I have in mine are thus:
—————————————————————–
monolog
edit_screen_depth 16
check_rooms
no_endgame
vbrush_snap
;new_snap
translate_by_grid
springcap
max_spring_vel 1000
toggle_draw_lgd3d
;game_screen_depth 16
edit_screen_size 800 600
;game_screen_size 1024 768

monolog: This gets monolog.txt working
edit_screen_depth 16: We all know this by now right? (if you don’t this is needed to see what you are doing)
check_rooms: Helps with errors in room brushing see below. Room brushes with issues will be highlighted yellow.
no_endgame: Another common command which we all know, prevents dromed from closing when you die as you test in game mode.
vbrush_snap: Snaps multibrushes or so we’re led to believe
;new_snap: A different method of grid snapping, I prefer the default method which is why I placed the ; before the command to prevent the command from being used.
translate_by_grid: Mystery to me, but if Rob placed it in his user.cfg there must be some use. If you know then by all means let us all know!
springcap: ” ”
max_spring_vel 1000: ” ”
toggle_draw_lgd3d: ” ”
;game_screen_depth 16: Depending on what resoultion you run you can tinker with these.
edit_screen_size 800 600:
;game_screen_size 1024 768:

—————————————————————–

Room brushing:
—————————————————————–
*I cannot stress enough the importance of roombrushing your level as you build and not after you complete all of the terrain. The ai pathfinding has changed my terrain a number of times and could only have been known if I roombrushed and tested ai’s as I would go along. The ai’s often will show up in monolog whenever they enter non rom brushed areas which again, will help to locate any holes or over extended room brushes. Plus it’s much easier to room brush when the brushes are fresh in mind and not 6 months old in hindsight. There will be less sound holes this way as well as better propogation. There are times that roombrushing may be problematic due to the cube only shape.
By doing it as you go, you’ll avoid that. Also if the mission build is large and you’re nearing one or more of the prebuilt limits you won’t be short changed.
*With check_rooms inserted in your user.cfg as mentioned above you’ll see if you made flawed room brushes (center of one is in another) firstly and the highlighted ones thereafter occur if RB’s intersect through solid space which is unavoidable at times especially with irregular terrain.
I’m sure there are many dromeder’s with varying opinions on this esecially. However my experiences have taught me that the overall build time will decrease as well as prevent bad roombrushing from occuring. A personal pet peeve of mine is to walk into a sound void which throws immersion off completely for me.
—————————————————————–

Speaking of limits here’s some of them approximated (T2):
—————————————————————–
*Ambient objects; 232
*Total Brush insertions; 6920 My Durant crapped out around this figure but to be safe I stuck with no more then 6915. This includes all insertions regardless of what operation it is.
*Room brushes; 700 or so (maybe a tad more but this one I never breached)
*obj_max 2400 (can be routed using the ‘resize_obj_id_space’ without quotes) it will allow for obj limit resizing without alteration of the dark.cfg but be warned that it’s a one way ticket and you cannot shrink it back.
*Total Polys; 35,000 or so, but is best to keep around 25,000 or less I’d wager (do report with dump everything and it’ll show up in the defualt.rep file) According to Emil of Ion Storm (ex lgs’er as well) in one of his posts regarding Lotp vs Unwelcomed guest. He wanted to keep the total poly size down and instead of just opening angel tower up he ridded many terrain brushes to keep polys down as a trade off.
While there are a few FM’s with more, Inverted Manse comes to mind, it might be best to keep it down as not all of the players have computers as fast as what you may have. T2’s min specs are 233 p2’s I believe and there are some taffers running that still. Casing the joint and Sabotage sit around 25-26k and are quite large in honest truth. So I’m inclined to believe there is an association between slow downs and total polys even though T2’s limit is much higher.
*Cells; 26,000 and thereabouts. Sledge reported having a crapout while running optimize as it exceeded not far above that figure. This shows up on your csgmerge window during the optimizations.
*I understand there is an Area Brush limit which if I recall was like 45 or so for T1. I can’t imagine why there’s a limit on these.
—————————————————————–

Moon/Sunlight direction:
—————————————————————–
If I wasn’t completely off the wall and random in my thoughts while writing this… I’ll mention a method of getting that celestial object to sit where the mystery sun/moonlight’s direction is coming from.
In a small test mission I’ll make an airbrush with the ceiling skyhacked and place in the data accordingly for my sky (guesstimate the size and locale of the airbrush to be similar to your intended mission). At some point I’ll make an enormous amount of sunlight and run optimize. Using trial and error I’ll pinpoint where to locate that celestial object so that the shadows are where they should be. Most likely it’ll be the moon because most thieves are out at night. So simply tone down the amount of light after. After this I’ll take the data and transpose it into my level.
The reason why I don’t pointpoint a more accurate way is the fact that the celestial objects are the size you make them and no matter what trial and error is needed. Add a little blue to the color and bingo you have silvery moon. (see the lighting color tutorial for specs on coloring). I’m unclear as to why the OM’s didn’t use the sunlight feature as it makes the outdoors seem much more lifelike. —————————————————————–

File organization:
—————————————————————–
All too often at the guild we hear of people running into dangerous territory of “mission scrapping” and much can be due to lack of forethought.
*Save your work and save often
*Develop a system of saving so you know of who/what/where/how/when is going on with previous versions of the build.
*Backup.mis is created each time you save out.
p_portal.cow is created each time you portalize/optmize. If all else fails open it and set gamesys if it’s custom and save it to a new mis name.
Keep in mind that any future portalize/optmizes will rewrite it. So if you run into any issues, *IMMEDIATELY* stop and save your efforts. For instance when an error occurs I save out as missX.mis in case I need to go back to it.
—————————————————————–

Objective crafting:
—————————————————————–
The biggest tip to offer anyone is to gain an understanding of the process via reading the docs, then slap your head and say to yourself, “I should be using TOW.” Use that program and you’re objective issues will vanish.


About this entry