It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
ssokolow: As long as the root-privileged mounting and unmounting is accomplished using scripts only (no compiled code that didn't come with my system), I'd be OK with that too. (As you may remember, I'm the guy who's more likely to turn to Wine than allow Adobe's installer to meddle in my system.)

With trustworthy root-privileged scripts, a compressed filesystem containing AIR would be equivalent to the Windows/OSX approach of bundling AIR with the game.
That sounds really neat! However, at this point I have to admit I'm *completely* out of my depth. I think our current solution for installing AIR has to rely on a binary blob from Adobe at some point in the chain.

If I recall correctly, I think there is technically speaking an option that lets us circumvent it and do everything in a manner you'd be okay with, (basically manually moving a bunch of files around by hand and sprinkle black magic on top of) but that might violate Adobe's terms of service, and thus expose us to legal liability. For instance, our script would be much simpler if we just provided the Adobe AIR binaries ourselves, however the TOS stipulate they *must* be downloaded directly from Adobe (not provided directly by the developer).

Now, if some fans wanted to put that together for themselves that's one thing, but I don't think we'd be safe to distribute that officially.
Post edited July 10, 2014 by larsiusprime
avatar
larsiusprime: That sounds really neat! However, at this point I have to admit I'm *completely* out of my depth. I think our current solution for installing AIR has to rely on a binary blob from Adobe at some point in the chain.

If I recall correctly, I think there is technically speaking an option that lets us circumvent it and do everything in a manner you'd be okay with, (basically manually moving a bunch of files around by hand and sprinkle black magic on top of) but that might violate Adobe's terms of service, and thus expose us to legal liability. For instance, our script would be much simpler if we just provided the Adobe AIR binaries ourselves, however the TOS stipulate they *must* be downloaded directly from Adobe (not provided directly by the developer).

Now, if some fans wanted to put that together for themselves that's one thing, but I don't think we'd be safe to distribute that officially.
Well the actual scripting when admin is tacked on would simply go something like this...
[code]
#!/bin/bash
#mounting process

DIR = "`pwd`/aa"
mount adobeair.sqfs ${DIR} -t squashfs -o ro
#add error checking and throw a fit if it didn't work?

#execute game now with reduced permissions
su user ./aa/adobeair game.swf

#unmount and cleanup
umount ${DIR}
[/code]

As for the terms of service, someone mentioned adobe air was no longer supported? Usually unsupported software sorta gets dumped into abandonware. But i'm not sure. Having all the executables ready to be used would qualify as installed.

I don't think the TOS can tell you where to download your stuff from in order for it to work. The license can request/limit redistribution unless certain clauses are met...
Thanks for all that! I'll forward to my linux guy and see what we can do.

As for the TOS, Adobe has dropped support, but they are still providing archived binaries of the last supported version of AIR on linux. We're basically restricted in two ways:

1) We can't provide the binaries directly, we have to download them from their servers as part of the script
2) We can't circumvent accepting the Adobe EULA, etc; or at least, if the user wants to do that the user has to do that themselves (we can't automate it as part of the script).

Other than that we can basically do whatever it takes. Not that Adobe knows or even cares, I just have to keep my nose clean :)

Anyways if you PM me on GOG here I can loop you in on testing the latest builds of this thing and we can work it out over various iterations until it's something that meets your needs.
avatar
larsiusprime: 1) We can't provide the binaries directly, we have to download them from their servers as part of the script
2) We can't circumvent accepting the Adobe EULA, etc; or at least, if the user wants to do that the user has to do that themselves (we can't automate it as part of the script).
For stability i would find a version that's archive only (tar, zip or 7z) and a version that's archived so you aren't getting the newest version, instead it's a stable version we know that works.

If we can do that, then making a script to convert adobe air via extracting the files to where they need to be in a temp directory, set permissions, then build a filesystem that will give us the result we want. Of course this would happen after the user accepts the required licenses.
Alright so I got around to extracting it and trying to get it to work on my LiveCD of Slax. naturally it doesn't work... :P Slax is a little slow due to decompression of LZMA stuff, but that I'm doing other stuff too so speed isn't important to me for this particular test.

So it's extracted, but doesn't want to run the launcher. When I force the launcher it says it doesn't want to work. So fine, I try to work the 'fancy.sh' file, and it says to install Adobe air at directory so and so. Not too bad. Then it can't detect it.

So I think I just need a readme to follow that says where I should have this extracted to, what should be the working path (if there is one), if it requires a specific versions of libraries and which ones, and what should generally be in place already.

The version of Slax I'm using is the newest, so that's 7.0.8, which means most of the libraries will be up to date if they are a year old or so. (That includes I think KDE, but not Gnome).

So get back with me and I'll try to continue testing it here. Been a little while since I did this stuff..

edit: Some tinkering and although I got something working, I didn't get the launcher working. So...

edit2: Just occurred to me I didn't check which architecture I ran my liveCD on, and I'm pretty sure it was 64bit. With the games being 32bit that means the programs wouldn't run due to that and not any other technical difficulties, so I'll give it a second try.

So I gave it a try and the binaries work fine. Unfortunately slax doesn't use RPM's, so that's a bummer. But it is better than I thought. I'll give Ubuntu a try next.
Attachments:
slax_test.jpg (326 Kb)
Post edited July 13, 2014 by rtcvb32
Honestly? I think you should just go with:

avatar
larsiusprime: 1) Re-release a Haxe version of DQ1
DQ2 is basically going to be a rewrite of the DQ engine with new content. Theoretically this means we could re-release the original game data set in the new engine. The Haxe engine compiles down to C++ so it won't have a trace of AIR or flash or anything. That said, it will NOT be available anytime soon.
You'll avoid all these headaches and it's by far the safest option.
avatar
ALordaB: Honestly? I think you should just go with:

avatar
larsiusprime: 1) Re-release a Haxe version of DQ1
DQ2 is basically going to be a rewrite of the DQ engine with new content. Theoretically this means we could re-release the original game data set in the new engine. The Haxe engine compiles down to C++ so it won't have a trace of AIR or flash or anything. That said, it will NOT be available anytime soon.
avatar
ALordaB: You'll avoid all these headaches and it's by far the safest option.
The key phrase is "That said, it will NOT be available anytime soon."

As I understand it, this is about what to do right now, regardless of whether a Haxe re-release is made.
A new version is up in the usual place, for those of you who have tester access, except the filename is

gog_package.tar.gz

instead of .zip

I've included the Adobe AIR uninstall script now, and updated some of the other scripts, and I've included a README so we can manually handle common trouble-shooting issues.

Please give it a test and let me know how it goes?

(If you don't have tester access, just PM me)
Post edited July 21, 2014 by larsiusprime
By the way: folks who have PM'ed me, please make sure you have your contact settings such that you allow people to PM you back, otherwise there's no way for me to reply to you :)
avatar
larsiusprime: By the way: folks who have PM'ed me, please make sure you have your contact settings such that you allow people to PM you back, otherwise there's no way for me to reply to you :)
Oops... sorry! I've changed my setting. I forgot I had it disabled when I first signed up because I never thought I'd use it.
All right, I managed to do a little testing last night.

Mint 17 "Qiana" 32-bit Cinnamon edition

Launcher works like a charm. Launching simple and fancy versions work perfectly.

A couple minor things I noticed in-game:
- The EULA link did not work, nor did any buttons that are bound to external URLs.
- Sound effects seem delayed by half of a second; not sure whether or not this is merely a local issue
- Text was overlapping the graphics in one of the "goodies" message boxes. I have a screenshot but I left it on my home PC... I can provide it this evening
- Fancy version - when playing the official space mod, after every mission, the "Click here to begin" prompt and arrow pointing to the first mission reappears. Same thing when exiting town. I don't recall whether or not this happened on the Windows version.

I forgot to test the AIR uninstall feature, so I will do that tonight.

Fedora 20 x86_64

Could not get it to run. I guess I should have read the rest of this thread prior to trying this, as it was mentioned that 64-bit won't work out of the box.

It seems installing the glibc.i686 package got me partway there, but then I also needed to install the libstdc++.i686 package and for some reason yum refused to install it. I suspect this is because the package doesn't play nice when installed alongside its 64-bit counterpart, but I'm not really sure since this exceeds my knowledge of Linux. I would have kept troubleshooting but I ran out of time last night. If someone knows how I can get this working on Fedora x86_64, I would be very appreciative.
Post edited July 22, 2014 by jforte
I attached the screenshot I previously mentioned.

Tested on Arch Linux and it works beautifully. The simple version worked right away.

Fancy version was a little more involved, which should not be an issue for anyone who's bothering with Arch in the first place. However, I think it's worth noting that the xterm window was exiting immediately, so I did not even realize it was echoing instructions specifically for Arch Linux users until I dug around in the scripts. Now that I have it set up, it works great.
Attachments:
Thanks for that feedback. Looks like we didn't quite make it for the Linux launch, so I'll use the extra time to fix some of those little bugs if I can.