incremental patch discussion

I would like two volunteers to please download the 1.7 installer and make sure it works for you

Is this different to the one that I already tested (that seems to work fine).
 
How is this issue actually fixed then? By the installer?

If I edit the Dune Theme rather than create a new one does that get around the problem?

I do not understand the details, maybe keldath can help explain. The solution is in the file structure. In the 1.6.1 installer, the theme is in assets/modules/interface. In the 1.6.4 installer, we basically added a top level directory resources, with the theme under it somewhere. The 1.6.4 release note says to delete the entire assets/modules/interface directory. You can do this equally well on an XP machine to test. Once you have done this, then the theme files are picked up automatically somehow from the top level directory resources.

So any change you make inside assets/modules/interface will not help. Can you identify a subdirectory of the top level directory resources, with the theme files inside? Perhaps by replacing those files you can implement Brown Theme in a vista friendly way.
 
We are making good progress. Deliverator has redone all the wonders. Keldath has ported the insides ot he mod to use more modern versions of the modcomps for RevDCM, BBAI, BUG and BULL. I have added a lot of unit diversity changes. All of this will be coming out in 1.7, hopefully today. (Waiting for some buttons from deliverator).

Do you have any interest in going back to the action button project?


I have interest but have not time at all, as i said i am busy with some freelance job so cant spend my time for mod before i finish this project.
Was just telling i am consumed by RL stuff but not lost.
I hope i will finish my planned updates (actions + new promotions) closer/on next weekend.
 
I can also confirm the 1.7 installer works fine.

I have made a 1.7.0.1 patch to do the following:
1. Update the new theme to the correct 1.7 Vista compatible folder structure.
2. Change the effect of the Fai Water Tribute wonder to be +5% water in all cities. As Ahriman pointed out the 1.7 effect is pretty useless.

Download 1.7.0.1 Here
 
Bug: Ixian weapon tech is tradeable.

Issue: the Fremen capture chance on vehicles seems very high. Is it 100%???
It should be a small chance, maybe 15-20%.

Bug: when razing a city I get this:

partisans.jpg


Bug: Laza tigers aren't actually hidden nationality. Are they supposed to be? They appear hidden nationality (barbarian flag) but can move through other units and don't attack unless at war.
 
The EVENTTRIGGER_PARTISAN is from Revolutions. I have PM'd one of the developers to find out why; no answer yet, and I cannot find this string anywhere in the code. I'd like to find and fix that before I release. I'll look some more.

Ixian Weaponry is tradeable, just like any other UR. Why did you expect otherwise?

The Fremen vehicle capture chance is the same as the Harkonnen slavery capture chance, which is 50%.

I am undecided about putting the building change and new theme into 1.7. These seem like low risk changes.
 
Ixian Weaponry is tradeable, just like any other UR. Why did you expect otherwise?

Ixian weapons *technology* (a dummy placeholder you have set up) is tradeable.

ixweapon.jpg


The Fremen vehicle capture chance is the same as the Harkonnen slavery capture chance, which is 50%.

This is too high. A vehicle is way more valuable than a slave, and the intention is for this to be a minor flavor mechanic, not an anti-Ix-pwnage mechanic. I recommend 20%.

Bug: Laza tigers aren't actually hidden nationality. Are they supposed to be? They appear hidden nationality (barbarian flag) but can move through other units and don't attack unless at war.
 
EVENTTRIGGER_PARTISAN is, not surprisingly, an event trigger.

This is part of normal BtS. The BtS CvEventManager (in CvEventManager.py) triggers it in onCityRazed if a non-barbarian city is razed that has a population of more than 1. Presumably, the event manager is inheriting the default CvEventManager class and either the onCityRazed is not replaced or the replacement is doing a "self.parent.onCityRazed(self, argsList)".

When the partisan event trigger is triggered, the player gets a choice of 2 events. The first gives some units (it is something like the number of cultural expansions the city has had) by the razed city's location, the second gives a smaller number of units in the player's capital.

For it to work, you need the event trigger (EVENTTRIGGER_PARTISAN) in your CIV4EventTriggerInfos.xml, the two related events (EVENT_PARTISANS_1 and EVENT_PARTISANS_2) in your CIV4EventInfos.xml, and the associated code (getNumPartisanUnits, getHelpPartisans1, canApplyPartisans1, applyPartisans1, getHelpPartisans2, canApplyPartisans2, and applyPartisans2) in your CvRandomEventInterface.py.

To make it stop trying to trigger it, stop running the default onCityRazed. (What the best way to do this when using the BugEventManager is, I'm not sure. It may be as simple as adding that function to the class in a way that does nothing so as to override the default to make it stop.)
 
To make it stop trying to trigger it, stop running the default onCityRazed. (What the best way to do this when using the BugEventManager is, I'm not sure. It may be as simple as adding that function to the class in a way that does nothing so as to override the default to make it stop.)

Thanks! I found it in parallel. The problem shows up due to an improvement in BUG. Previously, I had overridden the CvGameUtils.py file with my own file. I had removed the partisan stuff and forgotten about it. Now with BUG, I can add my own gameutils calls, so I no longer need to override the file, so I deleted my copy. Now the unmodified BTS file is there. That is why I couldn't find the text in the DW directory; it isn't there.

The point of this BUG feature is to avoid the need of overriding this file. But, I am pretty sure there is no way to *prevent* the defaults from running. So I will have to override this file anyway.

ahriman said:
Ixian weapons *technology* (a dummy placeholder you have set up) is tradeable ... Laza tigers aren't actually hidden nationality. Are they supposed to be?

I'll make the tech untradeable. I haven't changed Laza Tigers in this release, so they work the same as before. But, I don't usually use HN units. Does the tiger work differently than other HN units? I'm not sure why that would be.
 
Your standard hidden nationality unit has bAlwaysHostile set to 1. This makes it able to attack any unit you don't own whether or not you are at war with the owner, and lets any other players units attack it as well.
 
@davidlallen

Here is the patch script you wanted. It uses the main mod's registry (which the main mod installer creates) in order to define the patch install path, further it checks for the presense of the Mod's ini file in the install path. If it does not find these, it aborts.
 
@davidlallen

Here is the patch script you wanted. It uses the main mod's registry (which the main mod installer creates) in order to define the patch install path, further it checks for the presense of the Mod's ini file in the install path. If it does not find these, it aborts.

Excellent! This will definitely reduce the number of installation issues for patches.

I have issued a couple of workarounds for the problem of checking the 3.19 registry key; one player confirms that he can use 7zip to get the data out anyway, and I have also uploaded a zip file instead of an installer. Are you getting any information about what test may be wrong? I guess you will be using the same installer in LoR, so we can both benefit from an improvement there.
 
I have recieved no error reports from LoR's installer. The logic is different, I emailed you that script yesterday. Here is the difference in Logic between LoR's main install script and, and Dune Wars; the cause of the returned false negative should be apparent apon examining the code:

LoR's
Code:
  Function findINSTDIR1

	Push $0
	#Search for a valid BtS registry key, and get the Install Folder
	
	#look for standard Civ4:BTS
	ReadRegStr $0 ${FIRAXIS_REG_ROOT} "${FIRAXIS_REG_KEY}\${BTSREG_STANDARD}" 'INSTALLDIR'
	${If} ${FileExists} $0
		StrCpy $INSTDIR1 $0
		!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${BTSREG_STANDARD}" "${BTS_VERSION}"
		Pop $R0
		StrCpy $CurrentVersion $R0
		Goto done
	${EndIf}

	
	# Civ4 Complete
	ReadRegStr $0 ${FIRAXIS_REG_ROOT} "${FIRAXIS_REG_KEY}\${COMPLETE_REG}" 'INSTALLDIR'
	${If} ${FileExists} $0
		StrCpy $0 "$0\${BTS}"
		${If} ${FileExists} $0
			StrCpy $INSTDIR1 $0
			!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}" "${BTSREG_STANDARD}"
			Pop $R0
			${If} $R0 == "1"
				!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${BTSREG_STANDARD}" "${BTS_VERSION}"
				Pop $R0
				StrCpy $CurrentVersion $R0
				Goto done
			${Else}
				StrCpy $CurrentVersion "Unknown"
				Goto done
			${EndIf}
		${EndIf}
	${EndIf}
	
	# Civ4 Gold
	ReadRegStr $0 ${FIRAXIS_REG_ROOT} "${FIRAXIS_REG_KEY}\${GOLD_REG}" 'INSTALLDIR'
	${If} ${FileExists} $0
		StrCpy $0 "$0\${BTS}"
		${If} ${FileExists} $0
			StrCpy $INSTDIR1 $0
			!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}" "${BTSREG_STANDARD}"
			Pop $R0
			${If} $R0 == "1"
				!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${BTSREG_STANDARD}" "${BTS_VERSION}"
				Pop $R0
				StrCpy $CurrentVersion $R0
				Goto done
			${Else}
				StrCpy $CurrentVersion "Unknown"
				Goto done
			${EndIf}
		${EndIf}
	${EndIf}
	
  ;No BtS registry found, give CurrentVersion a non 1,0 value
  StrCpy $CurrentVersion "null"
  Goto done

  done:
	Pop $0

  FunctionEnd
Note only a CurrentVersion value of "0" trips the BtS registry without 3.19 key, the other values of "Unknown" and "Null" cause different messages to be presented to the user (basically saying "something is different here, please make sure you have updated BtS before continuing), but the user may continue with installation. A value of "1" is considered normal.

This is the logic in Dune Wars current installer:
Code:
  Function findINSTDIR1

	Push $0
	#Search for a valid BtS registry key, and get the Install Folder
	
	#look for standard Civ4:BTS
	ReadRegStr $0 ${FIRAXIS_REG_ROOT} "${FIRAXIS_REG_KEY}\${BTSREG_STANDARD}" 'INSTALLDIR'
	${If} ${FileExists} $0
		StrCpy $INSTDIR1 $0
		!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${BTSREG_STANDARD}" "3.19"
		Pop $R0
		StrCpy $CurrentVersion $R0
		Goto done
	${EndIf}

	
	# Civ4 Complete
	ReadRegStr $0 ${FIRAXIS_REG_ROOT} "${FIRAXIS_REG_KEY}\${COMPLETE_REG}" 'INSTALLDIR'
	${If} ${FileExists} $0
		StrCpy $0 "$0\${BTS}"
		${If} ${FileExists} $0
			StrCpy $INSTDIR1 $0
			!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${BTSREG_STANDARD}" "3.19"
			Pop $R0
			StrCpy $CurrentVersion $R0
			${If} $CurrentVersion == "1"
				Goto done
			${EndIf}
			!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${COMPLETE_REG}" "3.19"
			Pop $R0
			StrCpy $CurrentVersion $R0
			${If} $CurrentVersion == "1"
				Goto done
			${EndIf}
			!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${COMPLETE_REG}" "${BTS}\3.19"
			Pop $R0
			StrCpy $CurrentVersion $R0
			${If} $CurrentVersion == "1"
				Goto done
			${EndIf}
			!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${COMPLETE_REG}\${BTS}" "3.19"
			Pop $R0
			StrCpy $CurrentVersion $R0
			${If} $CurrentVersion == "1"
				Goto done
			${EndIf}
			Goto done
		${EndIf}
	${EndIf}
	
	# Civ4 Gold
	ReadRegStr $0 ${FIRAXIS_REG_ROOT} "${FIRAXIS_REG_KEY}\${GOLD_REG}" 'INSTALLDIR'
	${If} ${FileExists} $0
		StrCpy $0 "$0\${BTS}"
		${If} ${FileExists} $0
			StrCpy $INSTDIR1 $0
			!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${BTSREG_STANDARD}" "3.19"
			Pop $R0
			StrCpy $CurrentVersion $R0
			${If} $CurrentVersion == "1"
				Goto done
			${EndIf}
			!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${GOLD_REG}" "3.19"
			Pop $R0
			StrCpy $CurrentVersion $R0
			${If} $CurrentVersion == "1"
				Goto done
			${EndIf}
			!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${GOLD_REG}" "${BTS}\3.19"
			Pop $R0
			StrCpy $CurrentVersion $R0
			${If} $CurrentVersion == "1"
				Goto done
			${EndIf}
			!insertmacro IfKeyExists "${LONG_HKLM}" "${FIRAXIS_REG_KEY}\${GOLD_REG}\${BTS}" "3.19"
			Pop $R0
			StrCpy $CurrentVersion $R0
			${If} $CurrentVersion == "1"
				Goto done
			${EndIf}
			Goto done
		${EndIf}
	${EndIf}
	
  ;No BtS registry found, give CurrentVersion a non 1,0 value
  StrCpy $CurrentVersion "Unknown"
  Goto done

  done:
	Pop $0

  FunctionEnd
Again only a "0" trips the code, but in the above logic a 0 is far more likely to be returned.
 
Thanks! I highly recommend you post a new, final version of the main installer and the patch installer to the download database. Digging through your SVN or a recent 12 MB release tarball to get a few hundred lines of script is confusing to me.
 
Well, I've emailed you the current script LoR is using. So you should have it. And the patch script is in that attachment above. These scripts only really work for RevDCM based mods, and they are also pretty advanced; to use them I think you'd need rudimentary programming knowledge. They aren't meant to be replacements or updates to the install scripts in the install scripts thread, so I wol't be officially releasing them. Besides if people want them, they can grab them easily off the LoR SVN.
 
to use them I think you'd need rudimentary programming knowledge. They aren't meant to be replacements or updates to the install scripts in the install scripts thread.

Of course it is your decision. But you have advanced the state of the art with the patch and 3.19 checking. It seems like an update to what is in the download database would enable others to make use of these advances. I did edit the scripts, but it did not take what I would call "programming" knowledge, no more than editing xml does. Even so, python and sdk modcomps get posted all the time which *do* require programming knowledge to modify successfully.
 
Back
Top Bottom