Spring RTS Engine

You asked:

Why is this engine fix not applicable to lobbies?

I answered:

Because the lobbies are not the engine and vice versa

Please reread the posts above as it appears the majority of the thread has been removed from your memory.

No, it's that you keep going completely off topic and sidestepping.

Your little fix only affects the engine which makes it absolutely worthless.

I keep leading you to the right answer (in an attempt to help you understand that the problem is actually quite complex) but you keep jumping the track.

No you're failing to actually read what I and yourself posted. This is why you think I'm sidestepping.

You are proposing Isolation mode as the solution and asking why the engine installer doesn't auto remove the security on the folder in program files.

I proposed an alternative, as isolation mode is a poor solution, a band aid at best, and what you are suggesting is merely another band aid on top.

Your counter to this was: "but how do I control where the lobbies put their stuff? How do I make them read this configuration you suggest?"

My reply was: "The engine solution is an engine solution, not a lobby solution. The two are not the same, it is up to lobby developers to solve that part, especially since technically that problem exists even with Isolation mode"

But further to the point:

Your little fix only affects the engine which makes it absolutely worthless.

I keep leading you to the right answer (in an attempt to help you understand that the problem is actually quite complex) but you keep jumping the track.

You do not lead to a fact, you state a fact. This is simply bad communication on your part. What I propose fixes numerous other issues. What you are doing is pointing out a flaw in the current lobby implementations based on the assumption that the environment is the spring working directory on a pre-Vista Windows machine.

It also demonstrates ignorance on your part of how the lobbies actually work. Go to your games folder in documents/my games/spring and you will likely find:

• A Zero-k Configuration file
• A Zero-K error log
• A spring downloader cache
• A Spring downloader error log

All that is left are tasclient and SpringLobby, of which tasclient looks in the working directory, and spring lobby has configuration options that default to ~/.spring if not set ( or found via unitsync ).

So it appears one of the main tools is fine with it, 2 of the three lobbies are too. All that is left is a patch ( or an engine developer or Linux person waltzing in saying "We already have that!" as I'm sure it's possible under Linux already ).

Isolation mode is for isolating spring installs ( ideally from others, USB drive installs, development and test environments ). For production level separation we need something more appropriate, not a band aid on top of Isolation mode.

AF wrote:For production level separation we need something more appropriate, not a band aid on top of Isolation mode.

Currently, there is nothing more appropriate. Obviously, that's what this topic was about in the first place. If you want to change how the engine and the lobbies do it, then you should either:

A: Make a patch
B: Make a new topic on it and try to persuade the devs to do it (Good frigging luck)

Personally, since I cannot do A, and B is a road to nowhere, I choose:

C: Make a Batch (and then compile it)


Currently, the way I'm doing it is the only way that works flawlessly without interfering with other spring/spring game installs.

Using a bat-to-exe converter to make a directory writeable = that has nothing to do with spring modding.
(maybe belongs to "lobby / infrastructure development", but such a hack is bad anyway)

It's not a hack. It's the same method that any program who needs write access to it's own program folder uses.

The most notable examples would be digital distribution platforms.