You are not logged in.
Have fun :-)
Offline
Not too impressed with the line-up this time around, hib #5 had the better line-up by far with Bastion, Limbo, Amnesia, Psychonauts and Swords and Sworcery.
Still, picked it up. Value for money is fairly insane.
Arch i686 on Phenom X4 | GTX760
Offline
Still, picked it up. Value for money is fairly insane.
I was thinking about this the other day: some people consider $0.99 for a song or couple bucks for a game to be actually too cheap, but not everyone earns the equivalent of $40-50k per year (average US & Wester Europe income).
Steam sales, Humble Bundles etc. means games "for the rest of us" :-)
Offline
I buy the Bundle every time, usually for around 10 bucks which is over the average (around the Linux average, which is *always* the top average) but still pretty cheap. I really, really wanted McPixel to figure in this one. Lost my chance a couple of weeks ago.
Swords and Sorcery was my favourite of all bundles up until now. From this one I tried Shatter, but there was a problem with textures being rendered as black only, didn't bother much with it because it's not my type of game anyway. Also tried DustForce, reminded me a lot of a platformer I used to play a few years ago - N. I don't have the time to invest in something like SPAZ, but it seemed pretty interesting, too.
Apart from Shatter, they seem to be working pretty well.
Offline
stefanwilkens wrote:Still, picked it up. Value for money is fairly insane.
I was thinking about this the other day: some people consider $0.99 for a song or couple bucks for a game to be actually too cheap, but not everyone earns the equivalent of $40-50k per year (average US & Wester Europe income).
Steam sales, Humble Bundles etc. means games "for the rest of us" :-)
Exactly!
They also provide some push for Linux development, albeit fairly limited (some actual native clients are developed, some end up being packed with a patched wine version), and provide amazing soundtracks on the side. In good quality.
I'm curious to see if they'll be adding games to this bundle as time progresses, they have been doing so far the previous bundles and I'm half expecting (hoping) this to happen again.
They're already on 73k+ sales
Arch i686 on Phenom X4 | GTX760
Offline
Another great bundle (though HB5 was the best).
I wish HB mentioned whether it was native/wine on their page. I'm not interested in playing games through wine.
Offline
Too...many...HB games.....
Seriously. I've gotten all of them so far but I've barely finished or even really spent much time with most of the games. I wish they'd only do it once per year...too much of a good thing and such. Nevertheless, I just got #6 so I'm looking forward to giving them a try
Offline
Cheers, Karol!
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
I am a little shocked. The torchlight installer understands pacman-ish. I installed it to the default path in /usr/local/{game,bin} and when I was asked whether it should register itself with the systems package manager, it produced a "valid" pacman entry:
$ pacman -Qi Torchlight
Name : Torchlight
Version : 1.0.20120918-1
URL : http://torchlightgame.com
Licenses : None
Groups : None
Provides : None
Depends On : None
Optional Deps : None
Required By : None
Conflicts With : None
Replaces : None
Installed Size : 498203,17 KiB
Packager : Edward Rudd http://www.outoforder.cc/
Architecture : x86_64
Build Date : So 31 Dez 1899 00:00:00 CET
Install Date : Mi 19 Sep 2012 00:14:15 CEST
Install Reason : Explicitly installed
Install Script : No
Description : An action role-playing game.
Offline
I am a little shocked. The torchlight installer understands pacman-ish. I installed it to the default path in /usr/local/{game,bin} and when I was asked whether it should register itself with the systems package manager, it produced a "valid" pacman entry:
Interesting indeed.
If only the package name didn't start with a capital letter ;P
Build Date : So 31 Dez 1899 00:00:00 CET
Offline
I see there's a Torchlight soundtrack up for grabs with the HB6. If you want the Torchlight 2 soundtrack (for free), go to http://www.torchlight2game.com/news/201 … oundtrack/ - 28 mp3s are waiting.
(source: The Escapist)
Last edited by karol (2012-09-18 22:39:13)
Offline
Fortunately, it seems to be very PKGBUILD friendly:
$ ./Torchlight-2012-09-18 --help
Usage: ./Torchlight-2012-09-18 [options]"
[options] can be one of the following things (all are optional):
General:
--help, -h Print this message.
--info, -i Print some info about this installer.
--check, -c Check integrity of the archive.
--frontend, -f <fr> Specify frontend
--unattended, -u Run installer unattended (no interaction)
Unattended (requires -u/--unattended):
--no-register, -r Disable package registration, therefore allowing non root installs.
--bindir, -b <d> Sets the destination directory for any executables. Make sure you have read/write access to this directory.
--overwrite, -O Install package, even if it overwrites any existing.
--datadir, -d <d> Sets the data destination directory. The data files are installed inside a subdirectory inside this directory. Make sure you have read/write access to this directory.
--ignore-failed-deps, -D Ignore any missing or faulty dependencies.
--packager <p> If the installer finds more than 1 package manager, use this to specify which one should be used. Run the installer without to see which are available.
--dlretries <n> Amount of retries incase downloading a dependency fails. Default: 3.
Advanced:
--keep Do not erase temporary target directory.
--nox11 Do not spawn an xterm.
--target dir Sets target directory for core contents (default is a temporary directory).
--tar arg1 [arg2 ...] Access the core contents of the archive through the tar command.
EDIT:
It also seems to bring all of it's depencencies along. There is even a copy of xdg-utils. Weird.
Last edited by Awebb (2012-09-18 22:45:13)
Offline
I got an error installing Torchlight
Error: Lua error detected: Unknown error!
No further info, that's all she wrote. Any ideas? Any dependency I may be lacking? I do have lua installed.
edit: Turns out I had just run out of space in /tmp. Not related to lua, then
Last edited by Onyros (2012-09-19 00:15:54)
Offline
just installed Torchlight. Installer was pretty good. After it installed, it wasn't in the PATH, and I couldn't just type the app name in GNOME3. I made a .desktop file for this.
Here it is, in case any of you want to copy it
/usr/share/applications/Torchlight.desktop
[Desktop Entry]
Categories=Game;ActionGame;
Encoding=UTF-8
Name=Torchlight
Exec=/usr/local/games/Torchlight/Torchlight.bin.x86_64
Icon=/usr/local/games/Torchlight/Torchlight.png
Type=Application
I have dual monitors, and the game runs at full resolution, but windowed (despite the settings saying fullscreen). Anyone have the same issue?
Offline
For some reason Shatter didn't install ok, I search on the directory where it says it will install the executables and it's empty. I'm having this problem with Torchlight as well, it's Nixstaller that is not working properly.
My bad the executable was in /usr/local/games.
Last edited by madprops (2012-09-19 01:22:59)
Offline
PKGEXT=".pkg.tar"
source=("Bastion-HIB-${_pkgver}.sh::https://www.humblebundle.com/login"
"Bastion-HIB-${_pkgver}.sh::http://www.humblebundle.com/downloads?key=${_humblebundleVkey}"
"$pkgname.desktop"
"mesa$pkgname"
"$pkgname.install")
case $CARCH in
i686) _arch=x86 ;;
x86_64) _arch=x86_64;;
esac
_char=\'
DLAGENTS=('https::/bin/echo %o > /tmp/arch && sed -i "s/.part//" /tmp/arch &&
/usr/bin/curl -s --cookie-jar /tmp/cjar --output /dev/null %u && cp /tmp/cjar ./ &&
/usr/bin/curl -sL --cookie /tmp/cjar --cookie-jar /tmp/cjar --data "username=$_humbleemail" --data "password=$_humblepassword" %u |
grep -f /tmp/arch |grep -o -E "data-web=[^ ]+"| sed -e "s/data-web=\([^ ]*\)/\1/" > /tmp/url &&
sed -i "s/$_char//g" /tmp/url &&
/usr/bin/curl --cookie /tmp/cjar --cookie-jar /tmp/cjar -fLC - --retry 3 --retry-delay 3 -o %o "$(</tmp/url)" &&
rm -f /tmp/{arch,url} || return 0'
"http::/usr/bin/curl -sL %u | grep Bastion-HIB | sed -e \"s/.*data-web='\([^']*\)'.*/url = \1/\" > /tmp/url &&
/usr/bin/curl -fLC - --retry 3 --retry-delay 3 -o %o -K /tmp/url && rm /tmp/url"
)
if [[ ! -f $SRCDEST/${source[0]%%:*} ]]; then
if [[ -z $_humbleemail || -z $_humblepassword ]]; then
if [[ -z $_humblebundleVkey ]]; then
msg "if you have bound your email and password to your account, "
msg "please export the values _humbleemail and _humblepassword so"
msg "that you can be logged in to download the game."
echo
msg "if you have not bound the key to an email, "
msg "please export _humblebundleVkey in your .bashrc"
return 1
fi
fi
fi
please use this type of thing for managing the source files... this way they can be downloaded directly in the pkgbuilds without using extra functions
I suggest still using _humbleemail and _humblepassword for any accounts, and _humblebundle6key for just the key
EDIT: ahh code tags, also I have put another example in for shatter-hib already, and lonesurvivor and i just put one in the shatter-hib comments
Last edited by gtmanfred (2012-09-19 01:50:03)
Offline
@gtmanfred
Please use [ code ] tags for posting code
like this
so it's more readable (monospaced font) ans easier to scroll (for longer listings): https://bbs.archlinux.org/help.php#bbcode
Offline
I think the games are pretty good even though I had never heard of any of them before.
Right now, I could only get two games to run perfectly: Torchlight and S.P.A.Z.
Shatter renders some of it's textures in black (as stated above). (Otherwise, the game works fine. In fact it works so fine that I managed to play it without realising the textures weren't supposed to be black for a little while.)
There appears to be a bug with Rochard's installer (It uses mono) so I can't tell yet if the game runs correctly.
Dustforce gives me only a black screen and when I'm lucky, some music plays in the background. (When I press ESC, I can hear a menu popup. I can then use the menu blindly to exit the game (It's the last option).)
(Vessel should be coming shortly.)
I'm surprised I had those errors since I remember fixing most of them a couple months ago when they occured with some of the games in the Humble Bundle 5.
Offline
Torchlight is great, but I'm getting an error when I try to descend to the 3rd level...
Torchlight.bin.x86: /builddir/Torchlight/TorchlightMacPort_09b/Projects_9156/Delvers/Delvers/EditorFramework/Logic/LogicObject.cpp:369: void CLogicObject::loadAndRelinkObjectInFromBinaryFile(CLogicGroup*, COgreReader*, CDescriptorLoadConfiguration*, std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> > >&): Assertion `pObjectDescriptorLinkingTo && m_pObjectDescriptor' failed.
Aborted
Anyone else with the same problem?
Offline
Torchlight is great, but I'm getting an error when I try to descend to the 3rd level...
Torchlight.bin.x86: /builddir/Torchlight/TorchlightMacPort_09b/Projects_9156/Delvers/Delvers/EditorFramework/Logic/LogicObject.cpp:369: void CLogicObject::loadAndRelinkObjectInFromBinaryFile(CLogicGroup*, COgreReader*, CDescriptorLoadConfiguration*, std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> > >&): Assertion `pObjectDescriptorLinkingTo && m_pObjectDescriptor' failed. Aborted
Anyone else with the same problem?
Yup.
torchlight: /builddir/Torchlight/TorchlightMacPort_09b/Projects_9156/Delvers/Delvers/EditorFramework/Logic/LogicObject.cpp:369: void CLogicObject::loadAndRelinkObjectInFromBinaryFile(CLogicGroup*, COgreReader*, CDescriptorLoadConfiguration*, std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> > >&): Assertion `pObjectDescriptorLinkingTo && m_pObjectDescriptor' failed.
I get that when going to the first waypoint from town. Bah.
Offline
<snip>
please use this type of thing for managing the source files... this way they can be downloaded directly in the pkgbuilds without using extra functions
As the author of the PKGBUILDs in question, I'm sympathetic towards requests for adding auto-downloading support, although I don't think it's actually necessary.
The AUR just wasn't built as a system for fetching sources from non-public locations. Simply asking users to download the files at their own leisure and then provide them locally before running makepkg is imo the KISS way. (And it also allows the user to e.g. choose torrent over web download etc.)
Of course, that "provide sources locally" solution is - by default - rather inconvenient: You have to manually locate the PKGBUILD folder (which is annoying when using an AUR helper) and manually place the archive in it. Whenever the package is to be reinstalled (e.g. when its $pkgrel was bumped), that needs to be repeated.
I presume it is this inconvenience associated with the "provide sources locally" solution, that leads people to ask for auto-downloading support even in case of Humble Bundles and the like.
I on the other hand think a more generic and in many ways better alternative is to instead make the "provide sources locally" solution more convenient.
This is what the _get_local_source() function does, which I already use in some of my PKGBUILDs:
For one thing, it explains to the user in which places exactly it looks for the source archive, so even newbies will know what they need to do.
Secondly, in addition to the PKGBUILD directory, it supports a second, user-defined search location - specified through the $LOCAL_PACKAGE_SOURCES environment variable. (And additional search locations are easy to implement.)
The recommended user work-flow now becomes:
buy/redeem your Humble Bundle
on your personal Humble Bundle page, click the download links of the games you want to install
export LOCAL_PACKAGE_SOURCES=~/downloads (or wherever your browser or torrent client places finished downloads)
packer -S xxxx-hib yyyy-hib ...
enjoy :-)
No more having to manually move around files. And if you set the environment variable persistently, future package upgrades will be completely painless as well.
This I think achieves about the same (and maybe even better) level of convenience as letting the user specify the humble bundle keys or account info as environment variables, and then performing auto-downloading in the PACKAGEBUILDS. Thus arguably making auto-downloading obsolete.
(Remember that unlike with most open-source AUR packages, the Humble Bundle download links are not something you'll have to tediously google for first - you will have them all at your fingertips right after buying a bundle, ready to click.)
The _get_local_source() funtion has the added benefit that it can be reused as-is for many other PKGBUILDs beyond Humble Bundle games, thus establishing a consistent way for AUR users to locally provide sources for PKGBUILDs with only a single environment variable that needs to be remembered (or set permanently).
-----------
As I stated at the outset, I'm sympathetic towards requests for auto-downloading (with _humbleemail, _humblepassword, _humblebundle6key env. variables), if people really want it, in addition to the streamlined "provide sources locally" solution outlined above.
However, I'm skeptical of your particular suggestion for implementing it (by overwriting DLAGENTS).
The way I see it, simply defining a _get_humblebundle_source() function (to wrap _get_local_source(), adding humblebundle.com downloading capabilities for the case that the source archive was not found locally) has the following benefits compared to your solution:
better front-end usability/polish
With your solution, if e.g. the user chooses to set _humblebundle6key rather than HiB account info, it will look like this:
==> Retrieving Sources...
-> Downloading shatter-linux-1347954459.sh...
curl: (3) <url> malformed
-> Downloading shatter-linux-1347954459.sh...
Other corner cases or invalid input are also hard to handle and/or will produce less than helpful output for the user.
With a custom function, the input and output can be validated and controlled completely in a user-friendly manner.
better PKGBUILD readability
Users are supposed to read/edit any PKGBUILD from the AUR which they install, to verify it doesn't do anything unexpected, and to potentially apply customizations/workarounds.
This imo translates into a responsibility for AUR packagers to not make the PKGBUILDs overly difficult to read and understand.
Having a big block of very obscure (for non makepkg-experts) spaghetti code before package() violates that.
My custom functions also add some readability burden, but not nearly as much since they neatly encapsulate the relevant code and make it easy to see even for newbies when exactly it gets called.
better PKGBUILD maintainability
My _get_*_source functions are just normal bash script snippets that evaluate in the same normal bash environment as the build() and package() functions, so there's nothing that requires special attention. The code can also be split across multiple short commands as convenient.
Compare this to the DLAGENTS solution: The code for each use-case needs to be pressed into in a single complex command that evaluates inside a raw shell environment. Plus you're getting into quoting hell.
I, for one, am pretty sure I can predict under which solution fixing a bug or adding a feature or adapting to humblebundle.com changes would be more pleasant (and less time-consuming)... :-)
better forward compatibility
I've seen ideas for PKGBUILD function libraries floating around on the mailing list in the past. If we already today encapsulate any code in AUR PKGBUILDs that would be worthy of including in such libraries in self-contained and reusable functional form, it will both be easier to evaluate whether such libraries might make sense to implement, as well as facilitate their adoption if they do get implemented.
Last edited by sas (2012-09-19 06:34:41)
my AUR packages ~~ my community contributions
Offline
As the author of the PKGBUILDs in question, I'm sympathetic towards requests for adding auto-downloading support, although I don't think it's actually necessary.
The AUR just wasn't built as a system for fetching sources from non-public locations. Simply asking users to download the files at their own leisure and then provide them locally before running makepkg is imo the KISS way. (And it also allows the user to e.g. choose torrent over web download etc.)
Indeed. Since I stopped using fully automatic AUR helpers, that make you an AUR lazybone, I stopped caring about downloading additional files. It is still a nice-to-have.
Offline
@sas
your functions however do not any checks that the package is actually what the name says it is (md5sum or sha sum)
I only suggested the DL_AGENTS array because in your pkgbuilds you mentioned you wanted to implement retrieving the files
if you are going to do that, please use DL_AGENTS, as then you are able to set the actual %u and %o for downloading and have makepkg take care of the md5sums, etc and actually use the source array
and by including the urls, you are actually able to use makepkg -g etc and have the md5 sums update anyway... that was the reason i suggested them
Offline
I buy the Humble Bundle just out of principle each time, that they have working linux versions. I wish I'd heard about it before HB5 though, I've only got it, 6, music bundle and android bundle 3. I really wanted Machinarium. I'm so broke that I pay about $10, only because I can't afford to buy any big games atm.
D:
Offline
Do you guys think it would be possible to have a stand-alone torchlight launcher in the AUR just like Jagged Alliance 2? Just the launcher without
the resource files. I have purchased TL1 on Steam some time ago. It works flawless with PlayonLinux without ever crashing or glitches but it would be nice
if I could use the native client too.
Last edited by blackout23 (2012-09-19 14:52:33)
Offline