Sorry it took so long, but I finally updated my VTF Shell extensions to support the 7.4 VTF format as found in Team Fortress 2/The Orangebox.
The delay was due to both Nem being busy with real-life stuff and unfortunately losing the code to the Photoshop plug-in which meant a re-write. This lead to the new version of VTFLib being delayed and as so many of our tools rely on it, we couldn’t update without it.
Anyway, everything is updated now – Nem has released the new VTFLib, VTFEdt and his Photoshop VTF plug-in with 7.4 support and I’ve updated my XP/Vista Shell extensions. I’ll update the 3DS Max plug-ins hopefully in the next couple of days. I’ve also updated the documentation for VTFLib.
One new feature though that’s worth mentioning. Since VTF 7.3, the VTF format has added support for “resources” embedded inside the actual VTF file. This was originally added, I believe, to better support features on the XBox360. What’s nice is that developers can add any custom resource and data they might need.
This gave me a brainwave.
Often you find VTF textures all over the place and if you’re creating a Mod it can be a right pain-in-the-arse to keep track of texture assets. Wouldn’t it be great if there was some sort of metadata inside the actual file containing useful information about who made the texture, how to contact them and what game/mod it came from? Basically EXIF for VTF files.
Well that’s what we implemented. Using a custom “Information” resource you can now embed useful information into VTF files for TF2/Orangebox using VTFEdit. You have the basic author and contact info, your texture version number, what game/mod it’s for and include a short note. My VTF Shell extensions can show this info as part of the detail columns in XP or in the properties view in Vista.
So you know the drill – un-install any previous versions of the shell extensions you have installed and make sure you have the Visual C++ 2005 SP1 runtimes installed if you don’t already.
Oh lord. It looks like I’ve caused a bit of a stir in the Day of Defeat:Source Modelling forums this past week – custom player models that actually work on-line.
Back in the days of Day of Defeat on the Goldsrc engine, we had a really busy custom player model scene. People were producing models for different countries, armies, regiments, units, etc. There were lots to choose from and customising DoD to your liking was a big thing.
When Valve released Day of Defeat:Source they implemented a file consistency checking system which is designed to prevent people from cheating by using heavily modified models that might give an advantage on-line. This consistency check, in it’s earliest incarnation, pretty much blocked all custom player models and led to a lot of talented character modellers quitting the scene. Why waste all those man hours making a kick ass player model if no-one can ever use it?
A little later, Valve released an addition to the consistency check called pure servers which in theory allowed server admins to permit custom player models or force the player to use the defaults from the GCF file. This is all well and good, but the consistency check is still invoked and your custom model can still fail at that!
Well I love a challenge and seeing people struggle to make even the smallest of edits to the default player models I figured I’d have a go at solving this mystery once and for all.
I’m lucky because I have a reasonably good relationship with some of the guys at Valve so Matt Boone, DoD’s main coder, gave me some of the numbers specifc to DoD and Mike Durand was kind enough to show me the source code for the entire consistency check function. Pure gold when it comes to figuring this stuff out and what exactly is making these models fail.
My test case, which proved successful, was to compile one of the default HL2 NPC characters from the Source SDK to work on-line with DoD:S. It worked, but took a fair bit of hacking and experiementation to not trip the check. From that experiment came a simple “proper” hack – replace the steel helmet on the German assualt class with a M43 field cap – a throw back to the DoD 1.3 days.
After posting a breakdown of how the consistency check works and then a kit of files for correctly compiling custom models so that they pass the check, things have started to take off again. Already people have started re-skinning and improving my cap model, people are starting to suggest other modifications to the player models and a few have actually started re-working and customising new ones.
I really hope this sees a resurgence in the custom player model scene of old and gives DoD:S a healthy shot in the arm.
I posted full details on the consistency check on the Day of Defeat:Source forums, but for those that want to know, heres a brief summary of how the consistency check works:
- Models are CRC checked against those on the server. This is skipped though when pure servers allow custom models.
- Models have their bounds checked against a pre-defined set of ranges. These bounds are calculated when the model is compiled and represent the absolute limit that any part of the models mesh reaches during any animation sequence. These limits can be represented as a bounding box, which is compared against a bounding box defined in game. If any part of your models bounds exceed the game’s, it fails.
- All materials used on the model must be “simple” – i.e. they use only the VertexLitGeneric shader, a diffuse, normal and phong maps. Certain other paramters are allowed but anything else results in the material being rejects and the model failing.
I believe all the current Valve Source based multiplayer games use this check so it may prove useful for CS:S and HL2:DM too.
Well I knew I was taking a bit of a risk with my first Vista compatible shell extension and yes, some bugs did creep in. I do test my stuff as thoroughly as I can but sometimes things slip through the net. :o(
Thanks to those who did take the time to contact me and report their bugs. The two most common problems seems to be missing C++ Runtime files (Microsoft requires specific versions for applications compiled with VS2005 SP1) and the extensions crashing when you right-click on a thumbnail.
The runtime issue is solved by installing them as necessary – I’ve provided links to them above the shell extension download page.
The thumbnail crash problem I’ve tracked down and have released an update to the extensions. As normal, you’ll need to uninstall the old version before installing the new but hopefully this will solve it.
For those of you still having problems, especially with Vista, please let me know if you’re getting any wierd error messages or so on. The easiest way to track and solve a bug is if I can get reproduceable proof of the bug and enough info to diagnose it.
Been a bit quite of late due to a huge ammount of work to get through… Sorry ’bout that.
What’s new this version?
Short version: Re-written, added support for Vista and with a much improved installer.
Long version: Updates to VTFLib so that it would compile under Visual Studio 2005 as a 32-bit and 64-bit DLL. ‘ve also added basic support for version 7.3 of the VTF format but that’s only of any interest to you if you work at Valve or are from the future and creating content for TF2. Re-written the actual shell extension code to combine both extensions into one DLL for XP/W2k and inplement some speed enhancements and better error handling. For Vista, I’ve implemented the new Property Handler system. Installer auto-detects what OS you’re running and installs the correct DLLs (32bit or 64bit) to match, handles registration better and adds a proper un-install option in the Add/Remove Programs dialog. (*phew*)
If you’re using a previous version I would recommend you un-install it and update to this new version. Please do use the un-installer as it helps remove the risk of something being left behind and screwing up. The installer for this version will attempt to remove any previous versions but it’s brute force and a last ditch method if it finds any offending files floating around.
UPDATE: Turns out that people installing the extensions on Vista 64bit were having issues. I tracked it down to needing the VS2005 SP1 Runtimes installed first. I’ve added links to where you can download the installer for these files on the download page.