No announcement yet.

Fix for the old missing cubemaps error

  • Filter
  • Time
  • Show
Clear All
new posts

    Fix for the old missing cubemaps error

    Issue: Missing cubemaps, from the file "AW-Cubes.utx"

    Lines like this commonly found in your log files.
    Warning: Missing Cubemap Cubemap AW-Cubes.Cubes.PS_Cube
    Warning: Missing TexEnvMap TexEnvMap AW-Cubes.Cubes.SunC

    Warning: Missing Cubemap Cubemap AW-Cubes.Cubes.MesaEnv2
    Warning: Missing Cubemap Cubemap AW-Cubes.Cubes.MesaEnv1

    I have only just discoverered this error, as I only just started editing with UEd3, since the drive with my main copy of UT99 (where I have all the current stuff I'm editing).

    I am quite surprised that no-one has ever found a fix (other than to just say "ignore it").
    Not good Enough for me

    Well after a few minutes of hunting and file-swapping, I found them!
    They are in....

    A quick test, of duplicating the offending cubemaps, across to the place where they are being referenced solves the issue of the errors (on loading a map), but the internal palette entries do not match, so I could not make them work without creating a new error
    To correctly fix this, requires exporting and re-importing all the missing bits, and making a new texture package.
    Again though, I think there may be an issue with the palette, as I cannot work out how to export/import just a palette.

    Alternatively I think it would be best solved if possible, with a patch or script to hook the calls and re-direct them to the alternative texture pack.

    Currently I may be able to muddle through the first option, but it would be better done by someone with real understanding of the implications of the fix, and more experience with UEd3.

    Alternative, alternative fix!
    The missing cubemaps seem to be mostly a problem with Vehicles.
    Try setting the mesh in your suspect VehicleFactory to "None" (The vehicles spawned by it will still work, but it makes it a pain in the editor).
    It looks like at some point in production Epic decided to move the vehicle textures to the other file, so the issue has been propagated by people "copying and pasting" vehicle resources from the UT originals, or using original textures.
    I am guessing in all these years, certain vehicles have never had the right reflections or metallic effects.

    Q: If this was fixed, would all these vehicles now look odd or fixed?

    I'm familiar with the errors. I have come to the conclusion that it's from Epic or Digital Extremes adding to a .utx file without loading the entire package and susequently saving it causing textures to be removed from the pacakge and thus causing errors. I kind of figured that out becasue I made that mistake myself recently.

    I think the best thing to do is use the "in use" tab in your texture browser and find the offending shaders. Then duplicate those shaders to myLevel, and replace the specular (or selfIllumination) with a new cubemap/environment map texture that is either in the game somewhere stock, or something imbedded in myLevel for the particular level. I've ran into the issue in the past, and really once you save the references as null, it really has no effect on anything as far as I could tell. THere are indeed a lot of shaders in the game that apparently used these cubmaps, but they're few and far between and can be fixed with a little myLevel work. (obviously using the improved/fixed myLevel shader instead)

    I was looking at some of the shadesr for vehicles and did not see the package in question in use in any of those shaders. There might be an easy fix that would work well for future levels. Modification of existing packages is a huge NO-NO. It's something epic could have possibly patched, but we're way beyond those days now.

    It may be possible to "rework" all of the vehilces in various ways. The best thing might to be to make a mutator called "ons fixer upper" or something. Go in and re-wrok all the shaders, and maybe even improve them visually and make the mutator essentially replace the textures used for the vehicle meshes. This may require creating new animation/static mesh files as well in addition to a new .utx package.

    There would be several possbilities on fixing this, but are you absolutley sure it's related to vehicles? I know for sure it's not limited to the vehicles. I've made a quite a few levels in the past that had the missing Aw-Cubes or whatever and I never make ONS maps or use vehilces in my levels.


      I'll do a bit of a break-down.
      (I'm still very new to UEd3)

      I was tinkering with a VCTF map (from the AirPower3.2 mod), and added some new vehicles from ZenCoders Advanced Armour and the XS vehicles pack,
      Using it's Generic all-gametypes vehicle factory spawner.
      The map has plenty of standard vehicle meshes in it, which I guess don't have a problem.

      Upon re-opening the map to edit I saw the errors.
      When I removed the new vehicles it went away. (Maybe I should have just changed the skin)

      The vehicles must be using an old texture that is still pointing at obsolete entries (not obsolete, just moved).
      The developers would not be able to link a resource that does not exist, so it must be through re-use/duplication of an old one that does (it could well be just 1 single texture that is at fault!).

      I'm guessing the problem generally shows up in maps with certain metallic reflections on meshes that use the offending texture (whichever it is), which is more likely to be used on a metal vehicle.
      If this is how it has propagated then it could be far more common than I first thought (I wish I had been using UEd back in 2004, or a Beta tester)

      I don't actually think a re-built AW-Cubes.utx file would cause any problems. I am a big fan of replacement texture packs
      Looking through various redirect sites, I have already found 3 different versions of this file in use
      The real one, the one from UT2003 and a small one that has all the entries, but they are all empty (obviously done for speed).

      I favour a hook to capture and re-direct calls from;
      Cubemap "AW-Cubes.Cubes.PS_Cube" to "X_AW-Cubes.Cubes.PS_Cube"
      TexEnvMap "AW-Cubes.Cubes.SunC" to "X_ AW-Cubes.Cubes.SunC"
      Cubemap "AW-Cubes.Cubes.MesaEnv1" to "X_AW-Cubes.Cubes.MesaEnv1"
      Cubemap "AW-Cubes.Cubes.MesaEnv2" to "X_AW-Cubes.Cubes.MesaEnv1"

      These resources do exist. just in the wrong file.


        Originally posted by Dr.Flay View Post
        Upon re-opening the map to edit I saw the errors.
        When I removed the new vehicles it went away. (Maybe I should have just changed the skin)
        This could have happened possbily because you opened the map, and once you hit save the resources are saved as null and are no longer an issue thus returning no error. To test this further, I would put a copy of each vehicle factory indivdually into a test level. First add only a manta then save. Reopne the map and see if there's any missing resources. Then add a scorpion and recheck...and so on. I know the exact materials you are reffering to.

        I'm guessing the problem generally shows up in maps with certain metallic reflections on meshes that use the offending texture (whichever it is)
        This part above is correct for sure.

        which is more likely to be used on a metal vehicle.
        I would not be so sure about the above statement. I see a lot of "metalic" shaders that do not use a cubemap/environment map as a source of the "shine," but rather use self illumination to achieve a similar effect. Check out the Manta or Cicada shaders and you'll see an example of what I mean.

        This requires more research from what you've said so far in relation to the vehicles. The fact that you pulled the stuff from a VCTF map is suspect. You gotta go completely stock to see what the deal is. The vehicles clearly do not have metalic shine on them inGame, but that doesn't mean they were not intended to.


          Groovy man, this is just the sort of feedback I need.

          I have used the map many times over the years as my testing-ground for stuff, as it is a big, open area that gives me plenty of time to find, and get in and out of vehicles.

          I've only recently started to actually edit them into the map, rather than summon them before I start playing.
          So far it has only shown up with vehicles as I have yet to change or add any decorations or meshes.

          BTW the older AirPower v3 mod just uses the standard vehicle skins and has not given me an issue yet, as I have not added anything standard-ish yet !
          It is only since adding custom meshes, which leads me to believe that (as I have the included textures installed) people have copied and pasted resources from a particular original file.

          I should point out I am somewhat OCD as I am blessed with Asbergers syndrome, so I like to tear things apart to see why they do or don't work.
          I get lots of requests to Beta test peoples stuff, as I try my hardest to break it, but with the knowledge of how I broke it. Hehehe.
          Wish I had the time for it all !

          I will be hammering this one down, coz it is annoying me

          BTWx2 (side-note) I have discovered since editing (improving) ini and int files for UT99, that I can do the same with 2k4.
          I prefer to edit the UT configs via the old Advanced Preferences window, but since it is hidden no one uses it.
          I have been editing my installed mutators etc. so they show up there, and can be configured quickly and easily without having to close and re-open Unreal** because I've added new monsters etc.
          At some point I'll be posting these elsewhere, in the same way I have been for UT99.


            I meant to come back sooner.
            Windows !
            It's bloody glass reflections!
            Either that or I've changed something else as well
            The windows on the vehicles are shiny now, so I was looking at the wrong vehicles to begin with. I should have been looking at the helicopters and planes, not the tanks and stuff.