Spring RTS Engine

I run Vista and UAC on my desktop.

Yeah, I know.

I do that because I develop software on this machine, and I want it to resemble the configuration of the average user, who is sadly stuck with Vista and UAC.

Now, here's the problem: the normal tools of Spring (that is, ArchiveMover and TASClient) are broken by UAC.

For a non-admin program, UAC makes any changes to the Program Files dir in the Virtualstore instead, silently. ArchiveMover runs as userland, so it works in the Virtualstore (even though it thinks otherwise). Spring reads from the Virtualstore, so this works fine. Springlobby does too. TASClient, on the other hand runs as admin, so it works only in Program Files. So, after I fetch a file from Jobjol and let Archivemover place it, TASClient can't find the file. I hit "refresh maps" and nothing happens.

This means that, to a normal user running Vista, UAC, ArchiveMover, and TASClient (which probably isn't too rare an occurrence) ArchiveMover makes files vanish. It even lies about where the file goes (well, microsoft lies, but ArchiveMover repeats the lie).

Now, I have a workaround: I can create a Spring DataDir (I used SpringLobby to do that)... but if you do that, TASClient throws a fit until you move the Lobby folder over into your DataDir.

So all in all, this is a mess.

(thanks to Brain Damage for helping me understand what's going on)

1. Archivemover needs a manifest to run as admin.
2. Why put spring in program files? You like running spring as admin just so it can edit your luaui configs?

I'm quite happy with UAC over here on my server 2008 install.

lurker wrote:1. Archivemover needs a manifest to run as admin.

It should not, and I think thats what he is complaining about.

lurker wrote:2. Why put spring in program files? You like running spring as admin just so it can edit your luaui configs?

Because thats where program files are supposed to be? And in linux, I don't need to run spring as admin to edit my luaui configs.

He's complaining that when it doesn't run as admin it hides the mods and maps in a virtualized program files and only the archive mover can see.

And as to your second point, he already said that setting up a separate data directory screws with tasclient.

that's the other part of the "portable spring" spectrum - ie. spring installed in Program Files (actually, any non-writeable directory) should use My Documents and App Data for content and configuration. ArchiveMover will have to learn to use unitsync if it doesn't already (for datadir stuff.)

lurker wrote:1. Archivemover needs a manifest to run as admin.
2. Why put spring in program files? You like running spring as admin just so it can edit your luaui configs?

I'm quite happy with UAC over here on my server 2008 install.

Because Spring goes in Program Files by default.

Let me clarify: I don't care about this bug. I have it resolved for myself.

But for any user with a stock Vista box (UAC), the default installation of Spring is broken - default installation is TASClient and Archivemover, all running in Program Files (UAC will request permission to install them there, and it will be granted because all users click "yes"). Then, ArchiveMover will place files in the VirtualStore and TASClient will not find them there. The same problem also occurs if you fetch files using SpringLobby (virtualstore) with TASClient (not virtualstore).

I already have a workaround. I don't need another one. I'm just saying that other Vista/UAC users might find this to be a showstopper.

That's a lot of newbies that are getting hosed.

That's kind of issue that's going to put off 80% of potential mainstream audience but is likely to never get fixed because devs would answer that you should just use Linux.

But I agree that ArchiveMover.exe is very phail, I first noticed that when I accidentaly double clicked in a mod already in /mods/ So phail that I make sure not to include it in my installers.

Pxtl wrote:But for any user with a stock Vista box (UAC), the default installation of Spring is broken - default installation is TASClient and Archivemover, all running in Program Files (UAC will request permission to install them there, and it will be granted because all users click "yes"). Then, ArchiveMover will place files in the VirtualStore and TASClient will not find them there. The same problem also occurs if you fetch files using SpringLobby (virtualstore) with TASClient (not virtualstore)

This is not, in my opinion, a Spring/ArchiveMover bug. It isn't even a Vista bug. It's a TASClient bug pure and simple. TASClient should not require running as a superuser. It has no valid reason to run as superuser. The whole Spring suite SHOULD be putting everything in the virtualstore or normal user home or whatever. Running as superuser defeats the whole purpose of UAC, which is to warn users that a program is being given rights not generally required by day-to-day applications. If someone intimate with TASClient can justify the need for administrative rights beyond a poor choice of support libraries or Vista network port lockdown then I'll take that back but I see no reason to repeat this poor behaviour in the rest of the Spring package.

If non-admin users can't install Spring then something is wrong.

BTW: On WinXP I installed to D:\Games\Spring. I can't see any Spring content in Program Files.

zwzsg wrote:But I agree that ArchiveMover.exe is very phail, I first noticed that when I accidentaly double clicked in a mod already in /mods/ So phail that I make sure not to include it in my installers.

Now that IS a bug. I'll look at the code as it should be rather easy to fix.

I agree. Either way, somebody has to make the change.

Also, ArchiveMover does have _one_ incompatibility with UAC - ArchiveMover tells the user where it just put the file. UAC redirected the file, so when the user opens up Windows Explorer to take a peek into Program Files, they won't find the file where ArchiveMover said it would go.

However, I doubt UAC ever tells you where it just put that damned file, so I'm not sure there's a good answer for that one.

Pxtl wrote:However, I doubt UAC ever tells you where it just put that damned file, so I'm not sure there's a good answer for that one.

Give.
It.
A.
Manifest.


And I find programs putting files in the wrong spot very preferrable to erroring out because they can't save at all.

Lurker, i already posted that this isn't my problem. I'm not saying "wahhh, can you help me with this". I already have my own fix. I'm saying "this is going to cause problems for people".