So just Change the TextBuffer to Zero and change the names of the Name Table. Am I right?
Yes, you are.
If I'm changing the Name of the entries of the Name Table - Unreal is still able to read the file?
Name table is used for following purposes:
1) names of resources, exported from current package
2) names of resources, imported from other packages (for example, when loading textured mesh, texture link is stored as index in import or export table, which is uses link to name table to describe this resource)
3) some other internal structure of package (all places, where text strings required)
4) identifiers inside compiled scripts
You
cannot modify names, used in 1-3, otherwise package cannot be loaded. But you can modify names, used in 4 - these names are used internally by engine, and engine does not matter, either variable named "AllowDownloadMesh" or "qwerty1"
So what is the point in putting the source inside the package if you don't need it to use the package in game?
There is only one point - to access sources after loading package into UnrealEd. You can edit scripts without rebuilding a whole package.
It would be great to have a .uc file when you export models out of packages.
Only
vertex meshes does require this file, and my tool generates it.
Skeletal meshes imported into packages using UnrealEd's GUI. Only mesh scale and orientation properties are lost while exporting - all other data (animaiton names, frame rate etc) are stored inside psk/psa files.
Support for Undying would be great.
I does not have this game. If I'll get it - probably, I will implement its support.
There is too much Unreal Engine games, I cannot support all of them
Some games are impossible to support - Unreal 2, DeusEx 2. 1st uses strange skeletal animation format, files are stored outside unreal packages
2nd does not uses unreal packages at all - all resources are stored in a raw format.
Maybe you could combine your tool with ushock so the tool would be a universal viewer and exporter.
My codebase is similar to Unreal's one (I'm trying to use similar coding style, I'm using similar data types ... I think, my code can be compiled with unreal engine source
) But Ushock uses STL, it was developed to quickly dig into unreal level format. Its package support is heavily based on
utpackage.pas (simply converted from Delphi to C++). It is possible to adapt Ushock to my codebase, but this work requires time and motivation. This is possible to create new game engine, which will support levels and meshes from Unreal Engine (this game engine automatically acquires EnrealEd - one of the greates tools in whole game development world). But there is no reason to integrate animated mesh support into Ushock.
I found another usefull site here
This page describes unreal's .3d file format, which is not used by game itself.