Source SDK SE2 Bugs: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
(Fixed)
No edit summary
Line 4: Line 4:


== General Hammer issues ==
== General Hammer issues ==
* Hammer crashes trying to load a map. Finishes getting chunks, then crashes as the map begins to display.  Unknown cause. Any help will be nice. [[User:Dr.Scrots|Dr.Scrots]] 17:52, 6 October 2007 (CST)
: This may be due to the issue I quote below - an entity with a missing classname. I have written a [http://www.thedaedalus.net/revivalwiki/MapFix a tool] that scans a given map and fixes any known issues - namely the 'no classname' issue. Simply drag your map onto the program, and it will create a new file, ''yourmap''_fix.vmf which is the altered version. See if that one works for you. --[[User:Daedalus|Daedalus]] 06:48, 8 Oct 2007 (PDT)
* Ragdolls and other physics objects like grenades or props fall right through my displacement maps. This only happens with levels I create, the in-game HL2-levels work. --[[User:Sterd|Sterd]] 12:12, 20 May 2007 (PDT)
::See [[Entities_fall_through_displacements|this article]].--[[User:Fitzroy doll|Fitzroy doll]] 06:28, 2 Jun 2007 (PDT)
* Hammer will crash trying to load a map (Postload processing) if there is an entity in the map that has no classname. I fixed this in a map that was doing it by setting the classname to "unknown_entity" --[[User:Daedalus|Daedalus]] 20:29, 30 Apr 2007 (PDT)
* Comments appended to entities, where able, don't like ctrl-enter for a carriage return. FIX: I had to manually open the .vmf file in a text editor and remove that particular keystroke to get my map running again. Hammer 4.1 Build 3576. (18 Nov, 2006)
* Defining custom colors under the 'Pick Color' button aren't saved when restarting Hammer 4.1 Build 3576. (17 Nov, 2006)
* All of a sudden the compiler will refuse compiling even the bsp of the map, giving an "unexpected symbol" error, pointing to symbols like ".", "{" or "}", and pointing toward a line and an entity. However, this bug does not seem dependent of an entity or a symbol, will move between entities and symbols if the mentioned entity is cordoned off, and will remain even though everything has been cordoned off in the map. The bug is map specific - other maps will work just fine.
:Verifying the cache, reloading Steam, and reloading the SDK resources, will not help. If loading the map again, Hammer will give the same "unexpected symbol" error, then a "memory could not be 'read'" error, and then shut down Hammer. If trying to salvage the map, Hammer will ''crash'' with the "Send Error Report" message.
:This bug is (or at least "can be") caused through proving one or several quote (") characters in a keyvalue (like for instance the ''Message Text'' field of a [[game_text]] entity). The compiler/loader will interpret the character as the end of the keyvalue argument and the execution of the following commands will not make any sense to it.
:Fix: There are two ways of fixing this problem:
:The first fix is to use a reverse compiler to reverse engineer your latest BSP file into the last working VMF file.
:The second fix is to load the malfunctioning VMF file up a text editor and changing it manually. As the file is usually quite humonguous, you will need to try to load the map up in Hammer and check the error message that will report which line the error occurs at. Then go to that line, remove the quote characters within the quoted argument, and save it. (If Notepad is used, you will need to turn off "Automatic Linefeed" and thereafter turn on "Status bar" in the "Show" menu, to be able to display the current row. {{note|I'm Swedish, so I'm just guessing their names here - please correct them if neccessary.}} )
* I can't import basic brushwork from GTKradiant .map anymore, was working fine before last update. When loading the .map, hammer crash with that Fatal Error: "BlockArray <0,0> - invalid block index.". Suggestions?
* I've recieved the same error while attempting to import hl1 .map files from Hammer 3.4 and GTK Radiant.
*I can't import .map files from Hammer 3.5 either, i've tried basically everything, including trying to roll back SDK updates or starting older versions, VALVe just doesn't appears to have added in something to allow that. [[User:Solokiller|Solokiller]] 06:14, 19 Aug 2006 (PDT)
EDIT: .rmf files now work, try to import .map files in hammer 3.4/3.5 and save as .rmf.
* I am having a similar problem to JustinMstroud, but I have some additional information. I just installed SourceSDK and when I try to save my initial Hammer configuration I get an error. When I close the hammer configuration screen it says "Changes will not take effect until the next time you run Hammer. After clicking OK I get a Windows Application Error for hammer.exe - "The instruction at '0x0d94dc24' referenced memory at '0x0000001c'. The memory could not be 'read'." As JustinMstroud described below, the new Hammer configuration doesn't save. Also, after the first time this happened, Hammer could no longer be started through Steam. When I try to start Hammer from Source SDK in Steam I get - "Error: No game configurations to run with." The only way to get back to the Hammer configution screen is to run Hammer.exe directly from the user@name\sourcesdk\bin folder, and then I'm just back where I started- in the specify configuration screen and unable to exit without getting that error and losing all the settings. This is on an Athlon 3000+ with Radeon 9800 pro 256 and 512 RAM --[[User:Tehblinkenlights!|Tehblinkenlights!]] 21:04, 11 Jul 2006 (PDT)
* I downloaded the Hammer editor; when I open it, it asks me to specify a configuration. I do so, but then I get a windows crash. The data does not save, so my configuration is gone. When I restart Hammer, it sees no configurations. I have looked around, but haven't found an existing issue that maps to my problem. Any suggestions? I'm running a P4 2.8 (dual core) with a GF6800, 1gb of RAM. Thanks [[User:JustinMstroud|JustinMstroud]] 15:08, 8 Jun 2006 (PDT)
** Try again after deleting the file game/bin/GameConfig.txt. --[[User:Roastbeaf|Roastbeaf]] 18:05, 7 Dec 2006 (PST)
*** Ok I have the Same Problem, but that message occures when i try and run the map. I tried deleting the gameconfig.txt and that didnt do anything. Any suggestions? [[user:mrabele]] 18:13 23 Dec 2006 (PST)
** I have the same problem over here but deleting the GameConfig.txt file does not change anything
* The following is said as the description for the "There is no player start." map problem:
There is no player start in the map. To add one, select the Entity (axe) tool, drag the crosshairs to the position you want the player to start at, and press ENTER.
The entity tool is not an axe though!&mdash;'''[[User:Ts2do|ts2do]]''' 12:37, 14 Apr 2006 (PDT)
* Sometimes (This has randomly happened three times this week.) Hammer will be unable to find a normally available .mdl file (like for a camera-window preview of a shotgun). When it doesn't find the .mdl file, it will display a dialog box about not being able to, and then simply ''quit''. To start Hammer again, you must restart Steam. --[[User:Andreasen|Andreasen]] 05:10, 2 Feb 2006 (PST)
*When I compile my map, and run it, I can pickup weapons but I have no HUD! I have no health bar, no armor, I cant switch weapons (unless I run out of ammo). Can someone please tell me whats happening?
**I also am experiencing the same problem, sort of. I'm running an Athalon 64 3000 1.5GB, GeForce 7300 GS. At first, when I would compile the map to test (the map I'm working on is a deathmatch one), everything worked fine. After not too long, it would load up fine, but after 5 - 10 seconds of playing in my map all model textures (Guns, Hands, Barrels, Boxes, Fences, Grenades, Powerups, etc.) would become solid colors. All textures on walls were fine. In addition, HUD becomes blank - as in it displays the black --[[User:NykO18|NykO18]] 19:46, 16 Aug 2006 (PDT)background box, but none of the detail inside. For instance, the health box you can see the transparent black box, but no numbers. At this point, if you press ESC, you see no words for the menu, however hovering the mouse pointer still creates the sound of hovering over the words. No crosshair either. I found a solution temporarily - If I threw a grenade in a corner and killed myself, when I respawned, everything would be back to normal for as long as I stayed in the map. As soon as I left HL2 and went back to Hammer, made changes, recompiled, everything would again get messed up until I killed myself. NOW though, everything is ALWAYS messed up, regardless if I kill myself or not. Even my dead body is a solid grey. Any solutions would be appreciated. I'll check back here occasionally, otherwise shoot me an e-mail at xkeitarox@gmail.com Thanks! --[[User:Keitaro|Keitaro]] 18:09, 25 Jul 2006 (PDT)
***This happens to me too.  I am using hl2 single player when it happens.  Is it only in hl2 that this problem occurs, or other games as well?  Post on here or answer at kvn_vlmr@hotmail.com. Thanks.--[[User:Calard|Calard]] 23:15, 17 Feb 2007
edit: i put in a info_node and used newgame_spawn and everything works now.
* I had set up a closed path_track circuit, marked one path_track entity, brought up its property box, opened the ''Orientation Type'' dropdown list, held down the Ctrl key and clicked on another path_track to try to see if you could select several path_tracks simultaneously, and at that point Windows explained to me that Hammer had crashed and shut it down. --[[User:Andreasen|Andreasen]] 14:25, 31 Jan 2006 (PST)
:I tried to reproduce this bug with the same track, but couldn't, so it's probably random. --[[User:Andreasen|Andreasen]] 05:30, 2 Feb 2006 (PST)
* Clip mode acts funky when a grip for the clip line is held down with the mouse button while enter is pushed&mdash;'''[[User:Ts2do|ts2do]]'''
* Windows Error reporter whining about hammer when closing hammer (this happened after the "cursor lost in model browser"-bug, not sure about this two bugs may be in conjunction?).
* When you have a group selected, and you try to carve, Hammer freezes.
:: Workaround: Don't carve.
* Displacement Alphas in hammer when compiled appear inverted in-game. Such as using sand with sand/rocks as the alpha. If you have it setup in hammer one way when you compile and play it will invert the alpha. Additional notes are that this bug occurred even without the new sdk beta and therefore is a bug that I hope is fixed soon. Thanks --[[User:RomeoGuy|RomeoGuy]] 16:57, 23 Nov 2005 (PST)
** Someone I know has exactly the same problem. [http://nyko18.free.fr/temp/blendhammer.jpg In hammer before compiling] and [http://nyko18.free.fr/temp/bugblend.jpg In the game after compiling]. --[[User:NykO18|NykO18]] 03:45, 20 Jan 2006 (PST)
** I have not got this problem. All alphas work fine.
::Workaround: Invert Alpha before compile, but is tedious.
:::Request: I have the same problem, how about a command line argument for the compiler to do it for me? [[User:Angry Beaver|Angry Beaver]] 20:20, 10 Feb 2006 (PST)
::::Request...it should work like it's supposed to!!!&mdash;'''[[User:Ts2do|ts2do]]''' 21:13, 10 Feb 2006 (PST)
* Selection of a Displacement only considers the original box it was made from.
* Brush creation manipulation box isn't cleared after a new brush has been creation, yet the handles aren't usable. If you try to use them, it starts drawing a new brush.
* if u change the name of the file, the search path is changed, but not the place where they are
: Please clarify. --[[User:JeffLane|JeffLane]] 14:15, 9 Jan 2006 (PST)
* When scaling objects the texture is not scaled along anymore (ie creating 3d skyboxes)
: Was this with Scaling Texture Lock enabled? --[[User:JeffLane|JeffLane]] 14:59, 9 Jan 2006 (PST)
* Something scary about the animations of props.. try this manipulation : Create a prop_x and select a model that is animated (like 'models/Combine_Dropship_Container.mdl') then make a copy (shift+drag & drop) of this prop_x next to the first one.. (in order to see the problem) Now open up the properties of one of the two props and try to change it's default animation to something else than 'idle'.. And yes, this is magic, the second prop_x just beside appear to follow the other one.. it's animation changes too. You can't create an opened Dropship Container and a closed one in the meantime.. (and it happens with all the models) --[[User:NykO18|NykO18]] 11:06, 29 Dec 2005 (PST)
** Not a bug. The model tab is only for preview, it does not change the entity itself. We should change the name of the tab and/or add some help text. --[[User:JeffLane|JeffLane]] 14:59, 9 Jan 2006 (PST)
*** Ok, thanks for clarifying.. because as far as I can remember (Worldcraft 2.0) there was a way to change the animations in the model properties. Am I wrong ?
*** You can specify the animation to use in the object properties for a prop in the class info tab. [[User:Rodeoclown|- RodeoClown]] 19:25, 20 Mar 2006 (PST)
* In the Face Edit dialog box when applying textures, the Select option in the Mode drop-down menu behaves identically to the Lift+Select mode.  Instead of just selecting the face without changing the current texture, it will select the face and lift its texture, making it the current texture. --[[User:Font38|Font38]] 23:58, 16 Jan 2006 (PST)
* In [[Hammer Torus Properties]], inputting a ''' Rotation Start Angle''' of more than 360 degrees results in a infinite loop of "Please enter a number between -360 and 360" dialogs (also, alt+tabing into Hammer while it is in this state will create more dialog boxes and when they reach the end of the screen, Hammer crashes). [[User:Jupix|Jupix]]
* When compiling, it says "BuildVisLeafs", when correct english is "BuildVisLeaves". This has lead to much confusion: The majority of all Hammer users now seem to believe the plural of "leaf" is "leafs", and is calling it "visleafs". (''Edit:'' Even if you claim that a leaf node in general doesn't abide by the same grammatical rules as a normal leaf does, user-who-wishes-to-be-anonymous, I'd like to hear this from Valve, so don't delete.)  --[[User:Andreasen|Andreasen]] 22:06, 12 Apr 2006 (PDT)
* Can't compile when using map names that contain numbers
* When minimizing Hammer (while a map is opened) the program shuts down or crashes randomly. [[User:Reaper47|Reaper47]] 04:58, 7 Aug 2006 (PDT)
** When I use my 'Go to the desktop' shortcut to reduce all the opened windows, if I try to restore Hammer from the taskbar, it crashes. --[[User:NykO18|NykO18]] 19:46, 16 Aug 2006 (PDT)
** I can confirm the "Go to Desktop"-shortcut problem. I've tried various things (Windows applications, games requiering 3D renderings, changing my pc configurations), but the only thing causing the crash is the "Go to Desktop"-button next to your Windows Start button. I understand why Reaper47 files this under "random crashes", it's a very common thing to use this button, often you don't even realise you are using it (automatism). - [[User:Hezus|Hezus]]
** I can confirm this too, it also does it while using the Win+D Hotkey. (I'm using NT 7.0 with 2.4GHz P4 and 1.5GB RAM) --[[User:Kayedj|Kayedj]] 03:43, 18th August 2007 (BST)
* The Window menu doesn't display the list of maps currently open if a map has been opened, closed and a new one opened.
*Having Hammer open and a map loaded, and then opening model viewer when keeping Hammer open(not minimized) causes hammer to crash, most likely due to the same files being used( model render tools used by both programs) [[User:Solokiller|Solokiller]] 11:16, 9 Sep 2006 (PDT)
* Selecting an entity in the 3D view, then selecting an entity right after causes a crash. {{unsigned|Quanta}}
:*EDIT: I can't duplicate the bug; must've been the current session of Hammer I was running, although I've had it crash before just by clicking on something. {{unsigned|Quanta}}
::*I've had this too. Usually after I change an entity's type. It's quite hard to reproduce, some times it keeps happening, other times it doesn't. --[[User:Daedalus|Daedalus]] 01:51, 9 Apr 2007 (PDT)
* Only 3 tool textures show up under the 'Tools' keyword. The rest show up under the 'combine' keyword. --[[User:Quanta|Quanta]] 14:46, 2 Jun 2007 (PDT)
* Clipping tool doesn't seem to like spheres with 16 sides. Keep getting that 'memory couldn't be read' error message, at instruction 0x0daf7a85. --[[User:Quanta|Quanta]] 16:23, 6 Jun 2007 (PDT)
* There's something about an instruction at 0x0daf7a85, because every time hammer crashes with 'memory couldn't be read', it says something about that exact same location. I've even confirmed this with a few of my friends. --[[User:Quanta|Quanta]] 10:51, 10 Jun 2007 (PDT)
* The SDK sometimes deletes Game Configurations, most likely it refreshes the SDK content without being told to do so. [[User:Solokiller|Solokiller]] 05:27, 20 Jun 2007 (PDT)
* When the SDK is started, "the copying files, please wait..." dialog always pops up, preventing fast usage of the SDK. Picture below. [[User:Solokiller|Solokiller]] 05:27, 20 Jun 2007 (PDT)
Picture: [[Image:Sdkbug1.jpg|thumb|left|40px]]{{clr}}
* Hammer should not crash if there's an error reading the file. Instead it should tell you the error, and stop trying to load, but keep running. --[[User:Quanta|Quanta]] 14:41, 4 Jul 2007 (PDT)
* Creating a prefab (Ctrl+R) with any kind of light entity selected won't retain the light's color - it defaults to white, making it frustrating to add colored light prefabs in.
:: Workaround: Select the light entity, click 'Pick Color' for the brightness attribute, click 'OK', then 'Apply'. --[[User:Quanta|Quanta]] 16:58, 4 Jul 2007 (PDT)
=== The [[Hammer Vertex Tool]] ===
* Vertex tool is unable to maintain coordinate precision when dealing with "complex" shapes, despite these shapes being concave. (See such an example in [[Talk:Hammer Vertex Tool]].) Upon reloading a map, certain coordinates will be moved less than half a unit off the grid. This bug is persistant and easily reproducable. --[[User:Andreasen|Andreasen]] 06:21, 25 Oct 2007 (PDT)
* When vertices are coincident, Hammer is no longer prompting to combine the vertices. When left coincident and brush is put in Vertex edit mode again, this error displays: "Edge with both face id's already filled, skipping..." --[[User:Spektre1|Spektre1]] 10:42, 25 Nov 2005 (PST) {{note|This occurred on a brush that was 1 unit wide. It seems to function normally on wider brushes. --[[User:Spektre1|Spektre1]] 10:46, 25 Nov 2005 (PST)}}
:"Edge with both face id's already filled, skipping..." also happened to me once when I made a cylindrical object of pretty normal size (11 faces). The error does not seem to go away: Every time that object is selected in vertex editing mode, that error message is given twice. Possibly related: After removing that brush and creating another, when trying to move the first vertice on that brush (using a unit scale of 1 for precision), two vertices was automatically moved about 100 units down and 1119 units to the side, making it end up far outside the window! This might mean that the bug lingers around even after the brush is removed. --[[User:Andreasen|Andreasen]] 06:21, 25 Oct 2007 (PDT)
* Get "Edge with both ID's already filled, skipping..." after combining vertexs and selecting another brush to vertex. Noticed that some faces were missing, too. Wasn't in a way that it was an invalid brush.
* Moving a vertex with the vertex tool while holding <nowiki><Ctrl> or <Shift></nowiki> will constrain the vertex along an axis of the Origin, rather than along an axis based on the vertex's original location, making this feature very unresponsive.
* After manipulating a brush in vertex mode, then undoing the operation, Hammer thinks the brush is still in its previous state (before the undo), and draws the selection box around that previous state. --[[User:Quanta|Quanta]] 08:53, 26 Jun 2007 (PDT)
: Screenshot: [[Image:Invalid Box.PNG|thumb|left|40px]]{{clr}}
* In Vertex Manipulation, if you drag across points and let go before the selection is drawn and then hit <nowiki><enter></nowiki> three times to try to select the points you thought you selected, Hammer crashes.
* Vertex editing mode: When manipulating vertices in a grid size of 1, the vertice(s) will move to the lower right location of whichever grid square the cursor has been dragged to.  With larger grid sizes, the vertice(s) move to whichever grid location the cursor is closest to.
* After doing some vertex manipulation, then saving and closing, Verticies on manipulated object messed up upon reload. Ex: three really closly spaced verticies (less than one unit) now where before there was one. Also, the "check for errors" does not appear to working correctly: after reloading the map, some solids were not loaded due to errors, when before closing the error check said no errors were found.
: Existing issue. Not a Beta SDK bug. --[[User:JeffLane|JeffLane]] 14:59, 9 Jan 2006 (PST)
::Will this bug be fixed with the episode 2 SDK update? It is very annoying, i can't create a good dome for my level without it screwing up the vertexes and making all my work bad. It seems to happen with several triangle brushes placed close together. [[User:Solokiller|Solokiller]] 10:52, 29 Aug 2007 (PDT)
* Width length height values in the status bar are weird in vertex tool when there is no selection box&mdash;'''[[User:Ts2do|ts2do]]'''
== Hammer 2D and 3D Views ==
* Hammer's 3D View is completely black, regardless of what is actually in the map. I tried resetting the view, changing the 3D View settings, I tried deleting the SDK and all sdk settings and files then reinstalling, but it still has the same problem. [[User:Moldrat|Moldrat]] 16:02, 2 Sep 2006 (PDT)
:Yes, for some reason the default camera has been removed. You'll have to make another camera, using [[Hammer_Camera_Tool|the Camera tool]]. --[[User:Andreasen|Andreasen]] 16:07, 2 Sep 2006 (PDT)
* 3d and 2d views begin to flicker black and flicker graphics messups (like polygons stretching to edges of screens, or certain wall s becoming invisible.  this gets gradually worse as time goes on, restarting hammer fixes temporarily.  I think this isn't only a beta thing, it may just be me, but hammer worked fine for 6 or 7 months before doing this.
** Picture: [[Image:corruption.jpg|thumb|left|40px]]{{clr}}
** '''Solution:''' Go to C:\Program Files\Valve\Steam\SteamApps\Account_name\sourcesdk\bin\ and create a shortcut to Hammer.exe with the parameter -dxlevel 80 like this: "C:\Program Files\Steam\SteamApps\Account_name\sourcesdk\bin\hammer.exe" -dxlevel 80
** I've started getting this problem too. Only in the last few days and only in the CS:S SDK, HL2 SDK works fine. Entity polygons corrupt in the 3D view and stretch out of shape. I'm using a Radeon 9700pro.
** I've also been getting these issues, on two different system setups in fact. Both were using radeons, though, an X800XL and an X1900XTX.
** I'm suffering from this too, but only recently. The one thing that's changed - drivers. Reverting to earlier drivers has not helped however. Models in 2D views render fine. Radeon 9800Pro256. --[[User:Johnsto|johnsto]] 10:59, 8 Jun 2006 (PDT)
** This issue also occurs in the Model Browser.
*** Cleaning out all traces of old drivers and updating to latest Omega drivers (3.8.252) has not helped. --[[User:Johnsto|johnsto]] 12:54, 19 Jun 2006 (PDT)
** '''As of the August 4th, 2006 SDK update, this issue has been fixed.'''
* Possibly related to the cursor issues below: Block, Camera, and Entity tools don't use any special cursors at all, just the default Windows pointer, even when dragging. Also, the "Use Crosshair Cursor" option has no effect. --[[User:EsBe|EsBe]] 23:41, 1 May 2006 (PDT)
* The model preview simply cannot find the models for [[item_ammo_pistol_large]], [[item_ammo_smg1_large]], [[weapon_bugbait]] and [[npc_launcher]] entities, instead displaying the big red error model. (The entities still works fine in-game.) --[[User:Andreasen|Andreasen]] 19:14, 20 Mar 2006 (PST)
* Using ctrl+shift+f to do a target name search while the cursor is over the 3d window will result in an inability to move in 3d view using the WASD keys next time the user attempts to do so.  This happens regardless of whether the 3d window is maximised or not.  Also happens when opening texture browser with shift+a, but in this instance the problem only occurs when the 3d window is maximised.  In the target name case, workaround is to move the cursor into a 2d window.  In the texture browser case, workaround is to minimize the 3d window. 14 February 2006
* Using Shift+Z to maximize the main camera window while the Z key is enabled (mouse rotating the view in camera window), will make the cursor and the view get stuck. --[[User:Olavenspire|Olavenspire]] 18 Jan 2006
** This is most likely because enabling the Z key restrains the cursor to the 3D window (found out when my Hammer crashed with Z key enabled), and maximizing the 3D window causes the cursor to try to be out of the box, but it must stay in the box, which makes the view stick. --[[User:Quanta|Quanta]] 15:13, 15 Apr 2007 (PDT)
* There is no special mouse cursor for creating brushes until you start dragging
* There is no special mouse cursor for applying overlays
* 'Textures' screen element does not close after use, even if it was closed beforehand. Would be a useful fix for people who use only hotkeys and don't have any buttons on-screen unless needed.
: Please clarify how you expect this to function. --[[User:JeffLane|JeffLane]] 14:59, 9 Jan 2006 (PST)
:: The window would only be open while the tool was in use, unless it was open before. A little like it comes out of the sidebar when used and pops back again when you exit texture mode. --[[user:TomEdwards|TomEdwards]] 01:19, 18 Jan 2006 (PST)
* <code>[[move_rope]]</code> is created with a bad '''Position Interpolator''' setting (0 should be 2), <s>and setting it to anything higher than 2 causes Hammer to crash.</s>
* Pasting or manipulating light_spot entities turns the light cones green. properties remain the same.
: workaround: restart hammer.
* Rotating models does not go smoothly anymore, it now is like having shift pressed when rotation. The old way allowed for much more freedom.
:Workaround: Hold ALT while rotating.
: Or hold SHIFT :D
* The rotation handles on brushes are open circles instead of solid.
* The camera handles when using the camera tool are open circles instead of solid.
* Overlays are not rendering correctly in the 3D views.
* Textures are stretched in 3d view when scaling an object, and then retain original scales when brush is set to desired size.
** It would make a lot more sense if the 3D scaling preview only happened if <tl> is on. Otherwise it's showing a change that won't actually occur.
: <s>This is a new feature, it will appear like that when the texture scaling lock is off, it's the button with <tl> on it. When on, it will not retain the original scales.</s>
:: It would be handy if the texture showed actual results instead of stretching, speeding things up.
* 3D Textured Shaded view doesn't always shade, client dependent.
: Could be GFX related, my card is a 9100 and only PS 1.4 (DX81) compatible.
* You can't select wireframe'd props/actors in 2D views by clicking. You've got to drag a selection box or select the ent's bbox (which isn't drawn!).
** workaround: you can do it by clicking the centre handle
* When the texture applicaton tool is open, when you use the right click method to apply textures, it seems to break movement in the 3D view with ASDW. ASDW movement functions again once you click back in a 2D view.
** It fixes for me when I undo as well.
** Happens for me when I have the window open at all. No clicking required!
: Not a Beta SDK bug. This occurs when the Texture Application window is over the center of the 3D view. Workaround: Move the Texture Application view to the side before applying any textures. --[[User:JeffLane|JeffLane]] 14:59, 9 Jan 2006 (PST)
* Can not compile maps. A Windows error occurs stating "Microsoft Visual C++ Runtime Library Runtime Error! Program: d:\steam\steamapps\syphon@shaw.ca\sourcesdk\bin\vbsp.exe R6025 - pure virtual function call" The issue occurs with both the beta and original versions of Hammer on a FRESH install of Windows.
** I got this problem too. It seemed to be caused by displacements intersecting other brushes. Deleting intersecting  brushes fixed the problem.
* 2D views do not have their labels displayed unless you mouseover where the label should be. This will confuse people who don't know what orientation each port is showing.
* After not being active some time, reopening hammer made all textures purple-black checkboard and there were also no models. After trying to close and reopen map, hammer crashed.
: Is this a chronic issue, or did it only occur once? --[[User:JeffLane|JeffLane]] 14:59, 9 Jan 2006 (PST)
:: I believe this is a chronic issue, because this has happened to me a few times as well - it seems to be mostly after running the map with Hammer minimized, then restoring Hammer. This doesn't happen all the time, but it has happened before. --[[User:Quanta|Quanta]] 18:39, 30 Apr 2007 (PDT)
::: Also, it happens most often if Hammer is open when Steam crashes and disconnects. Even when it reconnects, Hammer isn't running from the same session that Steam is now running from, and everything goes missing. --[[User:Quanta|Quanta]] 13:42, 13 May 2007 (PDT)
* IME language bar on the desktop causes each view flickering between 2D views and 3D textured view, making hammer near unusable. It doesn't happen when the language bar is minimized in the taskbar.
* Skew tool (ie. when you select a brush, then click it a second time to bring up the skew handles) does not snap to grid, and instead snaps to seemingly random points.
* Selecting a large amount of brushes and then moving them before undoing the operation results in the selected brushes disappearing in the 3d view.  Rotating the camera results in the brushes reappearing at certain view angles.  After this occurs, other brushes will sometimes disappear in the 3d view, too.  My current setup = Windows XP Pro (32 bit), latest dx drivers, 6800GT and driver version 81.95. -- [[User:Defrag|Defrag]]
** Workaround: Avoid moving lots of brushes if possible.  If the issue occurs, restart hammer.
** I've seen this problem too. It seems that Hammer thinks the brush is still in its previous position so it disappears when that position is off the screen. You can fix it by moving the brush in some way.--[[User:DeathByNukes|DBN]] 13:36, 3 Dec 2006 (PST)
* With Direct3D debug version of dlls selected in DirectX control panel, clicking in the Hammer 3d view on a 3d rendering causes Hammer to crash. Occurred after last SDK update. DX9 (Dec 2005), Windows XP Home. See [[Hammer_3D_View_MouseDown_Crash]] -- [[User:BJ|BJ]]
* The view legend ( Top(x/y), Front(y/z), etc. ) does not appear unless the cursor is positioned in the upper left corner. The legend then pops into view but disappears when the cursor leaves the window. &mdash; [[user:BJ|BJ]] 12 May 2006
* Hammer will, for me, will 'offset' the textured piece of the brush up to 16 units away from it's origin point, while leaving a red selection box where the brush actually is. Additionally, Hammer will draw a 1 to 2 unit red selection box (the texture select mask) over brushes (instead of just highlighting the texture). Additionally, earlier, moving a large amount of brushes and entities and undoing the operation caused the brushes to disappear, then randomly reappear as the camera viewpoint was moved - Reselecting them in the 2D view still caused them to remain invisible in the 3D viewport.
Here's a screenshot:
[[Image:Movingblock hammer.JPG|thumb|left|40px]]
Also, note the clipping on the selection mask on the right brush as well. This usually happens at distance, but seems to be reversed - Up close there is no selection mask and it fades in with distance.
--[[User:RabidMonkey|RabidMonkey]] 23:08, 2 Jun 2006 (PDT)
* Hammer no longer renders ropes that do not have MoveSpeed set.  --[[User:Raeven0|Raeven0]] 15:51, 14 Jun 2006 (PDT)
* Centering via Ctrl E and the pasting with Ctrl V doesn’t paste in the center of the views anymore.  This is really disruptive to workflow.  Sometimes it doesn't even paste within view. 
** Objects in the clipboard are pasted at the cursor's location. Again, this is a new feature and not a bug per se. --[[User:Raminator|Raminator]]
* If the 2D view is zoomed all the way in, you can’t hold shift bar and drag the view.
* If an invalid displacement exists and is visible in the 3d view, it will draw garbage, faces on the wrong solids, distorted solids, failing to draw a solid at all, etc. --Gman003 17:04, 3 Sep 2006 (PDT)
== Hammer VGUI Model Browser ==
* Suggestion: Model Browser already loads the current model when you launch it more then once. It should also select the folder, scroll to the currently displayed file string in the "filter" tab and select/highlight it. This will make navigation through the browser easier and more consistent. &mdash; [[User:Matveims|Matveims]] 18:31, 2 Feb 2006 (PST)
* Model viewer currently loads it's GUI incorrectly the first time; on close and re-open, it functions as expected.
** Resizing the window also fixes this.
* Choppy performance.
** using the search, results in a hangup for short time and it takes long to see what you wrote
* Rotating the model will reset view translations.
* Filter text input slow.
** Suggestion: Put a .1-.3 second delay on filtering, before the program parses the text, so the user can finish inputing a string before it searches. (Or a search button that also is pressed when Enter is hit.)
** Yes because in fact, if you type 'rock' in the filter, it will first search all models containing the letter 'r', and sometimes it takes a really.. really long time...
* The model browser should remember the state it was previously in when reopened; i.e., remember what folder was previously selected.
** It should also FORGET the text filter last used.
*** Why? I consider that to be a feature, not a bug. When adding props of a similar type, it would be a real pain to keep refiltering. It's slow enough as it is! &mdash; [[user:BJ|BJ]] 12 May 2006
* The 3D crosshair model, for things like the move_ropes, is so tiny it's really difficult to select in the 3D view. It would be a good idea to fatten the model up a bit, so it's easier to select.
* Suggestion: Add a field that indicates if model is a static prop or a physics model or a detail model.
* Suggestion: Allow user to toggle model skin in viewer.
* Suggestion: Allow switching between old model browser and new model browser.
* The model browser isn't loading. Don't know if it's related to the "SteamAppID 211" problem that has been report by others.
: Please clarify. Does Hammer crash, or does the model broswer actually just take a long time to appear? --[[User:JeffLane|JeffLane]] 15:26, 9 Jan 2006 (PST)
* All model folders are empty except for the starting folder.
: Was the filter control empty? --[[User:JeffLane|JeffLane]] 15:26, 9 Jan 2006 (PST)
* We cannot browse models located directly in the "models" folder anymore. The 'root' directory isn't accessible (got All .MDLs instead of the root where all the NPCs are located) --[[User:NykO18|NykO18]] 09:48, 29 Dec 2005 (PST)
** This is a feature request, not a bug. --[[User:JeffLane|JeffLane]] 15:26, 9 Jan 2006 (PST)
*** Hum.. this is more like a needed feature that was present in the non-beta sdk and which was deleted.
* When it can't find a model, it doesn't even bother to load an error model or something else. But it just crashes.
** If "model" key is set, the model viewer try to open the model set in this key. But the viewer doesn't test if the model exist or not. If the Key isn't set (so World Model is empty), the viewer display the Error.mdl. If not, The viewer crash and hammer follow it. How to reproduce : Set "bla" or what you want as string and aplly now use browse.
* Selecting most human models (corpses + combine work, all else fail) cause Model Viewer and Hammer to crash with 
  AppName: hlmv.exe AppVer: 0.0.0.0 ModName: shaderapidx9.dll
  ModVer: 0.0.0.0 Offset: 0001f546 02:26, 25 Jun 2006 (PDT)
[[User:Mlk|Mlk]] 02:27, 25 Jun 2006 (PDT)
* When there is a wrong model path typed in the entity properties and you press the button to open the browser Hammer crashes.
* Suggestion: Once the model browser opens the first time, it should make some kind of cache of the models (or at least the relative paths) so it doesn't have to load all of the models every time. --[[User:Quanta|Quanta]] 05:39, 2 Jun 2007 (PDT)
** ABSOLUTELY it should!! It's not as if there are memory issues...as an experiment I kept track of my system's memory usage while the model browser loaded the model list, and the total memory in use hardly increased at all.  I find it just stunning that we need wait about 30 seconds every time we want to add a prop, just to wait for the damn list to load.  What are these guys thinking!  I am currently in the phase of adding detail to a map, and this is drving me insane.  If you add up all the little instances of 30 seconds, as well as the frustration factor, this adds literally hours if not days to development time.
- In summary, anything that you would reasonably expect to be cached, should be cached, at least after first usage.
* Hammer crashes when entering the Model browser, after the Episode 2 SDK update. [[User:Solokiller|Solokiller]] 12:41, 7 Nov 2007 (PST)
== Hammer Autovisgroups ==
* Creating a brush with the NODRAW texture selected, then changing the textures, causes the brush to still be listed in the Nodraw autovisgroup. --[[User:Beans-v6|Beans-v6]] 15:06, 7 Dec 2005 (PST)
** This is probably because brushes are assigned to an Autovisgroup when they are created, so changing the texture won't change the Autovisgroup that they're currently in. --[[User:Quanta|Quanta]] 18:32, 30 Apr 2007 (PDT)
* Start new map, make a brush, use SKIP tetxure on all side, Hammer Auto VisGroup don't recognize this first brush, put HINT on one side, that's not update.
Duplicate it, now autovisgroup work, but only work the duplicated brush. Put the BlockLight texture on all side of duplicated Brush. Now uncheck Skip or Hint autovisgroup, Your BlockLight brush turn hidden. That's like previous point [[User:Gectou4|Gectou4]]
* Expand visgroup make a grayarea without group (on Vista), I have to unpand and expand it again to display visgroup correctly.
* On Vista sometimes, when a visgroup use more than 128 objects, it's can be lost some of them. the object of this group may appear later on another grid location.   
== Hammer Autosave ==
* Not really a bug, but the use of autosave should be optional...
: Change 'number of map iterations to save' to zero. Could certainly be a little clearer! --[[user:TomEdwards|TomEdwards]] 09:50, 5 Dec 2005 (PST)
:: Hammer already allows for the option of autosave. --[[User:Quanta|Quanta]] 05:40, 2 Jun 2007 (PDT)
== Hammer - Misc ==
* As I documented the [[prefab]]s, I found a couple of default prefabs that didn't work properly, or at all. I've listed fixes for them on their pages. Here is a link to a list of them: [[:Category:Prefabs]] --[[User:Andreasen|Andreasen]] 17:29, 31 Aug 2006 (PDT)
* A possible way to change the texture quality in the 3D view would be oh so nice.
** Thats done by mip-maps ingame... or make the texture
*** -quality  before converting it into a vtf
*** I also desperately need a way to change the texture quality in Hammer.  DX7 puts normal Hammer textures to high quality, but beta Hammer textures to low quality, and that is far too low for me to align accurately, as well as making identifying entities by looks impossible.
* Would it be possible to have the default texture (selected when Hammer is started) as nodraw? It would encourage better mapping.--[[User:DrBob|DrBob]] 04:37, 4 Dec 2005 (PST)
* Could you make it easier to import something from Hammer into 3DS Max? For example, the only way at the moment is to export to .DXF, and that generally loses information. Perhaps an export to .Max, or an importer plugin for Max?
** Workaround: XSI has a great map import feature. You could base a plugin off that or possibly import to XSI then save your file and import it into MAX.--[[User:Skidz|Skidz]] 15:55, 23 Nov 2005 (PST)
* Nothing has yet been said for when we are going to see a lighting preview option, but could you perhaps add the option to change the lighting in the shaded 3d view? So we can change it like in the model viewer and get a general idea of how certain types of lighting will look like ingame.
* After using Source SDK then restarting steam, DoD:Source, HL2, and HL2:Deathmatch update at 233 bytes and source sdk updates at 70% at a rate of 70 kb/s
** You need to run Steam with the -beta sdk option every time you start it, otherwise Steam has to re-download the non-beta version.  --[[User:Nailed|Nailed]] 23:38, 24 Nov 2005 (PST)
***I always run it with -beta sdk..but it keeps doing it
**** If you have steam to load with windows, you will also have to edit the reg key ''HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run'' to look like ''"d:\program files\valve\steam\steam.exe" -silent -beta sdk''
* Suggestion: After using Maya and other 3D-applications, it would be great to see a Hotkey-feature in Hammer! For example, map the Textures-window to M , Block-tool to B instead of Shift+B, etc etc. Hotkeys gives a much better workflow.
** The hotkeys there already are fine (Shift-A for surface props, Shift-B for brushes, Shift-C for camera and so on), and I don't see a reason to change them, especially since so many of us use them and have them engraved into our heads now! What additional hotkeys are you thinking of? --[[User:Johnsto|johnsto]] 02:02, 4 Dec 2005 (PST)
*** Thinking of being able to remap the current hotkeys for your likings, and add more hotkeys for things like the Texture Browser. Even hotkeys for Rotate 15 degrees, Scale +-0.1, etc etc. But this is just an industrial injury of me using Maya too much. --[[User:Zyndrome|Zyndrome]] 18:44, 4 Dec 2005 (PST)
* Insert original prefab button only appears after switching tools & not right away&mdash;'''[[User:Ts2do|ts2do]]''' 14:00, 6 Feb 2006 (PST)
* On map load, or new map start, hammer shuts down automatically; there is no warning or error notice.
: Does this happen with the Beta SDK, or when running the non-Beta version of Hammer? --[[User:JeffLane|JeffLane]] 14:15, 9 Jan 2006 (PST)
* I tried loading a large vmf file (5.51 mb) onto Hammer, which loaded quite well in versions before this beta, and the program crashed with a non-specific windows error saying "hammer.exe has generated errors and will be closed by Windows." --[[User:Jojoboy|Jojoboy]]
* When you enter an invalid wall width (ie 0.5) in the arch creation dialog, you get into an infinite series of "please enter an integer value" dialogs.
* When you create a prefab catagory (Prefab Factory) or create a prefab hammer will crash. --[[User:BloodShed|BloodShed]] 22 July 2006
* The 'SetSpeed' output appears twice on 'func_door' entities. It looks like only the second one actually do something. (I don't know if this problem also occurs with other entities) --[[User:NykO18|NykO18]] 21:08, 18 Aug 2006 (PDT)
* On 'trigger_multiple' entities the 'OnStartTouch' and 'OnEndTouch' outputs are both ignoring the 'Delay before reset' option of the trigger. The 'OnTrigger' output works correctly. (I don't know if this problem also occurs with other entities) --[[User:NykO18|NykO18]] 21:08, 18 Aug 2006 (PDT)
* On 'func_button' entities, the flag 'Not Solid' seems to have disappeared (as long as I can remember, there was one). Also, the 'Toggle' input has also disappeared. It seems now impossible to 'unpress' a button via an output when it has been pressed. --[[User:NykO18|NykO18]] 21:18, 18 Aug 2006 (PDT)
* All or the most of the 'item_xxx' entities are broken in HL2DM. I made a test map with displacements, props 'n stuff and I tried to put ammos and weapons on everything (on tables, on shelves, on displacements, on brushes). Althought none of the items are touching something, half of them are respawning badly after beeing picked up once.. On the 80 items I placed, only 40 are respawning correctly, the others are respawning at the origin of the map (coords 0,0,0).. I was thinking of a minor collision box problem, so I put them at least 40 units away from any obstacle, and I ran the test again, but with no success.. It's really a pain in the *** to make a HL2DM map with this sort of problem, I'm forced to stop mapping because of that. So maybe I made something wrong, but I don't think so.. just take a look at [http://nyko18.free.fr/temp/item_ammo_crossbow.png this picture]. These two item_ammo_crossbow are respawning at the origin of the map and I don't think it's normal. --[[User:NykO18|NykO18]]
* In relation with the above problem, a large number of 'item_xxx' entities are replaced by a big red 'ERROR' model in Hammer, like item_ammo_ar2 or item_ammo_pistol_large. But ingame they seems to be OK, it's just REALLY difficult to place them correctly with this huge error model. --[[User:NykO18|NykO18]]
* On env_sprites, if you browse to and select a sprite name, it will fill it in for you without the .spr/.vmt extension. While this works fine for the Hammer 3D preview, this prevents the engine from finding it in-game.
==Unsorted==
* When a func_breakable has the 'playerclip' texture applied (or perhaps other tool textures, haven't tested any others), HL2 will crash as soon as the map is run. The compile log makes no note of this, nor does Alt+P.
* When I was experimenting around with [[phys_hinge]]s, [[func_physbox]]es and [[phys_constraintsystem]]s, I created a phys_hinge but couldn't move it. Each time I tried to drag it into a new position with the mouse, which I couldn't, when I let go of the mouse button, the entity moved OUTSIDE the entire map, judging by the line, with its "blue ball" in the origin of the map. I saved the map and restarted Hammer and Steam, but still I was unable to move the phys_hinge. This bug disappeared when I manually typed in new coordinates for the entities "blue ball" in the ''Hinge Axis'' keyvalue field. --[[User:Andreasen|Andreasen]] 06:21, 23 Mar 2006 (PST)
** I can verify this as well. It's happened to me many times. The only fix was using brackets to increase the grid scaling, and THEN moving it, but if I tried to move it on a lower grid scale again, it screwed up. The only solution I had was to move it using the transform tool.[[User:MichaelLipik|MichaelLipik]]--
***This happened again, and after some tampering I concluded that if you try to move a phys_hinge (and possibly other entities too - didn't try that) while the grid scale is set to 1, this bug will happen. Setting the grid scale to 2 or bigger, will make the bug disappear, but it is easily reproducable by just decreasing the scale to 1 again. --[[User:Andreasen|Andreasen]] 15:48, 30 Mar 2006 (PST)
****I did some testing and it seems to only happen when an ent is defined with halfgridsnap...without it (such as [[phys_ragdollmagnet]]) it works marvelously&mdash;'''[[User:Ts2do|ts2do]]''' 16:25, 30 Mar 2006 (PST)
****I have reported this to [[User:Yahnbernier|Valve]] directly, and they will be releasing a fix for this in the next SDK update.&mdash;'''[[User:Ts2do|ts2do]]''' 21:35, 30 Mar 2006 (PST)
WORKAROUND: If the [[phys_hinge]](s) are selected simultaneously with normal entities ([[func_detail]], [[Weapon_smg1]]...) they should moive just fine. [[User:Bit Mage|Bit Mage]]''' 4:44, 6 Jun 2006 (EST)
* Hammer <-> HL2 compatibility (able to run both simultaneously without any problems)
** On this line of thought - Fix up the wc_ commands and developer environment ingame for HL2 <-> Hammer compatibility?
* Long file names can't be seen in Face Edit dialog.
* Face Edit dialog loses focus when cursor moves off the dialog. -[[User:Unknown]]
** I have also had this problem. But it also causes my view to scroll in one direction, it kind of acts like I am holding one of the directional keys down.If I try to counter the movement it halts the screen as suspected, but if I try to recreate the bug to reverse it, it doesnt seem to work. Thus making any further editing during this session impossible. Requiring me to restart hammer to continue. A Possible origin of this bug is in the quick window switching code. and the addition of me shifting my view while using the mouse. - [[User:PixlGnome|Tandem Fixation]] 01:25, 26 Apr 2006 (PDT)
**This is also hindering editing certain settings efficiently, Meaning I have to actualy stop and position my mouse so that it is not off screen to edit certain properties - [[User:PixlGnome|Tandem Fixation]] 01:25, 26 Apr 2006 (PDT)
*** I consider the lose-focus event to be a feature. It allows changing the 3d view to select different faces without closing/reopening the editor. &mdash; [[user:BJ|BJ]] 12 May 2006
****I think its because hammer renames the window to match whatever view the cursor is in. Doing so brings the Face Edit window out of focus. --[[User:Quanta|Quanta]] 14:36, 2 Jun 2007 (PDT)
* Hammer crashes if you startup a game without minimizing it and then reopening it before the game opens.
* Point At... button for angle keyvalues only set "angles" keyvalue.
* Occasionally the editor closes without warning or error.
* Editor becomes unstable and/or crashes on a fairly regular basis, often when adjusting overlays, deleting or working with move or keyframe ropes, when moving large amounts of brushes or entities, or doing large amounts of displacement modification.
* 3D view black models issue fix (failing to draw model textures because of video card limitations)
** I've noticed this only happens on Mx440's or whatnot, very low-end cards. --[[User:RabidMonkey|RabidMonkey]] 00:33, 16 Oct 2005 (PDT)
*** I managed to have it happen on a Radeon 9600, but it wasn't a reproducible bug. --[[User:Spektre1|Spektre1]] 08:32, 16 Oct 2005 (PDT)
****I just had this happen after a "steam update" that occurred today with a geforce4 TI 4400. Texture was working yesterday, it's just black today, and my other textures are fine. I had it scaled quite small to show good granularity, I'm trying to find a fix.--[[User:Mrobben|Mrobben]] 20:22, 5 May 2006 (PDT)
* Painting alpha values across multiple terrain brushes sometimes will not paint one of the selected brushes even though the points are lined up and sewn.
* Nudging objects with the arrow keys only moves one unit at a time, even when a larger grid is selected.
* Face Edit Sheet, Lightmap Scale only has space for 2 visible digits (128 shows up as 12 or 28.)
* Ctrl + E should still center on the selected object, even when in brush creation mode.
* Texture scaling lock rotates not-scaled faces (sometimes). See attached picture. [[Image:Scaletexlockbug.jpg|thumb|left|40px]]{{clr}}
* After the Day of Defeat: Source SDK update (or the 2D rendered models?) Hammer has begun to break up the 2D grid lines in triangles.
[[Image:Linebreak.JPG|thumb|left|40px]]{{clr}}
* Hammer crashes after wake up from screen saver
I have encountered a bug in hammer, running under XP Pro. I am using the "Windows XP" screen saver. And I have "Fast User switching" and "Use Welcome Screen" turned on. With my account that is password protected as well as guest account turned on. (Guest account is not logged in)
** 1: First run Hammer and open up a map.
** 2: Leave hammer running in the foreground. Wait for screen saver to start.
** 3: Wait a minute after screen saver starts, and use mouse mouse to wake up computer from screen saver.
** 4: Type in user password to re-enter windows and the standard windows error dialog is displayed asking to submit error report to microsoft or not fallowed by a memory error message box.
This is not always reprodceable. But it has happened to me 3 times today so I am posting it here. If I find a way to reliably reproduce the error I will post the info here. Be sure to '''save your work before leaving your computer''' with hammer running!
* Suggestion: Currently when moving a texture on a brush by clicking the up/down arrows in the texture window, every move is a new undo level. If you hold the mouse and move the texture many units this can result in dozens of undo levels wasted with a simple texture adjustment. Every texture adjustment change on a face should be one undo level until you de-select it.
* It is not possible to rotate brushwork & overlays simultaneously.  Doing so results in the overlay no longer working.  Fixing the  problem of "unused key, angles" in the check for problems dialogue doesn't do anything to fix this.  I make a lot of symmetrical maps (CTF etc) so this is a total pain because it means I have to redo all the overlays for the second base...  I've tried numerous approaches (including rotating, flipping on the x and y axis instead) and stuff, but I've not found anything that works yet.  I've got 340 overlays to redo for the blue base now and I'm not best pleased! -- [[User:Defrag|Defrag]] 11:29, 9 Sep 2006 (PDT)
* This isn't exactly hammer, but I don't see a VBSP bug page: If you have too many surfaces emitting detail props and end up with more than USHORT_MAX (65535) detail props, VBSP will have two behaviors: First, if none of the remaining props are detail sprites, it will finish building the BSP and says "Error! Too many detail props on this map. {0} were not emitted!", where {0} is the number of detail models over. On the other hand, if you have so much as one detail sprite after the maximum, it errors out without saying how many over, and doesn't finish. I've fixed this to just the one behavior for myself, but might as well report it for all. --[[User:Kateye|Kateye]] 18:37, 11 Oct 2006 (PDT)
* The compile tools consider func_ladder a world brush, despite being tied to an entity. I've contacted the creator of CST, but he doesn't works on it anymore. [[User:Solokiller|Solokiller]] 10:04, 4 Mar 2007 (PST)
** '''Workaround:''' use the '''tools/toolsinvisibleladder''' texture on ladders and make the ladder brush(es) func_detail or another entity (func_detail, unless you want to toggle the ladder or do some effect with it) [[User:Solokiller|Solokiller]] 09:37, 18 Jul 2007 (PDT)
* every time after a few minutes (can be 1 ore 15) hammer crashes and i get this error:
An unhandled win32 exception occurred in hammer.exe [4400].
* Make a an entity A parented to an entity B this one parented to A (like camera with func_rotating) make a game crash of course, but hasn't in ALT+P error, if you delete A or B and use cltr+Z Hammer will crash on next commands or in next seconds. [[User:Gectou4|Gectou4]]
=Reports confirmed fixed or dismissed=
== General Hammer issues ==
* Cursors don't always do what they're representing i.e. a drag cursor appears over a button or a text box.
** Cursors appear to not update properly when they're hovered from one object type to another. i.e., When a brush is selected, and the Object Properties dialog overlaps the selected brush; if the user moves the icon over the Object Properties dialog, the cursor is still a 4-way arrow.
: Should be fixed by today's update. --[[User:David Speyrer|David Speyrer]] 19:48, 16 Jan 2006 (PST)
* Creating an arch (mine was size 704x356, 180 degrees, wall thickness was 400 (full)) causes invalid solids when you save and reload the map.  Also, the front faces of the solids are not drawn (probably due to the invalid solid part) even before saving.  I tried this with 32, 64, and 128 face arches, all had the error.  Also happened on a 3072x2048 arch, 180 degrees, 3072 wall thickness.  Also, vertices end up half-way across the map when an arch is Clipped.  --[[User:Beans-v6|Beans-v6]] 15:06, 7 Dec 2005 (PST)
: Not an SDK Beta bug.
* I know we shouldn't use the Carve tool (and I'm not using it) but I was carving for a tutorial when a bug occurred. Try to carve a 128 units depth bloc with another 128 unit depth bloc and the carved bloc will be resized to several times the size of the whole grid in Hammer.. like infinite. --[[User:NykO18|NykO18]] 09:45, 30 Dec 2005 (PST)
** It seems to not happen anymore since the last updates. --[[User:NykO18|NykO18]] 03:50, 20 Jan 2006 (PST)
* All ents with the same model are set to the same sequence when the sequence is changed through the Model tab of the Object Properties page.&mdash;'''[[User:Ts2do|ts2do]]'''
** This is a duplication of the bug explained 5 paragraphs higher
== Hammer 2D and 3D Views ==
* While drawing a brush in the 2D-View, and clicking accidentally outside the brush, the whole former brush disappears.
:Could be fixed through decreasing sensivity of new brush drawing.
:: Fixed by today's update. --[[User:David Speyrer|David Speyrer]] 19:44, 16 Jan 2006 (PST)
* In morph mode I can't use directional arrows to move in 2d wievports. It's a bit annoying to use sliders every time when I want to carefully manipulate bigger brushes.
: Fixed by today's update. --[[User:David Speyrer|David Speyrer]] 19:44, 16 Jan 2006 (PST)
* Grouping Objects while 'ig' (Ignore groups) is on fails to group the selected objects.
: Not reproducible. The objects are grouped, but you can't select them as a group until Ignore Groups is disabled. --[[User:JeffLane|JeffLane]] 14:59, 9 Jan 2006 (PST)
* Displacement textures appear to be the exact opposite of what appears ingame&mdash;'''[[User:Ts2do|ts2do]]'''
** Duplication of a bug explained in the previous section.
== Hammer VGUI Model Browser ==
I noticed a couple of days ago when i tried to change one of my models, i clicked on the browse button to open up the VGUI Model Browser, hammer freezes up and does nothing, does the VGUI Model Browser not work anymore? (September 21, 2007)
Ok.. so i deleted the registry files for the VGUI Model Browser, and the VGUI Model Browser finally showed up in hammer, the only problem was, that there was just a gray window and a black box in the top left hand corner in that window, so what i did was stretch the window out, and for some reason the VGUI Model Browser corrected itself, pretty weird if you ask me.
I think the reason why this may of happened, was because of my dual monitor setup, but i could be wrong, a theory that when i open up the VGUI Model Browser, i had ATI Hydravision installed, which saves your program/window positions on a monitor, so your program/window opens up on a specific monitor, i had the VGUI Model Browser set to come up on my second monitor, but when i switched to using my main monitor, hammer probably still recongizes that i still have a second monitor on so when i click on the button to open up the VGUI Model Browser, nothing shows up on my main monitor, thus resulting that it's trying to open it on the second monitor, which could of happened i'm not really sure. (September 28, 2007)
== Hammer Autovisgroups ==
== Hammer Autosave ==
* Hammer tries to save to removable media, when it’s read only, same with read only folder rights. (This might not be a good idea for those working on source mods as final projects at Universities, or schools)
: Fixed by today's update. Choose a different autosave directory in Options->General.--[[User:David Speyrer|David Speyrer]] 19:50, 16 Jan 2006 (PST)
== Hammer - Misc ==


=See also=
=See also=

Revision as of 13:52, 7 November 2007

This page is for reporting bugs in the Valve Hammer Editor.

Reports

General Hammer issues

See also

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Source_SDK_SE2_Bugs&oldid=59993"