Bug#788057: game-data-packager: please add support for Blake Stone: Aliens of Gold and Planet Strike

[Fabian Greffrath]

Package: game-data-packager
Version: 41
Severity: wishlist

Hi Alexandre and Simon,

Blake Stone is a series of two nice FPS from the 1994 era based on a
modified Wolf3d engine. The source code to this engine has currently
been released to the public [1] and first source ports have already
emerged [2].

I seriously consider packaging ECWolf [3], which is a very advanced source
port of the Wolf3d engine with support for all of Wolf3d, SOD and even
Noah's Ark 3D in one binary. I have just contacted the author of
ECWolf and he told me that adding support for the Blake Stone games is
a work in progres. So, once this is ready, it would be very helpful if
g-d-p could already support packaging the corresponding game data for
the Blake Stone games.

Thanks!

Fabian



[1]
http://www.apogeesoftware.com/uncategorized/apogee-releases-blake-stone-source-code
[2] https://github.com/bibendovsky/bstone
[3] http://maniacsvault.net/ecwolf/


-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages game-data-packager depends on:
ii fakeroot 1.20.2-1
ii python3 3.4.2-2
ii python3-debian 0.1.27
ii python3-yaml 3.11-2
pn python3:any <none>

game-data-packager recommends no packages.

Versions of packages game-data-packager suggests:
pn arj <none>
ii binutils 2.25-7
ii cabextract 1.6-1
ii cdparanoia 3.10.2+debian-11
ii dynamite 0.1.1-2
ii gcc 4:5-3
ii gir1.2-gtk-3.0 3.14.5-1
ii gir1.2-pango-1.0 1.36.8-3
pn innoextract <none>
pn lgc-pg <none>
pn lhasa | jlha-utils | lzh-archiver <none>
ii make 4.0-8.1
ii p7zip-full 9.20.1~dfsg.1-4.1
ii python3-gi 3.14.0-1
pn unace-nonfree <none>
pn unrar-nonfree <none>
ii unshield 1.0-1
ii unzip 6.0-17
ii vorbis-tools 1.4.0-6

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Alexandre Detiste]

control: tag 788057 +newcomer
control: clone 788057 -2
control: retitle -2 g-d-p: please add support for Noah's Ark 3D

> Blake Stone is a series of two nice FPS from the 1994 era based on a
> modified Wolf3d engine. The source code to this engine has currently
> been released to the public [1] and first source ports have already
> emerged [2].

That's nice. I have the data, they are sold
in the same Steam bundle as ROTT.

> Noah's Ark 3D
This one I don't have, nor I care; so I cloned the bug.

Anyone interested just need to run:
"game-data-packager make-template <directory with assets>"
and reply on this bug.

Alexandre

[Alexandre Detiste]

So,

What should be the package names & install path ?
I would go with
*) blakestone-data : usr/share/games/blakestone
*) planetstrike-data : usr/share/games/planetstrike



I have _two_ slightly different versions of "Blake Stone : Aliens of
Gold" both from Steam(*)
with different MAPTEMP, VGAGRAPH, VGAHEAD, VSWAP.

Can you map this to version numbers ?
(maybe just having a look at title screen is enough)

I guess we need to support both, and the shareware version too;
if ECWolf plans to support it too.

I wish I could find needed info there:
http://maniacsvault.net/ecwolf/wiki/Game_data

-> does this also means ECWolf only support the Wolf3D v1.4 shipped on
Steam (!?)
but not others v1.4 &v1.2 versions ?

---------------------------

(*) This shouldn't be possible, because Steam upgrade software automatically,
but I had tricked the Linux version to download the Windows package (
see #775365 ).
It seems that when doing this, Steam gets confused and never upgrade the package
(so we'd better of download to /tmp ) ....

$ ls ../../.steam/SteamApps/common/The\ Apogee\ Throwback\ Pack/Blake\
Stone/ -l
-rw-r--r-- 1 tchet tchet 1280 déc 30 2013 AUDIOHED.BS6
-rw-r--r-- 1 tchet tchet 267636 déc 30 2013 AUDIOT.BS6
-rw-r--r-- 1 tchet tchet 186221 déc 30 2013 EANIM.BS6
-rw-r--r-- 1 tchet tchet 219918 déc 30 2013 GANIM.BS6
-rw-r--r-- 1 tchet tchet 18977 déc 30 2013 IANIM.BS6
-rw-r--r-- 1 tchet tchet 834 déc 30 2013 MAPHEAD.BS6
-rw-r--r-- 1 tchet tchet 520920 déc 30 2013 MAPTEMP.BS6
-rw-r--r-- 1 tchet tchet 276784 déc 30 2013 SANIM.BS6
-rw-r--r-- 1 tchet tchet 2878696 déc 30 2013 SVSWAP.BS6
-rw-r--r-- 1 tchet tchet 1024 déc 30 2013 VGADICT.BS6
-rw-r--r-- 1 tchet tchet 596336 déc 30 2013 VGAGRAPH.BS6
-rw-r--r-- 1 tchet tchet 639 déc 30 2013 VGAHEAD.BS6
-rw-r--r-- 1 tchet tchet 2767592 déc 30 2013 VSWAP.BS6
-rw-r--r-- 1 tchet tchet 2642 déc 30 2013 LICENSE.DOC
-rw-r--r-- 1 tchet tchet 8299535 déc 30 2013 manual.pdf
-rw-r--r-- 1 tchet tchet 4286 déc 30 2013 game.ico

$ ls ../../.PlayOnLinux/wineprefix/Steam/drive_c/Program\
Files/Steam/SteamApps/common/The\ Apogee\ Thro
wback\ Pack/Blake\ Stone/ -l
total 16124
-rw-r--r-- 1 tchet tchet 1280 jan 1 20:36 AUDIOHED.BS6
-rw-r--r-- 1 tchet tchet 267636 jan 1 20:36 AUDIOT.BS6
-rw-r--r-- 1 tchet tchet 186221 jan 1 20:36 EANIM.BS6
-rw-r--r-- 1 tchet tchet 219918 jan 1 20:36 GANIM.BS6
-rw-r--r-- 1 tchet tchet 18977 jan 1 20:36 IANIM.BS6
-rw-r--r-- 1 tchet tchet 834 jan 1 20:36 MAPHEAD.BS6
-rw-r--r-- 1 tchet tchet 526196 jan 1 20:36 MAPTEMP.BS6
-rw-r--r-- 1 tchet tchet 276784 jan 1 20:36 SANIM.BS6
-rw-r--r-- 1 tchet tchet 2878696 jan 1 20:36 SVSWAP.BS6
-rw-r--r-- 1 tchet tchet 1024 jan 1 20:36 VGADICT.BS6
-rw-r--r-- 1 tchet tchet 599397 jan 1 20:36 VGAGRAPH.BS6
-rw-r--r-- 1 tchet tchet 672 jan 1 20:36 VGAHEAD.BS6
-rw-r--r-- 1 tchet tchet 2767080 jan 1 20:36 VSWAP.BS6
-rw-r--r-- 1 tchet tchet 2642 jan 1 20:36 LICENSE.DOC
-rw-r--r-- 1 tchet tchet 8299535 jan 1 20:36 manual.pdf

[Fabian Greffrath]

Am Montag, den 08.06.2015, 14:34 +0200 schrieb Alexandre Detiste:
> What should be the package names & install path ?
> I would go with
> *) blakestone-data : usr/share/games/blakestone
> *) planetstrike-data : usr/share/games/planetstrike

I find that reasonable. While both games are officially called "Blake
Stone: Aliens of Gold" and "Blake Stone: Planet Strike", if you have a
look at the sale boxes, "Blake Stone" is emphazised for the first game
and "Planet Strike" for the latter.

I believe the game data for both games could go into
usr/share/games/blakestone (or even /usr/share/games/wolf3d ?) since
there a no file name conflicts expected, but I do not have a strong
opinion about that.

> Can you map this to version numbers ?
> (maybe just having a look at title screen is enough)

Not at the moment. But I have the version from GOG and it is as
follows:

$ cksum *.bs6
3161695409 1280 audiohed.bs6
420589065 267636 audiot.bs6
1114871724 186221 eanim.bs6
252307268 219918 ganim.bs6
57848105 18977 ianim.bs6
2706058191 834 maphead.bs6
2216597167 526196 maptemp.bs6
1537594560 276784 sanim.bs6
988152586 2878696 svswap.bs6
3201727701 1024 vgadict.bs6
1530478405 599397 vgagraph.bs6
2416181072 672 vgahead.bs6
248005271 2767080 vswap.bs6

> I wish I could find needed info there:
> http://maniacsvault.net/ecwolf/wiki/Game_data

Well, the games are not yet supported by ECWolf. But I am sure the
author will add the necessary data there once they are supported.

> -> does this also means ECWolf only support the Wolf3D v1.4 shipped
> on
> Steam (!?)
> but not others v1.4 &v1.2 versions ?

Yes, probably, I haven't checked yet.

Package-wise this would mean "Conflicts: wolf3d-v12-data", right?


- Fabian

[Fabian Greffrath]

Am Montag, den 08.06.2015, 14:34 +0200 schrieb Alexandre Detiste:

> Can you map this to version numbers ?
> (maybe just having a look at title screen is enough)

My Aliens of Gold does not show any version number, but my Planet
Strike shows it's v1.01.

- Fabian

[Alexandre Detiste]

> But I have the version from GOG

It's the same as what is currently on Steam.

Can you please provide output of:

1) lgogdownloader --list | grep blakestone, if you've never used it
before, it's best to run a plain "lgogdownloader"
first to let it interactively ask username & password and create a
security cookie.

2) game-data-packager make-template setup_<blake_stone_something>.exe

3) innoextract -l setup_<blake_stone_something>.exe

(step 3 could be automated into step 2, when this got implemented
https://github.com/dscharrer/innoextract/issues/17)

[Fabian Greffrath]

Am Montag, den 08.06.2015, 15:42 +0200 schrieb Alexandre Detiste:
> 1) lgogdownloader --list | grep blakestone, if you've never used it

$ lgogdownloader --list | grep blake_stone
blake_stone_aliens_of_gold
blake_stone_planet_strike

> 2) game-data-packager make-template setup_<blake_stone_something>.exe

$ game-data-packager make-template setup_blake_stone_aliens_of_gold_2.0.0.2.exe
_ 26888888 setup_blake_stone_aliens_of_gold_2.0.0.2.exe
b1686e263da9e836e67b64a2946a3222 setup_blake_stone_aliens_of_gold_2.0.0.2.exe
911ca4507713b091767664ef1d10a5850c573ffe setup_blake_stone_aliens_of_gold_2.0.0.2.exe
f19739d68493c0c72d749ef4133e5381c73d144a68e00f6dfd5cb8b5926393ef setup_blake_stone_aliens_of_gold_2.0.0.2.exe

$ game-data-packager make-template setup_blake_stone_planet_strike_2.0.0.2.exe
_ 21659584 setup_blake_stone_planet_strike_2.0.0.2.exe
2230bde51bc598440c14c978669209eb setup_blake_stone_planet_strike_2.0.0.2.exe
5171c5855d0df6ae38893aa80a072045efe5e06c setup_blake_stone_planet_strike_2.0.0.2.exe
3c8e508b6aa50134b8bc04498d73a26f266e3a81d14ba3e7fcca93f122699b12 setup_blake_stone_planet_strike_2.0.0.2.exe

> 3) innoextract -l setup_<blake_stone_something>.exe

$ innoextract setup_blake_stone_aliens_of_gold_2.0.0.2.exe
Extracting "Blake Stone - Aliens of Gold" - setup data version 5.5.0
(unicode)
- "app/AUDIOHED.BS6" (1.25 KiB)
- "app/AUDIOT.BS6" (261 KiB)
- "app/BS-HELP.EXE" (30.5 KiB)
- "app/BSTONE.BAT" (97 B)
- "app/BS_AOG.EXE" (137 KiB)
- "app/dosboxBlakeAOG.conf" (10.5 KiB)
- "app/dosboxBlakeAOG_single.conf" (113 B)
- "app/EANIM.BS6" (182 KiB)
- "app/FILE_ID.DIZ" (447 B)
- "app/GANIM.BS6" (215 KiB)
- "app/IANIM.BS6" (18.5 KiB)
- "app/INSTALL.INI" (116 B)
- "app/JAMERR.EXE" (10.9 KiB)
- "app/JM_ERROR.H" (9.39 KiB)
- "app/MAPHEAD.BS6" (834 B)
- "app/MAPTEMP.BS6" (514 KiB)
- "app/SANIM.BS6" (270 KiB)
- "app/SETBLAST.EXE" (72 KiB)
- "app/SVSWAP.BS6" (2.75 MiB)
- "app/VGADICT.BS6" (1.02e+03 B)
- "app/VGAGRAPH.BS6" (585 KiB)
- "app/VGAHEAD.BS6" (672 B)
- "app/VSWAP.BS6" (2.64 MiB)
- "app/manual.pdf" (8.07 MiB)
- "app/gfw_high.ico" (128 KiB)
- "app/goggame.dll" (279 KiB)
- "app/DOSBOX/dosbox-0.74.tar.gz" (1.21 MiB)
- "app/DOSBOX/DOSBox.exe" (3.55 MiB)
- "app/DOSBOX/SDL.dll" (438 KiB)
- "app/DOSBOX/SDL_net.dll" (13 KiB)
- "app/DOSBOX/GOGDOSConfig.exe" (7.07 MiB)
- "tmp/QTEULA.txt" (27.7 KiB)
- "tmp/dosboxEULA.txt" (19.3 KiB)
- "tmp/FoxitReader.exe" (2.57 MiB)
- "tmp/get_hw_caps.dll" (76.7 KiB)
- "app/GameuxInstallHelper.dll" (94 KiB)
- "app/gog.ico", "tmp/gog.ico" (67.6 KiB)
- "tmp/botva2.dll" (35 KiB)
- "tmp/crcdll.dll" (64.5 KiB)
- "tmp/md5log.ini" (7 B)
- "tmp/InnoCallback.dll" (63.5 KiB)
- "tmp/EULA.txt" (0 B)
- "tmp/14.Wing-Commander-Privateer.png" (1.16 MiB)
- "tmp/15.Rise-of-The-Triad.png" (1.34 MiB)
- "tmp/10.Bloodrayne.png" (1.07 MiB)
- "tmp/02.Far-Cry.png" (1.56 MiB)
- "tmp/03.Postal-2-Complete.png" (1.39 MiB)
- "tmp/GOGPACKBLAKESTONEALIENSOFGOLD.ini" (664 B)
- "tmp/background.png" (4.84 KiB)
- "tmp/bg-...@2x.jpg" (1.22 KiB)
- "tmp/BigFail.png" (1.63 KiB)
- "tmp/BigFail200.png" (3.41 KiB)
- "tmp/BigOK.png" (3.33 KiB)
- "tmp/BigOK200.png" (12.8 KiB)
- "tmp/BigWarn.png" (1.58 KiB)
- "tmp/BigWarn200.png" (3.27 KiB)
- "tmp/bottombar.png" (340 B)
- "tmp/bottombar200.png" (938 B)
- "tmp/btn_browse.png" (4.82 KiB)
- "tmp/btn_browse200.png" (11.5 KiB)
- "tmp/btn_close.png" (3.36 KiB)
- "tmp/btn_close200.png" (9.33 KiB)
- "tmp/btn_continue.png" (4.18 KiB)
- "tmp/btn_continue200.png" (11.2 KiB)
- "tmp/btn_exit.png" (3.76 KiB)
- "tmp/btn_exit200.png" (8.37 KiB)
- "tmp/btn_launch.png" (9.96 KiB)
- "tmp/btn_launch200.png" (21.5 KiB)
- "tmp/btn_md5.png" (8.73 KiB)
- "tmp/btn_md5200.png" (12.5 KiB)
- "tmp/btn_options.png" (5.01 KiB)
- "tmp/btn_options200.png" (12.5 KiB)
- "tmp/btn_save_as.png" (5.64 KiB)
- "tmp/btn_save_as200.png" (15.6 KiB)
- "tmp/btn_skip.png" (3.23 KiB)
- "tmp/btn_skip200.png" (8.52 KiB)
- "tmp/btn_start.png" (4.21 KiB)
- "tmp/btn_start200.png" (9.59 KiB)
- "tmp/btn_tryagain.png" (10.5 KiB)
- "tmp/btn_tryagain200.png" (24.2 KiB)
- "tmp/error.png" (726 B)
- "tmp/error200.png" (1.78 KiB)
- "tmp/error_icon.png" (1.44 KiB)
- "tmp/error_icon200.png" (2.14 KiB)
- "tmp/EULA.png" (2.32 KiB)
- "tmp/EULA200.png" (10.5 KiB)
- "tmp/EULAAccepted.png" (2.63 KiB)
- "tmp/EULAAccepted200.png" (11.4 KiB)
- "tmp/EULAShow.png" (1.47 KiB)
- "tmp/EULAShow200.png" (2.15 KiB)
- "tmp/EULA_bkg.png" (3.52 KiB)
- "tmp/GOG.png" (3.45 KiB)
- "tmp/GOG200.png" (5.29 KiB)
- "tmp/ok.png" (1.18 KiB)
- "tmp/ok200.png" (2.18 KiB)
- "tmp/OpenSans-Regular.ttf" (212 KiB)
- "tmp/OpenSans-Semibold.ttf" (216 KiB)
- "tmp/progress_center.png" (1.12 KiB)
- "tmp/progress_center200.png" (1.26 KiB)
- "tmp/progress_left.png" (1.15 KiB)
- "tmp/progress_left200.png" (792 B)
- "tmp/progress_right.png" (1.15 KiB)
- "tmp/progress_right200.png" (828 B)
- "tmp/scroll-handle-bot.png" (1 KiB)
- "tmp/scroll-handle-top.png" (1.01 KiB)
- "tmp/trackbar_back.png" (1.7 KiB)
- "tmp/trackbar_back200.png" (4.4 KiB)
- "tmp/trackbar_btn.png" (2 KiB)
- "tmp/trackbar_btn200.png" (5.65 KiB)
- "tmp/track_center.png" (1.09 KiB)
- "tmp/track_center200.png" (1.21 KiB)
- "tmp/track_left.png" (1.11 KiB)
- "tmp/track_left200.png" (558 B)
- "tmp/track_right.png" (1.12 KiB)
- "tmp/track_right200.png" (557 B)
- "app/Support.ico" (61.4 KiB)
- "tmp/GOG_EULA.txt" (7.33 KiB)
- "tmp/background.jpg" (97.5 KiB)
Done.

$ innoextract setup_blake_stone_planet_strike_2.0.0.2.exe
Extracting "Blake Stone - Planet Strike" - setup data version 5.5.0
(unicode)
- "app/AUDIOHED.VSI" (1.26 KiB)
- "app/AUDIOT.VSI" (297 KiB)
- "app/BS_FIRE.EXE" (141 KiB)
- "app/dosboxBlakePS.conf" (10.5 KiB)
- "app/dosboxBlakePS_single.conf" (114 B)
- "app/EANIM.VSI" (362 KiB)
- "app/IANIM.VSI" (18.5 KiB)
- "app/JAMERR.EXE" (21.6 KiB)
- "app/JM_ERROR.H" (10.8 KiB)
- "app/MAPHEAD.VSI" (834 B)
- "app/MAPTEMP.VSI" (163 KiB)
- "app/ORDER.FRM" (5.58 KiB)
- "app/PLANET.BAT" (102 B)
- "app/PSHELP.EXE" (18.2 KiB)
- "app/SETBLAST.EXE" (75 KiB)
- "app/VGADICT.VSI" (1.02e+03 B)
- "app/VGAGRAPH.VSI" (694 KiB)
- "app/VGAHEAD.VSI" (747 B)
- "app/VSWAP.VSI" (3.05 MiB)
- "app/Manual.pdf" (3.89 MiB)
- "app/gfw_high.ico" (127 KiB)
- "app/goggame.dll" (279 KiB)
- "app/DOSBOX/dosbox-0.74.tar.gz" (1.21 MiB)
- "app/DOSBOX/DOSBox.exe" (3.55 MiB)
- "app/DOSBOX/SDL.dll" (438 KiB)
- "app/DOSBOX/SDL_net.dll" (13 KiB)
- "app/DOSBOX/GOGDOSConfig.exe" (7.07 MiB)
- "tmp/QTEULA.txt" (27.7 KiB)
- "tmp/dosboxEULA.txt" (19.3 KiB)
- "tmp/FoxitReader.exe" (2.57 MiB)
- "tmp/get_hw_caps.dll" (76.7 KiB)
- "app/GameuxInstallHelper.dll" (94 KiB)
- "app/gog.ico", "tmp/gog.ico" (67.6 KiB)
- "tmp/botva2.dll" (35 KiB)
- "tmp/crcdll.dll" (64.5 KiB)
- "tmp/md5log.ini" (7 B)
- "tmp/InnoCallback.dll" (63.5 KiB)
- "tmp/EULA.txt" (0 B)
- "tmp/14.Wing-Commander-Privateer.png" (1.16 MiB)
- "tmp/15.Rise-of-The-Triad.png" (1.34 MiB)
- "tmp/10.Bloodrayne.png" (1.07 MiB)
- "tmp/02.Far-Cry.png" (1.56 MiB)
- "tmp/03.Postal-2-Complete.png" (1.39 MiB)
- "tmp/GOGPACKBLAKESTONEPLANETSTRIKE.ini" (664 B)
- "tmp/background.png" (4.84 KiB)
- "tmp/bg-...@2x.jpg" (1.22 KiB)
- "tmp/BigFail.png" (1.63 KiB)
- "tmp/BigFail200.png" (3.41 KiB)
- "tmp/BigOK.png" (3.33 KiB)
- "tmp/BigOK200.png" (12.8 KiB)
- "tmp/BigWarn.png" (1.58 KiB)
- "tmp/BigWarn200.png" (3.27 KiB)
- "tmp/bottombar.png" (340 B)
- "tmp/bottombar200.png" (938 B)
- "tmp/btn_browse.png" (4.82 KiB)
- "tmp/btn_browse200.png" (11.5 KiB)
- "tmp/btn_close.png" (3.36 KiB)
- "tmp/btn_close200.png" (9.33 KiB)
- "tmp/btn_continue.png" (4.18 KiB)
- "tmp/btn_continue200.png" (11.2 KiB)
- "tmp/btn_exit.png" (3.76 KiB)
- "tmp/btn_exit200.png" (8.37 KiB)
- "tmp/btn_launch.png" (9.96 KiB)
- "tmp/btn_launch200.png" (21.5 KiB)
- "tmp/btn_md5.png" (8.73 KiB)
- "tmp/btn_md5200.png" (12.5 KiB)
- "tmp/btn_options.png" (5.01 KiB)
- "tmp/btn_options200.png" (12.5 KiB)
- "tmp/btn_save_as.png" (5.64 KiB)
- "tmp/btn_save_as200.png" (15.6 KiB)
- "tmp/btn_skip.png" (3.23 KiB)
- "tmp/btn_skip200.png" (8.52 KiB)
- "tmp/btn_start.png" (4.21 KiB)
- "tmp/btn_start200.png" (9.59 KiB)
- "tmp/btn_tryagain.png" (10.5 KiB)
- "tmp/btn_tryagain200.png" (24.2 KiB)
- "tmp/error.png" (726 B)
- "tmp/error200.png" (1.78 KiB)
- "tmp/error_icon.png" (1.44 KiB)
- "tmp/error_icon200.png" (2.14 KiB)
- "tmp/EULA.png" (2.32 KiB)
- "tmp/EULA200.png" (10.5 KiB)
- "tmp/EULAAccepted.png" (2.63 KiB)
- "tmp/EULAAccepted200.png" (11.4 KiB)
- "tmp/EULAShow.png" (1.47 KiB)
- "tmp/EULAShow200.png" (2.15 KiB)
- "tmp/EULA_bkg.png" (3.52 KiB)
- "tmp/GOG.png" (3.45 KiB)
- "tmp/GOG200.png" (5.29 KiB)
- "tmp/ok.png" (1.18 KiB)
- "tmp/ok200.png" (2.18 KiB)
- "tmp/OpenSans-Regular.ttf" (212 KiB)
- "tmp/OpenSans-Semibold.ttf" (216 KiB)
- "tmp/progress_center.png" (1.12 KiB)
- "tmp/progress_center200.png" (1.26 KiB)
- "tmp/progress_left.png" (1.15 KiB)
- "tmp/progress_left200.png" (792 B)
- "tmp/progress_right.png" (1.15 KiB)
- "tmp/progress_right200.png" (828 B)
- "tmp/scroll-handle-bot.png" (1 KiB)
- "tmp/scroll-handle-top.png" (1.01 KiB)
- "tmp/trackbar_back.png" (1.7 KiB)
- "tmp/trackbar_back200.png" (4.4 KiB)
- "tmp/trackbar_btn.png" (2 KiB)
- "tmp/trackbar_btn200.png" (5.65 KiB)
- "tmp/track_center.png" (1.09 KiB)
- "tmp/track_center200.png" (1.21 KiB)
- "tmp/track_left.png" (1.11 KiB)
- "tmp/track_left200.png" (558 B)
- "tmp/track_right.png" (1.12 KiB)
- "tmp/track_right200.png" (557 B)
- "app/Support.ico" (61.4 KiB)
- "tmp/GOG_EULA.txt" (7.33 KiB)
- "tmp/background.jpg" (118 KiB)
Done.

[Alexandre Detiste]

Found this:
http://www.classicdosgames.com/game/Blake_Stone:_Aliens_of_Gold.html

So there are 4 versions: 1.0, 2.0, 2.1, 2.1., 3.0;
with 3.0 being the one currenlty on GOG & Steam.

Patches:

Blake Stone: Aliens of Gold Registered v2.1 to v3.0 Episodes 1-6 patch (797,606 bytes) 31 January 1999 DOS
Blake Stone: Aliens of Gold Registered v2.0 to v2.1 Episodes 1-6 patch (323,304 bytes) 1 July 1994 DOS
Blake Stone: Aliens of Gold Registered v1.0 to v2.0 Episodes 1-6 patch (751,113 bytes) 11 February 1994 DOS

$ unzip bs30pat6.zip
Archive: bs30pat6.zip
inflating: INSTALL.EXE
inflating: FILE_ID.DIZ
inflating: BS30PAT6.SHR

$ id-shr-extract BS30PAT6.SHR
decompressing: patch.rtp, compressed size: 628626
decompressing: patch.exe, compressed size: 20027
decompressing: patchw32.dll, compressed size: 90425
decompressing: patchme.exe, compressed size: 2217

--> same tool also used for Doom patching, not yet reverse-engeneered;
still commercialy avalaible, but not for retail:

http://www.pocketsoft.com/rtpatch_binary_diff_games.html
http://www.pocketsoft.com/wp_rtptech.html

$ strings patch.rtp | grep BS6 | sort -u
5VGAHEAD.BS6
`.AUDIOHED.BS6
AUDIOHED.BS6
AUDIOT.BS6
=EANIM.BS6
EANIM.BS6
GANIM.BS6
,:IANIM.BS6
....

[Alexandre Detiste]

more bits of info found online:

----

http://steamcommunity.com/app/238050/discussions/0/616188677683502209/?insideModal=1
"Did Blake Stone ever get patched?
I know a while ago there was talk on updating the bundled
versions of Blake Stone with the official patches but I can't find any more information."

"Aliens Of Gold is still 1.0" 23/9/2014

"It did now, pushing the update live with new Dosbox this week!" 20/9/2014

-------


http://www.gog.com/forum/blake_stone_series/not_the_final_version

"Versions 3.0 and 2.1 are essentially the exact same. There was one distinction: a price drop.
Originally version 2.1 sold for 29.95$, and then Apogee dropped the price,
and they re-released the game as "3.0", but the game itself is exactly the same."

---

http://legacy.3drealms.com/downloads.html

[Fabian Greffrath]

Am Dienstag, den 09.06.2015, 07:48 +0200 schrieb Alexandre Detiste:
> more bits of info found online:

That's interesting!

So, for Aliens of Gold we can treat 2.1 and 3.0 as equivalent
alternatives. Now we just need to find old data files of the pre-2.1
versions for the missing checksums.

- Fabian

[Alexandre Detiste]

>> -> does this also means ECWolf only support the Wolf3D v1.4 shipped
>> on Steam (!?)
>> but not others v1.4 &v1.2 versions ?
>
> Yes, probably, I haven't checked yet.
>
> Package-wise this would mean "Conflicts: wolf3d-v12-data", right?

Hum no, I'd like to be able to play Wolf3D v1.2 with wolf4sdl
and Blake Stone with ECwolf on the same system.

ECwolf should really checksums the data at game start.
(just check file size like wolf4sdl wrapper is already ok)

[Simon McVittie]

On Mon, 08 Jun 2015 at 09:02:31 +0200, Fabian Greffrath wrote:
> Blake Stone is a series of two nice FPS from the 1994 era based on a
> modified Wolf3d engine.

Alexandre,
The commit message for data/blakestone.yaml says "WIP". Do you consider
this to be ready for release, or should I disable it for g-d-p 42?

> I have just contacted the author of
> ECWolf and he told me that adding support for the Blake Stone games is
> a work in progres.

Do we want to disable the generation of these packages until a suitable
ecwolf exists, at least upstream?

S

[Alexandre Detiste]

2015-06-25 11:00 GMT+02:00 Simon McVittie <sm...@debian.org>:
> The commit message for data/blakestone.yaml says "WIP". Do you consider
> this to be ready for release, or should I disable it for g-d-p 42?

G-D-P already support the one version (to be) supported by ecwolf.

What remains to be done is locating v1.00
& firing-up DOSBox to apply the patches one by one to get the checksums
of all intermediate versions and tag them as "unsuitable".
(or get someone to reverse-engineer patch.exe)

So support for this get is not yet optimal, but already pretty good,
especially for Steam or GOG that both ships now latest version.

I can finish this soon.

> Do we want to disable the generation of these packages until a suitable
> ecwolf exists, at least upstream?

That's what I was thinking of when I added is_available();
this is better than having a flag in the yaml file;
because this got evaluated a run-time,
and then there is no hurry to release a new GDP each
time a new engine lands in the archive.

And this also recognize the .deb's provided by
upstream game engine projects.

Disabling it completely seems a bit too much;
maybe showing a warning and/or a confirmation prompt would be more appropriate,
and/or just always enable those if DEBEMAIL is set ?


There are tens of half-done engine recreations that
could be added to GDP to eventually help their development.
https://en.wikipedia.org/wiki/List_of_game_engine_recreations

Alexandre

[Alexandre Detiste]

Le lundi 8 juin 2015, 10:00:44 Alexandre Detiste a écrit :
> > Noah's Ark 3D
> This one I don't have, nor I care; so I cloned the bug.

Eating my own words here, as upstream (ecwolf)
say buying this game is the best way to support his efforts
and he only mapy back a little fee to license this game.

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/commit/?id=385a6b991146016360459121d0c884bd954c13ab

Like for Strife, the non-official engine has become the official thing.

What's the purpose of these two files: ?
- noah3d.pk3
- noah3d.wad

Can't get these to work with a Doom engine or ioquake3

[Fabian Greffrath]

Am Montag, den 29.06.2015, 17:33 +0200 schrieb Alexandre Detiste:
> http://anonscm.debian.org/cgit/pkg-games/game-data
> -packager.git/commit/?id=385a6b991146016360459121d0c884bd954c13ab

At first sight, I believed you got the game's name messed up. Back in
the SNES days it was known as "Super Noah's Ark 3D". But it seems the
official name for the re-release is now "Super 3-D Noah's Ark" just as
you named it. B-)

- Fabian

[Fabian Greffrath]

Am Montag, den 29.06.2015, 17:33 +0200 schrieb Alexandre Detiste:

> What's the purpose of these two files: ?
> - noah3d.pk3
> - noah3d.wad

Honestly, I don't know. After all, they are just archive file formats
and could be used in versatile ways. The pk3 format, for example, is
just a ZIP file and is often used for ZDoom mods, and ECWolf reportedly
has imported a lot of features from ZDoom.

It will be best to just have a look inside the ECWolf source code and
see what it does with these two files.

- Fabian

[Fabian Greffrath]

Hi Alexandre,

Am Montag, den 29.06.2015, 17:33 +0200 schrieb Alexandre Detiste:

> What's the purpose of these two files: ?

I just got in contact with ECWolf's upstream author (CC:ed) and he
provided some clarification on the role of these two files. Relaying
here with his permission:

> Anyhow, I stumbled across the thread on the Debian mailing list
> wondering about noah3d.wad and noah3d.pk3. The PK3 is ecwolf.pk3 with
> minor adjustments for the commercial release. The WAD serves a
> similar purpose as SVE.WAD does for Strife. It contains all the
> changes for the 20th anniversary edition and can be used with base
> ECWolf by loading manually.
>
> The pk3 should not be installed since it's tied to the binary
> version. The WAD can be installed if you like, but it will likely
> change from time to time as S3DNA updates. You can find the wad in
> the S3DNA repo, although without the SC-55 music pack integrated
> (don't feel like dumping 17MB of music into the repo).
>
> The reason for the two separate files is the PK3 is loaded before
> anything else (allowing game data to load) and the WAD contains some
> resources which override the base game data, thus needs to load after
> the n3d files.

Cheers,

Fabian

[Alexandre Detiste]

2015-06-30 9:55 GMT+02:00 Fabian Greffrath <fab...@debian.org>:
> I just got in contact with ECWolf's upstream author (CC:ed) and he
> provided some clarification on the role of these two files. Relaying
> here with his permission:

Thanks !

>> The pk3 should not be installed since it's tied to the binary version.

I'll remove the reference to the .pk3 file.

>> The WAD can be installed if you like, but it will likely change
>> from time to time as S3DNA updates. You can find the wad in
>> the S3DNA repo

>> It contains all the changes for the 20th anniversary edition and
>> can be used with base ECWolf by loading manually.

Is this the right way to call it ?
"cd /usr/share/games/super-3d-noahs-ark/ ; ecwolf --file noah3d.wad"

Could ecwolf be symlinked as /usr/games/s3dna and automaticaly
start in S3DNA mode when called this way + autodetect noah3d.wad
the same ways Doom engines chex.deh for example ?

---

Is this file only available via Steam or is it available on a plain website ?

If so, would it be possible to provide versioned URLs ?
(the downloaded files are matched against known-good checksums)

It's better to download an slightly older patch than no patch at all.

This file would get downloaded only if the *.n3d files are already present;
and game-data-packager uses a distinctive user-agent.

Alexandre Detiste

[Alexandre Detiste]

2015-06-30 11:19 GMT+02:00 Braden Obrzut <ad...@maniacsvault.net>:
>> Is this the right way to call it ?
>> "cd /usr/share/games/super-3d-noahs-ark/ ; ecwolf --file noah3d.wad"
>

> More or less. "ecwolf --file /usr/share/games/super-3d-noahs-ark/noah3d.wad"
> might be preferable if you allow users to add arguments of their own so the
> working directory doesn't magically change, but either way would work.

only one way work here, maybe I need to update ?

ReadConfig: Reading the Configuration.
IWad: Selecting base game data.
Can not find base game data. (*.wl6, *.wl1, *.sdm, *.sod)

-----

goal is to provide a .desktop file that simply launch the game
with standard parameters; if users know better, they can call
ecwolf by hand with custom parameters.
(or edit the .desktop file)

> The next version of ECWolf will have a way to autoload the wad through the
> config, although I'm starting to consider adding support for auto detection
> and loading it since you're not the first person to have asked.

This .desktop file should work out-of-the-box for all users;
without having to manually edit config files.

This could of course also be handled by a wrapper script
in our generated .deb that creates the config file
before first run or by patching the engine in the Debian package.

(use case 1: a computer with 3 users-id,
parent has a credit card & Steam account,
buy the game and then install it with game-data-packager
so that child1 & child2 can play it, without having a Steam account
in their unix account

use case 2: game is bought on a x86 computer running Steam,
but end up being played on an RaspberryPi or some other arm device)

>> Could ecwolf be symlinked as /usr/games/s3dna and automaticaly
>> start in S3DNA mode when called this way + autodetect noah3d.wad
>> the same ways Doom engines chex.deh for example ?
>

> No. The noah3d binary uses a slightly modified version of ECWolf which can
> be found here: https://bitbucket.org/Blzut3/super-3d-noahs-ark One of the
> modifications made there is the autoloading of that wad.

Fabian: I guess we don't want to package 2 engines that are 99%
the same thing in Debian.

>> Is this file only available via Steam or is it available on a plain
>> website ?
>

> It's also available in deb packages distributed on itch.io (as well as the
> Windows msi's, Mac dmg, and Android apk, but I'm sure those are less
> preferable).

Ok, I'll have a look at those.

> The alternate version of it is in the S3DNA repo:
> https://bitbucket.org/Blzut3/super-3d-noahs-ark/src/Noah1.3/wadsrc/noah3d.wad

> You'll probably want to use it anyway since from what Fabian tells me,
> Debian won't use my forked SDL_mixer for
> ECWolf ( https://bitbucket.org/Blzut3/sdl_mixer-for-ecwolf ), so not using
> OPL music will break some of the game sounds (can't run the OPL or PC
> Speaker emulators and play sampled/MIDI music at the same time with standard
> SDL mixer).

Well, I don't know the whole story, but if there really is something
broken in SDL_mixer, I'd rather have it fixed upstream for all games.

---

By the way:

We are trying to also support Blake Stone, but I couldn't identify all
the old versions.

In "patchutil" you use CRC32, to identify files, while we use MD5;
could you provide us the MD5 for the old versions ?

This can be in any very rough format, I'll do the editing.
(for wolf3d we should already have all versions)

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/data/blakestone.yaml

https://bitbucket.org/Blzut3/ecwolf/src/eeac477f694f572b2ad8bc2131d042e8fdca361e/tools/patchutil/main.cpp?at=default

Alexandre

[Fabian Greffrath]

@pkg-sdl: Please have a look at the post/patches linked to in the
second paragraph. :)

Am Dienstag, den 30.06.2015, 12:11 +0200 schrieb Alexandre Detiste:
> Fabian: I guess we don't want to package 2 engines that are 99%
> the same thing in Debian.

Nope, of course not. I'd prefer the engine being able to auto-detect
the requested game mode and act accordingly. If we end up with two
builds with slightly different CFLAGS or #defines, as we do with
wolf4sdl, I could live with that as well, though.

> Well, I don't know the whole story, but if there really is something
> broken in SDL_mixer, I'd rather have it fixed upstream for all games.

His patches were posted on the upstream dev list, but got no response
so far:

http://lists.libsdl.org/pipermail/sdl-libsdl.org/2015-June/098221.html

I guess upstream considers SDL*-1.2 dead and does not accept any
patches anymore. :( But maybe our SDL packagers at Debian could use
some of them. I am thus including them in CC. :)

- Fabian

[Manuel A. Fernandez Montecelo]

Hello,

2015-06-30 13:00 GMT+01:00 Fabian Greffrath <fab...@debian.org>:
> @pkg-sdl: Please have a look at the post/patches linked to in the
> second paragraph. :)

I have had a look at some of the patches, not in much detail though
(I'm in a bit of a rush in the last few weeks).

Perhaps some of them, at least the most simple and obvious, should be
(if not done already) reported in the bug tracker, attaching the
particular patch fixing the issue. I saw upstream happily accepting
patches in the past (although they are a bit slow to react sometimes).

So Braden already did the right think in trying to upstream his
changes, but breaking them down to small pieces for individual
consideration will help a lot in the process, I think.


In principle, I think that the changes as a whole are too big and
intrusive to try to add them to Debian. I am sure that some/most are
good fixes, but we have had continous problems with adding some patch
that people request to fix a problem in their project, and then
breaking another application for not obvious reasons, sometimes those
other applications even rely on the wrong/old behaviour. So adding
patches without support from upstream is a bit of a mine-field.

>> Well, I don't know the whole story, but if there really is something
>> broken in SDL_mixer, I'd rather have it fixed upstream for all games.
>
> His patches were posted on the upstream dev list, but got no response
> so far:
>
> http://lists.libsdl.org/pipermail/sdl-libsdl.org/2015-June/098221.html
>
> I guess upstream considers SDL*-1.2 dead and does not accept any
> patches anymore. :( But maybe our SDL packagers at Debian could use
> some of them. I am thus including them in CC. :)

Maybe it's obvious from previous context, but I didn't see how this
applied to SDL-1.2 and not v2? I think that specially the mixer
module is quite independent from other changes of the v2 library, so I
think that many might apply to v2 as well.


Speaking of which, if an active software has not considered starting
to use v2 already, at least they should make a plan. We don't plan to
retire 1.2 immediately, but it's obvious that upstream does not do any
releases of that branch, nor probably even accepts patches, so it
starts to be urgent to move on to the supported versions.


Cheers.
--
Manuel A. Fernandez Montecelo <manuel.m...@gmail.com>

[Fabian Greffrath]

Hi Braden and Alexander,

Am Mittwoch, den 01.07.2015, 10:40 +0200 schrieb Alexandre Detiste:
> --- a/src/wl_iwad.cpp Tue Jun 30 19:38:46 2015 -0400
> +++ b/src/wl_iwad.cpp Wed Jul 01 10:14:21 2015 +0200
>
> LookForGameData(datawadRes, basefiles, "/usr/local/share/games/wolf3d");
> + LookForGameData(datawadRes, basefiles, "/usr/share/games/wolf3d");

hm, I have just tried this patch and it works for me.

Some more questions:

1) It seems that ECWolf runs with uncapped framerate and interpolated
angles. Is it possible to turn this off?

2) Are there any plans to include support for Corridor 7 now that its
source code has also been released?

Thanks,

Fabian

[Fabian Greffrath]

Am Montag, den 06.07.2015, 07:17 -0400 schrieb Braden Obrzut:
> Define interpolated angles?

Well, not only updated each gametic, but also intermediately during
each rendering cycle.

> The source was released? If so that news hasn't reached me (which
> would be unusual since I had people tell me about the source release for the
> early id games and I was the one that prepared the release of them), any
> of the websites I visit, or Google.

Ouch, sorry! I mixed this up with its unreleased sequel:
http://corridor7.tripod.com/download.htm

> Regardless though, yes Corridor 7 and Operation Body Count will be
> supported.

Cool, thanks!

- Fabian

[Fabian Greffrath]

Am Dienstag, den 07.07.2015, 10:49 -0400 schrieb Braden Obrzut:
> Vanilla Wolf3D and thus ECWolf is actually capped at 70fps* which is the
> vsync rate of VGA 320x200. Uncapping it hasn't been a high priority
> since it runs faster than most people expect, although it would probably
> help with performance with vsync on.

I see. However, is it possible to restrict the framerate back to 70fps
or bind it to vsynv of my screen?

- Fabian

[Fabian Greffrath]

Am Dienstag, den 07.07.2015, 19:30 -0400 schrieb Braden Obrzut:
> It is restricted to 70fps. It works exactly like vanilla in that regard.

Does the same apply to wolf4sdl? I've got the impression that ECWolf
runs a lot smoother than that, thus I asked for "interpolation".

- Fabian

[Alexandre Detiste]

Hi,

Thanks for your checksums,
I finaly got around to edit Blake Stone package list.

The first recommended engine for v2.1 is still "bstone",
I would swap it as soon as ecwolf support Blake Stone.

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/commit/?id=a96e9dac8d87d924c0eea82a59938097888c4eee

Is this help text ok for you or can I improve it ?

+help_text: |
+ <bstone> engine support all versions of Blake Stone,
+ .
+ <ecwolf> engine only aim to support the best version (2.1) that
+ is also the one currently sold by Steam & GOG.com;
+ but provides and enhanced engine with easy modding facilities.
+ .
+ Choose wisely (or choose both).
+ .
+ Blake Stone v3.0 is merely a discount re-release of v2.1.

----

game-data-packager will add a "?pp=<hash>" to the GOG.com url it generates,
this allow engine maintainer to get some revenue;
so when ecwolf get Blake Stoen support; you might be interrested to
request this 'pp' id (partner program ?).

It nows default to Scummvm id's.
http://www.gog.com/game/blake_stone_planet_strike?pp=22d200f8670dbdb3e253a90eee5098477c95c23d

(now there remain the question on how to split that with "bstone" maintainer)

Alexandre Detiste

[Manuel A. Fernandez Montecelo]

(I am "replying all", but I don't know if all of you are interested in
this, please let me know if it's not so and I'll remove you from
future e-mails).


2015-07-01 1:27 GMT+01:00 Braden Obrzut <ad...@maniacsvault.net>:

> On 30/06/15 14:40, Manuel A. Fernandez Montecelo wrote:
>>
>> I have had a look at some of the patches, not in much detail though
>> (I'm in a bit of a rush in the last few weeks).
>>
>> Perhaps some of them, at least the most simple and obvious, should be
>> (if not done already) reported in the bug tracker, attaching the
>> particular patch fixing the issue. I saw upstream happily accepting
>> patches in the past (although they are a bit slow to react sometimes).
>>
>> So Braden already did the right think in trying to upstream his
>> changes, but breaking them down to small pieces for individual
>> consideration will help a lot in the process, I think.
>

> That's why I posted on the mailing list. If there's anything in there that
> would be accepted, I can break it out. But it just wastes my time to break
> out patches for everything and have them be denied.

To me it look like a chicken-and-egg problem -- upstream does not have
the time or mental energy to look at it because it is too much to
digest at once (it happened to me when skimming over it), you don't
want to make it easier to digest because you are not sure if they will
like it and don't want to waste your time.

It's always a tradeoff -- there's never a guarantee that it will be
accepted even if you split it in smaller chunks, but it usually makes
things more likely. On the other hand, if you don't make it easier
for upstream to look into it, it is less likely that upstream goes and
picks it up. This in turn might make things more difficult or easier
for you in the future (e.g. conflicts merging would make it more
difficult, but making sure that your patches don't change makes it
easier to know that it will work for you).

If I were you, I would at least submit a few requests to their
bugzilla to merge parts fixing the most straightforward / glaring /
serious issues, just pointing to your git repo or attaching a patch,
and see what happens.


> I suppose what frustrates me a little about the situation is that if I
> merged that source code into the ECWolf tree and didn't mention it, it would
> be packaged without a second thought, but since it's a separate repo in
> order to allow me to trivially merge any changes from upstream it's a big
> deal. To be clear, I'd never suggest that Debian provide the library in a
> separate package. Only statically linking. ;) But I'm glad that you guys
> are even considering packaging it at all.

To be clear, I am not considering packing this fork, at most I would
select some patches. And it's happening to me the same as I explain
above about upstream -- I lack the time / energy / motivation to spend
one or more afternoons looking at the patches, trying them and
deciding if to ship them or not. SDL upstream must have more interest
in seeing fixes and improvements for their project than me, but still
I suspect that this might be a factor explaining why they didn't reply
yet.


Also, if ECWolf included the source but didn't mention it, it would
most probably be detected by the maintainers and automatic tools and
would make it more difficult to get accepted, or people from central
teams like Release or Security could reject it altogether (e.g. as it
happened with ffmpeg for the last stable release, even if it's a much
more important package).

I had the same situation for example with K-3D and OGRE embedding
GLEW, if I recall correctly, and was working with upstream to make
them work with the copies shipped by the system, not the embedded
copies -- otherwise I was quite sure that the packages would end up
being dropped out of the distro because of this.


> My customized SDL_mixer is based of SDL_mixer 2.0. SDL_mixer 2.0 can
> actually be compiled against SDL 1.2 or 2.0 just fine, so I imagine the
> branch is just there for ABI reasons.
>
> [...]
> ECWolf compiles with SDL 2.0 starting with the recently released 1.3.2. I
> hear it doesn't compile with stock SDL_mixer 2.0 due to the way I call a
> certain function, but I haven't bothered checking it yet.

That's good, thanks.

The majority of packages in Debian which depend on SDL still goes with
1.2, but v2 is growing and I hope to have time to push for more of
this to happen in this release cycle.

[Fabian Greffrath]

Hi Manuel et al.,

Am Donnerstag, den 09.07.2015, 13:23 +0100 schrieb Manuel A. Fernandez
Montecelo:

> If I were you, I would at least submit a few requests to their
> bugzilla to merge parts fixing the most straightforward / glaring /
> serious issues, just pointing to your git repo or attaching a patch,
> and see what happens.

while we are at it, do you think upstream would accept this patch (or
did you already try to submit it upstream? I think I remember we talked
about this when we first applied it to SDL_mixer 1.2.)?

http://anonscm.debian.org/cgit/pkg-sdl/packages/libsdl2
-mixer.git/tree/debian/patches/bug-715461-soundfont_paths.patch

Cheers,

Fabian

[Alexandre Detiste]

Le jeudi 25 juin 2015, 10:00:08 Simon McVittie a écrit :
> Alexandre,
> The commit message for data/blakestone.yaml says "WIP". Do you consider
> this to be ready for release, or should I disable it for g-d-p 42?

It's ready now.

> Do we want to disable the generation of these packages until a suitable
> ecwolf exists, at least upstream?
>
> S

GDP can now check for engine / engine version at runtime;
this way GDP release cycle doesn't need to be sync'ed
with some other random package release cycle.

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/game_data_packager/__init__.py?id=5c2e0d89036a7fda0e5488aa3c4b8a285aab703a#n2361

User must now use '--force' if he hasn't yet installed ecwolf
upstream .deb or made a fake one with equivs.

This could also check for the presence /usr/games/<engine>
but I'd rather not promote unpackaged stuff in /usr/
outside of /usr/local/ .

Alexandre