One of Daxar's posts on the previous page (page 6) has a link to download his liTools bunch of programs. These are all command-line utilities that you will either have to run using the command prompt, or using a batch file.
In this case, to compress your file into a .pak, run "liCompress myMod.pak", replacing "myMod.pak" with your .pak name. You will need to do this in the same directory as liCompress.exe.
I'll try and get started with Matchbox soon to try and simplify the packing process.
I tried it. My file's name is 'spolszczenie' and when I'm using liCompress spolszczenie.pak window showing up just for a split second but not creating any file. But when I'm using liCompress spolszczenie without .pak it's creating a file without any extension.
That's a bit weird. Try running "liCompress spolszczenie.pak 1> out.txt 2> err.txt" (without quotes). It'll create the 2 text files, see what each one contains. Hopefully one should have some sort of explanation as to why no file is being created.
Okay. It's fine now. It was a very problem with txt file's name. So I got this spolszczenie.pak file. I dropped it onto modManage and it seemed to work fine.
Packing resource blob file spolszczenie.pak
Compressing file 1 out of 1: vdata/letterdb.dat
Adding table of contents...
Adding compressed files...
Done.
Time elapsed: 0 min, 1.516 sec
Hmm, that's strange. If you've modified the file, there's no reason for the changes to not show up unless it's not getting copied over/merged properly. Have you tried just changing the file and recompressing? If that works, and merging the mod in doesn't, then it's likely the fault of the ModManage program (which, come to think of it, is probably in a barely-working state as it is...).
Yep. When I decompressed spolszczenie.pak there IS my modified file. But when I tried to pull out and decompress .pak files from supposedly modified game there's no modification whatsoever.
1. Decompress resource.pak (if you haven't already):
liDecompress resource.pak
2. Copy your new letterdb.xml over into the vdata subfolder, overwriting the one that's there already (If there is not letterdb.xml there, and instead is a letterdb.dat, you may not be using the latest version of liTools. Get the latest here: https://dl.dropboxusercontent.com/u/31816885/liTools0.3.7.zip )
If these steps still don't show your changes ingame, then double-check and make sure that your executable is fully stripped; if your Little Inferno executable is around 3MB, it is stripped, if it's around 300MB, it's not. If not, run:
strip.exe "Little Inferno.exe"
and retry the above steps.
If this approach works, but the creating-a-mod approach and using ModManage doesn't work, then it's likely a bug within ModManage and I'll see if I can look into it.
embed.pak is the pakfile that contains itemmanifest.dat (which in turn decompresses to the individual item XMLs). Did you try recompressing that after your changes to the item XML?
Ah, yes. Windows and it's stupid forward-slash. For some reason I don't convert the .filelist.txt backslashes into forward slashes. I definitely should change that...
For some reason XML files don't like to work. I modified Magnet.xml to change it's price. In my magnetMod.pak.filelist.txt file I put data/items/Magnet/Magnet.xml, but it doesn't actually get packed. I unpacked the magnetMod.pak file and lo and behold, the file wasn't in there.
Apologies for my lack of work. Real life and other projects have restricted my time for work on a mod manager, but I will try and get something done soon-ish.
But if you can get your head around how the game files work (which hopefully shouldn't be too difficult), you can make mods with no coding at all. Unless you want to edit XML files, which requires some knowledge of the syntax, but again that's quite easy.
So I am now deciding to poke around with Little Inferno modding. Can someone give a rough explaination on how to get started? I downloaded liTools0.3.7, and I am not sure what all the Application files exactly do.
@kirdnehThere's a Readme.md file that explains everything.
@puggsoy I wanted to post this, but Mollom was blocking me...
Anyway, I started to make a mod manager in Qt just to see how good I am, and you know what? Its actually working pretty well by now! I'm almost done with managing mods, and I was already thinking about creating .limod(zip) files with a .pak, a .filelist.txt and an addin.xml in them.
If you want, we could work together on the program. Qt is pretty straightforward and easy to learn, and WoGLe was made with it.
P.S. Here's my original post (about two weeks ago I tried to post it, but I was blocked):
So, I was learning Qt as my homework for these holidays and after I passed through some tutorials I told myself:"Try to make some sort of a manager for Little Inferno that you wanted to make in Visual Studio but never made."
This is what I've done so far! Here it is
(Source included, latest Qt version required in order to compile)
It doesn't have many features now, and I haven't implemented any real mod management, but hey, it is a work in progress after all. : )
Hmm, well I can't really be bothered to install Qt to check this out, sorry. However, it might be better for the job, since there's not really any good (working) UI frameworks or libraries for Haxe (what I'm using). There is one, but I don't even know how good that'd look.
If you think it'll work then feel free to go ahead, I have a bunch of other stuff to do anyway.
Well, I'll continue to work on my program, and we'll see what happens!
By the way, I'm trying to compile it statically so that no one have to install Qt framework to make my program work.
I'm back! And here's some suggestions for the filelists...
1. I think .xml should be reserved in filelists. Error parsing XML file vdata/loctexmanifest.bin.xml: Error 3
Error: Unable to open file vdata/loctexmanifest.bin. Abort.
2. Compressing data/items/*/*.xml doesn't work. Still need to use vdata/itemmanifest.dat instead. Can you do something to merge these files?
3. Is everything new added to embed.pak by modManage now?
4. SERIOUS BUG ALERT!!!1! It seems that repacking embed.pak will make some item undestroyable. Screenshot here.
:~
1. I have no idea what you mean by the sentence "I think .xml should be reserved in filelists." Could you explain?
The error message you're getting there means your XML is either missing or malformed. Check your syntax.
2. Nope, adding .xml files to .filelist.txt files would fail miserably. Since itemmanifest.dat is the actual file that's being compressed (and there's no way to only compress one item xml at a time), this is quite intentional.
3. New files are not supported.
4. I'm not sure what I'm looking at. But if something is broken/not working, it means you did something wrong, so I'd recommend restoring the .pak files from a backup (I always keep backup ones handy for this very reason. I break stuff all the time).
1. I meant the users should put .xml in the filelist.txt to make this file less confusing because that .dat file doesn't exist.
2. I meant maybe you can add support for this. Put item .xml into the package (or only make itemmanifest.dat for these items) and when modManage is executed, liTools should merge two itemmanifest.dat files.
3. Oh okay. I'd prefer to load them to embed.pak by default because that's the first package that will be loaded.
4. Please fix... Just try these: strip "Little Inferno.exe"
liDecompress embed.pak
liCompress embed.pak
And there you go. The Plushies delivered with the chainsaw is broken.
Here's the diff result: http://paste.ubuntu.com/8085116/
Here's how I get this result: git init
git add .
git commit -a -m test
liDecompress embed.pak
git diff --word-diff > result.txt
It seems that the png files are changed, and burngrid/@grid is having some unknown issues.
1. Yeah, ideally I would allow that, but the whole .filelist.txt format was just the easiest thing to do at the time while I was throwing everything together, and it isn't exactly designed to be user-friendly anyway. Ideally, I'd figure out where I was going with the whole thing in the first place, and probably only allow xml.
2. Honestly, since there have been precisely zero mods to add items, this could not be lower on my priority list right now. It would require some very huge changes to the way itemmanifest.dat is processed, and I'm not all that interested in it to begin with. There's probably lots of issues with how items are handled already (one of which you just found!), just because it's such a huge chunk of code.
3. Ideally, yes. But I never fully thought through the changes that need to be made. New files probably work in some parts of the program and utterly fail to work in others. It's why I never announced new files as a supported feature; I never tested it. I added some bare-bones stuff in there, never announced anything, and people started complaining that new files don't work. Well no duh. : P
4. Good catch. I'll have to look into fixing that sometime. Probably some problem with the huge mammoth that is the itemmanifest.dat parsing code...
Oh ok.
2. 4. Try to use encapsulation. It will take more lines of code but it will make the code easier to read & write & debug imo. A function with 900+ lines is too scary. :~
Well I think there is. I don't know how things exactly works but here's an example: class string_resource {
public:
string lang;
string data;
int size();
int write_xml(...);
// etc.
}
class string_resources {
public:
vector<string_resource> strings;
}
That's perfectly reasonable, and fairly similar to what I have. The only issue here is the write_xml() function. How would you propose making that simpler than what I have already?
I'll be honest; I would dearly like to simplify a lot of this code. The issue is that I honestly don't know if there's a way to do so. If there is, I sure haven't thought of it. :/ There's probably ways to do it in scripting languages (for example, in Lua I could stick all the values in a table, and iterate through that, and the dynamic typing would really help out), but C/C++? Not so much. I would, of course, be more than willing to hear how Allen did it *cough*release the source*cough*, cause I'm sure he did something particularly brilliant.
It's not making things simpler, it's making things easier to debug imo. :~
Umm... If you want to use something dynamic, try virtual functions... class convertible {
public:
virtual void read_xml(...);
virtual void read_offset(...);
virtual void read_data(...);
virtual void write_xml(...);
virtual void write_offset(...);
virtual void write_data(...);
}
And then create a bunch of derived classes. I think that will make it possible to iterate.
EDIT: Daxar, how soon will you fix that bug? Because I need that bug fixed to continue my work. Not really important though. :~
Hey! You guys started discussing all this stuff more than a year ago, and probably most of you don't check this forum anymore. I know Daxar still does. But if you get a notification that someone replied to this thread (me), I just wanted to let you know that we're still trying to mod the game, and several new topics have been started, such as a new combos mod and a few item replacement mods. You might want to check them out, and please share any mods you've been working on.
Not likely. I'm quite busy with schoolwork atm, and it's very low on my priority list of things I feel like doing. Feel free to figure out what the problem is and submit a pull request to me on github, though.
Catalog
Combos
Forum
Get the Game
News
One of Daxar's posts on the previous page (page 6) has a link to download his liTools bunch of programs. These are all command-line utilities that you will either have to run using the command prompt, or using a batch file.
In this case, to compress your file into a .pak, run "liCompress myMod.pak", replacing "myMod.pak" with your .pak name. You will need to do this in the same directory as liCompress.exe.
I'll try and get started with Matchbox soon to try and simplify the packing process.
I tried it. My file's name is 'spolszczenie' and when I'm using liCompress spolszczenie.pak window showing up just for a split second but not creating any file. But when I'm using liCompress spolszczenie without .pak it's creating a file without any extension.
That's a bit weird. Try running "liCompress spolszczenie.pak 1> out.txt 2> err.txt" (without quotes). It'll create the 2 text files, see what each one contains. Hopefully one should have some sort of explanation as to why no file is being created.
Okay. It's fine now. It was a very problem with txt file's name. So I got this spolszczenie.pak file. I dropped it onto modManage and it seemed to work fine.
Packing resource blob file spolszczenie.pak
Compressing file 1 out of 1: vdata/letterdb.dat
Adding table of contents...
Adding compressed files...
Done.
Time elapsed: 0 min, 1.516 sec
But there's no change in game.
Hmm, that's strange. If you've modified the file, there's no reason for the changes to not show up unless it's not getting copied over/merged properly. Have you tried just changing the file and recompressing? If that works, and merging the mod in doesn't, then it's likely the fault of the ModManage program (which, come to think of it, is probably in a barely-working state as it is...).
Yep. When I decompressed spolszczenie.pak there IS my modified file. But when I tried to pull out and decompress .pak files from supposedly modified game there's no modification whatsoever.
Ok, try this:
1. Decompress resource.pak (if you haven't already):
liDecompress resource.pak
2. Copy your new letterdb.xml over into the vdata subfolder, overwriting the one that's there already (If there is not letterdb.xml there, and instead is a letterdb.dat, you may not be using the latest version of liTools. Get the latest here: https://dl.dropboxusercontent.com/u/31816885/liTools0.3.7.zip )
3. Recompress resource.pak:
liCompress.exe resource.pak
If these steps still don't show your changes ingame, then double-check and make sure that your executable is fully stripped; if your Little Inferno executable is around 3MB, it is stripped, if it's around 300MB, it's not. If not, run:
strip.exe "Little Inferno.exe"
and retry the above steps.
If this approach works, but the creating-a-mod approach and using ModManage doesn't work, then it's likely a bug within ModManage and I'll see if I can look into it.
Cheers!
-Daxar
So for mods to work, game .exe must be stripped? It's working now. Thanks
Btw. It seems like the game can't see modded names of the items. For instance modified data\items\Warranty\Warranty.xml.
embed.pak is the pakfile that contains itemmanifest.dat (which in turn decompresses to the individual item XMLs). Did you try recompressing that after your changes to the item XML?
All directories in itemmanifest we're using common slash and when I changed it to back slash it worked.
Ah, yes. Windows and it's stupid forward-slash. For some reason I don't convert the .filelist.txt backslashes into forward slashes. I definitely should change that...
For some reason XML files don't like to work. I modified Magnet.xml to change it's price. In my magnetMod.pak.filelist.txt file I put data/items/Magnet/Magnet.xml, but it doesn't actually get packed. I unpacked the magnetMod.pak file and lo and behold, the file wasn't in there.
wow! what a progress! btw what about the non coder? can they(we,i) make mods too?
i really want to make mods but i only learned JavaScript...
It's actually pretty easy to mod. I've made mods that do a few basic things like change the colour of items, such as green magnets.
Apologies for my lack of work. Real life and other projects have restricted my time for work on a mod manager, but I will try and get something done soon-ish.
But if you can get your head around how the game files work (which hopefully shouldn't be too difficult), you can make mods with no coding at all. Unless you want to edit XML files, which requires some knowledge of the syntax, but again that's quite easy.
So have you managed to get it to actually pack the XML files? Whenever I try it just never works.
So I am now deciding to poke around with Little Inferno modding. Can someone give a rough explaination on how to get started? I downloaded liTools0.3.7, and I am not sure what all the Application files exactly do.
@kirdnehThere's a Readme.md file that explains everything.
@puggsoy I wanted to post this, but Mollom was blocking me...
Anyway, I started to make a mod manager in Qt just to see how good I am, and you know what? Its actually working pretty well by now! I'm almost done with managing mods, and I was already thinking about creating .limod(zip) files with a .pak, a .filelist.txt and an addin.xml in them.
If you want, we could work together on the program. Qt is pretty straightforward and easy to learn, and WoGLe was made with it.
P.S. Here's my original post (about two weeks ago I tried to post it, but I was blocked):
So, I was learning Qt as my homework for these holidays and after I passed through some tutorials I told myself:"Try to make some sort of a manager for Little Inferno that you wanted to make in Visual Studio but never made."
This is what I've done so far!
Here it is
(Source included, latest Qt version required in order to compile)
It doesn't have many features now, and I haven't implemented any real mod management, but hey, it is a work in progress after all. : )
What do you think about it?
Hmm, well I can't really be bothered to install Qt to check this out, sorry. However, it might be better for the job, since there's not really any good (working) UI frameworks or libraries for Haxe (what I'm using). There is one, but I don't even know how good that'd look.
If you think it'll work then feel free to go ahead, I have a bunch of other stuff to do anyway.
Well, I'll continue to work on my program, and we'll see what happens!
By the way, I'm trying to compile it statically so that no one have to install Qt framework to make my program work.
And apparently there is still no mod that reduces time for packages to deliver to 1 second?
Apparently not! Kinda funny, huh?
Time to call in the modders!
I'm back! And here's some suggestions for the filelists...
1. I think .xml should be reserved in filelists.
Error parsing XML file vdata/loctexmanifest.bin.xml: Error 3Error: Unable to open file vdata/loctexmanifest.bin. Abort.
2. Compressing data/items/*/*.xml doesn't work. Still need to use vdata/itemmanifest.dat instead. Can you do something to merge these files?
3. Is everything new added to embed.pak by modManage now?
4. SERIOUS BUG ALERT!!!1! It seems that repacking embed.pak will make some item undestroyable. Screenshot here.
:~
Howdy!
1. I have no idea what you mean by the sentence "I think .xml should be reserved in filelists." Could you explain?
The error message you're getting there means your XML is either missing or malformed. Check your syntax.
2. Nope, adding .xml files to .filelist.txt files would fail miserably. Since itemmanifest.dat is the actual file that's being compressed (and there's no way to only compress one item xml at a time), this is quite intentional.
3. New files are not supported.
4. I'm not sure what I'm looking at. But if something is broken/not working, it means you did something wrong, so I'd recommend restoring the .pak files from a backup (I always keep backup ones handy for this very reason. I break stuff all the time).
1. I meant the users should put .xml in the filelist.txt to make this file less confusing because that .dat file doesn't exist.
2. I meant maybe you can add support for this. Put item .xml into the package (or only make itemmanifest.dat for these items) and when modManage is executed, liTools should merge two itemmanifest.dat files.
3. Oh okay. I'd prefer to load them to embed.pak by default because that's the first package that will be loaded.
4. Please fix... Just try these:
strip "Little Inferno.exe"liDecompress embed.pak
liCompress embed.pak
And there you go. The Plushies delivered with the chainsaw is broken.
Here's the diff result: http://paste.ubuntu.com/8085116/
Here's how I get this result:
git initgit add .
git commit -a -m test
liDecompress embed.pak
git diff --word-diff > result.txt
It seems that the png files are changed, and
burngrid/@gridis having some unknown issues.1. Yeah, ideally I would allow that, but the whole .filelist.txt format was just the easiest thing to do at the time while I was throwing everything together, and it isn't exactly designed to be user-friendly anyway. Ideally, I'd figure out where I was going with the whole thing in the first place, and probably only allow xml.
2. Honestly, since there have been precisely zero mods to add items, this could not be lower on my priority list right now. It would require some very huge changes to the way itemmanifest.dat is processed, and I'm not all that interested in it to begin with. There's probably lots of issues with how items are handled already (one of which you just found!), just because it's such a huge chunk of code.
3. Ideally, yes. But I never fully thought through the changes that need to be made. New files probably work in some parts of the program and utterly fail to work in others. It's why I never announced new files as a supported feature; I never tested it. I added some bare-bones stuff in there, never announced anything, and people started complaining that new files don't work. Well no duh. : P
4. Good catch. I'll have to look into fixing that sometime. Probably some problem with the huge mammoth that is the itemmanifest.dat parsing code...
Oh ok.
2. 4. Try to use encapsulation. It will take more lines of code but it will make the code easier to read & write & debug imo. A function with 900+ lines is too scary. :~
Well, yeah, but the issue with reading/writing XML and binary formats is that there's not really a good way to do so.
Well I think there is. I don't know how things exactly works but here's an example:
class string_resource {public:
string lang;
string data;
int size();
int write_xml(...);
// etc.
}
class string_resources {
public:
vector<string_resource> strings;
}
That's perfectly reasonable, and fairly similar to what I have. The only issue here is the write_xml() function. How would you propose making that simpler than what I have already?
I'll be honest; I would dearly like to simplify a lot of this code. The issue is that I honestly don't know if there's a way to do so. If there is, I sure haven't thought of it. :/ There's probably ways to do it in scripting languages (for example, in Lua I could stick all the values in a table, and iterate through that, and the dynamic typing would really help out), but C/C++? Not so much. I would, of course, be more than willing to hear how Allen did it *cough*release the source*cough*, cause I'm sure he did something particularly brilliant.
It's not making things simpler, it's making things easier to debug imo. :~
Umm... If you want to use something dynamic, try virtual functions...
class convertible {public:
virtual void read_xml(...);
virtual void read_offset(...);
virtual void read_data(...);
virtual void write_xml(...);
virtual void write_offset(...);
virtual void write_data(...);
}
And then create a bunch of derived classes. I think that will make it possible to iterate.
EDIT: Daxar, how soon will you fix that bug? Because I need that bug fixed to continue my work. Not really important though. :~
Hey! You guys started discussing all this stuff more than a year ago, and probably most of you don't check this forum anymore. I know Daxar still does. But if you get a notification that someone replied to this thread (me), I just wanted to let you know that we're still trying to mod the game, and several new topics have been started, such as a new combos mod and a few item replacement mods. You might want to check them out, and please share any mods you've been working on.
@Daxar
Is that bug going to be fixed soon? :S
Not likely. I'm quite busy with schoolwork atm, and it's very low on my priority list of things I feel like doing. Feel free to figure out what the problem is and submit a pull request to me on github, though.
Pages