[PC] LGP inserter/extractor/repacker & library - ulgp (1.2)

  • Thread starter Thread starter luksy
  • Start date Start date
Status
Not open for further replies.
Use a tool to allow the process to use more than 3GByte ram and it will work.
 
Per DLPB's request, I'm filing a bug report for 1.2.1.   Upon attempting to compile a heavily modified battle.lgp that will be 1.04Gb or larger, it throws the error "the volume for a file has been externally altered so that the opened file is no longer valid".  However, using a compiled version of Aali's code from https://www.ff7catalog.com/threads/5713/ will compile it just fine (though in instances like barret's attack, his shells will no longer appear. and there are a few other texture errors).   Your version has fixed whatever that problem is, it just won't compile it if it's too big it seems.

Also tried compiling the 1.04Gb battle.lgps using Aali's code and using 1.2.1 to then dump that.  It errors saying battle.lgp cannot be found
Click to expand...
I would like to see that broken LGP you produced with my tool. If you could come up with a set of source files that produce a broken LGP file with my tool and a working one with ulgp that would be even better.
 
I would like to see that broken LGP you produced with my tool. If you could come up with a set of source files that produce a broken LGP file with my tool and a working one with ulgp that would be even better.
Click to expand...
Well holy hell, I was testing the different lgps i had compiled to make sure I uploaded the correct one, but this time the textures and shells showed up.   But in the next fight they didn't at first, but did during the second attack. I even recompiled one from scratch again. 

My problem must have something to do with 60fps.  Though it is still strange that luksy's version keeps producing errors.
 
Could anyone explain to me what exactly causes the "Volume of a file has been externally altered" output in the command line? I'm having that issue now while trying to compile my battle.lgp file for my (soon to be released) mod. A few months ago I used this tool fine and didn't seem to have any problems. There exist plenty of mods which have larger battle.lgp files though -- so is there a work around for this?

Thanks,

QP
 
The previous version seems to choke with larger files due to all the memory-mapping going on, I've switched back to regular filestreams again which should fix the issue

https://dl.dropboxusercontent.com/u/3227870/ulgp_v1.3.7z

Command-line only for now, the invocation has a changed a little and is much simpler, just keep in mind that you must be in the directory where you want the files to be dumped/packed (the archive itself can be anywhere).
 
I've had a look and I think the syntax needs a little tweak.  The easiest and most common use people have is:

List:
Code: [Select]
Code: 
ulgp l File
Extract:
Code: [Select]
Code: 
ulgp x File Folder
Add:
Code: [Select]
Code: 
ulgp a File Folder
It's simple and it requires no effort or change apart from the x and a.

imho that should be the default behaviour.

The only other feature would then be to extract specific files, and that can just use something like

Code: [Select]
Code: 
ulgp f File Folder Filter
So the f flag would have a third parameter being the Filter for specific files.  For example, "cor" would return all "corel" fields and so on.

Code: [Select]
Code: 
ulgp f c:\ff7\data\field\flevel.lgp MyFields cor
 
Last edited:
I managed to re-introduce some bugs in v1.3, so they're fixed, and I've reworked the interface as follows:

There are no more commands, the first argument is autodetected as either a file or a folder. If it's a file it extracts, if a folder it archives the files in the folder.

If the second argument is omitted, it creates a folder from the stem of the lgp file if extracting (e.g. magic.lgp => magic/), or it adds .lgp to the folder when archiving, otherwise it uses the second argument as the target archive / folder.

Any other arguments are a list of files to extract / add, relative to the folder, if no files are specified it extracts / adds all files.

This also means you can just drag a file or a folder on top of the exe and it should do what you expect.

https://dl.dropboxusercontent.com/u/3227870/ulgp_v1.3.1.7z

(64bit only for now, will get round to a 32bit version).
 
Last edited:
I've replaced the file list with a single regex pattern, and recompiled for 32bit

https://dl.dropboxusercontent.com/u/3227870/ulgp_v1.3.2.7z

Keep in mind the pattern is regex, not a globbing pattern, so something like

  ulgp magic.lgp somedir "foo|bar"

can be used to extract "foo" and "bar" only, and

  ulgp magic.lgp somedir "x.*"

extracts all files beginning with x. The glob-like pattern "x*" would only extract files with two characters.
 
I have created a batch file to make modifying / decoding lgp archives in FF7 easier.

lgp_edit  is HERE

The batch file uses Luksy's ulgp tool.
 
Last edited:
Genuine question.  Why is this easier?  With the current ulgp, you drag the lgp over it and it extracts, or you drag the extracted folder over it and it compiles.
 
This can keep all your archives in one place and continually add files from "add" folder. Or can decode to "new" folder.  Or create new archive entirely from "new" folder.  It's a lot easier to see the benefits when you have a lot of archives you are continually testing with various files (especially when the number of files becomes very large like with char.lgp).

Plus one folder can keep the original archives for you to use again without having to keep copy pasting from game root.  This doesn't make ulgp any easier - it makes managing large edits to numerous lgps easier.  And it does it without having to know the command line.

I'm not sure how useful this will be for people, but it's definitely been useful for me.  8)
 
Last edited:
Can't seem to find a working link for the last version. Can anyone reupload it, please.
 
Last edited:
Status
Not open for further replies.
Back
Top