Hi Okto,
I'm completely new to this and have made my first script. Any advice gratefully recived.
Well, as you said it's a simple script, and I didn't spot any mistake in it. The download URL was probably http://www.gog.com/gamecard/$GOGID rather than http://www.gog.com/$GOGID (you can check with games still on sale that such kind of URL results in a 404), but since as you said this game has been removed from the store it doesn't matter anymore. Maybe the URL should even be removed.
I've left 'POL_SetupWindow_SetID' blank as I don't know exactly where the numbers come from. I assume they're assigned to scripts that are approved.
This is correct, that's the entry number in the official repository, and while not explicitly displayed on pages (maybe it should?), it's not too hard to guess because it appears in several repository related URLs.
This game seems to work well with various version of wine, but I've selected a recent one which I know to work due to a complete play through with it. Is this a good or bad choice?
Latest stable Wine version is the best choice in my opinion, whenever they can be used. Experimental versions are sometimes required because of recent bug fixes or new features, or sometimes because of specific but dramatic performance improvements; But regressions do happen too, so they'd better be only used in scripts if there's an obvious benefit vs. the latest stable version.
The md5 checksum has been calculated and used, but the installer allowed me to choose and run another game's gog installer, have I done this part wrong, or perhaps it only applies to downloads rather than local files?
There's two uses for those MD5 hashes:
- To make sure downloads happened successfully, as being sure that downloads went successfully at transport layer seem hard to get right;
- To make sure the installers used are exactly the ones the script has been tested with.
They're very useful for the first point, and are definitely used for that today.
The second point is slightly less evident; I mean, I'm all for the repeatability of installations, always enforcing a static version of Wine instead of using "System" version, etc, and I really like when I get some bug report about a script to start by being sure the installer used is the same I tried, because things change between versions of their installers, times and again, so it's important to check that.
However it may happen that scripts are not updated immediately, and in fact it does happen because we have to maintain so many of them, and they're so many hours in the day (not to mention I have less time and enthusiasm about updating those scripts that I used to say until about a year and a half, because of my new job). So, not testing hashes during "local installations" give some slack for users to try different versions. It's just something that I keep in mind when I see a local installation in a debug log.
For this specific script, the fact it's no longer in the store probably means the installer may not be updated anymore, so it lessens that second point too.
I've found on my computer, the game will only run on a virtual desktop. Is this likely to be the case on all computers, or just mine? I've found that adding the line 'Set_Desktop On 800 600' below 'SET_OS win7' tells wine to use a suitable virtual desktop, but I'm hesitant to include this as the need for it may only apply to my computer. I can also get it to run in fullscreen if I set my resolution to 800x600 before launching. Is there an easier way to run this game in fullscreen, ideally for all potential users?
It's not mentionned in the AppDB entry so it could be just your setup. Some games for example can't handle anything but 4:3 resolution ratios, not to mention multiscreen setups.
Personally I'd go without setting the resolution, and just watch for users feedback (if any).
Cheers,
Pierre.
Edité par petch
