Getting around launch as Admin for mergers

[davidlallen]

!!!

That is a million times simpler.

 

[phungus420]

Unfortunately I can't figure out how to make it work.

For starters getting NSIS to read a file is not simple to understand:

http://nsis.sourceforge.net/Read_from_text_file_line_number

Secondly I tried using that, and assuming I wrote it correctly, it still doesn't return correctly, because it's an XML file and not a txt file.

Here is the code I'm using in case I made any errors:

...
  !define GLOBAL_DEFINES "Assets\XML\GlobalDefines.xml"
  !define GD_VERSION_LINE "		<DefineName>CIV4_VERSION</DefineName>"
  !define GD_VERSION_NUMBER "		<iDefineIntVal>319</iDefineIntVal>"
...
The function in the above link "ReadFileLine"
...
 
  Function findINSTDIR1

	Push $0
	#Search for a valid BtS registry key, and get the Install Folder
	
	#look for standard Civ4:BTS
	ReadRegStr $0 ${MACHINE_REG_ROOT} "${FIRAXIS_REG_KEY}\${BTSREG_STANDARD}" 'INSTALLDIR'
	${If} ${FileExists} $0
		StrCpy $INSTDIR1 $0
		${If} ${FileExists} "$INSTDIR1\${GLOBAL_DEFINES}"
			Push 9
			Push "$INSTDIR1\${GLOBAL_DEFINES}"
			Call ReadFileLine
			Pop $0
			${If} $0 == "${GD_VERSION_LINE}"
				Push 10
				Push "$INSTDIR1\${GLOBAL_DEFINES}"
				Call ReadFileLine
				Pop $0
				${If} $0 == ${GD_VERSION_NUMBER}
					StrCpy $CurrentVersion "true"
					Goto done
				${Else}
					StrCpy $CurrentVersion == "false"
					Goto done
				${EndIf}
			${Else}
				StrCpy $CurrentVersion "${UNKNOWN}"
				Goto done
			${EndIf}
		${Else}
			StrCpy $CurrentVersion "${UNKNOWN}"
			Goto done
		${EndIf}
	${EndIf}

On my machine it's returning ${UNKNOWN} instead of true. It should be returning true if it was finding the global defines file and reading it (I've switched things around as well, it's definatly the reading part that's tripping it up, it finds the file fine). Anyone have any ideas about how to get NSIS to read an XML file?

 

[phungus420]

Well I found this, but it's obviously for people with degrees in programming. I can't figure out how I'm supposed to use it:

http://nsis.sourceforge.net/XML_plug-in


Here is the readme, I looked all through it, and the functions use fancy words like "handle" and "node". So yeah, it doesn't tell me how to use it to just read an XML file, find a tag, and ask for the value inside the tag. Would be nice if someone who understands this stuff could take a look at the readme and tell me how I'm supposed to code that. Or even if this plug in can do what I need, which I think it does, I just have no idea how to code for it.

 

[phungus420]

I have made a post here for help on this:

http://forums.winamp.com/showthread.php?s=&threadid=227162

It's only 2 pages long, and my post is at the end. Someone responded, but they did not explain what i need to do. They show this as an example of what I should do:

nsisXML::select /NOUNLOAD '/Define/iDefineIntVal'
${If} $1 != "0"
nsisXML::getText /NOUNLOAD
;the result should be in $3
${If} $3 == "319"
;do what you want
${Endif}
${Endif}


But I don't understand how to use this code. How am I declaring what XML file to read? And I see I'm asking it if it gets a value of 319, which is correct, but where is this code telling it what tag to look in?

 

[EmperorFool]

But I don't understand how to use this code. How am I declaring what XML file to read? And I see I'm asking it if it gets a value of 319, which is correct, but where is this code telling it what tag to look in?

I don't have time to look at the post right now (later), but the tag is in that first line: '/Define/iDefineIntVal'. It's what's called an XPath to the tag, like a folder path. You should need to put '/GlobalDefines' at the start (or whatever the root tag is in the XML file).

Isn't there a simple "if $x is in $file" test so you can look for this?

<iDefineIntVal>319</iDefineIntVal>​

 

[phungus420]

Isn't there a simple "if $x is in $file" test so you can look for this?

<iDefineIntVal>319</iDefineIntVal>​

Took some searching, and you are correct. Much simpler this way. Also I'm not sure if you need the XML plug in or not for it to work, since I'm having it read an XML document, and the script I pulled and put in my Include folder says it's to find an instance in a text document. But it works for me. Also this is so much simpler then all those damned registry checks.


@davidlallen

Here is the Script. Put the "FileSearch.nsi" in your NSIS include folder obviously. If it doesn't work, install the XML plug in above, but I have a feeling you wol't need that, and this function can read XML documents fine.

 

[davidlallen]

Great! To make sure I understand, this is the full install script, which checks the registry to find the BTS install location. But the new feature is that instead of all the various troublesome 3.19 registry checks, it looks in this BTS XML file to find the 319 string. If either of these checks fails, then it refuses to install. After installing, it writes your key into the registry. Is that right?

Was there a problem with finding the BTS install directory for Steam installations?

Do you plan to make another test installer to see if arkham or deliverator will test it on their Steam machines?

Does the current *patch* install script check for 3.19 in some way, or does it only check for modname/modname.ini?

What shall we do about situations where the user installed the full release with a zip (because they had steam and could not use the previous full release installer) and then want to use the patch installer? It will fail, unless I am mistaken.

I will repeat my suggestion that you put both of the scripts into the download database; they are a big advance over the previous versions that were there from last year.

 

[phungus420]

The logic for the installer is as follows:

Check the registry for the BtS install directory (three separate checks here for a standard, gold and complete install) ---Now if none of these succeed, allow the user to install, but warn them that no registry was found, so things might be messed up. Also let them know that the installer will only install for the path they set if that path has the BtS .exe in it (makes sure they are installing it in the correct path). The reason why I did this, allow the installer to install even if no Civ4 registry is found, is because some users have put their copy of BtS on other drives, and/or moved things around, and screwed up the registry information. They can still install, but it must be in the BtS directory due to the BtS .exe check.

If the registry directs the installer to a BtS install directory look for a global defines file in the install directory\Assets\XML (keep in mind the install directory is the BtS directory so that the BtS executable check can be performed, the installer later puts the mod in the mods folder of this directory, and creates one if non exists --of course a user is going to have a mods directory unless they deleted it, but if they did for some reason the installer will create one). If the Global Defines file can't be found, it will still let them install, but it will warn them again that something is not right, and prod them to make sure they are updated to 3.19, and let them know that the install path has to have a BtS executable in it, or else the installer will refuse to continue with installation (the OK button is greyed out in the "select your install directory page").

Now assuming a Global Defines file is found it checks it for the presence of this "<iDefineIntVal>319</iDefineIntVal>" and if found tells the user everything is hunky dory, and they just need to click "next" to continue. If this isnt' present in their Global Defines file then they are not updated to 3.19, and the installer will abort and give them a warning letting them know why, and directing them to how to install the patch, and telling them to run the installer again after being patched.

Edit: Also assuming the installer doesn't abort due to the 3.19 check, it reads the registry for a previous installation of the mod, and if it finds the mod's registry, forces an uninstall (The uninstall is forced by running the Uninstaller in the mod's directory, which the previous installer created when it installed the mod; the user can abort the mod uninstall, but doing so causes the installer to abort). This is done to make sure no old files from a previous version are left over to cause conflicts. A full fresh install of the mod, forces a completely fresh install this way.


Now for the patching script I uploaded for you before. It looks for the mod's registry, uses that for the install path, and then double checks by making sure the mod's ini file is in there. If any of these checks fail, the installer will abort. How I'd suggest to deal with the users with zipped folders is to release 1.7.1 as a full release again, since your main installer is broken anyway (which is what this whole thing is about), and use the patch script for the next update, which will then require 1.7.1 to be installed.

Interestingly enough we could start getting fancy, and having the installer sign version keys, and then the patch script could make sure the version is correct as well, not just make sure the mod is installed. But I have no need for such a function ATM, and don't feel like adding that yet. I may very well do so if or when LoR 1.0 is released.

 

[davidlallen]

The logic for the installer is as follows: ...

Thanks. FYI, in all the times I have run your installer with or without the mod installed, it always says it will perform the uninstall, but never deletes anything. So I have directed users to delete or rename their previous Mods/Dune Wars directory before installing a full release. Does it work for you?

Now for the patching script I uploaded for you before. It looks for the mod's registry, uses that for the install path, and then double checks by making sure the mod's ini file is in there. If any of these checks fail, the installer will abort. How I'd suggest to deal with the users with zipped folders is to release 1.7.1 as a full release again, since your main installer is broken anyway (which is what this whole thing is about), and use the patch script for the next update, which will then require 1.7.1 to be installed.

It may, or may not reduce confusion to call my next release 1.8 instead of trying to explain that *in general* a two dot release is a patch, but both 1.6.1 and 1.7.1 were full releases instead. I will think about that.

Thanks a lot for your help!

 

[phungus420]

I believe you were using NikNak's script before. I know the uninstall function works, and have seen it work on other computers, as well as users have reported that it removes stuff when run.

 

[EmperorFool]

XML documents are text documents with an organized way of placing the text inside them. You shouldn't need any XML library since it won't be parsing the XML--only reading a boring ol' text file.

 

[mathaplo]

Dune Wars is not working with my steam installation. I'll be willing to do some tests if still needed.

 

[davidlallen]

Please try Dune Wars 1.7 for Steam.

 

[phungus420]

Due to a thread in the Tech help forums, I'm curious about how BUG will handle it if the user installed BtS on an external drive. The install directory code for the UserSettings folder is handled in this function:

;Look for valid BtS folder in My Documents Path
Function findCivRootDir
	Call findINSTDIR1

	Push $0
	# locate the Civ4:BTS INI folder
	StrCpy $0 "$DOCUMENTS\My Games\${BTS}"
	${If} ${FileExists} "$0\${CIV_INI_FILE}"
		StrCpy $CivRootDir $0
	${Else}
		;Civ4 config not found, use My Games folder instead, as BUG searches here, if this folder exists
		StrCpy $0 "$DOCUMENTS\My Games"
		${If} ${FileExists} $0
			StrCpy $CivRootDir $0
		;Neither a valid BtS or My Games folder found in the users My Documents directory, UserSettings folder will be installed into the main mod's folder
		${Else}
			StrCpy $0 "$INSTDIR1\Mods"
			StrCpy $CivRootDir $0
		${EndIf}
	${EndIf}

	Pop $0
FunctionEnd

So how will the mod handle loading the UserSettings if the user has BtS in the E drive, and the mod is installed to E:\...\BtS\Mods\ModName? Will BUG be loading them fine, or will being on a different drive mess things up?

 

[Fimbulvetr]

I installed Civ4&Warloards&BTS to T:\Civ4\, my BTS mod folder therefore is T:\CIV4\Civilization 4\Beyond the Sword\Mods\ and that's where I install all mods to, including my merged BUG & co. Everything's running perfectly fine; even my merge's files copied over the BAT 2.1 folder for that matter

Then again, no mod has to load any settings out of a folder that is not his very own, so not having any issues is to be expected.

 

[phungus420]

But wouldn't NSIS end up returning C:\My Documents from the $DOCUMENTS call? To be honest I'm not sure how things work when you're using multiple/external hard drives. Fuyu would you mind running the RevDCM installer in the RevolutionDCM modpacks thread and see where it installs the maps and UserSettings (RevDCM's installer is 12MB)? The 2.7 installer is located in the 2nd to last post in the thread right now, I'm curious to know how the installer handles your external drive.

 

[Fimbulvetr]

It's very internal iirc, just a different letter

 

[EmperorFool]

$DOCUMENTS is going to point to wherever the user's Windows installation has the user's My Documents folder. Whether that's C:\Documents and Settings\<user>\My Documents or E:\Users\<user>\Documents doesn't matter. If there is no My Games folder there, it will go to wherever they installed BTS.

I'm just not understanding the problem here. Can you give a concrete example of what is failing?

 

[Fimbulvetr]

Spoiler :

.. as expected

 

[phungus420]

@EF not sure if there is a problem. Just wondering if the code I have will properly handle external and multiple hard drives.

@Fuyu
Where does it install the UserSettings folder too? The installer wol't tell you, this happens behind the scenes. Look at the code I posted above to see the 3 places where it should install it.