Hi, here's a tidy-up of the Unreal Tournament ebuilds, standardizing their layout and applying the LoadClassMismatch change (bug #44351) to version 436 also (because it looks like a good thing). In the old ebuilds, "ut" gave the error "dirname: missing operand. Couldn't run Unreal Tournament (ut-bin). Is UT_DATA_PATH set?" This is now fixed twice - by dosed, and games_make_wrapper. loki_patch was not being run in unreal-tournament-436.ebuild - this is fixed. I haven't tested the GOTY ebuilds.
Created attachment 87347 [details] unreal-tournament-436.ebuild
Created attachment 87348 [details] unreal-tournament-451.ebuild
Created attachment 87349 [details] unreal-tournament-goty-436.ebuild
Created attachment 87350 [details] unreal-tournament-goty-451.ebuild
goty-451 installs and runs ok
Created attachment 90408 [details] unreal-tournament-451.ebuild This ebuild removes the need for a separate GOTY ebuild. And hopefully gets around the security problem in bug #44351 by splitting the server executable into a separate ebuild. Can someone post the result of "ls -lR /mnt/cdrom" for the 2 GOTY CDs? Then I can get rid of the file collisions which are probably present between the 2nd CD and unreal-tournament-bonuspacks.
Created attachment 90447 [details] UT_GOTY_CD1
Created attachment 90448 [details] UT_GOTY_CD2
Created attachment 90458 [details] UT_non-GOTY_CD Here's the file list on the original UT99 CD.
Created attachment 90495 [details] unreal-tournament-451.ebuild This ebuild adds flexibility to handle the variety of directory names on the CDs (e.g. Maps/MAPS/maps). I don't think it's worth bothering much about file collisions, at this stage of the game's lifecycle :)
Created attachment 90496 [details] unreal-tournament-451.ebuild Added "-f" to 2 cp commands, to fix a potential permissions failure.
Created attachment 90499 [details] unreal-tournament-451.ebuild Added "cdcache" directory, so that the 2nd patch application doesn't try to grab files from the 2nd GOTY CD.
Created attachment 90500 [details] unreal-tournament-451.ebuild Added check, and stopped the Loki patch from being applied if the GOTY files are pre-patched to the same level.
Created attachment 90502 [details] unreal-tournament-451.ebuild Fixed sed of Core.int, and the uncompressing of maps.
Created attachment 90556 [details] unreal-tournament-451.ebuild Added tweaks to UnrealTournament.ini
I think UT doesn't work without opengl, so it should be dependant on opengl and not use a useflag.
UT99 can use Glide and SDL software rendering *instead* of OpenGL, as shown by: grep Render ~/.loki/ut/System/UnrealTournament.ini Although no-one would probably want to :)
But doesn't opengl just pull in mesa? And I thought sdl and glide were dependant on opengl. Please correct me if I am wrong.
Created attachment 90793 [details] unreal-tournament-451.ebuild Added sed commands to change the default renderer based on the USE flags. SDL and Glide don't need OpenGL, it seems.
Created attachment 111536 [details] unreal-tournament-451.ebuild Hopefully added support for the Midway Unreal Anthology DVD.
Created attachment 111662 [details] unreal-tournament-451.ebuild Removed RDEPEND on the bonuspack, to fix Portage's "circular dependencies" error. This apparently works with the Unreal Anthology DVD: http://forums.gentoo.org/viewtopic.php?p=3934507#3934507
Why does the S3TC flag not copy those textures for the non-GOTY version? I have a non-GOTY retail copy of the game, but with two-CDs, ie the second CD has the S3TC textures which I would like to have installed. Do other people's non-GOTY versions only have a single CD? P.S. My copy of the game is a UK retail store-purchased version, which I bought back in 1999 not long after it was released. Note that whilst it does have the S3TC textures it doesn't have any bonuspacks included, which is why it is correctly being detected as a non-GOTY version.
Created attachment 119795 [details] file listing for first CD of 2CD non-GOTY version
Created attachment 119799 [details] file listing for second CD of 2CD non-GOTY version
Created attachment 119805 [details] unreal-tournament-451.ebuild Updated ebuild which will load the second CD and copy textures across if S3TC flag is set even for non GOTY versions.
Created attachment 119828 [details] unreal-tournament-451.ebuild The ebuild in comment #25 is no good, because cdrom_load_next_cd could be called (line 340) without the 2nd CD even being *defined* (as in e.g. line 210). To add support for the non-GOTY 2nd CD without breaking the ebuild for the other UT2004 versions (and yes, non-GOTY is normally just 1 CD, as shown in comment #9), it must be identified properly in pkg_setup(). Please test the enclosed ebuild, which will pull in the 2nd CD if a standard 1st CD is detected, and the S3TC USE flag is set.
Created attachment 119873 [details] unreal-tournament-451.ebuild Oops, I meant UT99 not UT2004. Renamed S3TC to highres, so it's obvious what it means. Defaulted UseS3TC=1 if opengl or sdl USE flags are set, because it's harmless if the highres textures are not installed, and most video cards these days can use them.
Thanks, I hadn't quite understood how the cdrom loading functions work. I tested your most recent ebuild and it works fine here.
UT:GOTY disk 1 (Version 432) http://rafb.net/p/iqOsQ381.html UT:GOTY disk 2 (Version 432) http://rafb.net/p/FqpHAg34.html
Created attachment 133340 [details] unreal-tournament-451.ebuild Midway Anthology improvements: Symlink code is simplified. Only the UT files are unpacked. It took far too long to unpack everything else and I ran out of space!
Comment on attachment 119873 [details] unreal-tournament-451.ebuild I'm not sure whether the "unshield g ... xargs ... || die" would actually die if there was an error.
Created attachment 133420 [details] unreal-tournament-451.ebuild Good point. This should do the trick.
I think pkg_setup can be simplified. The mixed case thing isn't a problem because from what I've seen from the Unreal Gold ebuild submitted in #130051 and from the eutils source, I think you can give alternative files to search for separated by colons. So we should be able to do something like this. if [[ -e "${r}/Help/BonusPackReadme.txt" ]] || [[ -e "${r}/HELP/BonusPackReadme.txt" ]] ; then IS_UT_GOTY="y" einfo "Found UT99 \"Game Of The Year\" edition" cdrom_get_cds Help/BonusPackReadme.txt:HELP/BonusPackReadme.txt Help/chaosut break I'm not sure though. Please correct me if I'm wrong. The comment at the start of pkg_setup is also not quite true. Even if it weren't for the mixed case thing, we would still not use cdrom_get_cds initially because of the other versions of the game. I wondered if there is a better way to handle that but I don't think there is, short of totally rewriting the cdrom functions. I'm going to attempt to unify the Unreal ebuilds and add support for the anthology. I'll post it up if I get somewhere.
Mixed-case *is* an issue, if the CD has been copied to a Linux partition and is being installed from there. Unify? For UT2004, see bug 159164.
Sorry, I worded that badly. I simply meant that you don't have to do separate calls to cdroms_get_cds because you can separate the alternative with colons. I've just looked at your UT2004 ebuild and doing that should make that one much simpler in particular. And by Unreal, I meant the original Unreal. There is a user-submitted ebuild for Unreal Gold and no one has added support for the anthology yet. It would be best if all three versions were handled by one ebuild, or maybe two in order to handle Return To Na Pali separately.
Created attachment 133455 [details] unreal-tournament-451.ebuild After looking at the eutils source again, I worked out an even better way to do it. I'm only able to test it with the anthology but it should work with the others. When you give alternatives separated by colons, cdrom_get_cds sets the variables CDROM_SET, which is the index of the alternative that was found, and CDROM_MATCH, which is the name of the alternative that was found. When I first tried it, I saw some harmless error messages. I've fixed this in eutils. Check out bug 195864.
Created attachment 134110 [details] unreal-tournament-451-r1.ebuild Well I've been on strike from work the past week so I spent all my time on this. I've almost totally rewritten it, though you can still see some remnants of Paul's stuff. There's a list of improvements longer than my arm but I won't go into them all now. The biggest change is that the files to copy are explicitly named. This is done so that if you're copying from an installation that has bonus packs or other mods, it won't copy those, just the bare game. As a result, even installing from GOTY will not give you bonus packs 1-3. The upshot of this is that ALL the bonus pack stuff (not just #4) can be moved into the bonus pack ebuild and every edition of the game will be treated in the same manner. After installing once, you can even point CD_ROOT back to /opt/unreal-tournament, and it'll reinstall from there, which is handy for later updates. It either detects that installation as GOTY or original, depending on whether you installed the bonus packs or not, but either way, exactly the same files are always installed. I've tested this a hell of a lot. I only have Unreal Anthology but because of what I said above, the other code has effectively been tested too so the GOTY CD and original CD should work. The only thing I haven't really tested is the highres texture stuff because my card doesn't support them and Unreal Anthology doesn't include them. Note that the second CD from GOTY is only required if you want the highres textures. The other stuff on that disc only relates to the ChaosUT and RocketArena mods. These aren't required and weren't even included with Unreal Anthology. Paul, could you explain the dependencies for me? I don't know what UIDEPEND is actually for, plus I'm not sure why you removed some of the amd64 dependencies or why you moved virtual/opengl inside of x86.
Created attachment 134111 [details] unreal-tournament-bonuspacks-4.ebuild New bonus pack ebuild. This used to use the game versions but I'm not sure why. I have given it a version of 4 to indicate the 4 bonus packs that it installs. It can either install bonus packs 1-3 from the GOTY CD, the Unreal Anthology DVD or by downloading the necessary files. Bonus pack 4 is always downloaded.
UIDEPEND is just a convenient variable, useful when DEPEND and RDEPEND have some overlaps. It's not a variable that Portage recognizes. Not actually useful in this ebuild. I put virtual/opengl in the wrong place. The amd64 deps are a mess: http://www.gentoo.org/proj/en/base/amd64/emul/content.xml Probably best/easiest to use: amd64? ( >=app-emulation/emul-linux-x86-sdl-10.1 ) ${Ddir} should be quoted: "${Ddir}" einfo in pkg_postinst() should be changed to elog, so that the comments are recorded. Not caring whether xdelta fails is a backwards step - use the patching code in my ebuild above. "tar Ojxf" should die if it fails.
Created attachment 134124 [details] unreal-tournament-bonuspacks-4.ebuild That's the bonus pack ebuild fixed up. I'm not used to adding "die" to everything. I try to remember to quote whenever necessary. Okay about UIDEPEND. I've only seen it called CDEPEND before. I didn't realise that's what elog did though I suppose the name does give it away. einfo messages do get displayed again when Portage finishes but I guess elog is better. I'm a little unsure about the xdelta thing. I may have a different idea. I'll explain later. (-:
I've tried to get my head around all the different installers and patches. I'm still a little confused. ut-install-436-GOTY.run installs from the CD but what are the patches actually for? They shouldn't be for updating the game to 436 because GOTY is version 436 already. I don't think they're for making Linux-specific adjustments to the game. I compared the target MD5s (obtained using xdelta) with the MD5s of the files from Unreal Anthology. All but one of the files were effectively patched already and that other file didn't match the source MD5 either. Can someone check if this is also true for the actual GOTY edition? If this is the case, it would seem that these patches are useless. ut-install-436.run presumably installs from the original CD and patches from whatever version that was (400?) to 436. I used to have the original but I gave it to a friend. He's giving it back to me tomorrow so I can check then. I found another file called ut-436-nodelta.run on icculus.org. I was hoping it would patch from any Windows version to Linux 436. Unfortunately, it only patches from previous Linux versions - 425 and 428. It says that it also patches from 436 but I don't really understand that since it's supposed to patch TO 436. If we can verify that the GOTY patches are indeed useless and that the patches for the original version apply cleanly then I'll be fairly happy. But what about people who are trying to install the game from a Windows partition? Unless the game is totally unpatched (400) or patched to 436 already, none of the files I've mentioned above would be individually suitable. Perhaps I could combine ut-436-nodelta.run with the other files. For example, I could patch what I can from 425/428 to 436 and then just unpack the missing files. I tried to see it the Windows "no delta" patch was any good but I couldn't break down the .exe any further than unzipping it.
Heh I just figured out what those GOTY patches are for. I was comparing some more MD5s and decided to throw one of them at Google to see what came up. I found an extremely useful page. http://www.unrealadmin.org/forums/archive/index.php/t-11684.html That list shows two GOTY versions, 432 and 436. The MD5s confirm that the GOTY patches update from 432 to 436. Phew! Now I know this, I'll have a further think about the best way to tackle this in general and post back tomorrow.
> because GOTY is version 436 already This is a super-duper *universal* installer ebuild, which works on the really old (pre-GOTY) versions also. If you're not prepared to support the oldest versions of UT also, then please create and use your own bug. The unreal-tournament-bonuspacks ebuild should be in its own bug also. I'm not trying to stop this development in the slightest, but just move it to the proper place. > All but one of the files So state the file, and its md5sum. > ut-436-nodelta.run So how is that useful? > what about people who are trying to install the game from a Windows partition? They are on their own. That is totally beyond the scope of this ebuild.
Created attachment 134427 [details] unreal-tournament-451-r1.ebuild I am trying to support pre-GOTY, I was just trying to work out what the patches in ut-install-436-GOTY.run were for. Now I know. I thought I'd draw the same conclusion as you, that people with other versions would be on their own but after digging a little deeper, I managed to support a fairly wide range of versions with very little extra effort. The versions this ebuild supports are 400, 432, 436, 440, 451 and 451b. That leaves 413, 425, 428 and 436creative. I have added a comment to the ebuild that explains how this is possible. I have now tested the original release and the high resolution texture stuff. It turns out my Intel 945G supports S3TC after all. I've renamed the USE flag back to "S3TC" because even though "highres" is easier to understand because this is a specific feature that doesn't work on just any card or driver. As far as I know, the closed source NVIDIA drivers support it but the closed source Radeon drivers don't. Some open source drivers support it through the use of libtxc_dxtn but there are legal issues surrounding that. I'm trying to get it added to Portage in bug 65607. I thought about depending on it but the closed source NVIDIA drivers don't need it. The game still works with the high resolution textures installed and the S3TC setting enabled even when the software support is missing so it is safe not to depend on the library. libmikmod.so.2 is now deleted because Portage can provide that. libSDL-1.1.so.0 is also deleted because the game doesn't use it anymore. Version 451 of ut-bin looks for libSDL-1.2.so.0, which Portage can also provide.
Comment on attachment 134124 [details] unreal-tournament-bonuspacks-4.ebuild I've posted the newest version of this in bug 104599.
Is "${patch} .0" correct? Occurs twice. I think it would be more user-friendly to *not* die if S3TC is unavailable, given that this is a very lengthy emerge. eerror is fine.
Created attachment 134453 [details] unreal-tournament-451-r1.ebuild Those errors would probably only occur when installing from a previous installation but okay, they're not really fatal. I've added some code to allow the high resolution textures to be installed from a previous installation. It's a bit fiddly because there are no high resolution texture files without a low resolution equivalent but I felt it was worth doing because now I won't have to put the CDs back in every time there's an update. Running `basename ${patch} .0` twice is fine, all that does is return the patch's filename with .0 stripped off the end. I'm pretty happy with this now so I'm going to continue with the original Unreal and Return To Na Pali.
Created attachment 134458 [details] unreal-tournament-451.ebuild mv is overwriting, so can potentially need -f. I think. Used if..then instead of &&, to have commands die if they fail. Fixed dies that were in a subshell: http://devmanual.gentoo.org/ebuild-writing/error-handling/index.html Simplified the graphics-related USE flags. SDL looks better than opengl on my nvidia 8800. I can't see anyone wanting to install this with software-only rendering :-) The little "ucc" script is no longer installed, so the unreal-tournament-ded ebuild should provide ucc instead. Added QA_TEXTRELS. I need libmikmod.so.2 from my UT version 400 CD, rather than my native x86 version, to hear music. So, the ebuild does not delete it.
Created attachment 134481 [details] unreal-tournament-451.ebuild Heh I forget how often subshells get created. You must be using the ALAudio (OpenAL) driver. When I tried it, the music didn't work. I had heard of problems relating to the driver so I assumed it was just broken. But I remerged, leaving libmikmod.so.2 in place and the music does indeed work now. The ALAudio driver provides more effects than the generic driver and now I know it works, I've used the openal USE flag to modify UnrealTournament.ini like we've already done for the renderer. I didn't think it had anything to do with x86/amd64. The SDLGL renderer may work better for you but on here, I get no texturing at all (!!) when S3TC is enabled and other weird artifacts when it's not enabled. Almost everyone will have the sdl USE flag enabled and they will assume that having it enabled on this game is a good thing. I think the OpenGL renderer should definitely take priority, even if the sdl USE flag is enabled, since it is the recommened renderer. I'd rather have the software renderer as the "else" case rather than the SDLGL but I'll leave that up to you.
Created attachment 134489 [details] unreal-tournament-451.ebuild Realised that installing from the CD was keeping the executable bit on copied files. I've replaced all instances of "cp -f" with "install -m0644". install doesn't have a -f option but it seems to automatically remove the destination file anyway.
Created attachment 134494 [details] unreal-tournament-451.ebuild 644 is wrong - see /usr/portage/eclass/games.eclass Might as well use the enclosed method. It's inelegant, but then so is having to wait for all those megabytes to copy.
It was okay though because prepgamesdirs fixes the permissions later. It was just necessary to remove the executable bit. Why not just run install with -m0640 anyway?
It's better to fix these permissions once, rather than in a dozen scattered-around areas. Coding style - safer for future changes.
Created attachment 134569 [details] unreal-tournament-451.ebuild Realised that Glide.ini.tar.gz and OpenGL.ini.tar.gz simply contain UnrealTournament.ini files with different drivers selected. Just unpack one of them since we select the drivers later anyway.
Who is going to want to use the software renderer? Next to no-one. Which means it's pointless to add back in the opengl USE flag, when opengl is DEPENDed on anyway (if not 3dfx). This just creates confusion. Defaulting to opengl rather than sdl is fine, but it is a backwards step to remove my elog about having both an opengl and sdl driver to try. An elog is far more noticeable than a comment in a long ebuild.
Created attachment 134584 [details] unreal-tournament-451.ebuild Okay okay, sorry, I did forget to update the dependencies. I'm still confused about what you would prefer but I think this is it. Also removed SGLDrv.int. It's for PowerVR but I got it mixed up with the SDL stuff.
Created attachment 134591 [details] unreal-tournament-451.ebuild More unneeded files. These are from the original Unreal and were included in the 451 patch for some reason.
Comment on attachment 134494 [details] unreal-tournament-451.ebuild "System" is missing from: ~/.loki/ut/System/UnrealTournament.ini
Created attachment 134594 [details] unreal-tournament-451.ebuild Well spotted.
Created attachment 134878 [details] unreal-tournament-451.ebuild SoftDrv.int is another unneeded file.
Created attachment 135068 [details] unreal-tournament-451.ebuild Minor improvements. Got rid of that case-fixing for loop because we delete half those files now anyway. Replaced with simple mv's. Devs, if you're watching, I'm confident that this is as ready as it'll ever be now.
Created attachment 135179 [details] unreal-tournament-451.ebuild Improved the language stuff slightly.
Created attachment 136048 [details] unreal-tournament-451.ebuild Major localisation fixup. That stuff was hardly working at all before because the filenames were lower case when they needed to be mixed case. I've also put the localised sounds in separate directories (e.g. Sounds/frt/*.uax) because it's tidier. Windows only installs one set of sounds at a time but we don't have to do that.
Thanks everyone for your work on this. There's just one cp failure with the version I have. Apart from that it seems to work fine. >>> Unpacking source... cp: cannot stat `/mnt/System/[Ll]icense.int': No such file or directory * * ERROR: games-fps/unreal-tournament-451 failed. * Call stack: * ebuild.sh, line 1701: Called dyn_unpack * ebuild.sh, line 817: Called qa_call 'src_unpack' * ebuild.sh, line 44: Called src_unpack * unreal-tournament-451.ebuild, line 330: Called die * The specific snippet of code: * eval cp -f "${CDROM_ROOT}/${SYSTEM_DIR}"/${SYSTEM} System || die "cp System" * The die message: * cp System
Hmm that's strange. Is there really no License.int or license.int file on your copy? Maybe it has a different case? Which edition of the game is it? I have the both the original and Antology, plus I've seen the CD listing for GOTY edition and it's present on all of those. It may not matter though because I don't think this file is actually needed anyway. If it's missing from yours, I think I'll just remove it.
It's the "Best of Infogrames" version. I posted the file lists here.
Created attachment 136790 [details] unreal-tournament-451.ebuild Ah so you have. I've removed that file now. I also noticed that your copy has localised manuals that don't appear to be all the same (please check that they aren't all in English like the others) so I've added support for those too.
Created attachment 137625 [details] unreal-tournament-451.ebuild Fixed quote problem.
Time to get all those ebuilds into the tree, isn't it?
They might be more willing if you test it and let us know if it worked for you.
(In reply to comment #70) > They might be more willing if you test it and let us know if it worked for you. > So I tried it and fail since the dependency unreal-tournament-ded is non existant. Is there an ebuild for it in another bug?
See bug 138448 about that and use Paul Bredbury's ebuild, not Conrad Kostecki's. I haven't tried it myself since I don't have the "dedicated" USE flag enabled but it looks okay at first glance.
I tried it out with S3TC but not dedicated. Installs and runs fine on x86. Will try out next on amd64
I will confirm that it install well and better than the previous ebuild. It runs as well as the previous way I had it installed. I still have a terrible problem with stuttering sound I can't figure out though :(
Try with/without OpenAL enabled. It's known to be quite buggy (this was the early days of OpenAL) and mine occasionally stutters with it so I tend to turn it off. Unfortunately you have to use that driver when playing Unreal/RTNP but that's not the case for UT. There are also various sound settings you can adjust in the menu and in the config file.
Solved my problem in this thread: http://ubuntuforums.org/showthread.php?t=329639 . It was a sound card specific problem. Just needed to add "options snd_hda_intel position_fix=1" to my kernel module options. So yes, this ebuild works great, no problems on my end with GOTY disks.
Tried it on amd64 and it installs without problems. It runs ~4 times too fast, and sound is clunky, but that is probably not related to the ebuild but rather hardware and faulty configs...;-)
Hah! I'm using it on amd64 too and it runs fine except that it locks up the machine up hard every now and then but I'm not sure if that's related to the game. My system is running on faulty RAM that I have to use the BadRAM patch for so maybe it's related to that. With regards to it running too fast, my friend tried it on Windows recently and he had that problem too. From what I've read, I think it could be related to the number of CPU cores but sometimes you can work around it by enabled vsync. I can't remember if the game has a vsync option but if not, you can force DRI to do it.
The issue wrt the game running too fast is not related to cores but actually related to frequency scaling. UT99's internal timer is based on the clock rate of your system. If UT starts with the CPU idleish and clocked down, the internal timer will be based on your lower CPU rate. The game will get started and the machine will clock up so the game will run super fast. The solution is to either set your frequency governor to 'performance' or to write a startup script for UT that hoses your CPU while UT starts.
Well, since this computer is a Laptop, I went with the 100% CPU power startup programm. Works fine now ;-)
Using ebuild for 2007-12-03 16:10 gives this: * Found CD #1 root at /media/UT_CD1 * Found UT Game CD or previous installation >>> Unpacking source... cp: cannot stat `/media/UT_CD1/System/BossSkins.int': No such file or directory cp: cannot stat `/media/UT_CD1/System/UnrealEd.ini': No such file or directory cp: cannot stat `/media/UT_CD1/System/UnrealEd.int': No such file or directory * * ERROR: games-fps/unreal-tournament-451 failed. * Call stack: * ebuild.sh, line 1701: Called dyn_unpack * ebuild.sh, line 817: Called qa_call 'src_unpack' * ebuild.sh, line 44: Called src_unpack * unreal-tournament-451.ebuild, line 330: Called die * The specific snippet of code: * eval cp -f "${CDROM_ROOT}/${SYSTEM_DIR}"/${SYSTEM} System || die "cp System" * The die message: * cp System * I checked the CD and those files are indeed missing from the CD... but if they aren't there on the official CD, why is the ebuild checking for them? Or do I have a CD that's unusable with the ebuild?
Man, how many bloody versions are there?! Is there anything in particular you can tell us about yours? Was it called something different? UnrealEd is Windows-only so those two can be removed from the installation. I'll have to check about BossSkins.int.
(In reply to comment #82) As far as I know this is just the first release of the game, no GOTY or anything. It does work, as I've used the CD in installation of the ebuild that's in Portage right now, but using this particular ebuild, I guess it's slightly different. I really can't find anything useful on the CD that would suggest its uniqueness other than those files being missing.
Created attachment 140883 [details] unreal-tournament-451.ebuild Finally got around to investigating this. It turns out your version isn't unusual after all. None of those files are mentioned in the non-GOTY listings uploaded here. I must have got confused somewhere along the line. The good news is that BossSkins.int is included with the 436 patches so it doesn't matter that it's missing from some CDs.
I'm running into a problem with the unreal-tournament ebuild... neither ut-install-436.run nor ut-install-436-GOTY.run were automatically fetched, and once I found them on Google and downloaded them into distfiles, I got an error during src_unpack: >>> Starting src_unpack * UT version 400 (original unpatched) detected >>> Unpacking ut-install-436.run to /var/tmp/paludis/games-fps-unreal-tournament-451/work/patch-ut * I'm sorry, but I was unable to support the Makeself file. * The version I detected was ''. * Please file a bug about the file ut-install-436.run at * http://bugs.gentoo.org/ so that support can be added. !!! ERROR in games-fps/unreal-tournament-451: !!! In unpack_makeself at line 4170 !!! makeself version '' not supported !!! Call stack: !!! * unpack_makeself (/var/tmp/paludis/games-fps-unreal-tournament-451/temp/loadsaveenv:4170) !!! * unpack_patches (/var/tmp/paludis/games-fps-unreal-tournament-451/temp/loadsaveenv:4244) !!! * src_unpack (/var/tmp/paludis/games-fps-unreal-tournament-451/temp/loadsaveenv:3768) !!! * ebuild_f_unpack (/usr/libexec/paludis/0/src_unpack.bash:42) !!! * ebuild_main (/usr/libexec/paludis/ebuild.bash:477) !!! * main (/usr/libexec/paludis/ebuild.bash:492) diefunc: making ebuild PID 8450 exit with error die trap: exiting with error. I'm using paludis version 0.30.3 and the latest ebuild from this bug. (the version posted on 2008-01-13)
Ok, I got ut-install-436.run from a different server and it seemed to fix the issue. The first one I got was from download.beyondunreal.com/browse.php?dir=official/ut/ but apparently that one doesn't work.
I guess someone needs to update the Loki mirror list.
This ebuild doesn't seem to work when installing from a local copy of the GOTY CDs (ie., using CD_ROOT_1 and CD_ROOT_2). If I specify CD_ROOT_1 to point to my on-disk copy, the emerge fails with this: <SNIP> * Found CD #1 root at /home/user/data/apps/games/PC/Media/Unreal Tournament/CD1 * Found Unreal Anthology DVD >>> Unpacking source... * The Unreal Anthology DVD does not include the high resolution textures * but you may install them if you have them available from another source. * Otherwise, please disable the S3TC USE flag. For some reason, my GOTY CDs get detected as the Anthology DVD. If I unset CD_ROOT_[12] and repeat, it DOES correctly detect and install from the original CD-ROM. As an experiment, I tried this: export CD_ROOT_1=/mnt/cdrom But it failed again, detecting it as Anthology. Just for the hell of it I even tried this: export CD_ROOT_1=/dev/null and it STILL detected it as Anthology (and, obviously, failed). So, it appears that the ebuild is ALWAYS detecting anything CD_ROOT_1 points to as the Anthology edition. I've been trying to troubleshoot, but I'm not really clear on how the CD stuff works so I haven't had much luck. Any suggestions on how to fix this? I like the thought of a unified UT ebuild, but the main reason I'm worried about this now is because I apparently need to get this ebuild installed so I can then install Unreal on my amd64 system (bug 130051). Thanks.
It's been a very long time since I looked at this but it could be related to bug #195868. As to where this is going, I've given it some thought and it would probably be better to script it in another language like Python and to maintain it separately from the ebuilds because ebuilds really shouldn't be this long. It's on my grand TODO list but fairly low down, I'm afraid.
Yeah, that sounds exactly like what's happening. I Can't figure out why, though. It looks like the first thing it searches for is "System/UTMenu.u", which does exist under "$CD_ROOT_1/". However, it also references an alternative case spelling of that same path, which doesn't exist, and then something about AutoRunData, which doesn't exist. Then there's a space followed by chaosut (which does exist) and the UnrealEd (which does not). I'm not sure what all that's about; the syntax doesn't make any sense to me. So what would you recommend? As I said before, I'm mostly interested in getting this working so I can install my copy of Unreal Gold using the linked ebuild. If this ebuild is NOT going to ultimately make it into portage, which I was assuming it would, I guess I can fall back to the old unreal-tournament-goty ebuild, but then the existing unreal ebuild in portage doesn't have amd64 support. Is there anything I can do to troubleshoot this, or should I give up on it now and save myself the time? Thanks, James.
I'm quite hazy on it myself but I've had a fresh look. So I take it you want S3TC, otherwise you wouldn't need the second CD. cdrom_get_cds is called with two lists of files, one for each CD. Each entry in the colon-separated lists corresponds to a CD set. This is how we tell the different releases apart. If you match the first entry, System/UTMenu.u, then CDROM_SET should get set to 0 and you should then see "Found UT Game CD or previous installation" but you're telling me that's not what you're seeing. Is the Help/chaosut located on your second CD? It should be. Also, are you saying that you successfully managed to install it from your original CDs? If so, why are you still trying to install from a copy on disk?
(In reply to comment #91) > So I take it you want S3TC, otherwise you wouldn't need the second CD. Ideally, yes. I'd like my game to look as good as possible. :-) > If you match the first entry, System/UTMenu.u, then > CDROM_SET should get set to 0 and you should then see "Found UT Game CD or > previous installation" but you're telling me that's not what you're seeing. Is > the Help/chaosut located on your second CD? It should be. Yeah, this is what I don't get. I can copy the "System/UTMenu.u" right out of the ebuild, cd to what I specified for CD_ROOT_1, then ls that file and it's found with no problem. I don't know why it's failing to detect that. Ditto for Help/chaosut in CD_ROOT_2 (although it's a directory - should that matter?). > Also, are you saying that you successfully managed to install it from your > original CDs? If so, why are you still trying to install from a copy on disk? I tried it just to see what would happen. It got past the point where it failed when I specified CD_ROOT_[12], so it seems like it should work fine, but I killed it after that. I'll go ahead and let it complete the install just to verify. The reason I want it to install from my on-disk copy is because I'm copying ALL of my game CDs to my NAS, both for backup purposes and convenience. If I can't install UT from the on-disk copy, though, then it doesn't do me much good. I want to make sure I can get a clean install from the on-disk copy before I consider this process done. So far, everything else (including UT 2004) has worked great; just need to figure out what's going on with this one.
So yeah, installing directly from the CD does work fine. It copied data from both CDs without a single problem.
Well, I spent another hour or so troubleshooting, and still haven't been able to figure out what's wrong. As another random and desperate experiment, I tried changing the CDROM_SET check to this: 0|1|2) UT_SOURCE="normal" Thus, any result would choose the normal CDs instead of the anthology. Once I changed this, the rest of the installation proceeded perfectly. So, all of my CD data is properly found by the part of the script that does the real work, copying and unpacking files, but the detection bits in that cdrom_get_cds is failing. I've fiddled with that line in countless ways, but I just cannot get it to return anything other than anthology. Very frustrating... I'll post one more request for help before dropping it: any other ideas or suggestions? Can anyone else with the GotY CDs get this to work (from an local disk copy, of course)? Thanks again.
(In reply to comment #94) > figure out what's wrong. Check CD_ROOT, which is used in pkg_setup().
Stick a few echos in /usr/portage/eclass/eutils.eclass if it helps. I may at this later if I have time. I don't have GOTY but it should behave the same way with the original.
Found it. Finally. Was a bug in cdrom_get_cds(). If you're interested, please check out bug 327549 for the details.
Nice work finding that. I knew there was at least one problem in the eclass. Sorry I wasn't more helpful.
Can anyone add it to the sunrise overlay or mayby in the offical portage tree? Both ebuilds (ut and unreal) work perfectly but the offical like crap. whats about replace them both?
What do you think about it? It is more stable and less buggy as the tree one... Why nobody want to intigrate id or replace the one in the tree by this one? and in this turn lets do the same with the unreal ebuild and unreal-tournament-bonuspacks versions in the bugtracker...
Less of the bugspam please. I've explained the likely reason why it hasn't gone into the tree yet. I still intend to write a new installer but it's not my top priority. As to whether it's better than the in-tree ebuild, probably yes, but there's more that could potentially go wrong with it.
Created attachment 288297 [details] games-fps/unreal-tournament-451.ebuild Updated ebuild to support installing from path containing spaces and parentheses (eg., '/Unreal Tournament (GotY Edition)'). Required some funky escaped quotes in the eval statements.
Calculating dependencies... done! [ebuild R ~] games-fps/unreal-tournament-451 USE="S3TC openal -3dfx -dedicated -doc" LINGUAS="-es -fr -it" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] y >>> Verifying ebuild manifests >>> Emerging (1 of 1) games-fps/unreal-tournament-451 * ut-install-436-GOTY.run RMD160 SHA1 SHA256 size ;-) ... [ ok ] * ut-install-436.run RMD160 SHA1 SHA256 size ;-) ... [ ok ] * UTPGPatch451.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] /usr/portage/games-fps/unreal-tournament/unreal-tournament-451.ebuild: Zeile 199: cdrom_get_cds: Kommando nicht gefunden. >>> Unpacking source... cp: Aufruf von stat für „/HELP/Logo.bmp“ nicht möglich: Datei oder Verzeichnis nicht gefunden cp: Aufruf von stat für „/HELP/ReadMe.htm“ nicht möglich: Datei oder Verzeichnis nicht gefunden cp: Aufruf von stat für „/HELP/Unreal.ico“ nicht möglich: Datei oder Verzeichnis nicht gefunden cp: Aufruf von stat für „/HELP/UnrealEd.ico“ nicht möglich: Datei oder Verzeichnis nicht gefunden cp: Aufruf von stat für „/HELP/UnrealTournamentLogo.bmp“ nicht möglich: Datei oder Verzeichnis nicht gefunden cp: Aufruf von stat für „/HELP/UnrealTournamentSetupLogo.bmp“ nicht möglich: Datei oder Verzeichnis nicht gefunden * ERROR: games-fps/unreal-tournament-451 failed (unpack phase): * cp Help * * Call stack: * ebuild.sh, line 85: Called src_unpack * environment, line 2330: Called die * The specific snippet of code: * eval cp -f "\"${CDROM_ROOT}/${HELP_DIR}\""/${HELP} Help || die "cp Help"; * * If you need support, post the output of 'emerge --info =games-fps/unreal-tournament-451', * the complete build log and the output of 'emerge -pqv =games-fps/unreal-tournament-451'. * The complete build log is located at '/var/tmp/portage/games-fps/unreal-tournament-451/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/games-fps/unreal-tournament-451/temp/environment'. * S: '/var/tmp/portage/games-fps/unreal-tournament-451/work' What is the problem and can someone fix it?? Thx!
Ok i have found it. The error is because there have to be a "cdrom" in the line: "inherit eutils games" in the ebuild -> "inherit eutils cdrom games" should it be. but doesnt know because... maybe jared B. has delete it?
Now it fails here: >>> Emerging (1 of 1) games-fps/unreal-tournament-451 * ut-install-436-GOTY.run RMD160 SHA1 SHA256 size ;-) ... [ ok ] * ut-install-436.run RMD160 SHA1 SHA256 size ;-) ... [ ok ] * UTPGPatch451.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * This package will need access to 2 cds. * CD 1: UT Game CD or Unreal Anthology DVD * CD 2: UT High Resolution Textures CD * If you do not have the CDs, but have the data files * mounted somewhere on your filesystem, just export * the following variables so they point to the right place: * CD_ROOT_1 CD_ROOT_2 * Or, if you have all the files in the same place, or * you only have one cdrom, you can export CD_ROOT * and that place will be used as the same data source * for all the CDs. * For example: * export CD_ROOT_1=/mnt/cdrom * Found CD #1 root at /media/UT_GOTY_CD1 * Found UT Game CD or previous installation >>> Unpacking source... * UT version 432 (GOTY or patched) detected /var/tmp/portage/games-fps/unreal-tournament-451/temp/environment: Zeile 3149: unpack_makeself: Kommando nicht gefunden. sed: kann patch-ut/bin/x86/ut nicht lesen: Datei oder Verzeichnis nicht gefunden * ERROR: games-fps/unreal-tournament-451 failed (unpack phase): * sed ut * * Call stack: * ebuild.sh, line 85: Called src_unpack * environment, line 2651: Called unpack_patches * environment, line 3152: Called die * The specific snippet of code: * sed "s:\`FindPath \$0\`:${dir}:" patch-ut/bin/x86/ut > ut || die "sed ut"; * * If you need support, post the output of 'emerge --info =games-fps/unreal-tournament-451', * the complete build log and the output of 'emerge -pqv =games-fps/unreal-tournament-451'. * The complete build log is located at '/var/tmp/portage/games-fps/unreal-tournament-451/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/games-fps/unreal-tournament-451/temp/environment'. * S: '/var/tmp/portage/games-fps/unreal-tournament-451/work' >>> Failed to emerge games-fps/unreal-tournament-451, Log file:
All this stuff used to be in eutils.eclass but it seems to have moved. I'll try to look at this as soon as I can but I have a very busy week ahead of me. In future, please post error messages in English (LC_ALL=C) because otherwise it's harder for us to help you.
Thanks! I found it! In this ebuild and in the unreal ebuild in https://bugs.gentoo.org/show_bug.cgi?id=130051 there have to be "cdrom unpacker" to have added :-) If you add this two words, thank it works perfectly :-) PS: same for https://bugs.gentoo.org/show_bug.cgi?id=162097 and https://bugs.gentoo.org/show_bug.cgi?id=104599. only add "cdrom unpacker" and they will work :-)
Beter Textures which should be downloaded by the ebuild with use for unreal-tournament: http://www.uttexture.com/UT/Website/Downloads/Textures/Textures.htm Beter Textures which should be downloaded by the ebuild with use for unreal: http://www.unrealtexture.com/Unreal/Website/Downloads/Textures/Textures.htm
And here is the source code of the new renderer :-) http://www.uttexture.com/UT/Website/Downloads/Patches/OpenGLPatches/OpenGLPatches.htm first the binary for windows and at the bottom the sources :-)
Created attachment 323854 [details] games-fps/unreal-tournament-451.ebuild minor update: cdrom and unpacker eclasses now explicitly included, as required
Necrobump! I hope some of you are still around. I'm just letting you know that I'm working on this again for the first time in 10 years and now I'm actually on the games team so this will definitely get committed. I've already hacked away at my old ebuild to use EAPI 6, remove games.eclass, improve case-handling, and generally simplify and clean up the code. Bash arrays FTW! :D I've lost my original copy but I still have the Anthology DVD so I'm hoping you guys can test the other versions for me. It seemed to be working pretty well before so I'll try not to change that aspect of it. I'm also going to add support for the GOG version though, which I also have. More details later!
w00t! I'm still around. Just got rather discouraged at the lack of any progress on the games stuff in the last few years and stopped bothering with it. Did see some recent updates from you in my other bugs, but just hadn't gotten around to following up on that. Since it sounds like you're genuinely interested in getting things moving again, I'll make a point to do that and give you some feedback soon. Nice to see you back, especially with that shiny Dev tag after your name. :-)
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8b093e47371dceaf8e3daaa099a8c20cba1a6d0c commit 8b093e47371dceaf8e3daaa099a8c20cba1a6d0c Author: Aaron Bauman <bman@gentoo.org> AuthorDate: 2019-12-08 21:08:20 +0000 Commit: Aaron Bauman <bman@gentoo.org> CommitDate: 2019-12-08 21:08:20 +0000 games-fps/*: drop last-rited pkgs Bug: https://bugs.gentoo.org/44351 Signed-off-by: Aaron Bauman <bman@gentoo.org> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=25ccd8cf8f654fefc66ef924b5558873e1e44dcf commit 25ccd8cf8f654fefc66ef924b5558873e1e44dcf Author: Aaron Bauman <bman@gentoo.org> AuthorDate: 2019-12-08 21:28:28 +0000 Commit: Aaron Bauman <bman@gentoo.org> CommitDate: 2019-12-08 21:28:28 +0000 games-fps/unreal-tournament: drop vulnerable Closes: https://bugs.gentoo.org/386383 Signed-off-by: Aaron Bauman <bman@gentoo.org>
