SDK Bug: All your entities get wiped from the vmf.

[Ravidge]

There's currently a issue where Hammer will try to load your vmf, but if it finds a invalid solid it will wipe all entities from the file.

If you don't have any autosaves or backups this can be pretty troubling.
For now it's recommended that you save your work as a completely new file (as in, don't just hit ctrl+s, hit the Save As... button) from time to time.

As far as we know this only affects the Source Engine MP version of the SDK (TF2 and CS:S).

What to do if it happens to your file?
We don't really know. If you know, please tell us, be as specific and detailed as possible.

TIP: when trying to restore your files using autosaves or backups, make duplicates of everything! You don't want to end up replacing a important backup file with a failed restore attempt.

Things you can try:
1) Load your vmf in another source SDK. This means something like alien swarm SDK, portal SDK or cs:go SDK.
It seems that only the TF2/CS:S SDKwill actually wipe the entities when a invalid solid is found. Others will simply remove or attempt to fix the erroneous solid itself.
If you map loads in another SDK, and all the entities are present (all/most textures will be solid white and models will display a ERROR sign) then you're in luck.
All you need to do is save the file like you normally would. The error should be fixed and you shouldn't have lost any data. You can now re-open it in the TF2 SDK and continue mapping.

2) If you compiled your map recently, you can decompile your own bsp to retrieve a vmf.
It's not a very elegant solution, but at least you haven't lost EVERYTHING.

3) vmf files are written in plaintext and can be opened with a text editor. If nothing else works. You can start digging into these "documents" and trying to fix the problem manually.
Copy/pasting entities from a older save could potentially save you a lot of trouble. However, manually editing your vmf through a text editor is dangerous in itself. It's a last resort option.


If you've found a reliable way to fix this problem, please reply to this news post with the solution, everyone will love you for it.

Until Valve decides to fix this issue, maybe we should all start hitting alt+p before closing hammer.

Just an FYI so everyone knows, I emailed Valve about this yesterday (tfteam@valvesoftware.com, CCing Robin and Eric Smith for good measure) with a good description of what happens and how. Here's hoping they do something.

[ForbiddenDonut]

The few times this has happened to me (both to soot and geiger), it was because I was vertex editing, my editing selection grid stopped responding and I saved/re-opened Hammer to get it to work again.

Unfortunately, if you're in the middle of what becomes an invalid solid, it will give you that error and the bug that follows. So, if my grid ever becomes unresponsive, I immediately delete the solid I was working on to prevent it.

Otherwise, I do what Ravidge says - I rotate save four different file types (under different backup numbers) every session. Alt+p before every compile and save is always a good habit to pick up.

Only you can prevent Hammer fires!

[Kill_the_Bug]

In case you don't know about rotaing saves they are:

Save file as yourmapname - when you start your map - then as you work:

Save as yourmapname-01
Save as yourmapname-02
Save as yourmapname-03
Save as yourmapname-04

then repeat the above sequence repeatedly.

Personally I don't repeat the files (the ultimate back up) I just keep going, 05, 06, 07, 08, 09, etc

That way I can keep going back in time in a sequential fashion and pick out and modify stuff as needed / IF needed.

My most recent map went up to 89 or something like that maybe more

[Little Dude]

I actually found a solution where you do not need to use another SDK. All you have to do is place TF2 in the 2009 version of SDK and you can open maps with invalid solids. However, if you do manage to eliminate the solids in that version, you still can't open it in the MP version of SDK.

I found the solution here: http://forums.steampowered.com/forum....php?t=2708126

[Mr. Happy]

DEATH TO THE ENTITY GNOME!

What little dude said, except you don't need to create a tf2 config, just use the Ep2 or Portal config. And the file should still work with TF2/MP Hammer. If it doesn't, redo the process with 2007.

It seems that clicking NO when Hammer asks if it wants you to fix the file avoids the bug. It doesn't save, so you can prevent Hammer from breaking the file.


AND YOU DO HAVE BACKUPS! By default they are in C:\HammerAutosave and they have a different file extention (.vmf_autosave), so you will need to switch the file type in the dropdown in Hammer's Open dialog to see them, or you can just rename them (just chop that _autosave off) in Windows Explorer as you would with any other file (assuming you have "Show File Types" and if you don't, well, you don't know what I'm talking about.)

EVERYONE should probably take this new and dangerous bug as an opportunity to adjust their AutoSave settings, increasing the space used etc. Take note, the autosave timer resets everytime you manually Save so if you hit Ctrl+S every few minutes like I do you might not have as many as you expect.

NOW, let's say you've got your file and you want to rescue it using Notepad, it is possible and I'll detail it below, but using an SDK or opening a backup is usually easier.
----
If you are curious, here's how to save the file without a different Hammer:

1. Click NONONONONONO when Hammer asks you if you want it to fix the solids. Close Hammer.
2. Make a copy of the file! Make ten copies just in case!
3. Open the file in Notepad (I prefer Notepad++) and search the file for "entity".

You will see something like this:

entity
{
"id" "2"
"classname" "info_player_teamspawn"
"angles" "0 0 0"
"origin" "-384 -128 0"
editor
{
"color" "220 30 220"
"visgroupshown" "1"
"visgroupautoshown" "1"
"logicalpos" "[0 0]"
}
}
etc. etc. etc.

Select the word "entity" and everything below it down to the bottom. That's all the entities, and then also the cameras and cordons.

Paste that into a new file and put this at the top:

versioninfo
{
"editorversion" "400"
"editorbuild" "5653"
"mapversion" "2"
"formatversion" "100"
"prefab" "0"
}
viewsettings
{
"bSnapToGrid" "1"
"bShowGrid" "1"
"bShowLogicalGrid" "0"
"nGridSpacing" "64"
"bShow3DGrid" "0"
}
world
{
"id" "1"
"mapversion" "2"
"classname" "worldspawn"
"detailmaterial" "detail/detailsprites_2fort"
"detailvbsp" "detail_2fort.vbsp"
"maxpropscreenwidth" "-1"
"skyname" "sky_tf2_04"
}


4. Save as a new .vmf and BAM! A new clean map file with just the entities.
5. Open the map in Hammer and let it fix the invalid, and crash out.
6. Open the map in Hammer (which now has no entities) and the map of just entities, and paste the entities into Hammer.
7. Done

[YM]

I'm swapping to google drive for my working directory. by default it saves either the last 100 previous versions or the last 30 days worth of versions (whichever is smallest) and 5GB of space total. It's not good like dropbox is for sharing files quickly but it has more space from the get-go.

[grazr]

I woulda thought someone like you managed to max out the referal file size boosts on DB. I've got about 6G on it at the moment (I believe 2G is min and 8G is max for a free user?).

How much space does Google Drive offer? I know i could google search it, but it's probably useful for others who see this thread to see it here from someone using it.

[stevethepocket]

I discovered today that this bug even affects some of the SDK bundled source files, including Gravel Pit and Dustbowl. So that's nice.

I've gotten this twice in the last 48 hours, and both times it was after a Hammer crash. In both cases I hadn't been doing anything that would lead to an invalid solid. My conclusion is that Hammer creates these invalid solids, or is encountering some other error where entity data is corrupted and then removed, but the only way Hammer can tell you this is by calling it an invalid solid, if that makes sense? At any rate, be really careful dudes.

it also converted all my brush ents to " " class ents and screwed up their vis groups and that includes func_details and oh god dfhgdfgg why

why