RifE Launcher thread

maybe it's WinXP, maybe it's the Steam version

Click to expand...

Definitely not XP. I am using Win 7 64bit Steam I would believe though, because that is what I am using.

By the way the command "multiple" in my path was in the path that CivIV was using to launch RIFE. (I used Sysinternals Process Explorer to find it)

having a little trouble here. Tried changing the "read only" attribute on the specified folders, and it seems to work, but when I look at the files again after confirming, they return to read-only. I am an administrator on my machine (XP).....not sure what gives, here.

Any thoughts?

Does the launcher support /altroot?

My aliases are normally like:

"C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Civ4BeyondSword.exe" mod="Mods\Rise from Erebus" /altroot="Z:\Documents\My Games\Rise from Erebus"

That way all save files, options, etc are saved to a separate directory than plain Civ, or other mods. (I like to have separate save directories for each mod).

Elm said:

Does the launcher support /altroot?

My aliases are normally like:

"C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Civ4BeyondSword.exe" mod="Mods\Rise from Erebus" /altroot="Z:\Documents\My Games\Rise from Erebus"

That way all save files, options, etc are saved to a separate directory than plain Civ, or other mods. (I like to have separate save directories for each mod).

Click to expand...

no, it doesn't because I haven't know about that ... i'll try to add it

Moin,

can't disable modules via rife-launcher. The error-window says:


System.IO.IOException: You don't have access to "C:\Program Files (x86)\2K Games\Firaxis Games\Sid Meier's Civilization 4 Complete\Beyond the Sword\Mods\Rise from Erebus1.30\Assets\Modules\NormalModules\FallUnder".
bei System.IO.DirectoryInfo.MoveTo(String destDirName)
bei RifELauncher.FormModules.buttonCommit_Click(Object sender, EventArgs e)
bei System.Windows.Forms.Control.OnClick(EventArgs e)
bei System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.ButtonBase.WndProc(Message& m)
bei System.Windows.Forms.Button.WndProc(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Arctic Nightwolf said: "but before that, try to check whether you have write permission to the modules / inactive modules folders (( properties -> security/permissions -> enable write permission for you ))".

I'll try that now.

Greez,

Tschuggi


P. S.: I enabled access for me but it's still not possible to disable the modules (Bannor - Chain of command, Fall Under, Mekara Order).

Tschuggi said:

System.IO.IOException: You don't have access to "C:\Program Files (x86)\2K Games\Firaxis Games\Sid Meier's Civilization 4 Complete\Beyond the Sword\Mods\Rise from Erebus1.30\Assets\Modules\NormalModules\FallUnder".
I enabled access for me but it's still not possible to disable the modules (Bannor - Chain of command, Fall Under, Mekara Order).

Click to expand...

well ... the error is quite clear ... you can't write in mods folder, so you just allowed access only on topmost folder of modules and inactive modules, or the folders are read-only

and what should I do now?

Nirek said:

One odd thing I did see, even though it appears to be working for me correctly, looking in the .config file in the rife directory, it appears it still has not written the correct mod path to that file, not sure why. It still shows this in that file.

Code:

    <userSettings>
        <RifELauncher.Properties.Settings>
            <setting name="PathToCiv" serializeAs="String">
                <value>NOTSET</value>
            </setting>
        </RifELauncher.Properties.Settings>
    </userSettings>
</configuration>

Click to expand...

Incidentally, I just figured something out with a project I'm working on that you might or might not already know: When you use Properties.Settings, the values in the .exe.config file do not change, even if you save them from the program. The saved user settings go somewhere in the Local Settings path for the user.

An interesting and stupid consequence of this is that if you release a new version, because it is keyed by build number, the user's saved settings may not transfer over to the new version. There's a way around this, using Settings.Properties.Default.Upgrade().

EugeneStyles said:

An interesting and stupid consequence of this is that if you release a new version, because it is keyed by build number, the user's saved settings may not transfer over to the new version. There's a way around this, using Settings.Properties.Default.Upgrade().

Click to expand...

hmm, thanks for info

btw, screen on new version of module manager: http://img193.imageshack.us/img193/4876/modulestate2.png

Tschuggi said:

.

Click to expand...

well, i don't know ... i'm not _that_ skilled in windows, that i could say how to deactivate protection of one folder in any version of win ... /: ...

I had the same error. Running the launcher as admin fixed it. Problem was it didn't have permission to modify stuff in program files.

... some basic conflict check implemented ...

thoughts?

That is a really great idea. Especially if someone has a ton of modules.

arcticnightwolf said:

... some basic conflict check implemented ...

thoughts?

Click to expand...

That is excellent.

Although, I would like to know, is this too much information for a typical user. Would someone who does not know what a UNIT_CORGAYLE is understand this message? If it's not too much trouble, I think a standard warning might be better, with either the option to see a more detailed message after that or an option in the launcher to show more detailed warning messages.

And I'm curious, how many lines of code?

Milaga said:

That is excellent.

Although, I would like to know, is this too much information for a typical user. Would someone who does not know what a UNIT_CORGAYLE is understand this message? If it's not too much trouble, I think a standard warning might be better, with either the option to see a more detailed message after that or an option in the launcher to show more detailed warning messages.

And I'm curious, how many lines of code?

Click to expand...

Probably best to actually pull the textkey related to the item in question (so it shows Corgayle rather than UNIT_CORGAYLE), but honestly... Everything is CLASS_TYPE so it's usually understandable.

I'd also prefer something with a heavy disclaimer. Just because two modules modify the same entry does not make them incompatible... They can be modifying completely different tags.

Honestly, one of the best things to do, to make it both clear to the player and keep it in the hands of the modders and keep it easy on the code side, is to use the version.txt (maybe renamed ModInfo.txt, as it would now have more usage) file. Have a list of compatible mods (mod name, AND version number, to be safe!), and when the compatibility check finds a possible result, check that list for both modules. If the opposite module is in both lists, don't display any warning. If in one list, say X module claims to be compatible, but Y does not. If neither says it, tell say that both modules modify the same entry and are possibly incompatible; Check with the authors.

ok, I added dependency on other modules, as some of #erebus regulars wished ...

version.txt containing only numbers (0-9) and maximally one period (".") is still supported, however I added another file "info.txt", that looks like this:

Have you thought about adding the capacity for the launcher to install modules?

All you really need to do is unpack a zip file. If you add a [files] section to the info.txt file you could even support upgrading, just by deleting any file not listed.

Bonus point if you add logic that allows both packing the files both with and without a directory.

odalrick said:

Have you thought about adding the capacity for the launcher to install modules?

All you really need to do is unpack a zip file. If you add a [files] section to the info.txt file you could even support upgrading, just by deleting any file not listed.

Bonus point if you add logic that allows both packing the files both with and without a directory.

Click to expand...

tbh i thought about directly downloading the modules from internet ... but idk ... next thing i'll try to do will be most likely profiles, because Jemon ((lemonjelly)) keeps requesting that ... (( both ini settings and modules ))

Downloading modules directly would be good but we'd need either a good referencing of links or our own "rife modules database".

I'm not sure GreyFox domain can hold such a database.

Opera said:

Downloading modules directly would be good but we'd need either a good referencing of links or our own "rife modules database".

I'm not sure GreyFox domain can hold such a database.

Click to expand...

i was thinking the first, but now i think that it could be quite risk virus/*ware-wise, so i guess that installing / downloading won't be implemented. period.

arcticnightwolf said:

i was thinking the first, but now i think that it could be quite risk virus/*ware-wise, so i guess that installing / downloading won't be implemented. period.

Click to expand...

I don't think there is any added risk from viruses. Basically because if you are going to get modules; which is presupposed from playing a mod in the first place; you have to get them from somewhere anyway.

As long as the install procedure is transparent; show the url where the mod is downloaded from and allow the user to change it; I see no (additional) problems.

Any mod can potentially contain malicious code. Whether you download it via a launcher or not.