ZylonBane on 31/12/2008 at 21:47
Ugh, a potential problem just occured to me-- conflict between the custom animation script and the built-in animation system. That would suck to have to include an entire duplicate set of textures without the underscore in the filenames.
Nameless Voice on 31/12/2008 at 22:32
That's what I was just thinking.
Well, in any case, it's not much of an issue until someone takes on the much larger task of adding the animated brush screens to the unstripped missions.
Edit: Okay, I looked into using Telliamed's automated texture-swapping tool, but there's a problem with it.
The tool takes a list of textures in the format oldfam/oldtexture newfam/newtexture scaleoffset uoffset,voffset, and the problem is that the uv offset it takes is a fixed value and not a scaler.
For example, if a texture is 64x64 and has a UV offset of 8,8, then replacing that with a 256x256 texture would involve giving it a scale factor of -2 (halve the space taken up twice), and then multiplying all the UV offsets by 4, to be 32,32. The program doesn't do this scaling part.
Telliamed supplied the source code, however, so it should be easy enough to fix.
ZylonBane on 31/12/2008 at 23:05
Since Dark bases the lightmap scale off the underlying texture scale, I'd always assumed that independently twiddling the texture scale would cause Horrible Things to happen.
It would be nice to be proven wrong on this.
Nameless Voice on 31/12/2008 at 23:22
Telliamed's tool only adjusts the scale and UV mapping on the brushes themselves, not in the world rep. In other words, you still need to reportalise afterwards, so it won't break the lightmapping but it also won't work on stripped missions.
I modified the program to automatically realign the textures based on the scale factor, and it seems to work flawlessly now. I just need a list of old texture to new texture mappings and scale factors. This is the mapping file that I was experimenting with:
Code:
tech\b64 techw\b64 -1
tech\p0022 techw\p0022 -2
tech\p0021 techw\p0021x -2
tech\p0015 techw\p0015x -3
tech\p0036 techw\p0036x -2
tech\p0034 techw\p0034x -2
tech\p0011 techw\p0011x -2
tech\p0010 techw\p0010x -3
tech\p0020 techw\p0020x -2
tech\p0024 techw\p0024x -2
tech\p0025 techw\p0025x -2
tech\p0023 techw\p0023x -2
(-1 means the texture is four times the size (2x in both directions), -2 means it's eight times the size, and so on.)
ZylonBane on 1/1/2009 at 00:33
Ah, I was thinking it worked on stripped levels. Still nifty though.
I believe I can generate a mapping file like that. As part of this project I built a spreadsheet with much of the necessary information already compiled. I'm guessing a step that can't be automated is setting the custom animation rates. That shouldn't be too bad though-- if I understand the way DromEd works, the ones with doubled animation rates can be fixed by just changing the tech screen archetype, and there's only a handful with non-doubled rates.
A more time-consuming problem is that, with actual legible text, it's going to be very obvious that a lot of the tech textures were applied rather sloppily. There are tech textures that are backwards, sideways, upside-down, misaligned, you name it. These will require manual adjustment.
Nameless Voice on 1/1/2009 at 01:04
Right, modifying the animation rate for all screens should be simple enough, or even just modifying the global texture animation rate (which would affect the animated Many textures, too) - I think SecMod did the latter.
ZylonBane on 1/1/2009 at 01:56
But it's important to note that a few textures still need to run at the original speed. And there are various fixes/improvements that can be rolled into the process, like fixing the "green concentric circles" animated texture being unbreakable.
This is definitely an area that will need solid documentation for the full release.
Nameless Voice on 1/1/2009 at 02:02
Another one of Telliamed's DarkUtils, ObjTree, might of use here - you can use it to read .xml files of archetype changes and apply them to a gamesys. That utility is not very reliable, though. My experience with it was that sometimes it would decide not to read an .xml file, but if you split it into multiple .xml files with maybe 1-2 archetypes each, it would read them without a problem. Not quite sure why, it didn't seem to be based on length.
Enchantermon on 3/1/2009 at 17:50
Quote Posted by ZylonBane
That is, unfortunately, correct. The best we can practically do for the stripped levels is create new high-framerate textures at the original resolutions.
Meh. Thought so.
Quote Posted by ZylonBane
The best we can
impractically do is reproduce those levels from scratch. But that would require a huge investment of time and effort.
Indeed; especially with such a small fanbase.
ZylonBane on 3/1/2009 at 18:07
Quote Posted by Enchantermon
Indeed; especially with such a small fanbase.
Don't underestimate the size of it. SS2 is one of the true classic PC games. I don't doubt there will still be people playing it for the first time decades from now.
But speaking of the unstripped levels... exactly which ones do we not have access to?
