Common UnrealEd Crashes: Easily Avoidable Tragedies
Contents
General
- Don't put lights into the solid space because it will cause crashes.
- At least on Win2K Pro, right-clicking on the desktop and changing Appearance -> Schemes will crash the editor.
- When setting the Light Color (Button in UEd 2) don't click on any of the viewports. If you do, the Editor will crash.
- Don't try to do "Convert -> Static Mesh" on a static mesh. ;)
- Doing Edit -> undo too many times in a row usually results in a crash
- Don't right click on a viewport and select View-> show fluid surfaces if there is no fluid surfaces in your level.
- When in Terrain Mode don't select a HUGE area with the vertex editing tool and try to move it. Because you are trying to move so many vertices at the same time UnrealEd will most likely crash or freeze up.
- Creating a Warp Zone to itself will cause a big crash!
Brushes and vertices
- When you are vertex editing be careful and don't cross the edges of polygons and don't overlap two or more vertices. If you overlap the vertices you won't be able to separate them afterwards and if the overlapping reduces the facecount of the object then UEd will instantly crash after you release the mouse button moving the vertex.
- Save a lot when you are using the BSP based terrain brush.
- Keep a close eye on what you move and where
- If you are using the Vertex mode the sensitivity of the movement depends on the grid setting you use. Certain grid settings will need a steady hand and lots of concentration.
- Don't try to select a surface's underlying brush with SHIFT+Left-Click if the brush has been deleted (see Mouse Control for more on this function).
- Don't duplicate a brush that's smaller than the current grid size, or equal and off-grid.
- If you must put a tetrahedron (sphere) brush into your map, don't set the extrapolation value above 3 or 4. This results in a hugely complex brush shape that not only tears the BSP to shreds but also is likely to cause a crash when you try to add or subtract it.
2D Shape Editor
- Don't cross edges in the 2D Shape Editor. When you try to extrude the shape UEd will crash.
- UnrealEd 2 can be crashed by importing a texture file into the 2D Shape Editor incorrectly (and, this happens unexpectedly). When you open the 2D Shape Editor and attempt to import a door texture with the intent of transferring the exact dimension to a 3D Brush, you can crash UnrealEd by doing 2D Shape Editor Menu -> File -> Image -> Get From Current Texture. The behavior of the 2D Shape Editor is inconsistent, sometimes the above mentioned technique works, sometimes it doesn't. (This suggestion from Machismo) The solution is that the 2D Shape Editor can only open .bmp textures. So, when you have the desired texture selected in the Texture Browser, right click the texture and select, Export to .pcx. In the Save Dialog window, select, Save as Type > All File Types, and save the file as a (unique name) .bmp file. Then, from within the 2D Shape Editor, select, 2D Shape Editor Menu -> File -> Image -> Get From Disk and, import.
- Tarquin: I've never had this problem, some people say it's frequent. Could it be OS-related? I've just seen a post on TO about this occuring after a switch to win2k.
- Daemonica: I don't think it's Win2K, a few of us use it here with no problems, it's a useful and often used tool.
- Legal: I don't get it with UED2 but with 3. It must be teh G0bl1n :p
Textures
- If you delete a texture that is in use UEd will crash. Fix: use the Texture Replacement Tool before deleting a texture. (Even if you don't see the texture, it might be used on an invisible surface of a brush.)
- There are several ways to crash UED if you are not careful when deleting or renaming textures, they are:
- Deleting a texture that is in use - if you delete a texture that is in use, UED will crash if you try to save or look at the texture in the 3D view (this is really tough, you're moving around and all of a sudden it hangs). The correct way to do this is to first make sure that the texture is not in use Anywhere in the map (including surfaces you can't see!), and then delete the texture. If you have used the texture a lot and are not sure where all it is, then you can use the texture replacing tool, or test if you have gotten rid of the texture entirely by performing a texture cull, which will also remove the texture for you.
- Delete a texture and then rename another texture to be the deleted texture's name - I'm not quite sure of the specifics, but if you want to do this delete the old texture, save, and re-open the map, then rename the other file. Better yet if you are simply replacing a texture import the new one right over the old one.
- Importing a file of .bmp or .pcx type that is NOT in indexed 8-bit color format will crash the editor with a General Protection Fault. (I'm not sure you can actually save a .bmp in RGB color mode or anything else besides indexed but I know for a fact that Photoshop is quite willing to save a .pcx in RGB color mode).
- In UnrealED 3, many time importing a texture with the same name, overwriting a previous texture, and then using the same type of DXTC compression to compress the texture gives a crash. Possible workarounds would be compressing the texture before importing.
- This won't crash UED, but it'll make your map completely unplayable, saving the MyLevel package as a texture package, or SM package, etc. So far i have found no remedy for this.
- Creating a new Raw material derived from itself. (eg. Creating a TexPanner which Pans itself).
When creating a new raw material the Texture browser will automatically select this new material. This is a common trap for people who:
select the derivative material from the Texture Browser -> Create the new material -> Click the Use button to use the selected derivative material. The correct procedure is as follows:
Create the new material -> select the derivative material from the Texture Browser -> Click the Use button to use the selected derivative material.
Sounds
- Adding a modified AmbientSound to your level, when the file size becomes too big for the Unreal Engine (Can this be accurately quantified?) will cause both Unreal Tournament and the Unreal Editor to crash. Typically, this is a file mixed with ModPlug Tracker and converted to .wav format. (I will add a better explanation later)
- Adding a custom sound to your level without importing it properly ( and, I don't know the correct technique for this) will cause a General Protection Fault. The level design will then be unplayable, even if you delete the Ambient Sound. The recommended techniques in various tutorials, does not work as advertised. (I will research this and find the TRUTH.)
- Importing sounds with 44KHz 16bit quality and above is not firmly supported by UE1 and playback of such is almost certain crash case. Upper recommended limit for sounds is either 44KHz 8bit (if you really care for those highest frequencies) or 32KHz 16bit (if less noise is a priority).
Terrain
- Terrain texture layers do not like being rectangular.
- Do not use the terrain smoothing tool near the edges of terrain.
BSP Rebuild Options
- Which settings in the Build window can safely be changed?
- Anything in the Optimization section. Avoid at all cost the BSP Rebuild Options section. People have completely killed UnrealEd by changing these. (This seems to be what everyone quotes, but you can quite safely change the sliders without destroying the editor. They are also set back to the default settings when you next load UED, so you can just reload the editor if anything goes wrong)
- Changing the first slider alters the amount of BSP cuts that are made. I don't know the exact effects of this, only that setting it to the highest level gives a ridiculous amount of BSP cuts and setting it to "Minimise Cuts" does exactly that. Mess with it a bit if there's a BSP error that you absoloutly can't get rid of, or lower this slider if your node count is far too high.
- The second slider adjusts how zone portals are handled when rebuilding bsp. Very rarely, a zone portal won't zone off an area, even if it completly seals it. Setting this slider closer to the "Portals cut all" option should fix this problem. Setting the slider to "Ignore Portals" will increase the chance that the ed won't zone an area off (don't know what the point of that is)
Related Topics
Comments
Whenever I set all the rendering options in advanced properties to true and then select show all actors, the editor runs fine until i move the camera through a wall and outside of the level, it then jams and when i close it (with Ctrl, Alt + delete) i get an error in different parts of the level. –ProjectX
Daid303: Creating an inline object in the Default properties of any actor in the Actor browser also gives a GPF.
Wormbo: Don't try to create an Emitter that emits particles with high acceleration values and lifespan. UnrealEd will decide to eat up more and more memory (more than usual) and doesn't respond anymore.
Winxprules: I hope you can help me here... When I go to build my map, UnrealEd crashes when it comes to Illumination Occluding. I'm guessing that illumination has something to do with the lighting, but I just wanted to check. If you could help, I'd appreciate it very much. Thanks.
Winxprules: Never mind... I managed to fix my problem by deleting every last light from the level. It took a while but it was well worth it ;)
Tarquin: Save yourself time if you ever have to do this again: see Actor Context Menu -> Select all <class>.
Winxprules: Thanks for the tip, Tarquin :)
DataCable: This may be game-specific, but the UEd 1 bundled with DS9:TF will crash if you have no object(s) selected and simply move the cursor over the title bar of an already-opened properties window. Took a while to realize that this was causing otherwise seemingly random crashes.
Leggy: Is it me, or does putting many lights on the grid cause the editor to crash to the desktop during Illumination occuluding sometimes? I had a map that just would't build, and I selected all the lights and moved them by less than a grid unit in each direction, and now it works perfectly.
Bob_The_Beheader: Hmm...It's kind of hard to tell why UEd crashes when it happens while it's starting up. It's just given me this error while the splash screen is showing:
Build UT2004_Build_[2005-02-15_17.02]
OS: Windows XP 5.1 (Build: 2600)
CPU: GenuineIntel Unknown processor @ 3196 MHz with 510MB RAM
Video: NVIDIA GeForce FX Go5200 (4690)
Assertion failed: WhiteCircle [File:.\UnTerrainTools.cpp] [Line: 788]
History: FTerrainTools::Init
I've recently started learning to code UnrealScript, and so I've rebuilt packages and stuff, maybe that has someting to do with why it crashes?
MythOpus: Well Bob, in UnrealScript recompiling the original packages that come with your game is a general no no, unless you A. have a license and B. are making a totally new game. What most people do is build upon the default packages by extending actors within the default packages. An example would be having a Sphere as an actor in a default package and you want to create a basketball. You would 'extend' the Sphere actor from the default package and make the new Basketball class in your own custom package (I.E. MyBasketball.u).
I hope this helps... Also... about the error itself, I think it has to do with the importing of the source code that you had recompiled... or the absense of that native source code all together (The C Headers)
Bob_The_Beheader: Thanks. I do know about object oriented programmming, but the default packages are rebuilt when you run UCC, right? That's all I meant. People must think I am going around promoting screwing with the defualt packages, what with this and the page I made, Actors_Snap_By_Default. I really am not. I do know that it's bad.
MythOpus: Heh... actually UCC doesn't actually rebuild any package unless the .u for that package has been deleted. Therefore, normally UCC only checks to see if the packages are still there. If they are, it goes to the next package in the list until it finds an EditPackage string that has no .u package. Then it looks for the source (the folder that holds the .uc files) of that package and uses that to compile a new package.
StarWeaver: Got a new one (I think, anyway): Changing a Projector (In my case it's always been position or rotation, both by dragging and by changing the numeric properties) and then using Undo causes a GPF. (My vague guess from the call chain would be the propertly list getting corrupted on read or write to the undo history . . . which is odd, because I'd think it would use the same operations as a cut or copy or duplicate . . . )
SuperApe: Or how about adding a property definition above the list of other definitions, while an object of that class already exists, with those properties configured, in the current map space. Hit compile and GPF. Solution: remove the object or simply clear out the property settings.
Hellkeeper: "Don't try to run UEd 2 and UEd 3 at the same time, most likely all hell breaks loose. (Or one of them just crashes. )". Hum, I frequently run Ued 1.0, 2.0 and 3.0 at the same time, copy/pasting brush from one to another without problem (except tremendous amount of HOM everywhere). They do not crash until I do stupid things (converting a pawn to static mesh, this mesh to brush, and copying it to Unrealed 1.0).
Kirk: I encountered the illumination occluding related crash as well, after making a set of very large and narrow brushes. Perhaps the lightmap for the BSP generated for the brush (in this particular case) was too large/disproportionate or something. In any case, splitting the brushes in two got rid of the crash. Perhaps useful to some.
JeffMOD:I keep getting the following messsgaes before Ued even loads fully: General protection fault!
History: WBrowserStaticMesh::UpdateMenu <- WBrowserStaticMesh::OnSize <- WWindow::WndProc <- WWindow::StaticProc <- WWindow::WndProc <- WWindow::StaticProc <- WBrowserStaticMesh::OnCreate <- WWindow::WndProc <- WWindow::StaticProc <- PerformCreateWindowEx <- WBrowser::OpenWindow <- WBrowserStaticMesh::OpenWindow <- WM_BROWSER_UNDOCK <- WEditorFrame::OnCommand <- WWindow::WndProc <- WWindow::StaticProc, and, General protection fault!
History: WBrowserStaticMesh::UpdateMenu <- WBrowserStaticMesh::OnSize <- WWindow::WndProc <- WWindow::StaticProc <- WWindow::WndProc <- WWindow::StaticProc <- WBrowserStaticMesh::OnCreate <- WWindow::WndProc <- WWindow::StaticProc <- PerformCreateWindowEx <- WBrowser::OpenWindow <- WBrowserStaticMesh::OpenWindow <- WM_BROWSER_UNDOCK <- WEditorFrame::OnCommand <- WWindow::WndProc <- WWindow::StaticProc <- FALVoiceModule::NoteDestroy <- UALAudioSubsystem::NoteDetroy <- ULevel::DestroyActor <- (Camera myLevel.Camera0) <- UPlayer::Destroy <- UViewport::Destroy <- (WindowsViewport Package.WindowsClient0.TerrainHeightmap) <- UWindowsViewport::Destroy <- UObject::ConditionalDestroy <- (WindowsViewport Package.WindowsClient0.TerrainHeightmap) <- UWindowsClient::Tick <- UEditorEngine::Tick <- UpdateWorld <- MainLoop. can anyone provide a fix, or will I hhave to stay online until i can get Source SDK?
darth_san:I get some problem with UnrealEd of Repubic Commando: when I try to edit some default properties (generally this is text parameters) in Actor Classes, UnrealEd crashes. It is very strange. Please tell me, what is the cause of this crashing? Forgive me for my bad English (I'm from Ukraine).
EQ²: With respect to the error posted by JeffMOD above, I've found the cause of this error in UnrealEd 3.0 to be "un-docking" the Static Mesh browser from the tabbed container window. It seems that you can un-dock all windows except the Static Mesh browser! So if you, like me, like to undock all the windows so you can tile them on other monitor(s), un-dock all of them except for the Static Mesh browser. To fix this error, open up UnrealEd.ini (or MyUnrealEd.ini if using the U2 editor), find the [Static Mesh Browser] section, and delete the line which says Docked=0. Hope this helps someone.
Falcao:With respect to the error posted by JeffMOD above. To fix this error, open the file "unrealed.ini", find the [Static Mesh Browser] section and change the value of "docked" to 1.
Pegasus: Inspecting an Emitter that has one of its objects' UseDirectionAs property (found in the Sprite subcategory within the actor's Emitter category via the properties dialog) set to any value either containing "right" (meaning either PDTU_Right or PDTU_RightAndNormal) or PDTU_Scale seems to crash UEd when attempting to switch to that particular object's tab in the Particle Editor. A characteristic example of this are the jumppad emitters in ONS-Tanks-A-Lot-)o(-V4, for which a quick fix entails changing their UseDirectionAs property to PTDU_Up and then enabling Spin Particles from inside the Particle Editor's Rotation section to achieve the same visual result of upward spark movement.