Madden NFL 13 Vita ast files

[lorak]

Hi, I am new to this forum and have recently found quickbms (v0.7.6a) as I would like to extract a few ast files from Madden NFL 13 PS Vita version to replace uniform and stadium textures. I am aware of and have applied the following scripts ElectronicArts ast extractor BGFA.bms (from 2012-09-17) together with func_getTYPE.bms (from 2015-06-05). First, I am not sure if those are the most recent versions of the scripts. I have attached those scripts to this post by the way.

Quickbms and the scripts above work without errors with the exception of the file qkl_patch.ast. In the attached picture you can see the error message that appears in quickbms and the header of that .ast file (BGFA1.05g) in an hex editor.



I have a few requests:
1. Could you please help me to fix/avoid that error?

2. Quickbms and the scripts referred above extract the contents of the files qkl_boot.ast, qkl_fe2ig.ast, qkl_interface.ast, qkl_misc.ast, qkl_ram.ast and qkl_stream.ast without errors, however only the extracted folder qkl_stream contains correct file extensions. The rest of the extracted folders also contain extensions like ".58464e52" and again ".ast". I was thinking that this is probably due to the file definitions in func_getTYPE.bms. Quickbms extracts it in this way as actually "does not recognizes" all the file types present in those .ast files.

Is there a way to try to sniff the file types inside those big .ast files, i.e., qkl_boot.ast, etc?
How to use your generic splitter/scanner script for this task?

3. Is there away to extract the files with file names and extension instead of for example, just qkl_fe2ig_0.xml?

Hope someone can help.
Thanks.

[aluigi]

I don't see a sample archive, without it there is not much we can do.
The following are the scripts made by me about the "BGFA" format and I guess they "may" work with your files:
http://aluigi.org/bms/madden2010.bms
http://aluigi.org/bms/nbajamfire.bms

[lorak]

Thank you for those scripts, however did not work. I got the same error message as in the image above in the first post.

How can I generate a sample archive? If I remember correctly, you have a script to do it.

The file size of qkl_patch.ast is almost 53 MB. The other files are much bigger, a couple of them close to 1 GB.
Anyway, you can download that file following this link: http://www.megafileupload.com/oeuN/qkl_patch.ast
Thanks.

[aluigi]

I don't see a real format with information about the files so the best solution is using offzip:
offzip -a qkl_patch.ast output_folder

[lorak]

Thank you very much!!
There is no error this time and it seems that I have all the contents extracted. There is a bunch of xml, dds and dat files and a few apt files. Their names however are numbers.

Is there a way to extract those files with the "correct" file names?
It would be easier to try to identify what files to edit/replace. Maybe those numbers are actually the file names, I do not know yet.

Anyway, thank you very much again for your help.

Now, I will try to look for the textures I would like to edit/replace and post my findings here.

[lorak]

Actually offzip works better than quickbms (v0.7.6a) to extract the files from the .ast files with only one exception that can be extracted with quickbms (v0.7.6a) together with the scripts ElectronicArts ast extractor BGFA.bms (from 2012-09-17) and func_getTYPE.bms (from 2015-06-05).

A bit more details about it, offzip extracts files from:

qkl_boot.ast, qkl_fe2ig.ast, qkl_interface.ast, qkl_misc.ast, qkl_ram.ast and qkl_patch.ast. Although it shows a lot of error messages when working with qkl_stream.ast. However, quickbms (v0.7.6a and the scripts referred above) extracts its contents without errors apparently.

Edit: Even with that bunch of error messages, it seems that offzip is able to extract the files form qkl_stream.ast as well extracting 77% (?) of its contents though.

What is the meaning of that percentage?
With some files the percentage is 99% and 77% (it changes) with others.

I think I have found the textures to replace/edit. I shall work on that and try to repack everything again to see if that works.

Edit: The only concern I have at this moment is if the names of those files are in fact numbers as is the case with the extracted files. A problem would appear when repacking and more important, when the game actually tries to load the contents from .ast files. I read in the forums a bit more about offzip tool and there is no problem with the file names of the extracted files, as those numbers are the offsets to re-inject the modified files.

Thank you again for your help.

[aluigi]

The percentage tells what's the amount of data of the input file that has been read/extracted.
99% or any result above 95% is perfect, 77% is a problem.
That low percentage is caused by the presence of uncompressed data in the archive that, obviously, offzip can't extract.

[lorak]

After reimporting a few files with offzip, it seems that everything is working as expected!!

I have replaced/edited a couple of textures to test and I found no problems!!

Thank you very much for your help and the tools supplied.

[aluigi]

That's a great news

[lorak]

First, many thanks for the help in the past.

I have another query. The repacking process with offzip v0.4 seems to be successful. Then, when launching the game and selecting one of the modified uniforms (.dds updated textures) the game either loads everything with no issues or sometimes crashes, it seems to be at random. Do you have any idea of what could be the issue?

It looks like the Table of Contents or at least the texture file names are located before (previous offset than) the textures files. See below.

In this link (the link will last for 30 days or so) you can find one of my updated textures "0f5b8cc0.dds" (worked in GIMP) and the block of the corresponding original file including texture file names in the files "Original extracted file". The real texture starts at offset 240.

Thanks in advance.

[aluigi]

offzip is blind, can't know if the new size is bigger than original, that may be the reason of these problems.
No solution.

[lorak]

Ok thanks, perhaps this issue could be related to the file header of each replaced file too.