This is an ebuild for kingpin. It uses the loki installer available here: http://www.liflg.org/?catid=6&gameid=2. It works for me on x86 and amd64. The dependencies are most probably incomplete, I wasn't sure what else it requires. Reproducible: Always Steps to Reproduce:
Created attachment 121667 [details] kingpin-1.20.ebuild
Lesson in how to properly do dependencies for binary packages: #1. ldd is your friend First, install the game using your ebuild, then run "ldd filename" on the executables. Each library that it shows the executable linked to, use equery (or some other tool) to determine to which package the library belongs, and add that to RDEPEND. It is very likely that the main binary will be static, meaning it won't be dynamically linked to anything (oversimplified, but good enough for our purposes). In this case, you get all of your information from the libraries, which have a .so extension. #2. Test, test, test... ;]
Created attachment 124046 [details] kingpin-1.20.ebuild Here's an ebuild which works with the "Sold Out" label reissue of Kingpin. Needs the latest native version of unshield, otherwise unshield does not extract all the files. /etc/kingpin.conf is not needed. Untested on amd64, but will hopefully work.
I'm attaching an updated and largely expanded/rewritten ebuild to support installation of the Kingpin data files from both the original CD and the Good Old Games package. Support for the GOG package requires the innounp ebuild I included in bug 371195. As discussed in in that bug report and bug 363719, using a separate innounp package will provide both an easy solution for users to extract their data files (without relying on Windows) and a single innounp package to worry about maintaining. Support for the CD-ROM should also still work just fine, although I've made a few changes to improve things where appropriate. I dropped the unshield requirement, for example, as the latest version of the binary package includes a newer version of unshield that works properly. I also removed some filename case changes that were causing graphical glitches in the game. I'm sure I made some other changes as well, but can't think of any offhand. Last big thing worth mentioning is that, since the GOG package does not include a CD, the built-in CD check will obviously fail. I found that the CD check simply checks for the presence of a particular file in any mounted iso9660 filesystem, so I created a fake cd ISO image that can be mounted with the loopback option to workaround the CD check. This image is built during install, so no extra files are required. Instructions for this are output with elog. Guess that's it. Let me know if you find any problems. I tested this pretty heavily, so I think it should be solid.
Created attachment 278899 [details] games-fps/kingpin-1.20-r1.ebuild
Created attachment 278901 [details] kingpin Manifest including Manifest file as well, since ebuild digest requires all files be available and will complain about the missing GOG setup package
Created attachment 288145 [details] games-fps/kingpin-1.20-r1.ebuild Attaching a very minor update to my last ebuild. It's basically just cleanup and a formatting/notification improvements.
Created attachment 308995 [details] updated ebuild added unpacker inherit for unpack_makeself added line to use mkisofs (cdrtools) if genisoimage (cdrkit) is not available
Created attachment 308997 [details] games-fps/kingpin-1.20-r2 fixes fakecd.iso still doesn't get installed though.
Hey, Benn. Thanks for the update. Couple questions: 1. What's the explicit unpack_makeself and unpacker inherit for? Is that some new requirement? 2. I like the idea of supporting both cdrkit and cdrtools, but I'm not sure you're method is the best approach. I think something like this would be cleaner: if has_version app-cdr/cdrkit; then genisoimage ... elif has_version app-cdr/cdrtools; then mkisofs ... fi
Created attachment 323830 [details] games-fps/kingpin-1.20-r3.ebuild Updated ebuild with a few improvements: * Incorporated Benn's suggestion for the unpacker eclass, and also included the cdrom eclass, as both are now required * Incorporated Benn's suggestion regarding supporting app-cdr/cdrtools, though I implemented it as shown in my previous comment * Fixed output location of fakecd.iso - didn't catch this, but my last update ended up putting it in the doc directory. Sorry about that. * Switched over to innoextract from innounp. Unlike innounp, innoextract is a native Linux utility, so there's no need for wine, and file extraction is significantly faster.
Created attachment 349606 [details] games-fps/kingpin-1.20-r3.ebuild Made a few more changes. Aside from some general updates and cleanup, this features a couple noteworthy changes: 1. I fixed a filename capitalization issue that the game complained about during startup. I personally never noticed any issues with it, nor do I see any obvious improvement after the fact, but I figure if it's complaining there's probably a reason. 2. I added support for CD audio for the GOG release. Now, this is a bit hackey since they GOG doesn't provide an image containing the original CD tracks for this game (like they do for some others), but instead just provide Ogg-encoded versions. I guess the Windows version can handle that, but I can't figure out any way to get the Linux version to do so. To make this work I had to do a few things: * I added a music USE flag to control whether the music is installed or not. This has a depend on !cdinstall, as if you're using cdinstall it's assumed you will (or at least can) mount the original CD. It'll also create a CUE sheet with USE=music, which is necessary for mounting it with cdemu (see next item). * You need to use cdemu to mount the virtual CD in such a way that music tracks will be properly recognized. I added that as a dep for USE=music, and also added some new info in postinst to help users get started, since cdemu is probably unfamiliar for most people. One other note - on my computer, the game begins to stutter if I have CD audio enabled. It's weird - it plays fine at first, then begins to stutter just slightly, then each stutter gets progressively longer by a couple hundredths of a second each time. After a couple minutes of playing, the stutter is quite noticeable and very annoying. I get no stutter without the CD audio, and my system is plenty powerful enough to be able to handle this game, so I really don't know what's going on. I guess it could be a a cdemu issue, but I use that for a number of other games and have never had that issue before, so it doesn't seem likely. Would be interested to know if anyone else experiences this. As always, feedback welcome.
