File Conflcts are a many spleandored thing of annoyance

[EvilGrins]

Most often when someone hears "file conflict" they immediately think when trying to get on someone's server they get bumped off as one of the files on their system has the same name but is fundamentally different from one on that server. Which happens.

But there's other cases, as this sometimes happens on one's own system.

While I'm very much in favor of not allowing any new map files to overwrite the ones I already have, on occasion a file that doesn't have the same name but does contain a number of the same elements as a file I have causes an indirect file conflict which disrupts any of the maps I already had.

Like that which is now occurring in that screenshot.

Happened toward the end of February and I'm still trying to work out what I added (still grab lots of interesting maps from various sites) that disrupted the texture package of that map.

As previously mentioned, I have to 2 installs of UT on my system... on 2 different hard drives. My original install from back in 1999 (never deleted it) and the more recent one I've been using the last couple decades. That map still looks like it should in my older install (use the original install for compatibility tests) confirming that it's something new I got which made a mess of the one I primarily play on.

[OjitroC]

Open the map in the Editor in your original installation - make a note of the name of the texture package used on those areas. Go to your new install, find the texture package, move it out somewhere and copy in the texture package from your original installation.

Yeah, that's a real pain, as is .utx and .u files sometimes having the same name so the textures don't load as the system files are searched first.

I seem to recollect this map being mentioned before (perhaps you posted a version of it?). I also recollect that I had similar problems with those textures which, I think, I sorted out in the end - possibly by changing them, not sure now, it was quite a long time ago.

[EvilGrins]

Open the map in the Editor in your original installation - make a note of the name of the texture package used on those areas.

Tried that first, didn't work. The file hasn't been disturbed or altered, and as stated on my original installation the map still looks like it's supposed to.

A newer file I added is the issue, if I can figure out what it is and delete it then the map should be restored.

That or I suppose I can manually retexture all the trees and bushes. Whee.

[OjitroC]

Open the map in the Editor in your original installation - make a note of the name of the texture package used on those areas.

Tried that first, didn't work. The file hasn't been disturbed or altered, and as stated on my original installation the map still looks like it's supposed to.

A newer file I added is the issue, if I can figure out what it is and delete it then the map should be restored.

That or I suppose I can manually retexture all the trees and bushes. Whee.

So is there a .u or other file with the same name as the texture file?

What's the name of the map?

[EvilGrins]

That's the thing, I don't know. File conflict may be a file with a different name that has similar elements in it.

I see this sometimes in skinning projects. 2 different skins that have similar stuff inside the .utx which, for some weird reason, in the selection windows you can see stuff from the other skin even if it's not setup that way.

The map with the issues is this one:
https://unrealarchive.org/maps/unreal-t ... dace2.html

[OjitroC]

That's the thing, I don't know. File conflict may be a file with a different name that has similar elements in it.

The Engine will look at package names - it will load all the files necessary for a map (uncomment out DevLoad in your UT.ini and you will see what files are loaded for a particular map) - it won't go through all files looking for classes or .pcx for example.

I see this sometimes in skinning projects. 2 different skins that have similar stuff inside the .utx which, for some weird reason, in the selection windows you can see stuff from the other skin even if it's not setup that way.

Yeah, I get that particularly with the Marine model (of which there is more than one) and, I think, with the SpaceMarine in particular - I also got it with a Female Commando skin where the head had the same name as one of the default FC skins so two head textures were loaded. Here the Engine will read through the .int files and will only load skins which have an .int - so in the case of the FC it found two different skins with one element having the same name and loaded that element.


------------------- SOLVED IT ------------------------

Opened the map in UTPT and saw that JDdeco01.utx has two trees and a treeline texture. Opened up the map in the Editor and ... no textures on the trees and surround/treeline. Looked in the Texture Browser and saw that JDdeco01.utx had not loaded. Clicked on OpenPackage and got a texture of a tractor and something else - just that, no trees

So the problem file is JdDeco01 - I have that in my System folder and possibly you do - move it somewhere else (otherwise the map that uses it won't work) and you should see the textures from the .utx load in the Editor and the trees and treeline should be properly textured.

I now remember having looked at this a long time ago.

[EvilGrins]

JdDeco01 actually has a bit more than that, but the map (when working properly) only uses 2 of them

Should mention I've had this map for about a year, had the Skybox reworked and changed some things around it. It looked perfectly okay up until last month.

This is the full deal:

[OjitroC]

JdDeco01 actually has a bit more than that, but the map (when working properly) only uses 2 of them

Indeed it does but the relevant .pcx here are those used in that map (2 trees and the treeline textures).

So it's working OK for you now?

[EvilGrins]

Yes, everything is running fine again...


...although I'm a little concerned about what that JdDeco01.u file was for, now that it's no longer in the systems folder.

[OjitroC]

...although I'm a little concerned about what that JdDeco01.u file was for, now that it's no longer in the systems folder.

Well, you may find out one day when a map doesn't load - with the error message 'Can't find JdDeco01'

Seriously though that file contains 2 Decorations - a Lantern (an oil lamp) and a Tractor (a red Massey tractor from the 60's(?)) - so decorations for a very specific 'theme' and hence, probably, a very limited number of maps. As far as I know, there is no way to determine which map(s) those Decorations may be used in short of opening every map to look at the dependencies.

So, no, I wouldn't be concerned about it not being in the System folder - just keep it somewhere off the UT path so it can be put back into the System folder should it be required one day.

Oh yeah, in passing - it might be an idea, if you are going to distribute an edit of 7th Hole, to include a Readme informing people that they will need to move JdDeco01.u out of their System folder (should they have that file) as, otherwise, the map won't run.

[EvilGrins]

I'll probably take screenshots of this thread or link to it from my little UT corner of the internet.

Now I gotta wait for my pathing consultant to finish up the current thing he's working on before sending him this to assess and path; mostly works okay but for some odd reason (maybe by ironic design) bots keep getting stuck in the sandtraps.

[sektor2111]

Seriously though that file contains 2 Decorations - a Lantern (an oil lamp) and a Tractor (a red Massey tractor from the 60's(?)) - so decorations for a very specific 'theme' and hence, probably, a very limited number of maps. As far as I know, there is no way to determine which map(s) those Decorations may be used in short of opening every map to look at the dependencies.

Hmmm.... no, me one I don't work this way.
If package has only two classes it will take around 2-6 minutes depending on drive speed and fragmentation to find out in which "*.UNR" file can be found
whatever string concerning class's name. If package would have 20 classes, there would be needed 20 searching tasks - still faster than opening every single map...
This is how I reconstructed from ground Zero a MH server that has MAPS with END and not just throwing files because they were using "MH" prefix... Later I filtered out all maps without Bot Support when I reworked my MH assets and rewriting A.I. stuff. Later I tested them directly for potential extra issues. Still faster than taking everything one by one.

[OjitroC]

Seriously though that file contains 2 Decorations - a Lantern (an oil lamp) and a Tractor (a red Massey tractor from the 60's(?)) - so decorations for a very specific 'theme' and hence, probably, a very limited number of maps. As far as I know, there is no way to determine which map(s) those Decorations may be used in short of opening every map to look at the dependencies.

Hmmm.... no, me one I don't work this way.

Neither do I - to do that would be ... err, silly (to put it mildly)

So how does one search for classes in maps? Like I said, I had no idea that it is possible to do that.

[sektor2111]

Let me show you something - perhaps you'll find it cute...

ValidSelection.PNG

This is what I've learned as computer user - not as a programmer because I'm not an I.T. guy and I don't have such dreams...

Resuming... Mainly files used by UT are not very encrypted, certain strings are in human readable format, classes are not an exception and even can be seen junks of properties used elsewhere, but somehow discarded by UT, which is not that bad...

It would be helpful for community if an IT dude would write a DependencyTracker whatever for figuring if an opened/loaded package has assets that can be found in which maps from a specified folder... this would help in cleaning up large files no longer used because lousy maps were deleted and nothing needs these anymore.

[OjitroC]

Let me show you something - perhaps you'll find it cute...

I do indeed - I don't have that software but have found something similar so thanks for that