problems with hardy install

[dclee]

not really a problem for me.but for other it could be.
mods maps ai are installed to home/username/spring not home/username/.spring

if this happens to you just copy continence of spring to .spring
unless you do this you will also get an error when trying to use the CAupdater as it can't find the mod directory.

but after you do as written above it will work.

just thought I'd let people know just in case they hit the wall i hit

[YokoZar]

Copied there by what?

The package itself doesn't install anything there...

[aegis]

iirc the python ca updater defaulted to .spring/mods

[Tobi]

SL defaults to enabling ~/spring as data directory in ~/.springrc.

~/.spring however, is still enabled in the ubuntu packages, so you ought to be able to use both directories at the same time. (~/spring is then used as writable data directory, ie. screenshots/demos etc. end up there.)

Cadownloader throws an exception if ~/.spring/mods doesn't exist so you have to create that before using it, that was probably why cadownloader didn't work for you.

[YokoZar]

SL defaults to enabling ~/spring as data directory in ~/.springrc.

~/.spring however, is still enabled in the ubuntu packages, so you ought to be able to use both directories at the same time. (~/spring is then used as writable data directory, ie. screenshots/demos etc. end up there.)

Cadownloader throws an exception if ~/.spring/mods doesn't exist so you have to create that before using it, that was probably why cadownloader didn't work for you.

This seems wrong, application data directories should always be hidden.

[BrainDamage]

not necessarily, all those app dirs are not supposed to be manually modified by the user (settings, cache, ecc), something which instead is required with a spring installation (copying widgets, replays, ecc), and tbh you're not online to see that 9/10 new users were having problems with the hidden folder (not finding, ecc); I just don't see why creating an invisible path by default if afterwards you'll always have to symlink it to make it visible, instead create it visible by default and give the option to make it invisible (like it is now).

I just changed SL dir creation wizard to default to $home/spring instead of $home/.spring, then it saves as usual to .springrc, the fact that python downloader doesn't like isn't SL's fault because spring datadir handler doesn't have any hardcoded path and instead checks for .springrc entry.

It's the downloader which is non standard here, I actually have a windows partition referenced in my .springrc and works perfectly fine, in fact if spring doesn't have your datadir set in springrc uses the home folder itself ....

[YokoZar]

not necessarily, all those app dirs are not supposed to be manually modified by the user (settings, cache, ecc), something which instead is required with a spring installation (copying widgets, replays, ecc), and tbh you're not online to see that 9/10 new users were having problems with the hidden folder (not finding, ecc); I just don't see why creating an invisible path by default if afterwards you'll always have to symlink it to make it visible, instead create it visible by default and give the option to make it invisible (like it is now).

Fair enough, but some of this should be accessible through the Springlobby interface itself. You've been pretty good with that though.

[clericvash]

not necessarily, all those app dirs are not supposed to be manually modified by the user (settings, cache, ecc), something which instead is required with a spring installation (copying widgets, replays, ecc), and tbh you're not online to see that 9/10 new users were having problems with the hidden folder (not finding, ecc); I just don't see why creating an invisible path by default if afterwards you'll always have to symlink it to make it visible, instead create it visible by default and give the option to make it invisible (like it is now).

Fair enough, but some of this should be accessible through the Springlobby interface itself. You've been pretty good with that though.

See i asked about it before and i got a shit answer "because that is how all linux programs and games work". Well has anyone asked why the fuck we have to have hidden folders all the time, seriously, it helps no one.

[Martin]

... Well has anyone asked why the fuck we have to have hidden folders all the time, seriously, it helps no one.

Well, I for one want the folders hidden because I consider it rude for a program to create new (visible) folders in my home directory. I just want to play Spring and maybe add some new maps -- I don't want a new folder in my tidy home directory.

I have 17 visible and 89 hidden folders in my home directory right now. Imagine if all the hidden folders were visible, then I would have a hard time finding the folders I actually care about.

[YokoZar]

not necessarily, all those app dirs are not supposed to be manually modified by the user (settings, cache, ecc), something which instead is required with a spring installation (copying widgets, replays, ecc), and tbh you're not online to see that 9/10 new users were having problems with the hidden folder (not finding, ecc); I just don't see why creating an invisible path by default if afterwards you'll always have to symlink it to make it visible, instead create it visible by default and give the option to make it invisible (like it is now).

Fair enough, but some of this should be accessible through the Springlobby interface itself. You've been pretty good with that though.

Actually I changed my mind, the user shouldn't have to trudge through the spring folder in almost all cases. That means we can do the right thing and hide it.

You can still make opening the folder accessible within the lobby client, of course; though, really, old maps/mods/replays should be removable from within the lobby interface as it can provide more information than nautilus ever could.

The lobby should autoinstall the maps/mods, and hand-downloaded ones should be installable with spring-installer. Settings shouldn't need to be edited by hand either. With all that taken care of, there's very little use case to go back into the folder by hand.

[koshi]

The lobby should autoinstall the maps/mods

the lobby _would_ do that for going on 5 months now, if someone had managed to package the necessary torrent lib...

[YokoZar]

The lobby should autoinstall the maps/mods

the lobby _would_ do that for going on 5 months now, if someone had managed to package the necessary torrent lib...

Right, that's where the problem is, not in the directory being hidden.

[clericvash]

The lobby should autoinstall the maps/mods

the lobby _would_ do that for going on 5 months now, if someone had managed to package the necessary torrent lib...

That doesn't help manually downloaded maps, mods, ai at all now does it, that just helps in-lobby downloads right?

[det]

The lobby should autoinstall the maps/mods

the lobby _would_ do that for going on 5 months now, if someone had managed to package the necessary torrent lib...

That doesn't help manually downloaded maps, mods, ai at all now does it, that just helps in-lobby downloads right?

Manually downloaded mods/maps are moved to your Spring dir with spring-installer now[1]. Just double click on them and click 'Install' or even open them directly from your web browser. AIs are different to archives, they would most likely be installed with apt into the system dir.

[1] spring-installer is in the Ubuntu PPA repository but isn't installed by default yet, it will become a dependancy of 'spring' soon. "aptitude update; aptitude install spring-installer" to start using it.