Post your Portal 2 Authoring Tool Bugs
Im trying to compile my map, but it says that func_portal_bumper is leaked, when i go to its coordinates, it appears to be out of my map, i cant select it with select tool, or find it in objects list, i copied my map without selecting place of that entity, and it keeps saying its leaked, though i have never created this entity myself.
Im new to Hammer, but when i previously compiled my map succesfully it looked great, but i cant release it with that error 8(
Can you please help me?
[SOLVED]
iWork925 wrote:
Continuing from my previous post. This is also a common occurance.
1) Its an issue with your card. Prolly the editor adresses a part of the memory wich isn't adressed at all times. (not even with crysis). I have had simulair issues with my graphics card. All games runned fine. Except EVE online, it crashed occasionaly but always while in one type of space (with gas clouds). Exemaning the error more closely. I found out a small part of the cards memory was corrupted. Otherwise hardly adressed. But with the EVE visuals id did and it crashed. I was confused since EVE isnt a heavy game for graphics cards. IMO your card is about to die... Just my 2 cents 
2) If your running Windows 7 it might be a registery fault. Since the driver isnt responding it might be Windows 7 thats bugging your graphics card. Win7 has a nasty reg key that basicly checks if your card is still responding all the time. Explained in easy words;
Windows 7 says to graphics card: poke "Hey you stil there"
graphis card to Windows 7: "Yeah"
Windows 7 says to graphics card: poke "Hey you stil there"
graphis card to Windows 7: "Yeah"
Windows 7 says to graphics card: poke "Hey you stil there"
graphis card to Windows 7: "Yeah"
Suddenly the following thing happens:
Windows 7 says to graphics card: poke "Hey you stil there"
graphis card gets no time to respond cuz he busy calculating
Windows 7 says to graphics card: poke "Hey you stil there"
Windows 7 says to graphics card: poke "Hey you stil there"
Windows 7 thinks: Graphics card not responding!!!! BOOT!!!
The Fix:
We will raise the TDR timeout period to 10 seconds. (this should be sufficient, don't go any higher as it may be bad for your video card IF an actual issue does arise.)
1. Open Registry Editior (regedit.exe)
2. Navigate to "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers"
3. Create a new 32_BIT DWORD Key, and name it "TdrDelay" (case-sensitive) and assign it a Decimal Value of "10". (If one already exists, just change the value from 2 to 10)
Or Copy the following into notepad, and save as a .reg file. (Easy Way) Then Import the settings.
Code:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers]
"TDR_DEBUG_MODE_IGNORE_TIMEOUT"=dword:00000001
"TdrDelay"=dword:00000010
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\DCI]
"Timeout"=dword:00000007
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\MemoryManager]
"Period.EnableEvictionThresholdForWrite"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\TdrTestMode]
"TDR_DEBUG_MODE_IGNORE_TIMEOUT"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\UseNewKey]
- Reboot your system, and try again.
Every animation for the robot arm has at least a couple of "idle" states. These will put the robot arm in its start or end position for each animation. Use the idle state ("idleend" is usually better as it puts it in its final "in-the-wall" state) for whichever animation you want as the initial animation instead of "BindPose." Makes placement a million times easier. 
If I select a block and open its properties, then try to move around the 3D view, it becomes unbearably laggy. Sometimes resulting in Hammer crashing.
That's all for me. I can usually get around these things by saving the map just before I click flags and closing the properties of an object until I need to use it.
Because when you reload the map all vertex points in the corner are off grid going nuts.. 
Load your point file and find where you leak is. Hammer doesn't lie when it says there is one.
When Hammer says that an entity is leaking, it doesn't usually mean that there is a problem with the entity itself. The entity is just the start of a trace line to the leak, which is generally caused by a gap in brushwork leading out into the void. The pointfile starts at the entity, and traces a path outside the level. The point where it exits the brushwork is where the leak is usually located.
Leaks can be caused by entities, specifically when their origin helpers are outside the map, but this is less common than traditional leaks caused by gaps in brushwork, or use of non-sealing textures on external walls.
EL POLLO LOCO wrote:
Yeah but the things its pointing to i haven;t touched or changed in any way. so I don;t get how its leaked.
I had the same problem. And with me it was a texture that leaked. The brush had the no draw texture and one face on the map side had a texture. It leaked like hell and it didnt show with the trace line. When I applied the texture all over the brush it stoped leaking.
Mediaburn wrote:
I had the same problem. And with me it was a texture that leaked. The brush had the no draw texture and one face on the map side had a texture. It leaked like hell and it didnt show with the trace line. When I applied the texture all over the brush it stoped leaking.
Some textures leak into the void because technically it isn't a solid block texture. For example there is a texture called "tools/nodraw_glass_footsteps". It looks like a nodraw texture but dont be fooled!, it acts like glass and will cause leaks if not used in the right place.