- Extract Thinapp Dat File Xml
- Extract Thinapp Dat File Online
- Extract Thinapp Dat File Extractor
- Extract Thinapp Dat File Download
- Extract Thinapp Dat File Rar
- Extract Thinapp Dat File Folder
ThinApp Instructions. To use the ThinApp version, create a SpecsIntact folder under 'My Documents', once the folder has been created, unzip the two files into the newly created SpecsIntact folder. To use SpecsIntact, open Windows Explorer, browse to the SpecsIntact folder located under 'My Documents', and double-click on the SpecsIntact32.exe file. To handle larger packages, VMware ThinApp created a separate.dat data container when the estimated size of a data container is over 200MB. This resolves an issue in which Windows Explorer might not show icons for large executable files. ThinApp MSIs for package.
The Setup Capture wizard starts the capture process by scanning the system to assess the environment and create a baseline system image.
Therefore, a clean Windows machine must be used to avoid the application installer to skip files and registry keys already present on the machine.
Create a system image before the application installation
- Build a clean machine using the client corporate image and install ThinApp (a virtual clean machine can also be used)
- Download the application to capture and copy it to the clean machine.
- Close any applications that might change the file system during the capture process.
- From the desktop, select Start > Programs > VMware > ThinApp Setup Capture.
- (Optional) In the Ready to Prescan dialog box, click Advanced Scan Locations to select the drives and registry hives to scan. Another location than the C: drive might be scanned if application is installed in a different drive. In rare cases, you might want to avoid scanning a registry hive if you know that the application installer does not modify the registry.
- Click Prescan to establish a baseline system image of the hard drive and registry files.
.
.
.
You can install the application to virtualize before the Setup Capture wizard rescans the system and assess changes from the initial system image.
Install the application and rescan the system
- When the Install Application page appears, minimize the Setup Capture wizard and install the applications to capture. If the application needs to restart after the installation, restart the system, the process restarts the Setup Capture wizard.
- (Optional) If you are capturing Internet Explorer, in the Install Application page, click Internet Explorer, to complete additional steps before installing the browser.
- (Optional) Make any necessary configuration changes to comply with your company policies.
- (Optional) Start the application and respond to any messages for information before you continue with the Setup Capture wizard. If you do not respond to any messages at this time, each user who uses the application must do so during the initial start.
- Close the application.
- Maximize the Setup Capture wizard, click Postscan to proceed with another scan of the computer, and click OK to confirm the postscan operation. ThinApp stores the differences between the first baseline image and this image in a virtual file system and virtual registry.
.
.
.
Entry points are the executable files that act as shortcuts into the virtual environment and start the virtual application. The entry points you can choose from depend on the executable files that your captured application creates during installation.
For example, if you install Microsoft Office, you can select entry points for Microsoft Word, Microsoft Excel, and other applications that are installed during a Microsoft Office installation.
During the build process that occurs at the end of the Setup Capture wizard, ThinApp generates one executable file for each selected entry point. If you deploy the application as an MSI file or use the thinreg.exe utility, the desktop and Start menu shortcuts created on user desktops point to these entry points.
Entry Points for Troubleshooting
ThinApp provides entry points to troubleshoot your environment.
Debugging an application might involve the following entry points:
- cmd.exe – Starts a command prompt in a virtual context (to view the virtual file system).
- regedit.exe – Starts the registry editor in a virtual context (to view the virtual registry).
- iexplore.exe – Starts iexplore.exe in a virtual context (to test virtualized ActiveX controls).
Entry points start native executable files in a virtual context. Entry points do not create virtual packages of cmd.exe, regedit.exe, or iexplore.exe.
If you cannot predict the need for debugging or troubleshooting the environment, you can use the Disabled parameter in the Package.ini file at a later time to activate these entry points.
Set entry points in the Setup Capture wizard
- On the Entry Points page, select the check boxes for user-accessible entry points.
- (Optional) To debug your environment, select Show entry points used for debugging check box to display the iexplore.exe, regedit.exe, and cmd.exe troubleshooting options.
.
.
.
You can use VMware Horizon Application Manager to manage the deployment and entitlement of ThinApp packages.
Usually, that option is not used; clients prefer tools like LANDesk or SCCM
.
.
.
ThinApp can use Active Directory groups to authorize access to the virtual application. You can restrict access to an application to ensure that users do not pass it to unauthorized users.
Set user groups in the Setup Capture wizard
- Select Everyone, or select Only the following Active Directory groups and click Add to specify Active Directory object and location information
- (Optional) Change the message that appears for users that ThinApp cannot authorize.
.
.
.
Isolation modes determine the level of read and write access to the native file system outside of the virtual environment. You might adjust isolation mode settings depending on the application and the requirements to protect the physical system from changes.
The selection of isolation modes in the capture process determines the value of the DirectoryIsolationMode parameter in the Package.ini file. This parameter controls the default isolation mode for the files created by the virtual application except when you specify a different isolation mode in the ##Attributes.ini file for an individual directory.
The selection of a directory isolation mode does not affect the following areas:
- ThinApp treats write operations to network drives according to the SandboxNetworkDrives parameter in the Package.ini file. This parameter has a default value that directs write operations to the physical drive.
- ThinApp treats write operations to removable disks according to the SandboxRemovableDisk parameter in the Package.ini file. This parameter has a default value that directs write operations to the physical drive.
- If you save documents to the desktop or My Documents folder, ThinApp saves the documents to the physical system. It sets the isolation mode in the ##Attributes.ini files in %Personal% and %Desktop% to Merged even when you select WriteCopy isolation mode.
Applying Merged Isolation Mode for Modifications Outside the Package
With Merged isolation mode, applications can read and modify elements on the physical file system outside of the virtual package. Some applications rely on reading DLLs and registry information in the local system image.
The advantage of using Merged mode is that documents that users save appear on the physical system in the location that users expect, instead of in the sandbox. The disadvantage is that this mode might clutter the system image.
When you select Merged isolation, ThinApp completes the following operations:
- Sets the DirectoryIsolationMode parameter in the Package.ini file to Merged.
- Sets up exceptions that apply WriteCopy isolation to the following directories and their subdirectories:
- %AppData%
- %Common AppData%
- %Local AppData%
- %Program Files Common%
- %ProgramFilesDir%
- %SystemRoot%
- %SystemSystem%
- Between the prescan and postscan capture operations, assigns Full isolation mode to any directories that the application creates during the installation.
Applying WriteCopy Isolation Mode to Prevent Modifications Outside of the Package
With WriteCopy isolation mode, ThinApp can intercept write operations and redirect them to the sandbox. WriteCopy isolation mode can be used for legacy or untrusted applications.
Although this mode might make it difficult to find user data files that reside in the sandbox instead of the physical system, this mode is useful for locked down desktops where you want to prevent users from affecting the local file system.
When you select WriteCopy isolation, ThinApp completes a number of operations:
- Sets the DirectoryIsolationMode parameter in the Package.ini file to WriteCopy.
- Sets up exceptions that apply Merged isolation to these directories
- %Personal%
- %Desktop%
- %SystemSystem%spool
- Between the prescan and postscan capture operations, assigns Full isolation mode to any directories that the application creates during the installation.
.
.
.
The sandbox is the directory where all changes that the captured application makes are stored.
The sandbox is runtime modification storage and is not a cache. The next time you open the application; those changes are incorporated from the sandbox.
When you delete the sandbox directory, the application reverts to its captured state. You might delete a sandbox when an application has a problem and you want to revert the application back to the working original state.
You can deploy the sandbox to:
- A local user machine : If you deploy the sandbox to a local machine, use the user’s profile as the sandbox location. The user’s profile is the default location because of the write access.
- A mobile USB device : A portable device location is useful to keep the sandbox data on the device where the application resides.
- A network location : A network location is useful for backing up the sandbox and for users who log in to any computer and keep their application settings. Use the absolute path to the location.
.
.
.
To improve ThinApp support for applications, VMware uses the capture process to confirm whether to collect anonymous data about deployed ThinApp packages.
The data includes the application start time, total running time, and number of runs for the application.
.
.
.
Setting up the project involves determining the inventory name and the project location.
- The inventory name facilitates internal tracking of the application and determines the default project directory name. The inventory name appears in the Add / Remove Programs dialog box for Windows.
- Change the directory where you want to save the ThinApp project.
.
.
.
The package is built from the project files, it’s a .exe or .msi file used to run or deploy an application.
Defining the Primary Data Container
The primary data container is the main virtual application file that includes the ThinApp runtime and the read-only virtual file system and virtual registry. It is a .exe or a .dat file.
To identify the primary data container after you capture an application, check the ReadOnlyData parameter in the Package.ini file.
- If the size of the primary container is smaller than 200MB, ThinApp creates a .exe file as the primary container. If the size of the primary container is larger than 200MB, ThinApp creates a separate.dat file as the primary container.
- If you select a .exe file to override the default .dat file when the size of the primary container is between 200MB and 1.5GB, ignore the generated warning. Selecting a .exe file enables all applications to work properly but might prevent the proper display of icons.
- If you cannot select a primary data container, type a primary data container name to generate a .dat file.
Generating MSI Packages in the Capture Process
You can capture an application and deploy it as an MSI Windows installation package. The MSI installation places the application in the C:Program Files directory.MSI packages automate the process of registering file-type associations, registering desktop and Start menu shortcuts, and displaying control panel extensions.
Compressing Packages in the Capture Process
Compressing a package in the capture process decreases the size of an executable package but does not affect MSI packages. Compression can reduce the on-disk storage requirement by 50 percent but slows the application performance when ThinApp uncompresses initial blocks.
.
.
.
By clicking the Save button, the Setup Capture tool create projects files before creating the package.
It is preferable to save that project files before creating the package. Saving the projects files allows using them later if you want to modify the package (for troubleshooting for example).
.
.
You can adjust project files and build the application for deployment.
- Edit Package.ini allows modifying application parameters for the entire package.
- Open project folder allows browsing ThinApp project files in Windows Explorer.
Click Build to build an executable package or MSI package containing the files you installed.
.
The package is created in the bin folder.
You can rebuild the package at any time to make changes with the build.bat file in the virtual application folder.
.
.
You can modify the Package.ini file to update the overall package. The file resides in the captured application folder. The following parameters are a few examples of settings that you might modify:
- DirectoryIsolationMode – Sets the isolation mode to Merged, WriteCopy, or Full.
- Merged: Applications can read and modify elements on the physical file system outside of the virtual package.
- WriteCopy: ThinApp intercepts write operations and redirect them to the sandbox
- Full : ThinApp blocks visibility to system elements outside the virtual application package. This mode restricts any changes to files or registry keys to the sandbox and ensures that no interaction exists with the environment outside the virtual application package. Full isolation is not advised in Package.ini file because that mode blocks the ability to detect and load system DLLs. You can use Full isolation mode as an override mechanism in the ##Attributes.ini files.
- RegistryIsolationMode – Sets the isolation mode to Merged, WriteCopy, or Full for registry. ThinApp sets the initial registry isolation mode to WriteCopy. That parameter is not included by default in the Package.ini file but can be added in the [Isolation] section. The parameter is not included in the Package.ini file because it’s not advised to set it to Merged or Full. Exceptions can be set in the HKEY_LOCAL_MACHINE.txt and HKEY_CURRENT_USER.txt files.
- FileTypes – Lists file extensions to be associated with an executable file. It’s possible either to add or remove extension files by listing them in the Package.ini file.
- Protocols – Same as FileTypes, but for associated protocols
- ExcludePattern – Allows excluding files or directories during the application build process. You must add a [FileList] heading before this parameter entry (see Package.ini Reference.pdf)
- Icon – Specifies the icon file to associate with a generated executable file. It’s possible to set a specific icon using a .exe file or .ico file (see Package.ini Reference.pdf)
- RetainAllIcons – keeps all of the original icons of the executable file
- AccessDeniedMsg – Contains an error message to display to users who do not have permission to run a package. That parameter is located under [BuildOptions] section. (see Package.ini Reference.pdf)
- PermittedGroups – Restricts use of an application package to a specific set of Active Directory users. That parameter is located under [BuildOptions] section. (see Package.ini Reference.pdf)
- UACRequestedPrivilegesLevel – Specifies privileges for programs requiring UAC information. If you do not specify privileges, ThinApp does not assign a default value but operates according to the asInvoker setting. That parameter is located under [BuildOptions] section. (see Package.ini Reference.pdf). You can use the following values to specify privileges:
- asInvoker (uses the user profile)
- requireAdministrator
- highestAvailable (uses the highest available privilege that can avoid the UAC)
- DisableTracing – Block standard .trace file generation to hide the application history
- LogPath – Sets the location to store .trace files during logging activity
- Version.XXXX – Overrides application version strings, or adds new version strings in the Version tab of Windows properties.
- Shortcuts – Lists the locations where the thinreg.exe utility creates a shortcut to a virtual application. If you add shortcut locations, use semicolons to separate the entries.
- InventoryName – Allows to change the inventory name of the package
- SandboxNetworkDrives – Specifies whether to redirect write operations on the network share to the sandbox.
- COM objects and DLL can also be managed using parameters (see Package.ini Reference.pdf).
- Virtual software dependencies can be managed using the Application utility (see Package.ini Reference.pdf).
- MSI settings can be specified with the MSI utility. It’s possible to specify icon in add / remove programs, the MSI name, the AllUser setting, manufacturer, InstallDir, ProductCode, ProductVersion… (see Package.ini Reference.pdf)
- Sandbox settings can also be changed using the Sandbox utility (see Package.ini Reference.pdf)
- DisableCutPaste – Disable the cut and paste option in the ThinApp application
- LoadDotNetFromSystem – Specifies that the ThinApp application must use the .NET installation that is present in the user’s system, not the .NET installation that is in the ThinApp application.
- StatusbarDisplayName – Displays the splash screen’s title in the status bar of the ThinApp application start dialog box. You can modify this value to display different titles in the status bar.
Delete or change the value of the parameter and save the file
Double-click the build.bat file in the captured application folder to rebuild the application package.
For more details about Package.ini file parameters, see Package.ini Reference.pdf
.
.
Application Link is a feature that connects dependent application packages at runtime. This allows the administrator to build relationships between packages without using Setup Capture to package all needed components into a single package. Component packages are often more efficiently packaged, deployed, and updated separately.
Create links between packages for the following scenarios:
- Link runtime components, such as .NET, JRE, or ODBC drivers, with dependent applications. For example, you can link .NET to an application even if the local machine for the application does not allow for the installation of .NET or already has a different version of .NET.
- Package and deploy application-specific components and plug-ins separately from the base application. For example, you might separate Adobe Flash Player or Adobe Reader from a base Firefox application and link the components.
Practice Creating an Application Link between Packages
Extract Thinapp Dat File Xml
Follow the process below to set up the link.
- Create the package with the component that you want to link, build the package as an EXE, and then rename the file to something other than an .exe extension to prevent users from running that package directly. A .dat extension will be used in this example: AdobeFlashPlayer.dat
- Create the capture of the originating package with the component already installed, for example, Mozilla Firefox.
- In the originating package, Mozilla Firefox, open the Package.ini file and set the RequiredAppLinks parameter as follows in the [Build Options] section: RequiredAppLinks=AdobeFlashPlayer.dat
- Place both packages in the same directory, locally or on the central file share.
- Launch the Mozilla Firefox application and then navigate to the Adobe site to verify Flash functionality.
Extract Thinapp Dat File Online
Note: Application Links can be specified as Required or Optional in Package.ini. If specified as Required, the primary application will not launch if it cannot connect to the linked application.
.
.
The determination of centralized versus de-centralized deployment depends on the execution mode of the package.
One of the decision points for virtualizing applications with VMware ThinApp is to choose which execution, or delivery, mode is appropriate for users, groups, and applications. There are two primary modes of delivery:
- Streaming mode
- Deployed mode¨
Streaming Execution Mode
Streaming execution mode allows the application to be centrally stored and accessed by multiple users. It is a one-to-many model that provides centralized deployment and update of the application package to multiple end users for execution via a Windows desktop shortcut.
The streaming mode of execution is often the best option for environments that are centralized and where desktops are always online. In streaming mode, the application is launched from a shortcut on the desktop or Start menu and then run from a remote location. The virtualized application is streamed into memory as the application requests files and registry settings.
The user must always have access to the central network location where the ThinApp streaming packages reside.
The storage location that hosts the applications must be highly available. The path through the network between the client device and the central network location must be robust.
Deployed Execution Mode
Deployed execution mode application packages are first deployed to the end user’s system, and then accessed from the local device. Users execute the application from an application package that is local, which allows for offline application use.
The actual location of the package can be on the local file system or a USB device. In this distributed model, each client device receives the package locally and therefore can run the application regardless of network connectivity.
Integrate the delivery of packages, which can be large .exe or .msi files, with your existing organizational process. An existing process, such as Active Directory publishing via Group Policy, will have an already established support structure and administration workflow. You can use Group Policy to deploy software to groups, organizational units, or individuals.
After the application package is delivered, application performance and availability is not subject to network or storage dependencies.
.
.
For the virtualized application to read files and registry keys and write their virtual equivalent in the package, the right isolation mode must be implemented.
ThinApp configures the isolation mode automatically but it can be specified manually by the packager.
3 distinct isolation modes:
- Full: If a system file or a registry key exists on both physical system and in the package, only the element in the package can be read, and writing is done in the sandbox.
- WriteCopy: If a system file or a registry key exists on both physical system and in the package, the element in the system can be read but writing modifications are stored in the sandbox.
- Merged: If a system file or a registry key exists on both physical system and in the package, the virtualized application can read and write the element in the system.
The global isolation mode can be set within a parameter in the package.ini file :
[Isolation]
DirectoryIsolationMode=Merged
The isolation mode can also be set individually for all folders and subfolders within the ##Attributes.ini file in all of them.
Regarding registry keys, the isolation mode can be set individually for each key at the start of the corresponding line in the registry text files at the root of the project.
.
.
Sbmerge.exe is useful to add modifications to an existing package without making a new capture.
To modify an existing package:
- Launch the ThinApp package
- Apply the modifications directly (they are then stored in the sandbox)
- Apply those modifications in the project folder using the following command: Sbmerge.exe Apply –ProjectDir <project_path> -SandboxDir <sandbox_path>
- Then rebuild to generate a new package including the modification
.
.
DLL_Dump.exe lists all running ThinApp packages and shows for each of them:
- DLL loaded by the application inside the package
- System DLL loaded by Windows.
This can be helpful for troubleshooting…
EsoExtractData is a Windows command line utility program used to extract data from ESO's MNF/DAT files. It is also available at ESOUI.
Installation[edit]
- Download File:EsoExtractData.zip or at ESOUI.
- Unzip into a directory of your choice (preferably a new directory).
- Run the program from the Windows command line (ex: Start::Run::cmd) or similar shell.
Extract Thinapp Dat File Extractor
Usage[edit]
IMPORTANT NOTE -- Exporting all files from the three ESO MNF files will take several hours and require over 100GB of free disk space.
- EsoExtractData --help or EsoExtractData -h
- View basic program usage and command options:
- EsoExtractData pathtogame.mnf exportpath
- Extracts the given MNF file and outputs to the given path.
- EsoExtractData pathtogame.mnf exportpath -z exportpathzosft.txt -m exportpathmnf.txt
- Extracts the MNF file and outputs a ZOSFT and MNF directory listing to the specified files.
- ConvertDDS exportpath
- Converts all DDS files recursively in the given path.
Command Line Options[edit]
- Show basic help.
- Save the MNF file directory to the given filename.
- Save the ZOSFT file directory to the given filename.
- Start exporting from the given file index.
- Stop exporting at the given file index.
- Only export the file with the given fileindex.
- Only export the given MNF index.
- Start exporting at the given MNF index.
- Convert all DDS files to PNG. Note that this currently crashes on some DDS files.
- Don't extract/save files from the MNF/DAT.
- Only extract filenames that match the given string or number. If a number is used it will match the fileindex of the subfile with no extension.
- Filenames can include paths however the names are checked both with and without the subfile path. For example, 'testfile.DDS' will match both 'testfile.dds'
- and 'path/to/testfile.dds'. Match is case insensitive. Wildcards in the filename are not supported. Added in version 0.33.
- Convert the given LANG file to 'filename.CSV'. Also outputs an ID file with the name 'filename.id.txt' which is needed when converting a TXT file back to LANG.
- One header row: ID,Unknown,Index,Offset,Text
- Column order is currently fixed.
- Offset column is recomputed when saving.
- Note that the values r, n and ' in texts are converted to their respective characters.
- Text column must be quoted to preserve commas in texts.
- Resulting LANG file will be larger than the original due to duplicate texts not being merged.
- Manually specify the output file for -l and -x commands.
- Location: 'ID-UNKNOWN-INDEX'
- Source: TEXT
- Target: Blank
- Save the LANG file in a plain text format (one text per line, LFs and CRs will be escaped to r and n). If combined with -p and extra blank line will be added between the texts to be compatible with Pootle's txt2po utility.
- Specifies the ID file to use when converting a TXT file to LANG. An ID file is created when converting a LANG to TXT/CSV and must match the file used when converting the TXT file back to LANG. It is a simple text file with one column containing the unique ID for each text in the file.
- -d [file1] [file2] or --difflang [file1] [file2]
- Compares two LANG/TXT/CSV files for differences. Will output files XXX.added.csv, XXX.removed.csv, XXX.changed.csv, and XXX.lang (or XXX.txt and XXX.id.txt if the -t option is used). For column format for the changed CSV file is [id columns...], [new], [old], [translated]. The two input files don't have to be the same type. If using TXT files use the -i1 and -i2 parameters to specify the associated ID files.
- Note: If the ID file used with -i and -i1 is the same you can omit one or the other parameter on the command line. For example, the following commands would be identical:
- -i1 [idfile] or --idfile1 [idfile]
- Use this to specify the assocated ID file if using a TXT file for the first file in a -d parameter.
- -i2 [idfile] or --idfile2 [idfile]
- Use this to specify the assocated ID file if using a TXT file for the second file in a -d parameter.
- -g [file] or --origlang [file]
- Use this with the -d command to specify the source for text for unchanged entries. If a text entry has not been removed or changed the text will come from this file. This can be a LANG, CSV or TXT file. If using a TXT file use the -i parameter to specify the associated ID file.
- --noparsegr2
- Don't parse any GR2 files for their original filenames. By default all recognized GR2 files are loaded and parsed by the Granny DLL in order to extract and output the file to its original filename.
- --extractsubfile combined
- Files that contain compressed record/subfile data are uncompressed and their data output to a single file. The combined file format is output in the following format:
- --extractsubfile seperate
- Files that contain compressed record/subfile data are uncompressed and their data output into individual files within a new subdirectory. Warning: This creates over 1 million files and adds several hours to the extraction.
Example[edit]
- Convert MNF Files
- Convert MNF Files With Directory Files
- Convert a Specific LANG File to CSV
- Convert a Specific LANG File to CSV With Custom Name
- Convert a Specific LANG File to CSV in a PO Compatible Format
- Convert a Specific LANG File to Text
- Convert a Specific LANG File to Text in a PO Compatible Format
- Convert a CSV File to a LANG
- Convert a CSV File to a Custom LANG File
- Convert a PO CSV File to a LANG
- Convert a Text File to a LANG
- Convert a PO Text File to a LANG
- Convert a PO Text File to a Custom LANG File
Version History[edit]
- v0.41 -- 17 September 2020
- Removed the -c/--convertdds option.
- Added the --luafilelist option.
- Added the --luastartindex option.
- Added the -y/--fileext option.
- v0.40 -- 6 February 2020
- Changed to a 64 bit build (to support Oodle decompression).
- Supports the new DAT format introduced in update 25 PTS.
- Skips empty DAT files which reduces the number of error messages.
- Added the '--oodleraw' option which saves subfiles in their original Oodle compression format.
- v0.34 -- 30 May 2019
- Fix default for the '-n' / '--filename' option.
- v0.33 -- 19 April 2019
Extract Thinapp Dat File Download
- Added the '-n' / '--filename' option.
- v0.32 -- 23 October 2018
- Fixed crash from null pointer reference received from Granny API.
- Updated Granny2.dll file which permits more original GR2 filenames to be extracted.
- v0.31 -- 17 April 2017
- Fixed extraction of the ZOSFT from ESO MNF in update 14 PTS files. Unsure how this will work with prior file versions however (is fine with update 13 at least).
- v0.30 -- 18 January 2017
- Added more matching magic bytes for recognizing GR2 (Granny) files.
- GR2 model/animation files are output acccording to their internal original path/filename in addition to their ZOSFT filename (if it exists) and numeric file index. The original path will be created under the 'Granny' path in the base export path.
- Recognize binary Havok files and assign them with the HKX extension.
- Recognize file data containing compressed sub-files and assign them the EsoFileData extensions.
- Recognize file data containing unknown ID data and assign them the EsoIdData extensions.
- Recognize file data for the PSB2 format (unsure exactly what it is though).
- Recognize file data containing more text data (including books) and give it the 'TextData' extension.
- Recognize 'FFX' file data.
- Recognize UTF-8 text files starting with the byte order mark EF BB BF and give the extension 'TXT'.
- Recognize the unknown XV4 file which seems to be just a DDS with 12 bytes of extra header data and 4 bytes of extra footer. The original file and a DDS version without the extra header is saved.
- Include the '--noparsegr2' parameter to prevent the parsing of GR2 files to extract their original filename.
- Added the '--extractsubfile' option for extracting compressed data from some file types:
- v0.29 -- 5 September 2016
- Fixed an infinite loop due to a truncated compressed file in file eso0002.dat from the update 12 PTS.
- v0.28 -- 8 March 2016
- Fixed a crash when extracting Game.Mnf data from the Thieves Guild DLC release.
- v0.27 -- 4 February 2016
- Added support for the 1.9 update on PTS (Thieves Guild DLC) for finding the ZOSFT in the ESO.MNF file. File index for the ZOSFT was changed from 0xFFFFF to 0xFFFFFF.
- v0.26 -- 19 August 2015
- When using -d the changed CSV file contains the original translation text supplied with -g if it exists in the last column ([id columns], [new], [old], [translated]).
- If the ID file used with -i and -i1 is the same you can omit one or the other parameter on the command line. For example, the following commands would be identical:
- v0.25 -- 28 August 2015
- Added the '-d' option for comparing LANG/CSV/TXT files.
- Added the '-i2' option for specifying the second ID file when comparing files.
- Added the '-g' option for specifying a source text for unchanged entries.
- v0.24 -- 9 June 2015
- Added the '-i' option to input an ID text.
- An ID file (.id.txt) is output when converting a LANG file.
- Convert a text file along with an ID file to a LANG file.
- v0.23 -- 11 April 2015
- Added the -t option for saving LANG files in a plain text format.
- v0.22 -- 9 April 2015
- Added the '--posourcetext' to use the source text column (2) in a PO-CSV file when converting it to a LANG file.
- Assume a PO-CSV file (3 columns) when the -p option is used with -x.
- Fix the location column (1) when creating a PO-CSV file (offset was used instead of index).
- v0.21 -- 9 April 2015
- Escape quotes in text as double-quotes (') instead of ' in CSV files to import correctly.
- Added the '-o' option for specifying the output filename for -l/-x commands.
- Added the '-p' option for outputting LANG CSV files in a PO compatible format.
- v0.20 -- 9 April 2015
Extract Thinapp Dat File Rar
- All cells are quoted when saving a LANG file as a CSV.
- Translate DOS linefeeds in LANG file texts as 'r' (was 'n' as previously).
- Convert a language CSV file back to a LANG file using the '-x' option:
- First row must be a header: ID,Unknown,Index,Offset,Text
- Column order is currently fixed.
- Convert r, n and ' to their respectice characters.
- Text column must be quoted to preserve commas in texts.
- Resulting LANG file will be larger than the original due to duplicate texts not being merged.
- Output filename will be the same filename with '.CSV' replaced with '.LANG'.
- v0.18 - 23 November 2014
- Fixed output of Game.Mnf with filenames.
- v0.17 - 7 November 2014
- Name changed from EsoExportMnf to EsoExtractData.
- Now has better, automatic loading of ZOSFT entries for filename correlation.
- Fixed incorrect filename assignment to files with the same ID.
- Added missing , to MNF file table CSV export.
- Added the 'UserData' column to the ZOSFT file table CSV export. Currently is the number of file entries found in the MNF data.
- Converts any .lang file to a CSV format if it can.
- Language file now exported in a normal CSV format (with commas and internal double-quotes escaped to ').
- Added the -b/--beginarchiveoption to start at a specific DAT file index.
- Added the -l/--lang option to convert a .LANG file to a CSV.
- v0.16 - March 2014
- Updated to support the patch for the 14 Mar 2014 beta.
- v0.15 - February 2014
- Updated to support the patch for the 8 Feb 2014 beta.
Known Bugs[edit]
- Errors Extracting from ESO0000.DAT -- There are many files from ESO0000.DAT are in an unknown/invalid format and do not extract correctly.
- Errors Extracting from ESO0204.DAT and Greater -- DAT files with index 204 and above are empty (just the DAT header) even though there are file entries in the MNF file. This results is errors when trying to extract file data from the DAT files that doesn't exist.
- DDS Conversion With -c -- There are some DDS files that will crash the built-in file loader for an unknown reason. Use the ConvertDDS.bat file included instead.
Converting LANG Files[edit]
This is a more in-depth explanation of how to convert LANG files to/from TXT/CSV files related to translating the texts to different languages.
- Create the Initial Export
- Save these files (LANG, CSV and two TXT) for later use as you will need them when re-importing the translated text. Note that the -p option is for importing the file to [pootle.translatehouse.org Pootle]. You can omit the -p for all commands but make sure to be consistent (a file exported with -p has to be imported with -p).
- Translate the File
- Import the en.orig.txt or en.orig.csv into your translation program/utility and translate strings as desired. When finished export the translated strings to a new.txt or new.csv file.
- Create the New LANG File
- The new.lang file can be used in an add-on to 'overwrite' the existing LANG file of the game.
- Update a Partially Translated File
- The game continually updates its text over time so you may wish to update a previously exported TXT/CSV file with all the new/updated text:
Extract Thinapp Dat File Folder
- The new LANG/TXT/CSV file will have all the translated lines from new.txt that haven't been changed or removed in the new LANG file and have all the new texts added. The changed CSV file will contain the new text followed by the original text in the last column. Be sure to keep the 3 new files new.updated.lang, new.updated.lang.txt, and new.updated.lang.id.txt as you will need them for future translations and updates.
Other[edit]
- Source code is available on Bitbucket.