Xenos5 |
Sunday 29 March 2015 at 6:32
|
Xenos5
|
In a similar vein to my earlier Shadow of Chernobyl post, I have a proposed rewrite of the existing Clear Sky and Clear Sky Patch 1.5.10 scripts. If approved, I will submit them as contributions to the existing scripts.
As with Shadow of Chernobyl, I'd also like to request a script name change, from "S.T.A.L.K.E.R. - Clear Sky" to "S.T.A.L.K.E.R.: Clear Sky", to reflect the actual game title.
Script:
#!/bin/bash
# Date : (2015-03-30T17:30Z)
# Last revision : (2015-03-30T17:30Z)
# Distribution used to test : Arch Linux
# Author : Alexander Borysov (Xenos5)
# Script licence : GPLv3
# Program licence: Proprietary
[ "$PLAYONLINUX" = "" ] && exit 0
source "$PLAYONLINUX/lib/sources"
TITLE="S.T.A.L.K.E.R.: Clear Sky"
PREFIX="STALKERClearSky"
WINEVERSION="1.7.39"
STEAM_APP_ID=20510
POL_GetSetupImages "http://files.playonlinux.com/resources/setups/$PREFIX/top.jpg" "http://files.playonlinux.com/resources/setups/$PREFIX/left.jpg" "$TITLE"
POL_SetupWindow_Init
POL_Debug_Init
POL_SetupWindow_presentation "$TITLE" "Deep Silver" "http://stalker-game.com" "Alexander Borysov" "$PREFIX"
POL_Wine_SelectPrefix "$PREFIX"
POL_Wine_PrefixCreate "$WINEVERSION"
POL_SetupWindow_InstallMethod "DVD,STEAM,LOCAL"
if [ "$INSTALL_METHOD" = "DVD" ]; then
POL_SetupWindow_cdrom
POL_SetupWindow_check_cdrom "setup-1.bin"
POL_Wine_WaitBefore "$TITLE"
POL_Wine "$CDROM/setup.exe"
elif [ "$INSTALL_METHOD" = "STEAM" ]; then
POL_Call POL_Install_steam
cd "$WINEPREFIX/drive_c/$PROGRAMFILES/Steam"
POL_Wine "steam.exe" "steam://install/$STEAM_APP_ID"
POL_Wine_WaitExit "$TITLE"
elif [ "$INSTALL_METHOD" = "LOCAL" ]; then
POL_SetupWindow_browse "$(eval_gettext "Please select the setup file to run.")" "$TITLE"
POL_Wine_WaitBefore "$TITLE"
POL_Wine "$APP_ANSWER"
fi
POL_SetupWindow_VMS "128"
if [ "$INSTALL_METHOD" = "STEAM" ]; then
POL_Shortcut "steam.exe" "$TITLE" "${TITLE}.png" "steam://rungameid/$STEAM_APP_ID -no-dwrite"
else
binary_path=$(find_binary xrEngine.exe | sed 's|dedicated/xrEngine.exe$|xrEngine.exe|g')
#binary_path=$(POL_System_find_file "bin/xrEngine.exe") # needs commit 09735e098bc3aa6649393c9271d5f55466f35bfb, presumably in PoL 4.2.7
POL_SetupWindow_make_shortcut "$PREFIX" "$(dirname "$(dirname "$binary_path")")" "bin/xrEngine.exe" "S.T.A.L.K.E.R.: Clear Sky.png" "$TITLE" "" ""
fi
POL_SetupWindow_Close
exit
Patch:
#!/bin/bash
# Date : (2015-03-29T03:30Z)
# Last revision : (2015-03-29T03:30Z)
# Distribution used to test : Arch Linux
# Author : Alexander Borysov (Xenos5)
# Script licence : GPLv3
# Program licence: Proprietary
[ "$PLAYONLINUX" = "" ] && exit 0
source "$PLAYONLINUX/lib/sources"
TITLE_REQUIRED="S.T.A.L.K.E.R.: Clear Sky"
TITLE="$TITLE_REQUIRED Patch 1.5.10"
PREFIX="STALKERClearSky"
# Gamefront download ids for the various releases
WW_ID=14026473
DD_ID=14028245
RU_ID=14031495
POL_GetSetupImages "http://files.playonlinux.com/resources/setups/$PREFIX/top.jpg" "http://files.playonlinux.com/resources/setups/$PREFIX/left.jpg" "$TITLE"
POL_SetupWindow_Init
POL_Debug_Init
POL_SetupWindow_presentation "$TITLE" "THQ" "http://stalker-game.com" "Alexander Borysov" "$PREFIX"
if [ "$(POL_Wine_PrefixExists $PREFIX)" != "True" ]; then
POL_SetupWindow_message "$(eval_gettext 'Please install $TITLE_REQUIRED first')" "$TITLE"
POL_SetupWindow_Close
exit
fi
POL_Wine_SelectPrefix "$PREFIX"
POL_SetupWindow_InstallMethod "DOWNLOAD,LOCAL"
if [ "$INSTALL_METHOD" = "DOWNLOAD" ]; then
POL_SetupWindow_menu_num "$(eval_gettext 'Please select the game release')" "$TITLE" "$(eval_gettext 'Worldwide')~$(eval_gettext 'Digital Distribution')~$(eval_gettext 'Russian')" "~"
case $APP_ANSWER in
0)
ID=$WW_ID
ARCHIVE_NAME="stkcsforpackefigspcjhpatchany10.zip"
EXE_NAME="stkcs-for-pack-efigspcjh-patch-any-10.exe"
;;
1)
ID=$DD_ID
ARCHIVE_NAME="stkcstolpackefigspcjhpatchany10.zip"
EXE_NAME="stkcs-tol-pack-efigspcjh-patch-any-10.exe"
;;
2)
ID=$RU_ID
ARCHIVE_NAME="stkcsruspackrpatchany10fixed.zip"
EXE_NAME="stkcs-rus-pack-r-patch-any-10-fixed.exe"
;;
*)
POL_Debug_Fatal "$(eval_gettext 'Could not parse game release response')"
POL_SetupWindow_Close
exit
esac
POL_System_TmpCreate "$PREFIX"
ARCHIVE="${POL_System_TmpDir}/$ARCHIVE_NAME"
POL_Call POL_Gamefront_Download "$ID" "$POL_System_TmpDir" "$ARCHIVE" "$TITLE"
POL_System_unzip -od "$POL_System_TmpDir" "$ARCHIVE" "$EXE_NAME"
PATCHNAME="${POL_System_TmpDir}/$EXE_NAME"
elif [ "$INSTALL_METHOD" = "LOCAL" ]; then
POL_SetupWindow_browse "$(eval_gettext "Please select the setup file to run.")" "$TITLE"
PATCHNAME="$APP_ANSWER"
fi
POL_Wine "$PATCHNAME"
POL_SetupWindow_Close
exit
Description:
S.T.A.L.K.E.R.: Clear Sky, is the prequel to S.T.A.L.K.E.R.: Shadow of Chernobyl. The plot follows a mercenary called Scar, who discovers he has an "unusual ability" after surviving an enormous emission that changes the Zone to the core. This ability allows him to survive the Zone's emissions at the cost of a rapidly deteriorating nervous system. With the assistance of the new Clear Sky faction, he attempts to track down the cause of the Zone's renewed aggression before its increasingly frequent emissions destroy him.
The game includes a "faction wars" feature, wherein the player is able to join one of a multitude of factions and assist them in capturing territory in a zone-wide cross-faction turf war in exchange for getting access to that faction's base and their trader's exclusive faction inventory.
Screenshots:
22x22:
48x48:
top:
left:
Edited by Xenos5
|
petch |
Sunday 29 March 2015 at 14:08
|
petch
|
Beware that find_binary appeared as the result of a refactorization in PlayOnLinux 4.2.2 only, so if you use it you should add
POL_RequiredVersion 4.2.2 || POL_Debug_Fatal "$TITLE won't work with $APPLICATION_TITLE $VERSION\nPlease update"
Between POL_SetupWindow_Init and POL_Debug_Init
But also, this function was not meant to be part of the public interface; If the lack of documentation is not a good indicator (since the documentation is lagging behind), the lack of POL_ prefix is the sign of private functions for anything even remotely recent. Maybe some public function should be made out of it, given it seems quite useful (I even reused in POL_Shortcut_Document to lookup for files that aren't binaries, so maybe it should get a more generic name too)...
|
Xenos5 |
Sunday 29 March 2015 at 15:02
|
Xenos5
|
Well, if I make a public function out of it, then it will appear as a refactorization only in PlayOnLinux 4.2.7 ;)
But seriously, I'm not really convinced it *needs* to be part of the public interface. I, for one, am using find_binary only to ensure that the right binary gets used by POL_SetupWindow_make_shortcut. In the unfortunate case of the first two stalker games, there are two identically named binaries, one the game, and the other the dedicated multiplayer server. I'm sure this isn't an awfully common case in games out in the wild, so maybe simply exposing find_binary under some public function would suffice as a quick solution.
Otherwise, maybe create a function that takes a path suffix, and searches for any binary whose path ends in it? That way you'd be able to specify the binary relative to the game root, independently of where the user chose to install the actual game. In fact, I'm pretty sure this could be written as a backwards-compatible enhancement to find_binary, because right now it takes full paths and binary names, and we'd just have to make it take everything in between as well.
Edited by Xenos5
|
petch |
Sunday 29 March 2015 at 19:04
|
petch
|
Ah yes, I noticed the sed but forgot to talk about it; I had the same problem with some games, I don't think the result of POL_Shortcut is deterministic in this case but from my experience it seems to pick the file with the deepest path, which is rarely the one you want. So, the first thing I'd change is to pick the file with the shortest path in this case.
Your suggestion is interesting too, but I don't know how easily this could be implemented in shell with the "find" commands available on Linux and OS X...
|
Xenos5 |
Sunday 29 March 2015 at 19:34
|
Xenos5
|
Well, as it happens, I've done it. I can't actually test on Mac, but my code is not all that different from the old code, so it should work. I've submitted a pull request; we can discuss it there: https://github.com/PlayOnLinux/POL-POM-4/pull/28
Also, as it happens, this change, while I think is good, doesn't entirely solve my problem. It solves the sed bit I do, but I still need to specify the directory to cd into, which I do by finding the directory of the binary, then 'dirname'ing it twice. So perhaps another change to expose find_binary under a POL_ prefix is in order?
|
petch |
Sunday 29 March 2015 at 20:01
|
petch
|
Yes, post filtering with grep, I was thinking of that too; I'm not sure we're not loosing some efficiency here (find does clever tricks, now we'd just be using it to list all paths), but at least it should work.
Use grep -i though, the old code what case insensitive, and that's very likely the right thing to do while dealing with "Windows" paths.
I was wondering if some "fast path" when some path with "/"s is provided should be kept, for example if it was used to lift an ambiguity, or if scanning the whole prefix what deemed too slow; Maybe something like "if $WINEPREFIX/drive_c/$argument exist, use that". Making it case insensitive would be much harder so it would only be fast if the correct case is provided though.
I'm not sure the interface can be changed to avoid the dirnames, you can't really return a tuple with shell functions ;)
So "$(dirname $(dirname $path))" or "$(dirname $path)/.." are probably unavoidable in shell style.
|
petch |
Sunday 29 March 2015 at 20:05
|
petch
|
Ah, also, old find_binary allowed for fnmatch() wildcard in its parameter (now it's even documented ;) ), using grep make it accept grep regex instead, so it's not strictly backward compatible
PS find seems to accept -ipath that would do what we want, it seems to be supported by BSD find too, but I need to check with a Mac
Edited by petch
|
petch |
Sunday 29 March 2015 at 22:44
|
petch
|
I tested find -ipath and it works on OS X
But as you said it won't solve your problem unless 4.2.7 is out (or widely in use, even :p )
|
Xenos5 |
Sunday 29 March 2015 at 23:25
|
Xenos5
|
Yeah, saw your patch and closed the pull request. Man, soooo many edge cases and stuff.
As you said, I'm gonna need to wait until 4.2.7, but the widely in use bit worries me. I mean, will I have to write two implementations for >= 4.2.7 and for < 4.2.7? And how long does that need to be maintained? I know the likes of Ubuntu and Debian are pretty slow to take on package updates sometimes, so what's the usual delay for PoL?
And in fact, if I'm going to need to support old and new versions, I may as well update the script now, simply letting the POL_RequiredVersion 4.2.7 check fail until it's actually released.
|
petch |
Sunday 29 March 2015 at 23:52
|
petch
|
Our internal policy is to support versions at least one year after the next version has been out, however as you said old versions can be around for a much longer time whether we officially support it or not: there's still plenty of 4.0.14 around...
You could support both with
POL_RequiredVersion 4.2.2
...
VersionLower "$VERSION" 4.2.7 && \
binary_path=$(find_binary xrEngine.exe | sed 's|dedicated/xrEngine.exe$|xrEngine.exe|g') || \
binary_path="$(POL_System_find_file xrEngine.exe)"
But I don't think it's worth the extra complexity; Just leave your code as-is for now, maybe just keeping the POL_System_find_file version in a comment as a reminder for a year (or two :p )
Edited by petch
|
Xenos5 |
Monday 30 March 2015 at 19:34
|
Xenos5
|
|
petch |
Monday 30 March 2015 at 19:55
|
petch
|
|
Xenos5 |
Monday 30 March 2015 at 19:59
|
Xenos5
|
Screenshots and descriptions? :'(
(And icons and images?)
((And script name?))
(((Thank you :D)))
|
petch |
Monday 30 March 2015 at 20:58
|
petch
|
Oups, forgot to check those, that should be fixed now :)
|
Xenos5 |
Monday 30 March 2015 at 22:22
|
Xenos5
|
Thanks. What about the script name change? Do you disagree with it, or did you just forget?
|
petch |
Monday 30 March 2015 at 22:36
|
petch
|
Changed, actually since it has to match $TITLE (for the automated bug reporting to work correctly) it had to be changed
|
Xenos5 |
Monday 30 March 2015 at 22:37
|
Xenos5
|
|