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

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.

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!

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

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/forums/showthread.php?t=2708126

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

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.

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.

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

just encountered this error.

recovered my map from one of the autosave files. however the cs:go sdk can open it fine (expected no materials/prop errors) i save it as a new file name.
i go to open it with source sdk and hammer immediately crashes. (opens other maps fine)

any ideas?

i tried deleting what i thought to be the problem brushes and resaving but didnt work.

edit: thanks to yyler's post http://forums.tf2maps.net/showpost.php?p=270720&postcount=11
crisis has been adverted.

I'm assuming this is the "official" thread for this problem (it's the longest one I've seen), so I'd like to post the fix I've been using.

I've been having problems with invalid solids that aren't fixable by opening the map file in a previous SDK version, because the solid isn't detected as invalid in other versions of the SDK (I've only been testing with the Source SDK and not L4D2/Portal 2). If I opened a map in the Half-Life 2 configuration it would work fine, but in TF2 there would be an invalid solid present. What I did was as follows (this is assuming there is only 1 invalid solid present in the file, which you can check in the error message Hammer gives you on load):

-----

1. Create a new blank map and save it.
2. Open the offending map (I did this with my own map and also the official version of Dustbowl provided by Valve, which was having this error). Using a text editor, copy all the entity entries from the first "entity" to the last "}" (before you get into the cameras section at the bottom of the VMF) into the middle of the blank VMF: ie. after the worldspawn class' last bracket and before the beginning of the cameras section. I also copied these entries into their own temporary text file so that I could work with them. Close the offending map file.
3. If an invalid solid is reported when the originally blank VMF is opened (it was both times for me), the solid is located in the entities. If not, it'll reside in the world brushes which are contained within the worldspawn class and you should delete the entities and copy those in instead to check. Either way, the method works pretty much the same: entities go between the final bracket of the worldspawn class and the beginning of the cameras section, whereas world brush "solid" classes go inside the worldspawn class between the final header property and the closing bracket. Below I'll be describing the method specifically relating to the entities, but the same applies for world brushes - just follow the same kind of method within the solids listed in the worldspawn, but paste the solid entries into their own text file first.
4. Get rid of all the entries pasted into the originally blank VMF and, from the temporary text file containing the list of entities you pasted, highlight roughly half of the entries (beginning in "entity" and ending in "}"). Paste them into the blank VMF between the worldspawn and cameras, save, and see if the map loads in Hammer (obviously choose "No" when asked to re-save the map if an invalid solid is detected). If no invalid solid is detected, delete the entries in the temporary text file that you highlighted and copied in; if an invalid solid is detected, delete the entites from the file that you didn't highlight (we want to keep the entries which contain our invalid solid somewhere within them). Once that's done, delete the entries in the VMF, highlight in the same way half of the entries that are left in the temporary text file and copy them into the VMF again. Keep going like this, deleting the sections that don't cause an invalid solid error and keeping those that do, and eventually you'll get down to a single entity class left in the temporary file which contains your invalid solid.
5. Once you're down to one entity you can copy the framework of the entity class into the VMF (ie. ignoring any references to "solid" classes), then go through the solids contained in the entity class one by one. For the solid that does cause the error, make a note of the "id" value at the beginning of the class.
6. Make a working copy of your offending map file (so that you still have the original in case something goes wrong) and open it in a previous SDK version. Go View -> Go to brush number and enter the ID of the solid in the previous step. This will let you know where abouts spatially the offending brush is in your map, so that you know what to replace later.
7. Close Hammer and open this same working copy of the map in a text editor. Search the file for the ID number and delete the whole "solid" class that contains it (if it's the only solid contained in the entity class, delete the whole entity). If you open the map file in TF2 again, the offending solid should be gone.

-----

TL;DR: In both the Dustbowl VMF and my own VMF the offending brush was a cone. I'm wondering whether the TF2 version of Hammer reads with a different precision to older versions, so values that may be rounded in previous versions of Hammer may not be in the TF2 version (or vice-versa). At any rate, I'd advise not using cones right now.