Getting around launch as Admin for mergers

Do you have TortoiseSVN or Eclipse with a SVN plugin installed? The link you sent me to won't work, because I'm not a memeber of your admin team. You won't do much setting up of the SVN on their website. It's done on your PC, through File Explorer or Eclipse. What you want to do is set up a new folder that you're going to use to contain the Repo. I'd suggest having a main LoR directory, then having subdirectories inside of there that actually contains the LoR main mod, as well as branches for the parts of the mod that other Modders take care of, such as RevDCM, or if you want, you can put your artwork that you want to keep separate here. Once you have the folder structure you want set up, without any files, then do a checkout. Don't do 1 checkout in the main LoR directory. Instead you'll want to do a checkout for each part of the mod. So for the main LoR files, that you modify normally, you'd check out a directory inside the main LoR directory. It'll look something like this....

LoR Mod/LoR
LoR Mod/RevDCM
Lor Mod/Graphics

or something like this, with each of those being checkout as it's own SVN project.

Hope that helps.
 
Under Code it says this is LoR's SVN repository:
svn co https://civ4lor.svn.sourceforge.net/svnroot/civ4lor civ4lor

So in Tortoise what do I need to do to create:
  • Main LoR SVN (like BUG's, or RevDCM's)
  • Source SVN (again like BULL's and RevDCM's)
  • Art folders for individual fpk files used in LoR, LoR has 4 packed art files, I want to be unpacked for easy modding in an SVN (in case achilleszero returns, or someone else takes over the Art side of LoR -- I wish I had this set up before as I'd have the 0.9.8 art for LoR instead of it all being missing and all the work achilleszero has done on it being lost)
    • RevDCM Art (the art files that get packed into the RevDCM.fpk)
    • Core Art (the art files that get packed into the Wolfshanze.fpk)
    • Ethnic Art (the art files that get packed into the Achilleszero.fpk)
    • Expanded Art (the art files that get packed into the EnhancedGraphix.fpk)

Edit, Nevermind I think I got it. I might come back later if setting up seperate folders is hard, but I've uploaded the source at least now.
 
Read that post I linked (the 2nd) that explains the benefits of having three top-level folders: trunk, tags, and branches. First, it's standard SVN practice so others will expect them. Second, it allows you to tag your releases easily so you can always compare any two releases or have people grab a specific release.

Just create the three folders above where you now have "LoR Source" and move that one into "trunk". Then commit. Now you can do all your work in trunk's folders.

Or don't. It's not critical, but I do recommend it.
 
put the main LoR in the trunk folder.

Put the others in their own folders under branches.

use tag to mark a new release. I'd suggest keeping the FPK files in the main LoR trunk folder.
 
No, branches is not for "other" code, it's for when you want to create a new work area based off the original for either experimental work or for having two lines of development. 99% of modders won't use it, but it's good to have just in case.

Your layout should look like this:

Code:
trunk/
  main/
    Assets/
      Art/
      Res/
      Python/
      XML/
    LoR.ini
    readme.txt
  sdk/
    CvCity.cpp
    CvCity.h
    ...
    makefile
  art/
branches/
tags/
 
OK, so now that I have things set up, everything is in the Trunk folder. What is the purpose of the Tags and Branches folders? I read the linked post, it just says to do it, it does not say the reasoning behind it, which I'm not seeing (I have two empty main folders).
 
When it comes time to do a release you tag the revision so that you can always see a snapshot of the repository as it looked when you did the release. SVN does this by doing a "soft copy" which means it just stores the revision numbers of every file into a different folder (the tags folder). This looks like it's copying your entire repository, but it's actually just copying revision/file markers.

Take a peek into BUG's tags folder. You can organize this folder any way you like. For BUG I created a "releases" folder in case I wanted other tags, which I later did want for BUFFY. It pays to plan ahead. The releases folder has one tag for each release I've done (I took over the release process with v3.0).

Making a tag is very easy, especially with a tool like TortoiseSVN. Just right-click your trunk folder and say "Create Branch/Tag", name it and put it where you want.

Branches are for when you want to have two different (forked) development versions. Let's say that you're working on your mod and someone comes along and says, "I want to add feature such-and-such, and it may take two months to add so I want to commit occasionally to the repository." You know those commits won't be fully working, so you don't want them mixed in with the work you're doing in the trunk (main day-to-day line of development).

So you create a branch (again another soft copy) for that developer in the branches folder, say "experimental-feature-tango" for brevity. ;) Now they can work in that branch folder just like it's the trunk. Once they have completed it you would merge it back into the trunk--just like using WinMerge to merge two mods together--and delete the branch (or keep it, it really makes no difference).

Granted, these are probably not thing you are going to need to do today or tomorrow, but eventually you'll want to do them. If you have those (empty) folders now, there's no cost and a huge payoff when you're ready for them. For now, just pretend they don't exist and do everything in trunk.
 
OK, back to the task at hand. Writing the installer that seperates out the User Settings Folder and puts it in the My Documents path so that we don't have the Launch as admin failure occur for mods that use the BUG UI.

I'm trying to figure out what to do if the Civ4 ini file isn't found. Looking at BUG's install script for guidence, we have this:

Code:
Function findCivRootDir

	Push $0
	
	# locate the Civ4:BTS INI folder
	StrCpy $0 "$DOCUMENTS\My Games\Beyond the Sword"
	${If} ${FileExists} "$0\${CIV_INI_FILE}"
		StrCpy $CivRootDir $0
		StrCpy $CivIniFile "$0\${CIV_INI_FILE}"
		Goto done
	${EndIf}
	
	# can't find it
	StrCpy $CivRootDir ""
	StrCpy $CivIniFile ""

done:
	Pop $0

FunctionEnd

This is a more complex question, I wish I could answer myself, but I can't quite figure it out. What should the installer do if it can't find the civ4 ini file? Also what exactly is the script doing here:
Code:
	# can't find it
	StrCpy $CivRootDir ""
	StrCpy $CivIniFile ""
 
It clears those two variables (sets them to an empty string). A later step during installation detects this and asks the user to locate their My Games / BTS folder. I think, at least that's what I would do if I were writing it. :D
 
Thanks EF. I have decided against setting up another screen for the user for UserSettings, that seems unnecessarily complicated. If the autodetection fails for the Civ4 ini file, the user did something really strange, and I doubt BtS will be in the Program Files Directory anyway. So I decided to set it up so that if the installer can't find the Civ4 ini, it just puts the UserSettings in the Mod's folder itself. Simple solution.

@Davidallen:

Here is the script. I've set it up to work with RevolutionDCM, as it's a dev script and RevDCM is small and easy to work with. You will obviously need to tweak things so that they work with your computer and mod (there are two optional add ons in this scripts as is as an example, and all the read paths are set for my computer, obviously). If you make any adjustments or improvements, please let me know and upload your improved script. As of now this is totally functional.
 
Note that BUG will look in the My Games folder for the "BUG Mod" mod folder (taken from CvModName.modName) as well. If you cannot find the CivIV.ini, just create this folder hierarchy:

Code:
My Documents
    My Games
        <modName>
            UserSettings
 
That's perfect, changed script to set that path as the alternate if it cannot find the Civ4 ini file in the My Documents BtS path. Also while I have your attention, please merge in this code into BUG's SVN so that mods that set a leader as valid for multiple civs show that in the civilopedia (nothing changes in the display for leaders of 1 civ, it looks the same, it just creates a scrollable civilization pane if there are multiple civs a leader is valid for):
http://forums.civfanatics.com/attachment.php?attachmentid=232497&d=1256699540

@davidallen

Script updated with EF's solution for when the BtS ini is not found.
 
Actually I'm wondering if I could take this 1 step further. Is there a way to check the version# of BtS, to insure the user is updated to 3.19? If this is possible, how could this be done? Assuming it is, I'd like to set it up so that if the installer detects a prior BtS version to 3.19, it aborts, and they are taken to a webpage (either here or Firaxis's official site), where they can download the 3.19 patch. Not being patched to 3.19 is the number 1 cause of failures for LoR, and I'd like to just nip this in the bud on installation.
 
You can check for the registry key for 3.19

Code:
HKEY_LOCAL_MACHINE\SOFTWARE\Firaxis Games\Sid Meier's Civilization 4 - Beyond the Sword\3.19

using NSIS. This is something I should have added to BUG's installer. Good call. Of course, I'm sure each type of package (Gold, Complete, Steam, etc) all use different registry key locations. :goodjob:
 
I don't like that approach, because it means that if the registry detection fails, the user simply wol't be able to install the mod (this can happen for users that install on a different drive). The best way would be to check the BtS .exe itself. You think this is possible?
 
Actually thinking about this more, that should work. But I'm over my head here.

Here is a check I have that works (I'll need to add a similar check for each Registry check, Gold, Complete etc):
Code:
  Function findINSTDIR1

	Push $0
	
...

	#Quick BTS registry Check
	ReadRegStr $0 ${FIRAXIS_REG_ROOT} "${BTSREGKEY}" 'INSTALLDIR'
	${If} ${FileExists} $0
		StrCpy $INSTDIR1 $0
		StrCpy $0 "${LONG_HKLM}\${BTSREGKEY}\3.19"
		Goto RegFoundQuick
	${EndIf}
...

  RegFoundQuick:
	${If} ${FileExists} $0
		Goto done
	${EndIf}

...

  done:
	Pop $0

What I need is in the last bit, something like this (I have no idea how to right this):
Code:
  RegFoundQuick:
	${If} ${FileExists} $0
		Goto done
	;${Else}
		;Open a new box that says something like
		;"Your copy of BtS has not been properly patched to version 3.19, /n
		;click OK to be taken to the civfanatics website where you may download the 3.19 patch, /n
		;Otherwise select cancel if you do not wish to update your copy of BtS
		;Then have the OK open up the civfanatics webpage, and abort installation, cancel will just abort
	${EndIf}
 
I think you need to allow the user to install anyway in those cases where you don't find all registry key locations. You might be able to change the button labels in a Yes/No/Cancel dialog box to say Continue/Upgrade/Abort. The other option is Continue/Abort where Abort takes you to a final installer page that has a link to the download locations.
 
That's not the problem I'm having. If it gets through all the registry checks and finds nothing, the installer will just run like normal (the user will need to manually find the install directory). I figure if the user has installed their copy of BtS in a way that has ruined the registry check, they know enough about computers to patch BtS themselves.

What I can't figure out is how to get a different dialog box to pop up when the if check finds that the registry for BtS exists, but it's not version 3.19.

This is the current on init function:
Code:
  Function .onInit

    Call findINSTDIR1
	Call findCivRootDir
    StrCpy $INSTDIR "$INSTDIR1"

	;Check to see if the mod is already installed
    ReadRegStr $R0 ${FIRAXIS_REG_ROOT} \
    "Software\Microsoft\Windows\CurrentVersion\Uninstall\${MOD_LOC}" \
    "UninstallString"
    StrCmp $R0 "" done

    MessageBox MB_OKCANCEL|MB_ICONEXCLAMATION \
    "${NAME} is already installed. $\n$\nDo you wish to uninstall?" \
    IDOK uninst
    Abort

    ;Run the uninstaller if you find a Registry Key for the mod
    uninst:
    ClearErrors
    ExecWait '"$INSTDIR\Mods\${MOD_LOC}\Uninstall.exe" _?=$INSTDIR'
	Delete "$INSTDIR\Mods\${MOD_LOC}\Uninstall.exe"

    done:

  FunctionEnd
I have no idea how to get it to say, run that, unless BtS's registry is detected and it's not version 3.19, in which case, run something else (the something else being an entirely different function, where it forces an abort giving the user an option to get taken to civfanatics 3.19 patch download) ...
 
Back
Top Bottom