Give me your Evil Files

I'm working on a Java library for parsing certain mapping-related files and I want to make sure it can handle as much of what people will throw at it as I can. Note that large chunks of the basic functionality are trivially portable to other languages, like C++, PHP, or Python.

But I need sneaky files. Tricksy files. Evil files. ("And... Methodists!")

• .vmt
• Soundscapes
• Particle manifests
• .ent entity data from a BSP (can extract with GCFScape)
• Or any other file that TF2 uses with a similar structure.

Edit: Never mind, that doesn't include VMFs... I'm not happy with the algorithm's performance for files that are thousands of times bigger than the ones I'm focused on. VMF parsing will be some separate project in the future, if at all.

Put comments anywhere. Put comments that look like they aren't comments. Put some things in quotes and others without. See if you can do it all one one line, even. Don't worry about evil like "The VDC says it's a value from 0.0 to 1.0, but I'll put... TWO!", because that's not the kind of parsing being done. It's just turning the files into a bunch of nodes with key/value attributes and children.

I will use them to create an unstoppably evil army of unit tests. The only rule is that they have to actually work in the game.

I'm actually more interested in everything except VMFs, since I have a bug I need to squish before I can test those, and even then they won't be something I need to parse any time soon.

I really just tossed in VMFs to make the possibilities of the final product more interesting: A a building block for tools that could rewrite VMFs to automate things. An example I've been kicking around in my own head involves displacements that slice through a volumetric 3D texture cube, so with some pre-compile step you could end up with utterly seamless banded sandstone caves.

So no, I'm not asking for your precious VMFs to maps you've made, but if you have anything of that style (vmf/vmt/soundscape/particle-list/etc. that looks weird but the engine still accepts it, I'm interested in it.
______________

Maybe an example is better.

A nice, innocent little VMT.

Where's the fun in that? Pretty predictable.

But what happens when someone makes something that works in the game (I don't know if this example does) but is somewhat weirder?

Muh, it's taking 120mb of Java heap memory to parse a ~5mb sdk_arena_lumberyard.vmf? Haaaaaaaax!

So it works fine for small files, but there's something about the parsing pipeline that balloons memory use with bigger ones. I'm hoping I can find the right secret sauce to chop about 75% of that memory use off, then I might stand a chance of parsing the 21mb behemoth that is Goldrush...

Edit: OK, you know what? Forget VMFs. I'm getting overextended: If I ever do them they'll be a separate project because the issues of scale means I have to approach parsing them somewhat differently than what works OK for everything else. Map VMFs tend to be about a thousand times larger than everything else, even if the file format is similar.