Jump to content

GemRB game installers


njw

Recommended Posts

I hereby present the first release of some native GNU/Linux game installers. At the moment only Baldur's Gate & Planescape: Torment installers are included, as they're all I currently own (shame on me). Please do try it out if you can, and let me know if you find any problems.

 

Download it from http://git.njw.me.uk/cgit/cgit.cgi/gemrb-g...s-0.1.0.tar.bz2

 

To use it, insert the first CD of the game you want to install, and run the auto-installer.sh script, with something like this:

 

./auto-installer -i new-bg-install -c /mnt/cdrom

 

It'll read the CD and (if it knows of the game) will start installing straight away. It also gives the option to download and install the latest patches for each game, if they're needed.

 

If you have a little time please do write install scripts for games you have (and send them to me!) - it isn't difficult, as I've put some time into getting the functions right so that the tricky bits just work. Look through the scripts to get an idea of how things work. The git repository for the scripts is at http://git.njw.me.uk/cgit/cgit.cgi/gemrb-gameinstallers/ if you wanted to clone it and work on it that way.

 

Note that unshield needs to be installed, and cabextract is needed for a lot of the patches, so install these before trying the scripts.

 

Hope you like it, and hopefully after a little testing this'll go into the gemrb tree.

Link to comment

nice, a generalisation of the bg1 work. I took a quick peek and the only comment is: rename the die() in the patch lib to something unique, so you don't have to worry about its redefinition if you ever source both implementations.

Link to comment

Good idea. At one point earlier in writing these I was overloading functions a lot, but it got messy and confusing, and things are certainly much nicer now.

 

Here's a new version, with nothing but that improvement in.

 

http://git.njw.me.uk/cgit/cgit.cgi/gemrb-g...s-0.1.1.tar.bz2

 

I forgot to mention that each of the install scripts, while designed mainly to be run from the auto-installer.sh script, will also work fine if run individually.

Link to comment

Per Nick's request, I'm announcing a supporting project for the installer files: an installer data collector. Just run the disc_collector script for each of the IE games that the installer doesn't already recognize and the disc collector will collect all the data Nick needs to create an installer for that game.

 

Submit the /tmp/gemrb_install_data.gz file to ie-disc-info@njw.me.uk, and your game should be able to be supported in the next version of the installer!

Link to comment

It would be nice if the "unneeded windows files" were truly just useless stuff; removing the .exe file means that any .exe-changing mods won't apply, and removing keymap.ini is a bad idea (gemrb will probably use it, someday).

Link to comment

Does the installer put some unique file in the install dir?

Anything would be good, but it would be useful indicator of gemrb for mods. (Like they don't have to mod the .exe). Or maybe even going as far as locating gemrb override?

 

This is just an idea, but we could start to think about making gemrb visible to mods.

Link to comment

Hi there, sorry I didn't notice your questions & thoughts for so long.

 

Avenger, at present, no, there aren't any unique files added by the installer, but I agree, this would make sense. Just a file called gemrb-installer.ini, containing the installer version number and options sounds like a good plan, how does that sound to you?

 

As for being a little kinder with the "remove unused files" option, that's a slightly muddy issue.

 

I'm not sure if this is a popular opinion, but I'm not keen on config files (like keymap.ini) being written to from the install directory anyway, as it won't work well e.g. if one tries to install the game from a package in /usr/share (as it should then all be unwritable). So I think that keymap.ini and other .ini files should be written to somewhere in ~/.gemrb/. Any .ini files found in the game directory could just be read as defaults, which are overwritten by anything in the appropriate place in ~/.gemrb

 

But I agree that the .ini files should stay around as defaults in the install, so I'll make sure they aren't removed by the script.

 

So that leaves the game .exe files as the other tricky area. As you say at the moment removing them makes some mods fail. Is this a problem, given that GemRB still isn't quite 'production-ready' (though I'm really excited at how great it's getting)? I'm not familiar with weidu, would it be feasible to build "if this was installed by a gemrb installer (eg if gemrb-installer.ini is present), ignore any .exe mod" functionality into it at the core weidu level (so that all mods were so corrected)?

 

I could also change the wording of the prompt "Do you want to remove unneeded windows files?" to something more like "Do you want to remove unneeded windows files (may break compatibility with some mods)?"

 

Thoughts? Ideas?

 

Once we've decided the best way to go with these issues, I'll release the new version, which is much nicer (thanks largely to Nick Daly [myownlittlworld]).

Link to comment
Guest Guest_Fuzzie_*
So I think that keymap.ini and other .ini files should be written to somewhere in ~/.gemrb/. Any .ini files found in the game directory could just be read as defaults, which are overwritten by anything in the appropriate place in ~/.gemrb

It's a bit problematic because a lot of people share their game data with a "real" install which does modify the .ini and would like the settings to stay the same between both games, but perhaps we should make it an option..

 

I'm not familiar with weidu, would it be feasible to build "if this was installed by a gemrb installer (eg if gemrb-installer.ini is present), ignore any .exe mod" functionality into it at the core weidu level (so that all mods were so corrected)?

Well, the only exe-modifying mod that anyone's really wanted to use with gemrb so far has been the Widescreen mod (obviously a popular one), to which lynx contributed a manual gemrb option. That manual work might end up being the only real solution since the exe modifications usually make changes gemrb needs to know about anyway.. but it's probably going to be less painful for them always having the exe around and just always making the changes *and* always adding the gemrb files, and I'm doubtful weidu upstream are going to want to accept file-ignoring hacks.

 

These are just thoughts on my part, though, and shouldn't be taken too seriously!

 

I could also change the wording of the prompt "Do you want to remove unneeded windows files?" to something more like "Do you want to remove unneeded windows files (may break compatibility with some mods)?"

That sounds like a good idea.

Link to comment

I actually think the proposed prompt is still a little muddy and inaccurate. A more technically correct prompt might be something along the lines of:

 

"Do you want to play the game using Windows or Wine, in addition to GemRB? [Yes]

 

If you answer 'no', certain writable and executable files that GemRB doesn't need will be removed. Unfortunately that will prevent the game from running in Windows and Wine. Answer 'yes' if you're unsure."

 

I like the option and the idea, but I'm wondering why we're including that option in the first place? The reasons I see are:

 

1. Makes the GemRB installation directory cleaner.

2. Makes things easier to debug when stuff goes wrong (you only need to check one set of config files: ~/.gemrb).

3. You can make the installation directory read-only. The installation is harder to screw up and tamper with.

 

Are those reasons worth keeping the option? Keeping the option means:

 

1. The installation process asks the user an additional question.

2. A user could install the game in a way that wouldn't work in Windows or Wine.

3. We break .exe modifying hacks and mods when we remove the .exe files. So far, that seems to be the Widescreen mod. Are there any others?

 

Point two is unlikely to cause a problem because most people using Windows or Wine would simply use the standard Windows installer from the CD.

 

I assume that point three is also unlikely to be problematic because I imagine that most people who install .exe hacks know what they're doing. Is that a good assumption?

 

-----

 

Avenger, what were you referring to when you mentioned "locating gemrb override"? I'm sure it could be done (especially if ~/.gemrb was already set up correctly), but I'm a little unclear as to what you actually meant.

 

-----

 

If we go with installing a gemrb-installer.ini, what data should it contain? Is a gemrb.ini already installed, and if so, what data does it not contain that belongs in the gemrb-installer.ini? If we don't include gemrb.ini, we could easily just touch the file during installation so users know they can add data to their heart's desire.

Link to comment
It's a bit problematic because a lot of people share their game data with a "real" install which does modify the .ini and would like the settings to stay the same between both games, but perhaps we should make it an option..

 

Making it an option sounds good to me. gemrb.cfg should be the place to handle this. but we don't have to worry about it until we're saving those files in the first place ;-)

 

If we go with installing a gemrb-installer.ini, what data should it contain?

 

I currently plan to include the following information in gemrb-installer.ini (which will itself be installed into the main game directory)

 

  • gemrb-installer version number (e.g. 0.3)
  • full game name (eg Baldurs Gate 1: 5CD International version)
  • full install (eg 1)
  • patch names (eg BG1 TOTSC official UK patch v1.3.5512)
  • windows files removed (eg 1)
  • gametype (eg bg1)
  • number of cds (eg 5)

 

Is a gemrb.ini already installed, and if so, what data does it not contain that belongs in the gemrb-installer.ini?

 

At present the installers don't touch gemrb.cfg, and nor should they. However, with the gemrb-installer.ini information supplied above gemrb would have all it needed to start the game (see the recommendcfg function used after a successful install with the scripts). So we could think about allowing users to just point gemrb to the directory it was installed in, and an appropriate default gemrb.cfg could be generated. This may be best done in gemrb-launcher - your thoughts, Nick? Others? Seems to me like a good way of further reducing the bar to getting games running in gemrb.

 

I think the exe issue can be resolved just by clarifying wording. 'Do you want to keep Windows-only files (may also break compatibility with some mods)?' seems like the clearest to me.

 

The installation process asks the user an additional question.

 

Incidentally, another nice feature which I'll add soon is ability to set all options as arguments to the script, so it can be run non-interactively. This will also make it more useful for scripting and integration with package managers.

Link to comment

Hello!

I tried using installer (version 1.0.2) with PST

And it kept saying the following:

 

./pst/install-4cd-minimal.sh: 20: source: not found
./pst/install-4cd-minimal.sh: 21: source: not found
./pst/install-4cd-minimal.sh: 23: parseargs: not found
./pst/install-4cd-minimal.sh: 25: checkforbin: not found
./pst/install-4cd-minimal.sh: 27: getcd: not found

 

The script deed it's job anyway, but didn't ask if I wanted full install and patch and so on.

 

I discovered that chenging the first line of ./pst/install-4cd-minimal.sh file from #!/bin/sh to #!/bin/bash actually helps, but a lot of messages appear. Like chgrp: changing group of `new_pst_install_1/music/bt4/bt4f1.acm': Operation not permitted .

 

So I wanted to ask what it was :thumbsup: . Was it a bug? Or I should have done something to my system (Ubuntu 9.10) to make the installer perform right?

 

And... What does this message mean?

/tmp/iepatch/Trmt11.exe: library not compiled to support large files.

Link to comment
Hello!

I tried using installer (version 1.0.2) with PST

And it kept saying the following:

 

./pst/install-4cd-minimal.sh: 20: source: not found
./pst/install-4cd-minimal.sh: 21: source: not found
./pst/install-4cd-minimal.sh: 23: parseargs: not found
./pst/install-4cd-minimal.sh: 25: checkforbin: not found
./pst/install-4cd-minimal.sh: 27: getcd: not found

 

The script deed it's job anyway, but didn't ask if I wanted full install and patch and so on.

 

I discovered that chenging the first line of ./pst/install-4cd-minimal.sh file from #!/bin/sh to #!/bin/bash actually helps

 

Hi Terix, thanks for posting your experiences in detail :-) This issue is because the scripts use the 'source' command, which (I didn't realise) is bash only (and Debian/Ubuntu use dash by default). I'll change it to '.' in the next release, which will fix it.

 

, but a lot of messages appear. Like chgrp: changing group of `new_pst_install_1/music/bt4/bt4f1.acm': Operation not permitted .

 

Were you installing onto a FAT (windowsy) partition? If so, that's fine, you can ignore that. If not, that's wierd...

 

So I wanted to ask what it was :thumbsup: . Was it a bug? Or I should have done something to my system (Ubuntu 9.10) to make the installer perform right?

 

Nope, looks like you did everything right :-)

 

And... What does this message mean?

/tmp/iepatch/Trmt11.exe: library not compiled to support large files.

 

That means the ubuntu build of cabextract hasn't got 'large' file support enabled. That shouldn't be a problem at all.

 

Thanks again for the feedback, a new release will be around soon (honest!)

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...