Override all textures in map

I'm trying to do some greenscreen work in CS:S and I want to do it on a existing map but here's the problem:
I can't figure out a easy way to take every texture in the map and replace it with a singular [green] texture, short of decompiling the map and actually doing it manually... I can't take a demo from one map and play it on another so I can't decompile the map.

Well, without having to manipulate and re-compile a map, I would find just the textures (not all I'm hoping) that will affect what you're doing, and produce one texture to apply for all of them, thus updating their appearance in any map that uses those altered textures.

To do this would be basically a file-renaming task. The one texture to compile to a .vtf file type, will be renamed to fit its matching name listed in the .vmt files, which is what the engine really references. The material stays the same, but the image changes. And it's also worth noting, that all altered .vtf files must match their corresponding .vmt folder locale in order for them to appear in game.

And to return your game textures back to normal, You would simply delete or move those altered textures.

Whatever same-name files you place within the 'cstrike' directory will take precedence over those located within the .gcf files.

Is that What you were getting at?

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

I was gonna suggest that but the odds of pulling it off without either borking the files or borking the game so it fails to load seems too high to me.

We are talking about renaming potentially hundreds or thousands of textures. Or 5, I dunno.

---

The best things in life, aren't things.

I think at worst, it wouldn't crash the game, but those textures which aren't working would simply show up as the infamous pink and black checkerboard image in-game.

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

When the map is compiled some of the texture data is written into the bsp file (light maps are kinda the big thing that comes to mind...). Things like expected size of the texture file, lighting values, bump-mapping, uv texture coordinates, etc.

If that occurs your looking at potential crashes in the engine when you hand it a texture of of size 10KB when it was expecting a texture of size 145KB - the engine might handle it, but theres a very good chance it doesn't (perfect programmers don't exist).

Whatever same-name files you place within the 'cstrike' directory will take precedence over those located within the .gcf files.

I would try this. .gcf files are mostly read only for the time being (valve proprietary disk layout system), and the textures in the cstrike folder to take preference over the textures in the gcf file. You could copy the textures folder out of the gc file to the cstrike folder, then replace textures with your own ones one-by-one.

Know BSP though there can still be problems (like I mentioned, expected texture size data).

---

Posting And You

sighs
I hate it when I'm almost right.

---

The best things in life, aren't things.

omegaslayer said:
it a texture of of size 10KB when it was expecting a texture of size 145KB - the engine might handle it, but theres a very good chance it doesn't (perfect programmers don't exist).

hmm, I never thought of that.

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

Riven said:

omegaslayer said:
it a texture of of size 10KB when it was expecting a texture of size 145KB - the engine might handle it, but theres a very good chance it doesn't (perfect programmers don't exist).

hmm, I never thought of that.

I believe too this is how you can "hack" the engine to executing malicious code on your system (to install viruses). If say the engine was expecting a texture of size 10KB, and you hand is 11KB, the allocated memory difference of 1KB can contain malicious code can may get executed later when a function returns (Also called buffer overflow).

Disclaimer: I have no actual proof if this bug exists, I've never seen valve's raw source code at this level (the source code that is available isn't as deep as the actual rendering engine), but its my job (literally) to look for these kind of security holes. However I know how certain "hacked" code can cause problems...

---

Posting And You

It's a game ... you should assume it's the most, erroneous, security hole laden piece of software on the planet ... because games are.

Then again, depending on what libraries they're using, there could be automatic protections against basic attacks like buffer and stack overflow and various other injections.

---

Blame it on Microsoft, God does.