Siliconmaster
June 20th, 2010, 02:08 AM
So I keep seeing little threads asking about typical, but annoying tool errors that aren't covered by the HEK tut. Sometimes it will be an error that is covered by the HEK tutorial, but isn't working as Gearbox described it. I've decided to create this WIP thread to act as a go-to reference to those who are still using CE and running into issues with the ever-useful tool program.
There used to be a thread like this on the old gbx forums, but I can't find it. If anyone knows where it is, link me so I can use some of that information. For now though I'll add stuff here as it comes to mind. If anyone thinks of more weird errors and their causes, let me know and I'll add them.
06.13.10 22:19:52 EXCEPTION_ACCESS_VIOLATIONTypically this means that for some reason tool or sapien cannot access the scenario file. It's the Halo equivalent of the Windows "The process can not access the file because it is used by another process" error. I've found that this can be fixed by closing all other Halo-related programs that might be using the file, including any dev hacks that are open. As a last resort restarting will shut down all process and usually solve the problem.
Building subclusters...
cannot allocate subclusterThis error is related to Halo's portalling system. By default it needs to break the level up into "subclusters", with so many faces per subcluster. There are only so many subclusters per portal cluster. If you don't have enough portals, eventually the game runs out of subclusters, and you get that error. Adding in some basic portals will usually solve this pretty easily.
### WARNING found nearly coplanar surfaces (red and green)
This error. What the hell. Unless it's related to phantom bsp, which it very well may be, this error is simply the most obnoxious thing ever, and only exists to clutter up your debug.wrl files. Ignore it.
### ERROR: portal does not define two closed spaces. (see yellow in error geometry)
The HEK tutorial covers this one, but the error shows up any time the portal doesn't seal an area. Usually this means go find the mismatched vertex and weld it, but sometimes tool will give this error even when the area is completely and absolutely sealed. Sometimes it will declare an area sealed, and after you change something in a completely unrelated area tool will change its mind and call the first area unsealed. Often this can be fixed by deleting and remaking the affected portal. However, if you are absolutely sure that the area is sealed, then you can probably ignore it- I've had portals still function perfectly even when they're swamped by this error. A good way to check if the portal is working correctly is to go into sapien, into the "cluster properties" section, and switch the weather in one portal cluster. If the weather doesn't show up in the other cluster, your portal is working fine. If it does, you need to actually do something about it.
### WARNING unearthed edge (magenta boxed lines)
The HEK tutorial covers this one for most instances, but I'm including it here because sometimes tool decides it's having a bad day, and it calls a portal edge that is totally outside the geometry unearthed. The only way to fix this is to randomly move the points around until tool likes it. However, I'm not entirely sure it matters- the portal might work anyway.
### WARNING: a surface clipped to no leaves (see cyan in error geometry)
Normally, as mentioned in the HEK tutorial, this references a face that is coplanar with another section of geometry, like a box resting on a plane. You can usually fix it by raising the box slightly above the plane, thus giving the local portal system a chance to differentiate the faces. However, this error will also show up if you have a lot of faces in a single cluster, and then you start having multiple objects. For instance: You have a sealed construct floating slightly off the ground in one object, then the ground and surrounding level in another object, and then the lights in a separate object. In rare instances tool will pick random faces and call them "surfaces clipped to no leaves", which leads to some very confusing and meaningless .wrl debugs. This however is easily fixed by consolidating the objects into a single level object, or even better, actually connecting them physically to the level, instead of having them floating above the ground.
08.11.12 17:17:53 radiosity error: smooth triangle group too big for page levels\d40\d40\shaders\large lt steel08.11.12 17:18:02 EAX: 0x00000000
08.11.12 17:18:02 EBX: 0x1F379D01
08.11.12 17:18:02 ECX: 0x00000000
08.11.12 17:18:02 EDX: 0x00000000
08.11.12 17:18:02 EDI: 0x0018E560
08.11.12 17:18:02 ESI: 0x00000000
08.11.12 17:18:02 EBP: 0x0018E438
08.11.12 17:18:02 ESP: 0x0018E428
08.11.12 17:18:02 EIP: 0x77B10C22, 83 C4 04 C2 ?????
08.11.12 17:18:02 EXCEPTION halt in \halopc\haloce\source\structures\radiosity\interme diate_radiosity.c,#2305: surface_index==last_material->first_surface_index+last_material->surface_count
This error is caused by having too many faces using the same smoothing group. This occurs most frequently with exported bsps, since sometimes all faces get set to smoothing group 1. I have yet to determine if this is a fault of the export program or a fault of 3ds max importing the .obj file, but it's somewhere in that process. To fix it, disable smoothing groups or do a better job at them if it's a totally custom bsp.
08.11.12 03:00:30 EXCEPTION halt in \halopc\haloce\source\memory\array.c,#130: index>=0 && index<array->count
This error has popped up from time to time on forums, but it's never been pinned down. It may be a general error, rather than a specific one, meaning that it could result from multiple problems. One I have heard is that it is exceeding the poly limit of tool's import function.
In my case, it was an issue with double-sided glass. When exporting bsps from Halo, be aware that a single face imported with the % symbol will become two faces, one facing each way. Therefore, upon exporting bsps from Halo, any surfaces that used the % symbol originally are now doublesided physically in 3ds max. If you try to use the % symbol again, tool will try to make them 4-sided, which then causes a crash. Solution- delete one side of the glass and recompile, still with the % symbol. Getting rid of the % symbol and keeping the double-sided glass might also work, but then any new glass also needs to be double-sided so it's all the same.
There used to be a thread like this on the old gbx forums, but I can't find it. If anyone knows where it is, link me so I can use some of that information. For now though I'll add stuff here as it comes to mind. If anyone thinks of more weird errors and their causes, let me know and I'll add them.
06.13.10 22:19:52 EXCEPTION_ACCESS_VIOLATIONTypically this means that for some reason tool or sapien cannot access the scenario file. It's the Halo equivalent of the Windows "The process can not access the file because it is used by another process" error. I've found that this can be fixed by closing all other Halo-related programs that might be using the file, including any dev hacks that are open. As a last resort restarting will shut down all process and usually solve the problem.
Building subclusters...
cannot allocate subclusterThis error is related to Halo's portalling system. By default it needs to break the level up into "subclusters", with so many faces per subcluster. There are only so many subclusters per portal cluster. If you don't have enough portals, eventually the game runs out of subclusters, and you get that error. Adding in some basic portals will usually solve this pretty easily.
### WARNING found nearly coplanar surfaces (red and green)
This error. What the hell. Unless it's related to phantom bsp, which it very well may be, this error is simply the most obnoxious thing ever, and only exists to clutter up your debug.wrl files. Ignore it.
### ERROR: portal does not define two closed spaces. (see yellow in error geometry)
The HEK tutorial covers this one, but the error shows up any time the portal doesn't seal an area. Usually this means go find the mismatched vertex and weld it, but sometimes tool will give this error even when the area is completely and absolutely sealed. Sometimes it will declare an area sealed, and after you change something in a completely unrelated area tool will change its mind and call the first area unsealed. Often this can be fixed by deleting and remaking the affected portal. However, if you are absolutely sure that the area is sealed, then you can probably ignore it- I've had portals still function perfectly even when they're swamped by this error. A good way to check if the portal is working correctly is to go into sapien, into the "cluster properties" section, and switch the weather in one portal cluster. If the weather doesn't show up in the other cluster, your portal is working fine. If it does, you need to actually do something about it.
### WARNING unearthed edge (magenta boxed lines)
The HEK tutorial covers this one for most instances, but I'm including it here because sometimes tool decides it's having a bad day, and it calls a portal edge that is totally outside the geometry unearthed. The only way to fix this is to randomly move the points around until tool likes it. However, I'm not entirely sure it matters- the portal might work anyway.
### WARNING: a surface clipped to no leaves (see cyan in error geometry)
Normally, as mentioned in the HEK tutorial, this references a face that is coplanar with another section of geometry, like a box resting on a plane. You can usually fix it by raising the box slightly above the plane, thus giving the local portal system a chance to differentiate the faces. However, this error will also show up if you have a lot of faces in a single cluster, and then you start having multiple objects. For instance: You have a sealed construct floating slightly off the ground in one object, then the ground and surrounding level in another object, and then the lights in a separate object. In rare instances tool will pick random faces and call them "surfaces clipped to no leaves", which leads to some very confusing and meaningless .wrl debugs. This however is easily fixed by consolidating the objects into a single level object, or even better, actually connecting them physically to the level, instead of having them floating above the ground.
08.11.12 17:17:53 radiosity error: smooth triangle group too big for page levels\d40\d40\shaders\large lt steel08.11.12 17:18:02 EAX: 0x00000000
08.11.12 17:18:02 EBX: 0x1F379D01
08.11.12 17:18:02 ECX: 0x00000000
08.11.12 17:18:02 EDX: 0x00000000
08.11.12 17:18:02 EDI: 0x0018E560
08.11.12 17:18:02 ESI: 0x00000000
08.11.12 17:18:02 EBP: 0x0018E438
08.11.12 17:18:02 ESP: 0x0018E428
08.11.12 17:18:02 EIP: 0x77B10C22, 83 C4 04 C2 ?????
08.11.12 17:18:02 EXCEPTION halt in \halopc\haloce\source\structures\radiosity\interme diate_radiosity.c,#2305: surface_index==last_material->first_surface_index+last_material->surface_count
This error is caused by having too many faces using the same smoothing group. This occurs most frequently with exported bsps, since sometimes all faces get set to smoothing group 1. I have yet to determine if this is a fault of the export program or a fault of 3ds max importing the .obj file, but it's somewhere in that process. To fix it, disable smoothing groups or do a better job at them if it's a totally custom bsp.
08.11.12 03:00:30 EXCEPTION halt in \halopc\haloce\source\memory\array.c,#130: index>=0 && index<array->count
This error has popped up from time to time on forums, but it's never been pinned down. It may be a general error, rather than a specific one, meaning that it could result from multiple problems. One I have heard is that it is exceeding the poly limit of tool's import function.
In my case, it was an issue with double-sided glass. When exporting bsps from Halo, be aware that a single face imported with the % symbol will become two faces, one facing each way. Therefore, upon exporting bsps from Halo, any surfaces that used the % symbol originally are now doublesided physically in 3ds max. If you try to use the % symbol again, tool will try to make them 4-sided, which then causes a crash. Solution- delete one side of the glass and recompile, still with the % symbol. Getting rid of the % symbol and keeping the double-sided glass might also work, but then any new glass also needs to be double-sided so it's all the same.