I created some decal actorsd and then imported the tga files. and saved them to my packages.
When i reload ut3e it says Cant Find File for package. Do i have to store the files somewhere,?/
I saved the decal actors once id imported the TGA files???
I created some decal actorsd and then imported the tga files. and saved them to my packages.
When i reload ut3e it says Cant Find File for package. Do i have to store the files somewhere,?/
I saved the decal actors once id imported the TGA files???
I don't have the editor installed on this PC, so I can't get too exact here.
If you aren't importing your textures/meshes into your map file, you need to make sure you save your new package in the proper hierarchy. I'm not sure of the exact structure, but if I remember correctly, you need to 'Save As...' your package in with the other Epic packages in your root install directory.
If I'm making a map, I save the custom assets inside the map package itself. That way, you don't need to mess around with other packages; you just have your map, and that's it.
I understand there are quite a few negatives to having it all stored in one big map, but I always take that route simply because it keeps things less complicated. If you don't mind dealing with the large map size or having your assets readily available for other maps, I'd just keep it inside the map package itself.
While we're on the topic, can someone more knowledgeable than me maybe go into detail a bit more as to the pros/cons of saving all your assets into the map file itself? I understand the filesize gets larger and I'd imagine that effects map loadtimes, but what are some of the specifics?
Also, what is the purpose of the MAPNAME_LOC_int.upk file that is generated when you publish a map?
Sorry for the thread highjack; it seemed like a relevant place to ask.![]()
UT3 PC Tag: Mapper724
Plssss Help..lol
Someone must know whos made graffiti decals for a wall
The reason it's good is because it keeps everything together, and no need for a whole handful of files floating around (think of when someone downloads a whole heap of maps, it keeps it easier to manage for them too).
I don't see any real negative of the filesize, one way or another you're going to use the same amount of space anyway, so shouldn't effect load-times at all. (many of my uncooked maps can get to be around 150mb+).
On a side-note, make sure you clean out your autosave folder every now and then (I ran out of hard-drive space and didn't know why until I finally looked there and found over 10gig of autosaved files I didn't really need anymore!)
Remember you can keep your assets in Groups to keep it in order. (this is just myself, but I usually have a "meshes" and "materials" and "textures" group in my map file. Sometimes I might have more for specific things, for example "meshes_outside" and "meshes_inside". Use your own system, whatever way you find easier to manage / keep sorted) - this probably mostly applies to using a lot of custom imported stuff.
I'll start by saying I'm no expert on this, but I'm pretty sure that file keeps a record of all the assets used in your map and where to find them (either in your map file, or another package, or in Epic packages for example)
The "int" is for International and just means you could have the same map file but with some differences specifically for another language for example.
(might point to a different package with another version of a texture with text on it - a similar texture but in another language for example)
Generally, you don't have to worry about this file (just make sure you copy it with your cooked map). Unless of course you want to support another language specifically.. (I have no experience there)
When you make your package name for your stuff, just use the name of the current map, eg Shootemup_beta_021 and wehn you resave the map to Shootemup_beta_022 they will automaticly be saved to that new name too!
One thing, you should compress your textures from tga to dxt5 (or dxt3 if you have only fully opaque and fully transparent regions.)
As sneh said groups is very very useful - its in the properties of averything you stick into the map, even a bsp brush. You give things a group name, eg. buildings, and then you can go into view and check only the groups you want to see so you could uncheck buildings and poof they aren't visible in tha window and you can see the roads and trees for example then just as if you'd never stuck them into the map. (EDIT-> sorry this is a different type of group, sneh was talking about naming stuff in packages, sorry)
Thanks sneh.![]()
What do you mean by "my packages"?
For community maps you should be specifying the map file name for the Package on the Import dialog. This places all imported content directly into the map file.
In other words, on the Import dialog for the Package use your map file name or use the combo drop-down to pick your map file name. For the Group, use something logical such as Textures or Meshes or Decals or whatever. And adopting a good asset naming convention is a smart idea such as TX_RedBrick_D for a texture of red brick that is the diffuse, look at Epic's packages for an example.
Make sure that you are creating backup copies of your map often. That way if you import a bad asset, you won't lose all of your work.
I create backup copies with numbered name suffixes (ie. 001, 002, 003, ...) one or two times each day when I am working on a map.
You shouldn't be using external packages.
For community content, only large mods or TC's should consider using external packages if there is a lot of shared content between maps or if they want to support other-user-created content, ie. letting community people map for their TC later.
Not true.
When you cook your map most of the content from all of the referenced external packages is duplicated into the map file to make it seek-free. For single community maps this makes using external packages essentially a bad idea.
Cooking a map to be seek-free will make it larger anyway, regardless of whether you import everything into the map or use an external package, since much of the external package will be duplicated into the map file.
Well that excludes me then...
bye...
Pros: many
Cons: none
For one-off community maps you always want to put all of the custom content into the map file. This will make the map load faster and will prevent the redundancy of duplicated assets between an external package and the seek-free cooked map.
AFAIK it should be just the localization strings for any specific objects that have string data that were duplicated to the map when it was made seek-free. I couldn't find anything specific on this in the licensee area. Localization strings are to support different languages. AFAIK LOC and .ini files are not required for a cooked map to work.
It will prevent package versioning issues as well.
Cooking seek-free will duplicate much of the external package into the map file anyway. So using an external package actually makes the entire set even larger. In other words, a single all-in-one cooked map file will be smaller than the combination of a cooked map with an external package.
Localization only has to do with strings, ie. language differences. So displayed hud text, class error messages, etc. need localization.
Asset pointers such as package.group.texture do not require localization, otherwise you would have to rename your package to the other languages besides the one you created it in.
Textures will always be automatically compressed unless you choose the Defer option on the Import dialog, in which case it is then compressed when you save the file.
Last edited by DGUnreal; 07-11-2008 at 04:19 PM.
DG... I... I think I love you.
Manlove aside, thanks for the corrections; I took level design in post-secondary and our teacher taught that it was good practice to use external packages as much as possible. Granted, this was UT2k4, so a lot may have changed... or he didn't quite know what he was talking about, at least in regards to community mapping. He may have been teaching more in regards to TC. In 2k4, I always just stuck it in the MyLevel package because I hated the hassle, and my Unreal3 habits are the same. Luckily, it's designed that way this time around.
Thanks for setting the record straight.
Last edited by Kibbler; 07-11-2008 at 07:09 PM.
You're welcome (I think...)
Even with UT2004 custom content should be in the map file (myLevel in the case of UE2). This reduces dependancies, package version errors, multiple package file access on load, etc.
The only time external packages should be used is if you want other people to also use that content in their maps, such as TC's.
With UE3/UT3 things are even more this way due to what cooking does.
Bookmarks