Author Topic: [PC] LGP inserter/extractor/repacker & library - ulgp (1.2)  (Read 107695 times)

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #100 on: 2013-10-07 22:16:18 »
That's one way, I might just have to add support for standard globbing as this is obviously too complicated. As for the switches, they are based on the tar command. Also I'm keeping the libs separate as my apps will all be using them anyway, I'll make an installer or something.

Oh and I'll redo the GUI soon too.

dkma841

  • *
  • Posts: 1225
  • delete
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #101 on: 2013-10-07 22:17:02 »
|
that straight up line key on keyboard i can't press because it's located underneath Esc key and it's got 3 symbols in one :o i press it this comes ` or with Shift then this ¬ so how on earth can i make it do that straight line button in that same key? XD never mind i give up, thanks again :D

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #102 on: 2013-10-07 22:18:07 »
Just copy the text and right click in the command window > paste

DLPB_

  • Banned
  • *
  • Posts: 11006
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #103 on: 2013-10-07 22:19:03 »
yeah the best way to do it is to add  a normal encoder option.  Use some other flag.  Most people who are encoding are encoding from a folder anyway...  i dont see any real need to specify 1 or 2 files to be appended.  In nearly every case, having files inside the target folder is simple and works (and you can still append 1 or 2 files this way).


Kranmer

  • *
  • Posts: 766
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #104 on: 2013-10-07 22:33:51 »
Having trouble compiling the source in MinGW, i have installed MinGW GCC 4.8.1 and Boost 1.54.0 but i keep getting errors trying to compile main.cpp
Code: [Select]
C:\Temp\cc76I0PB.o:main.cpp:(.text+0x45): undefined re
ference to `boost::filesystem::path::parent_path() const'
C:\Temp\cc76I0PB.o:main.cpp:(.text+0x4c0): undefined r
eference to `lgp::Archive::Archive()'
C:\Temp\cc76I0PB.o:main.cpp:(.text+0x4f2): undefined r
eference to `lgp::Archive::addLgp(std::string const&)'
C:\Temp\cc76I0PB.o:main.cpp:(.text+0x6bf): undefined r
eference to `lgp::Archive::addFile(std::string const&)'
C:\Temp\cc76I0PB.o:main.cpp:(.text+0x79e): undefined r
eference to `lgp::Archive::write(std::string const&) const'
C:\Temp\cc76I0PB.o:main.cpp:(.text+0xed0): undefined r
eference to `boost::system::generic_category()'
C:\Temp\cc76I0PB.o:main.cpp:(.text+0xedc): undefined r
eference to `boost::system::generic_category()'
C:\Temp\cc76I0PB.o:main.cpp:(.text+0xee8): undefined r
eference to `boost::system::system_category()'
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/
bin/ld.exe: C:\Temp\cc76I0PB.o: bad reloc address 0x0
in section `.data'
collect2.exe: error: ld returned 1 exit status
any help you can give would be nice, thanks

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #105 on: 2013-10-07 22:41:06 »
If boost was compiled with mingw you need to link the filesystem and system dll's when compiling (just add them directly like any other object file), if not you'll need to link to the import libs instead.

Kranmer

  • *
  • Posts: 766
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #106 on: 2013-10-07 22:47:56 »
I am kind of a newbie when it comes to compiling (usually i just follow directions and it works), so i don't fully understand what you mean but i have tried Compiling boost myself and using a precompiled version from http://nuwen.net/mingw.html and both fail to compile, i did try adding the libs to the same folder as the ULGP source but still got errors, guess this may be out of my league.
Also another small question but why is boost used on this version of ULGP but not on previous ?

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #107 on: 2013-10-07 23:02:30 »
It just occurred to me you're not linking the lgp object file either, anyway try downloading my libs archive and copy it to the same dir as the source, and run this

g++ -std=c++11 -O3 main.cpp lgp.cpp *boost*.dll

Kranmer

  • *
  • Posts: 766
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #108 on: 2013-10-07 23:10:18 »
OK i have now put the source and the libs into the same folder, then typed "g++ -std=c++11 -O3 main.cpp lgp.cpp *boost*.dll" and it did this

EDIT- Sorry that was my fault, i corrupted my MinGW installation, reinstalled and now i get
Code: [Select]
C:\MinGW\ulgp>g++ -std=c++11 -O3 main.cpp lgp.cpp *boost*.dll
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/
bin/ld.exe: i386 architecture of input file `libboost_filesystem.dll' is incompa
tible with i386:x86-64 output
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/
bin/ld.exe: i386 architecture of input file `libboost_system.dll' is incompatibl
e with i386:x86-64 output
C:\Users\Kram2\AppData\Local\Temp\cccsYswN.o:main.cpp:(.text+0x27): undefined re
ference to `boost::filesystem::path::codecvt()'
C:\Users\Kram2\AppData\Local\Temp\cccsYswN.o:main.cpp:(.text+0x48): undefined re
ference to `boost::filesystem::path_traits::convert(char const*, char const*, st
d::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&,
std::codecvt<wchar_t, char, int> const&)'
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/
bin/ld.exe: C:\Users\Kram2\AppData\Local\Temp\cccsYswN.o: bad reloc address 0x0
in section `.data'
collect2.exe: error: ld returned 1 exit status
« Last Edit: 2013-10-07 23:21:10 by Kranmer »

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #109 on: 2013-10-07 23:21:51 »
Ah this might be to do with a std::to_string conflict, maybe the mingw distro you downloaded includes those functions because standard mingw hasn't got around to it yet, adl might be causing my own to_string function to conflict with the std:: versions, I'll change the name.

edit: I've updated the source in the lgp.7z archive, hopefully the conflict is gone now (haven't tested!).

edit2: Ah ok saw the updated, basically you're trying to link my boost libs which are 32bit using your 64bit mingw, that won't work, you'll either have to fix your boost lib issue or just use the standard mingw.

Also I'm using boost filesystem because 1. I've become a bit of a portability nut, 2. boost::filesystem is in C++ TR2 and will probably be part of the standard library at some point, and 3. the winapi functions are a pain in the ass!
« Last Edit: 2013-10-08 00:38:23 by luksy »

Kranmer

  • *
  • Posts: 766
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #110 on: 2013-10-08 00:36:12 »
I'm still getting the same errors, i'm guessing its just me, i will just give up on building the source for now, thanks anyway :)

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #111 on: 2013-10-08 01:18:23 »
It should work with plain mingw and the boost dlls I built

http://sourceforge.net/projects/mingw/files/latest/download

You need to make sure you uninstall the other mingw because it's probably modified your PATH env. variable, IIRC normal mingw won't though so you'll have to add it manually.


As for making changes to the interface, the reason things are the way they are now means I don't need to second guess what the user is attempting to do, which would actually be relatively easy if it weren't for magic.lgp and the insane lgp path handling.

It doesn't help that the windows dir function is schizophrenic: dir /b gives a raw dump of local filenames, dir /s gives a recursive dump using relative paths but with full dir info.  Use them together and for some reason the paths are now absolute, which isn't a problem for any other file except magic.lgp.

Making changes to the interface to fix these issues will result in either a loss of flexibility, or require even more options which in a way complicates things further, most of the complexity of the syntax can be fixed with batch files anyway.

Come to think of it this can be resolved mostly by allowing dirs to be specified in the file list, I'll update it.

What does everyone think?

Ok with a few tiny changes things are a lot easier for non-magic.lgp archives and it still remains as flexible as before.
Entire folders can be specified in the file list, so if you want to create an archive from scratch from a single folder, it's enough to say

ulgp -c foo.lgp thefolder

Note that this WON'T work for magic.lgp because paths are important, magic.lgp would have to be

dir /b thefolder | ulgp -c foo.lgp -eC thefolder

I'll upload the changes later.

Actually this will cause problems if you need to overwrite...sigh. I'll think of something.

Ok got it, was actually fairly straightforward and should make all of us happy.
« Last Edit: 2013-10-08 07:43:44 by luksy »

Kranmer

  • *
  • Posts: 766
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #112 on: 2013-10-08 23:47:28 »
Thanks luksy i finally got it working, installed the latest version of MinGW from that link (i was downloading from their sourceforge site and it was downloading a old installer) and removed all my old environment paths and started fresh, in the end the final command i used to get it working was
g++ -I C:\MinGW\ulgp\boost_1_54_0 -std=c++11 -O3 main.cpp lgp.cpp *boost*.dll
Thanks again.

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #113 on: 2013-10-09 00:24:38 »
Cool, I'll have the updated version uploaded soon.

Ok one for testing

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

Basically the only change is that if you do not specify any files when creating or appending, all files are read, so these should now all work as expected:

dump all:
ulgp -x archive.lgp -C targetFolder

create lgp from scratch using all files / folders in targetFolder
ulgp -c archive.lgp -C targetFolder

overwrite all files
ulgp -r archive.lgp -C targetFolder
« Last Edit: 2013-10-09 01:41:05 by luksy »

DLPB_

  • Banned
  • *
  • Posts: 11006
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #114 on: 2013-10-09 13:04:03 »
Seems to work a charm. After kranmer places it all together and after upx, it comes out at 225KB

1 small issue though.  When using wrong tag (like -e instead of -r), the app hangs.  But that's small potato.

Good job!

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #115 on: 2013-10-09 13:58:25 »
The app isn't hanging, it's waiting for input on the command line if you use -e.

Also I can appreciate wanting to plonk everything into one file, but that defeats the idea of keeping the code separate and the file size to a minimum, you end up distributing multiple copies of the libs with every app. Not that I have other apps planned but you never know. And I've kind of gone off upx too, compression is understandable for distribution (that's where 7zip comes in) but not necessary for the actual executable with today's storage spaces.

DLPB_

  • Banned
  • *
  • Posts: 11006
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #116 on: 2013-10-09 14:37:46 »
For me it just makes things nice and neat to have it in 1 package (especially with installer) .  After upx and all the files in the exe, it comes out as around 220 KB not bad!

I know why you want it separate too tho.  8-)

Obviously if I had like 5 of your programs I had to distribute with an installer, it would be pointless combining all the files.  I just think a standalone command line tool should be 1 exe.   It isn't any biggie anyway, you release the source so people can use it.
« Last Edit: 2013-10-09 15:23:30 by DLPB »

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #117 on: 2013-10-10 05:58:48 »
Ok here's what are ideally the final versions of the commandline and GUI app

http://goo.gl/WxHoSa

(the google shorterner is just to let me know how many times it's been clicked).

This archive has all the libs and source included, I tested it briefly but would appreciate anyone who can chip in (Dan...:D)
« Last Edit: 2013-10-10 07:25:39 by luksy »

LeonhartGR

  • *
  • Posts: 2577
  • ~Whatever...~ Enjoy life!
    • View Profile
    • LeonhartGR Productions
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #118 on: 2013-10-10 12:22:21 »
I love GUIs... hehe! Thanks!

Kranmer

  • *
  • Posts: 766
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #119 on: 2013-10-10 16:36:40 »
Thanks for the new version Luksy, having problems making a LGP with sub folders using the GUI or command line, i tried using
dir /b thefolder | ulgp -c foo.lgp -eC thefolder
as you posted that previously but it still doesn't do sub folders,
Dan has told me that -r works with sub folders but -c doesn't.
But anyway other then sub folders everything else seems to be working great :) Thanks

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #120 on: 2013-10-10 21:44:33 »
That's odd, I'll check again later, I could have sweared it was working, I even made a test script.

edit: Seems to be working for me, by the way if you don't specify any files it will automatically add everything in the specified folder so you can just do ulgp -c foo.lgp -C thefolder

To get a better idea of what's going on, post a dump of the directory structure you have and run ulgp with the -v flag

The commandline app doesn't dump the files with -t due to a bug, but that isn't causing your issue.
« Last Edit: 2013-10-11 05:09:46 by luksy »

DLPB_

  • Banned
  • *
  • Posts: 11006
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #121 on: 2013-10-11 12:06:04 »
I run ulgp -c foo.lgp -C folder1

With -v I get
"inserting 2 files/folders
Inserting folder2\config2
Inserting "config"
Writing lgp file to foo.lgp

But on decode, no folders.

Structure is >

\folder1\folder2

Inside folder1 there is a file called config
Inside folder2 there is a file called config2

Inside foo after -c all there is is config and config2
« Last Edit: 2013-10-11 12:07:36 by DLPB »

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #122 on: 2013-10-11 13:48:25 »
This is entirely intended and you should get the same results with classic lgp, folders are only preserved for identical filenames in separate folders, i.e if you have foo.txt in the folders test1 and test2 it should work fine. Unique filenames are stripped of their paths.

DLPB_

  • Banned
  • *
  • Posts: 11006
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #123 on: 2013-10-11 14:01:07 »
This is entirely intended and you should get the same results with classic lgp, folders are only preserved for identical filenames in separate folders, i.e if you have foo.txt in the folders test1 and test2 it should work fine. Unique filenames are stripped of their paths.

But -r kept them?

Surely sometimes different files in different folders are necessary?
« Last Edit: 2013-10-11 14:03:57 by DLPB »

luksy

  • *
  • Posts: 375
    • View Profile
Re: [1.0] ulgp - lgp inserter / extractor / repacker & library
« Reply #124 on: 2013-10-11 22:11:26 »
That's because when the lgp was created, the path was stripped. When you used -r, you now have two files with the same filename, so the new one is inserted with its path. The only file that uses paths is magic.lgp, and it only uses them for files with identical filenames — the only reason lgp even exists is so the files can be looked up in the hash table, so unique filenames have no need for a path.

I can change this of course if it makes more sense to always keep paths, it's just something that will never be necessary for actual game files.