Errors on maps

[DieHard SCWS]

I found out that there are maps that give an error on the current S3TC textures. The error is either caused by a missing texture or by there is a difference in the name of certain textures.


So far i had it on 3 maps, i only know the name of 2 of them.

DmProng one of my favorite maps.
DmDarkCity-D

If anyone find more maps that have similar errors on the current S3TC textures, please post it in this thread so we can take out/repair the errors.
.
.
.

[Hyper]

I've had version conflicts on more maps, especially the maps of the server Snipers Paradise. But these conflicts can be easily solved by restoring the originaltexture again.

But I also have installed a few of UT's S3TC textures, which can canse extra conflicts on maps designed for UT's original textures I think.

[DieHard SCWS]

The way i solve that problem for now is, i have two Unreals installed, normally i play with an S3TC Unreal, in the rare case i come across such map i just use my normal Unreal for the moment.


But indeed if you want to restore the texture involved, here is an example how to "read" a Critical Error.

DmDarkCity-D

[img]http://www.celticwarriors.net/website/S3TCMedia/CEDmDarkCity-D.jpg[/img]


DmProng

[img]http://www.celticwarriors.net/website/S3TCMedia/CEDmProng.jpg[/img]


In both cases the texture Warpdemo1 and WarpDemo2 are part of the Genwarp.utx package, IceTexture refers to the class, in this case it will have an animated Icy look.


So for both maps above, you simply can restore the Genwarp.utx file


But please post mapnames and the name of the texture, maybe its just this package that causes problems, if so, mayby ill remove it from the downloads.



Just something like this:

Critical Error:
DmProng: Genwarp.utx: DemoWarp1
DmDarkCity-D: Genwarp.utx: DemoWarp2
.
.
.

[Hyper]

My errors were different. Not these crashes but version conflicts on the texture files. (Where it's imposible to enter a server because it uses different textures as you got installed)

[DieHard SCWS]

You mean there are maps in Unreal that use modifief original UT utx files? Well thats a bad thing lol.


I asume these maps are relative new, maybe ask the makers to change the names................

If a map is converted to Unreal, than you always should create new unique utx files, and not use modified original ones.


After all, UT olschool players will have mismatches, thats not good, i wish mapmakers would be much more aware on such things. Not to mention that it does make S3TC users difficult to play.
.
.
.

[TCP_Wolf]

I don't recommend going on RUSH's server anyway.

Tons of downloads, below average quality maps, mods and code pieced and stolen together without giving proper credits to their makers... it's a shame servers like that exist at all!

[Pitbull]

If a map is converted to Unreal, than you always should create new unique utx files, and not use modified original ones.

Personally I like to embed any files right to the map. This way no conflicts will ever happen. Every type of file within unreal can be embedded right to the map.

[DieHard SCWS]

Personally I like to embed any files right to the map. This way no conflicts will ever happen. Every type of file within unreal can be embedded right to the map

And normally you are absolutelly right, but there now is an exception, S3TC textures..............

If you embed textures to make your map is fine, even for S3TC users.

The cool part of creating your own textures for a map is, that you very easely can make the textures for both the normal and S3TC version.

How? well just create them in a size from 1024 x 1024 pixels so you can add alot of detail to it. Than for the normal map scale them down to whatever you need, and for the S3TC version keep them at 1024 and don't Index Color them.


However, when you embed them, you need to make 2 maps with the same name, but with 2 different sets of embedded textures, and since they are different, they will cause a conflict when entering a server running that map


And as said, the cool part of making your own textures is: with virtually no extra work you can create a normal map, but also a true S3TC map.......................


Unnececarelly to mention that this only aplies for the textures, not sound or music.


Its not finished, but i already explain this a bit on this page:

http://www.celticwarriors.net/website/S3TC/S3TCandMapping/S3TCandMapping.htm

And to be sure there is no confusion about this !!!!

If you made a normal map with embedded textures, both a normal and S3TC user can play on that map without any mismatches, you just can't add S3TC textures to it.
.
.
.

[Hyper]

I don't recommend going on RUSH's server anyway.

> I totally DISAGREE to this one.

Tons of downloads

> A GOOD thing in my opinion: Finally a server offering a total new experience.

, below average quality maps

> Well, that's a personal opinion. I played them and I think these maps are awesome, if you like sniper maps.

, mods and code pieced and stolen together without giving proper credits to their makers... it's a shame servers like that exist at all!

> Most stuff has been imported from UT, but for the players it's not an issue where the maps come from, that's something between Rush and the makers of the UT maps, not something the average player should be worried about.

[TCP_Wolf]

Hyper, the last time I was there I found code stolen from me and Smartball without giving me or him credit where it was due! The mod was called "AssualtPro" (yes someone can't even spell correctly there...) and contained EDM and UTF code directly copied and pasted with the credits removed AND PARTLY EVEN REPLACED WITH HIS OWN CREDITS!

Such demeanor deserves no respect whatsoever - and this is not just my personal opinion!

[Hyper]

Interesting. I thought he was just running EDM2. He must have become quite skilled in scavenging. But using code without giving credits is not a good thing indeed.

By the way: He removed EDM again for more than a week now, at least the EDM console. (Which in my opinion a good thing because it created more trouble than it fixed)

[DieHard SCWS]

I took Genwarp.utx out of the packages, this means the packages now also have a version number. Saturday evening (03-26-2005) the updates should have been uploaded)


Btw Hyper i still would like to know some mapnames from maps you had mismatches on. I want to have a look at them.
.
.
.

[Hyper]

I took Genwarp.utx out of the packages, this means the packages now also have a version number. Saturday evening (03-26-2005) the updates should have been uploaded)


Btw Hyper i still would like to know some mapnames from maps you had mismatches on. I want to have a look at them.
.
.
.

I don't know map names, but I know those version conflicts occured at maps at Snipers Paradise. So you might want to test it yourself when you have converted UT S3TC textures instaled.

[DieHard SCWS]

Another package error did surface:

http://www.oldunreal.com/cgi-bin/yabb2/YaBB.pl?num=1137875007/0


In this case its the HubEffects package containing an error, the same here goes for the GenWarp package, better use the original Unreal package. The HubEffect package does not contain any S3TC to begin with, so you will not loose anything by using the original one.
.
.
.

[Kerilkkorn]

Yes, I did not test the package tool with special effect packages recently. Avoid replacing uneeded packages, I can't guaranty a thing. And I don't have the time to fix that for now. Sorry.

[DieHard SCWS]

Yes, I did not test the package tool with special effect packages recently. Avoid replacing uneeded packages, I can't guaranty a thing. And I don't have the time to fix that for now. Sorry.

The packages mentioned so far having troubles with Animated Textures were not created using your merger tool, they both are default UT 2th CD textures converted with your first conversion tool to Unreal.


We did create oné package using Animated Textures, thats the SpaceFX package. We only replaced the normal textures inthere, not the Animated ones. I have uptill now not heard of any problems with that package.


So for that part your merger tool seems to work fine. The only thing i did not try yet was to replace an actual Animated Texture, no clue if the tool will do that properly. And its just a feeling, but i have the idea it will work just fine, mainly because the tool did everything correct so far.


For short, your merger tool is not responsible for the mentioned errors



It still has a hugh memory leak, that can be anoying sometimes, i need to reboot alot  :-/



But if i would ask for any change in the tool, it would prob be the UT compatabillity, i dont play UT myself, but i think it would be a cool gesture to UT people if that would work too, or make an UT specific version merger and keep the two seperate.


But for Unreal, except for the hugh memoryleak it works like a charm so far
.
.
.

[DieHard SCWS]

I decided to do a small test after all, with the GenWarp package, to see if i could replace a Wet Texture inthere.


The result was negative.


In the GenWarp package are two textures from  the crate like in Deck16 that have a wet surface as can be seen in NyLeve on top of the crate by the second elevator.


One texture is called: gw_rusty
The other which contains the Wet part is: Awetx1


First i tried to replace the normal texture gw_rusty


After the merging, the utx file was 2Mb bigger, so the texture was replaced alright, which i expected.


I went in Nyleve but only saw a complete black surface, even when fired upon with the dispersion.


Than i tried to replace the Awetx1 texture, as i expected nothing happened, the filesize did not change.



This to me is obvious, and ill explain:

In Nyleve the texture that has been added to the map is Awetx1, but the Awetx1 does not contain a texture from its own, theres no texture in it. It only contains the effects (the wet movement). Since the merger tool reads the original package and only replaces a texture that is present, this texture does not contain a texture and therefore it cannot replace anything. The merger tool did here what it is supposed to do.


What Awetx1 does is, it "borrows" the actual texture from gw_rusty and projects the Wet part on top of it.


That was the reason why i did add the gw_rusty texture first. Theoretically Awetx1 should "borrow" the now S3TC gw_rusty texture and projects that one ingame.


But as said it stayed black.............


Pure theoratically i dont think at all the merger tool is doing anything wrong, as far as i can see it work just fine and did exactly what was to be expected. It did add the actual texture, and of course its unable to replace a texture that not even there.



Why now its not visible i dont know, maybe internally Unreal is unable to "borrow" S3TC textures.

As said this is highly theoretical, and i could be completelly off there. On the other hand, if i look at all the official UT packages, speciffically the GenWarp and HubEffects which are the only packages with Wet or other animated stuff, than Epic seems to be unable to do that trick either, except that the merger tool from Kerilk seems NOT to give an error




All together it means that those textures at this moment cannot be upgraded, whatever the reason is............................
.
.
.

 

[Kerilkkorn]

For compatibilyty reason it would be best to stick with unreal and unreal generated packages to make S3TC versions. mixing UT and unreal will give error for sure because of incoherent import tables.

The wet texture is a real problem. I'll have to figure something out to fix that, because they HAVE TO BE CHANGED!!!!

I can't stand the floor in Vortex.

Don'y know when I'll have time though.

[DieHard SCWS]

For compatibilyty reason it would be best to stick with unreal and unreal generated packages to make S3TC versions. mixing UT and unreal will give error for sure because of incoherent import tables.

That is wat i ment in the post somewhere above.


Why not make 2 merger tools, oné for Unreal, oné for UT, so i can convert an Unreal package AND an UT package. Meaning 2 different files.


From my point of view, the only thing ill have to do is, pressing the merger tool twice.

If so, the only thing ill ask, have the unreal merger create a folder Unreal instead of Temp, and the other UT, so i dont have to worry about overwriting the one with the other


If it would be possible like that, its simply click, click giving me two seperate files


And yeah i agree, at the end alot of wet textures do line up with other textures that are or will be high res, like the floor you mentioned and the crate i mentioned..........




I did do some further testing and that gave me some weird results, and i have to think and re-test to find out what the results mean. I did check if the Drawscale had any effect on the isue, and it seems it does, though i don't understand the result lol.


If i add a dds file that is exactly the same size as the original(128 x 128), than the crate texture is visible again ? ? ?

For the tests i used a picture from a Nebula, to make sure theres no mistake, and either it should have not showed up at all, or it should have shown the nebula on the crate, but no, it shows the texture of the crate never the less, which than would suggest the crate texture is stored somewhere after all. But it also suggests, that it IS looking at the source texture, its a bit weird lol.


To test this further i should make a package from scratch while adding 512 x 512 pixel textures, so i can test better if the texture is inthere or not.
.
.
.

[BOZO]

Code: Select all

//=============================================================================
// Bitmap: An abstract bitmap.
// This is a built-in Unreal class and it shouldn't be modified.
//=============================================================================
class Bitmap extends Object
      native
      noexport;

// Texture format.
var const enum ETextureFormat
{
      TEXF_P8,
      TEXF_RGB32,
      TEXF_RGB64,
      TEXF_DXT1,
      TEXF_RGB24
} Format;

// Palette.
var(Texture) palette Palette;

// Internal info.
var const byte  UBits, VBits;
var const int   USize, VSize;
var(Texture) const int UClamp, VClamp;
var const color MipZero;
var const color MaxColor;
var const int   InternalTime[2];

The var const int USize, VSize may be something that contributes to the problem with the Fractal Textures. I'm wondering if the internal code operation depends on these values to decide how big the texture is. Even though you are changing the reference texture the Fractal texture still thinks it is normal size according to these settings. I think this is assigned when you create the texture at a particular resolution. Is this being adjusted upwards for the S3TC version of the Fractal Texture also?

[DieHard SCWS]

You could be correct, and no, the merger will not change that setting, it only replaces a texture, so if theres no texture it will replace zero information.


But still, it does not explain all, because i also tried this with a complete red texture, to make sure that even if its scaled wrong, i still would see a red surface, but it shows complete black. While if i change the red texture to the exact size as the original, theres still no red but the crate texture, which should not be possible, as said unless its stored somewhere after all.



Because the difference in filesize cannot be seen if a texture is yes or no in that package, i need to create a package on my own with larger textures. The current textures only show a 1kb/4kb difference in in package size, and this is too small to measure if its now still there or not. That size difference can even change by simply re-saving the file. I need bigger files to test this.

TEXF_P8,
TEXF_RGB32,
TEXF_RGB64,
TEXF_DXT1,
TEXF_RGB24

And that small list, does that represent all supported formats ?


If so, than that explains why i was unable to add DXT3 and DXT5 textures, and does this apply to any texture or just Fractal Textures? If DXT1 is the only DXT support than thats definatelly a pitty, because there are some texture that could have good use for 256 grey Alpha blending.
.
.
.

[Kerilkkorn]

I guess this can be considered as feature...
We might get it with another patch.

[DieHard SCWS]

And as you already said you don't have time at the moment, and that is ok, except the floor an a few other textures, most of them i cannot update at the moment since i have not created the textures for those.



In general, those textures also apear as normal texture in other packages, and those are the packages i work on.



And at this moment i still spend all my time on the SGC map textures, and for the URP i am working on SkyCity.utx, GenEarth.utx, GenTerra.utx and maybe i am gonna update Langs.utx (UnrealGold) since that package does contain a fair share of textures that already have been created for other packages.


So for the Fractal Textures theres no hurry at the moment, ill just hear when you looked into it.
.
.
.

[BOZO]

I can pretty much confirm that DXT3 and DXT5 will not work in Unreal and UT. That compatibility was added for UT2003+...

You know I would try to go in and adjust those const int values with a hex editor to see if that is what is causing the texture replacement at a different resolution failure issue. This should be relatively easy to test out. If I get a chance I will do a bit of testing myself on this issue.

Smirftch could look over the Fractal Texture code and let us know for sure if that is the dependency that is messing the replacement with a different sized texture in this case.

[DieHard SCWS]

I can pretty much confirm that DXT3 and DXT5 will not work in Unreal and UT. That compatibility was added for UT2003+...

Thats definatelly a pitty

Smirftch could look over the Fractal Texture code and let us know for sure if that is the dependency that is messing the replacement with a different sized texture in this case

Can't he implement DXT3 and DXT5 in the 227 patch


Btw, wont the hexeditor create a version missmatch ?
.
.
.