If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

So you're telling me that I'm insanely lucky that I've never had a problem installing any of the 60 some-odd games from the HIB guys over the spectrum of installers they use on three different systems (along with id Software's and Icculus' installer scripts for their games)?

.run is not A thing, it's just a blob. If you haven't experinced any side effects of it, it's just because you haven't cared to look what i did to you system or tried to clean it. And as also mentioned not all HIB games where delivered in .run and thowes that where might not even have been packaged by the same people.

.run is not A thing, it's just a blob. If you haven't experinced any side effects of it, it's just because you haven't cared to look what i did to you system or tried to clean it. And as also mentioned not all HIB games where delivered in .run and thowes that where might not even have been packaged by the same people.

I wasn't just talking about *.run packages. I said the HIB guys (meaning the developers who participated in the bundles - my fault for the confusion there), as well as Icculus, id Software, and Epic, seem to have solved the problem with installing on multiple Linux systems in a variety of ways. In my case, all of them work.

Let me say that again so you don't miss it: With the exception of *.rpm files (which I don't use), I can install ANY of the HIB games via ANY method the developers made available without problems on three different machines, as well as id Software's offerings, Icculus' ports, and my old Epic games.

To me, installation over multiple distributions seems like a solved problem because people have solved it. Pick an installer and I've had it work: tar.gz, *.run, *.sh, Linstaller, and whatever else they've decided to try.

So should I go buy lottery tickets and take advantage of my miraculous luck, or is GOG's excuse a little thin?

Well you completely forget that current 64 bit systems have got much more problems with binary 32 bit packages than you might think of. That's what i really think could be a problem for steam as well - especialy when some want to sell games which have been done via wine libs and can not be ported to 64 bit easyly. Also you often have to delete sdl/openal libs in order to use the system provided ones with old games because the shipped ones are so dated that you don't hear anything or you get other problems. When you use pulse audio and maybe use that to use hdmi sound then you also get much more problems. I did not manage to play Doom 3 or Quake 4 with PA on a 64 bit system without strange sound problems. Wine somehow is better integrated but you have got real huge problems with older apps. Luckyly Dhewm3 is there so that you could play at least the standard missions of Doom 3 now with a 64 bit binary (some rare crashes happend, a few more in the last level), but for RoE it really crashes too often when the Grabber is used to catch a fireball - that's really no fun at all.

I wasn't just talking about *.run packages. I said the HIB guys (meaning the developers who participated in the bundles - my fault for the confusion there), as well as Icculus, id Software, and Epic, seem to have solved the problem with installing on multiple Linux systems in a variety of ways. In my case, all of them work.

Let me say that again so you don't miss it: With the exception of *.rpm files (which I don't use), I can install ANY of the HIB games via ANY method the developers made available without problems on three different machines, as well as id Software's offerings, Icculus' ports, and my old Epic games.

To me, installation over multiple distributions seems like a solved problem because people have solved it. Pick an installer and I've had it work: tar.gz, *.run, *.sh, Linstaller, and whatever else they've decided to try.

So should I go buy lottery tickets and take advantage of my miraculous luck, or is GOG's excuse a little thin?

My point isn't that they won't work but that they tend to make a mess, removing the application later unclear or not supported in many cases.

Well you completely forget that current 64 bit systems have got much more problems with binary 32 bit packages than you might think of. That's what i really think could be a problem for steam as well - especialy when some want to sell games which have been done via wine libs and can not be ported to 64 bit easyly. Also you often have to delete sdl/openal libs in order to use the system provided ones with old games because the shipped ones are so dated that you don't hear anything or you get other problems. When you use pulse audio and maybe use that to use hdmi sound then you also get much more problems. I did not manage to play Doom 3 or Quake 4 with PA on a 64 bit system without strange sound problems. Wine somehow is better integrated but you have got real huge problems with older apps. Luckyly Dhewm3 is there so that you could play at least the standard missions of Doom 3 now with a 64 bit binary (some rare crashes happend, a few more in the last level), but for RoE it really crashes too often when the Grabber is used to catch a fireball - that's really no fun at all.

Thanks, Kano. That's a reply I can understand.

Unfortunately for your argument, I don't seem to have audio problems running Doom 3 or Quake 4 (natively) on my 64 bit install under Mint 12 with PulseAudio. I just logged into Mint to check, in fact, and I'm responding to you from the same. What's more, those games are being called from my 32 bit Ubuntu 12.04 partition. And the audio is crystal clear with no discernible lag and no crashes (yet).

I'll grant you that compiling WINE on 64 bit to run 32 bit programs was a bit of a chore, though. Why those libraries aren't included with the basic download is beyond me. I remember hunting them down being a pain in the ass.

I did recently have a minor issue with sound in UT2004 (there wasn't any) which was previously working, but adding the padsp instruction to the executable line of the launcher script (under the "#Let's boogie!" section) cleared that problem up. I'm not claiming that this was a newbie fix by any means, but neither was it coding down to the metal. However I can see having to do such a fix being a turn-off for the fire-and-forget crowd.

In summary, I guess what I'm trying to say is that I don't seem to be having these problems. If you say you're hitting bumps, then I believe you. Never doubt it. I'm just offering proof that it *can* work, and without a hitch. If we can agree that any problem which has been solved can be solved, I see GOG's position to be somewhat less than completely truthful.

My point isn't that they won't work but that they tend to make a mess, removing the application later unclear or not supported in many cases.

To me, that sounds like the developer either not knowing how to write an uninstall script, or refusing to do so. The devs of any application know damned well where every single file they've installed lives. That's not a fault of the installer, and I'm not sure that it should even be a responsibility of the developer to write. The point of obtaining software is not to uninstall it, but to put it on your machine and use it. Uninstall scripts are nice to have, not requirements for operation. And I would hardly consider the lack of one to be a dealbreaker. My application not running or crashing every two minutes - THAT'S a dealbreaker.

I agree with Kano. As stated, this doesn't sound like a strong argument.

Last edited by Larian; 10-29-2012 at 10:55 PM.
Reason: Clarity and tone

To me, that sounds like the developer either not knowing how to write an uninstall script, or refusing to do so. The devs of any application know damned well where every single file they've installed lives. That's not a fault of the installer, and I'm not sure that it should even be a responsibility of the developer to write. The point of obtaining software is not to uninstall it, but to put it on your machine and use it. Uninstall scripts are nice to have, not requirements for operation. And I would hardly consider the lack of one to be a dealbreaker. My application not running or crashing every two minutes - THAT'S a dealbreaker.

I agree with Kano. As stated, this doesn't sound like a strong argument.

They might overlook fies generated by the game. Also this is handled nicly by packages so to me it is a faling of using .run rather then a package.

Do you really use HDMI audio over PA? On a system without HDMI it worked as well.

Nope. Never used HDMI audio on my desktop because I've got a 5.1 Logitech sound system being driven by ASUS onboard audio. My monitor speakers are ... well, they're Visio monitor speakers. I'm not an audiophile by any stretch of the imagination. However I don't remember any problems with either Limbo or Skyrim when I took my rig to a buddy's place. The only connection we had was HDMI there and it played nice.

To be honest, audio has always been one of those things that I get running and then back away from slowly saying "See? it works! Now don't nobody touch this and nobody gotta get hurt ..."

If you want I could jigger around with HDMI audio to see what happens tomorrow. I'll make the adjustments and fire up Doom 3 and report back.

They might overlook fies generated by the game. Also this is handled nicly by packages so to me it is a faling of using .run rather then a package.

If I understand you correctly, you're saying that *.run packages are fine if developers make a way to clean up after themselves? I don't know about that. I'd rather deal with a few stray 20kB - and inert - text files (probably by ignoring them), than have a .deb or .rpm that only installs on a certain flavor of Linux.