Jump to content

wghost81

Premium Member
  • Posts

    1186
  • Joined

  • Last visited

Nexus Mods Profile

About wghost81

Profile Fields

  • Website URL
    http://wghost81.wordpress.com
  • Country
    Russia

wghost81's Achievements

Mentor

Mentor (12/14)

  • First Post
  • Collaborator Rare
  • Posting Machine Rare
  • Conversation Starter
  • Week One Done

Recent Badges

0

Reputation

  1. Randomly here :) I rarely check the forums, but I do check my mail regularly, so using Nexus PM is an easier way to reach me if needed. Texture replacement was tested with Batman as I did those for Batman modding team. I've only briefly got back to XCOM to see if they work at all, no extensive testing was done, so I imagine there might indeed be issues with different data types that are not used by Batman. If you notice any, don't hesitate to PM me - I can't promise an immediate fix, but at least I will be aware of it. PS I'm not working with Pavonis. Still an independent modder with chaotic activity timings :)
  2. Great :thumbsup: dubiousintent, let me use this opportunity to finally say that you are a pillar of this community. The wiki is a massive work and it's useful not only for XCOM modders but for all the UE3 modders out there. So, from the bottom of my heart - thank you for all these years of making sense of our random posts!
  3. github repo: https://github.com/wghost/UPKUtils
  4. A tutorial on how to mod the textures without texmod with the links to the necessary tools. Work in progress, but at this point it can be considered fairly stable. I will update and link github repositories later. Export procedure was tested with both XCOM:EW and Batman: Arkham Asylum. Import procedure was tested with Asylum only.
  5. He-he :) Didn't expect that myself :) But here I am, back to coding upk stuff. Thanks for keeping the forums alive, I miss this place and the good old times.
  6. It's been a while :smile: I was finally able to finish a project started a very-very long time ago by Drakous79. Thanks to the people from Batman modding community who approached me with the problem of texture modding in that game. I guess, 5 years away give you a broad enough perspective to realize what you've been doing wrong :smile:. First off, Texture2D export data format. UE3 Texture2D object inheritance looks like this: Object <- Surface <- Texture <- Texture2DIts serialized data start with PrevObjectRef (same as everything else) followed by DefaultPropertiesList (see my old docs on upk format). Then come its own data as follows: an empty bulk data chunk (12 zero bytes + 4 bytes of absolute file offset pointing to the MipMapCount) MipMapCount (4 bytes) serialized MipMaps array of MipMapCount elements unknown data Unknown data seems to be just a bunch of memory variables someone had forgotten to exclude from serialization. MipMapCount should correspond to MipTailBaseIdx property defined in DefaultPropertiesList: MipTailBaseIdx = MipMapCount - 1MipMaps are BulkData with 8 additional bytes of SizeX and SizeY: 4 bytes of Flags 4 bytes of ElementCount 4 bytes of BulkDataSizeOnDisk 4 bytes of BulkDataOffsetInFile BulkDataSizeOnDisk bytes of image data (if Flags do not have StoredInSeparateFile or StoredAsSeparateData bit set) 4 bytes of SizeX 4 bytes of SizeY Possible Flags: StoredInSeparateFile = 0x00000001 StoredAsSeparateData = 0x00000040 EmptyData = 0x00000020 CompressedZlib = 0x00000002 CompressedLzo = 0x00000010 CompressedLzx = 0x00000080 If StoredInSeparateFile bit is set, the TextureFileCacheName property defined in DefaultPropertiesList is used to obtain the name of the tfc file (texture cache file) - usually it's 'Textures'. Furthermore, externally stored mipmaps are compressed (usually lzo), so expect CompressedLzo bit being set too. For such mipmaps ElementCount corresponds to uncompressed size, BulkDataSizeOnDisk corresponds to compressed size and BulkDataOffsetInFile corresponds to Textures.tfc absolute offset. SizeX and SizeY contain corresponding image dimensions. If StoredAsSeparateData bit is set, the image data are stored in the same package, but outside of this object serialized data. If EmptyData bit is set, both BulkDataSizeOnDisk and BulkDataOffsetInFile are set to 0xFFFFFFFF and ElementCount is set to zero. There are three interesting parameters defined in DefaultPropertiesList: Format, LODBias and NeverStream. Format is always present and defines texture block compression method. XCOM mostly uses BC1 and BC3 (DXT1/DXT5). LODBias is... well... LOD bias. It defines the number of textures to drop, effectively allowing to limit texture resolution. More info on textures and their properties can be found here and here. For modding purposes it's important to know that for, say, 2k texture you should have 12 mips defined, but LODBias set to 2 will limit the resolution to 512 and cause the first two mips to be dropped (the corresponding BulkData will be empty). Adding those mips back won't do anything unless you also mod LODBias to zero. Be careful here, though, as the engine calculates the final LODBias as a sum of several parameters (see the links above), so do not assume the LODBias value based on Texture2D properties only! NeverStream boolean set to true forbids the engine from streaming the texture out of memory. Mipmaps for such textures are usually fully embedded in a startup package (all the mipmaps for all the LOD levels). So, with this knowledge in mind, what's the problem of modding textures? Well, it's how the cooking is done. The most frequently used textures are not streamable and embedded into just one startup package. Those are easy enough to mod by just replacing their mipmap data. But lots of textures (map tiles, for example) end up being cooked into a dozen of different packages with low-res mips being embedded directly (usually up to 512) and hi-res ones being kept in an external tfc (Textures.tfc). It's done to speed up the loading process. So if we want to alter such a texture, we need to alter all the packages it resides in, plus its Textures.tfc data. Which is... quite a task at a first glance. And this is where we made a mistake 5 years ago: making a PatcherGUI patch file to mod just one texture is a pure pain and it becomes unrealistic if we want to change dozens of textures. And no, Drakous79, my friend, upk lists won't help here ;) What we need is a completely new tool. On the paper the process is simple enough: take an existing texture, export it to a dds file with all the mipmaps, edit and re-import. We can move/resize export object data if needed, we can change default properties, we can even alter the TextureFileCacheName to point at something else (Texture2D is an obvious choice as the property is a NameProperty and thus has to be present in the name table). But we also need to be sure we do it for all the packages that use this texture. Currently, I'm working on a set of tools that allow mass exporting/importing of textures. The first one, ExportTexturesToDDS, is 99.9% ready and can export individual textures or the whole game into dds file(s) creating an inventory file along the way. The inventory file is a simple csv (comma-separated values) file that holds the full names of all the textures found with the list of packages they were found in. Using this list another tool, ImportTexturesFromDDS, can take all the textures you feed it and import them back into all the corresponding packages. At this point ImportTexturesFromDDS can already work with individual textures and mass-import is what I'm working on. Since we can potentially go to higher resolutions, re-importing textures into the existing Textures.tfc doesn't seem to be the way here. Using a new custom tfc file is a better solution. But the problem is that we're working with cooked packages and while modding and testing stuff we're doing it one texture at a time, which complicates things due to Textures.tfc being just a bunch of "dumb" data with no additional information on what they belong to. To address the issue I came up with a custom tfc format that stores metadata on embedded mipmaps in a separate field. Vanilla Textures.tfc format: C1 83 2A 9E "magic" followed by lzo compressed blocks alignment bytes (zero-padding, not used by xcom, used by batman) C1 83 2A 9E "magic" ... etc Custom Texture2D.tfc format: 2B 42 91 53 "magic" 4 bytes of BlockOffset 4 bytes of BlockSize 4 bytes of NextBlockOffset a list of inventory entries C1 83 2A 9E "magic" followed by lzo compressed blocks ... Each inventory entry has the following data: 4 bytes of BulkDataSizeOnDisk 4 bytes of BulkDataOffsetInFile 4 bytes of ObjectNameLength ObjectNameLength bytes of FullObjectName Max block size is 0x8000. When the limit is reached, the tool makes another block and writes its offset to the NextBlockOffset field of the previous block. The resulting macro-structure of a custom tfc looks like this: [metadata block #1] [compressed mipmap #1] [compressed mipmap #2] ... [metadata block #2] [compressed mipmap #N]...Metadata are ignored by the game itself, but are used by the importer to avoid hi-res texture duplication when importing a new texture on a per-texture per-package basis. That's it. I can't promise I'm back, but I will sure finish my work on texture exporting/importing. Linux/Mac users will finally be able to play with military retexture pack :)
  7. Here's my feedback on new design in pictures. Overall impression - design is too wide, too many pictures, layout is not optimal with lots of blank spaces. As a mod author I clearly prefer an old layout as it's much cleaner and gives me easier and faster access to all the information I need. Also, note that screenshots are taken on my tablet, so for mobile devices this layout works even worse than for PCs.
  8. Since I'm still having this problem with my mods, here's a picture: Hope the problem will be resolved for the new site layout.
  9. Was this problem resolved for a new site layout? It was bugging me for a long time, because PayPal page for my native language doesn't provide a language switch and I really don't want to focus on donations in comments section, much less on the description page. Not to mention that donation talks are forbidden by the rules.
  10. Zyxpsilon, I don't want to hijack this topic :smile:, so, please, create another one or ask through PM/Steam. Short answer is: rotation angles are actual angles (per second), but they are restricted by interpolation speed. So if you want to change rotation speed, you need to change both CAMERA_ROTATION_SPEED and interpolation speed. Same goes for zoom in/out speed. Also, the mod uses exponential smoothing to calculate per second values for both rotation and zoom, so it will look like "stepping" for the first few seconds, but will rotate/zoom smoothly after all the values stabilize.
  11. Sadly they've implemented something similar to the first version of Strip Weapons mod and the button simply equips default weapons to all soldiers. So, I won't be taking down my mod, because latest version removes only actually upgraded weapons and leaves customized but not upgraded weapons in place. But I will update it to use native button instead of adding new one. Also, it looks like ini files are no longer merged, hence the problem with old ini under My Douments containing ModClassOverrides entries. In case of any update it's best to just delete all your ini files and let the game to rebuild them from scratch.
  12. Try this method: http://forums.nexusmods.com/index.php?/topic/3786040-uninstalling-mods-kind-of-some-of/
  13. Just for the reference: UE3 configuration files.
  14. We need Dubiousintent for XCOM2 wiki :) We got so lazy with him handling wiki stuff or us with EU/EW :)
  15. Thanks! Edit: Added manual install instructions to help the wiki. ;)
×
×
  • Create New...