Not really and not the bit that determines what comes from the hut.
1) Placement of sea goody huts is currently by Python because letting the engine do it reduces the number on land.
2) What you get from popping a goody hut is done by the goody mechanism. The no bad goody tag on ships is ignored by the dll. Change to the units produced does not work on sea but does on land.
3) Conversion of the land barbarian units to ships is done by the python afterwards.
I've looked into this and it's working exactly as programmed. There's a few things I think we need to do to program this better.
Looking at the python, it's rather clever. But I do have a full understanding of it. However, I'm having a hard time following your exact complaint. I imagine it has to do with the conversion of your own units to sea units rather than land ones right? I can help with that I think. The flaw was in python and the attempt has been commented out.
The main thing I think we have an issue with here is that the results are not era specific.
This means we could go about things 2 ways (and I may be able to relieve us of the need for the python at all here.)
1) We create a new tag for units that establishes a hierarchy which works much like the conscription tag works. An integer that lets us build a map of which units to select from and use the era the goody is revealed as a modifier. Ex: a result states to use the Unit on Hierarchy 1 but then the era is Ancient so modifies the result by +1 to get 2. As eras go up we get more powerful results.
2) We simply add an era tag (and eventually a map tag for multimaps) to GoodyInfos and we build out new goody results by era.
Either way, a new tag for bNaval would allow us to easily create differing results for goody islands and normal land goodies and have that result take place in the code. That would be quite easy.
I'm partial to the second option because units are getting a little too much info loaded on them as it is and I have more to heap on so at some point I'll need to find all ways to offload info from units that I can. So adding one that can be addressed instead by adding to the goody infos seems silly.
Another upside of Option 2 is that it lets us address this quite simply and gradually whereas Option 1 would take some planning before fully implemented at once.
Option 2, however, does have the downside of requiring a lot of new XML goody entries to cover all situations. (BTW, some barbarian criminal unit spawns and friendly healer spawns might be interesting for goodies.)
I'd be happy to work Option 2 and the bNaval tag out in the code and it wouldn't require immediate response from XML. But if I go about it this way, can I trust I can hand the project off to some enterprising modder that would like to use simple xml to expand our Goody Hut results?
Who will rise to the challenge?
Note: Any addition to the goody results xml looks like it needs an addition to this list as well:
Code:
def onGoodyReceived(self, argsList):
if (AutologOpt.isLogTribalVillage()):
iPlayer, pPlot, pUnit, iGoodyType = argsList
if iPlayer == CyGame().getActivePlayer():
GoodyTypeMap = {
-1: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_NOTHING"),
0: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_LITTLEGOLD"),
1: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_LOTSOFGOLD"),
2: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_MAP"),
3: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_SETTLER"),
4: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_TRIBE"),
5: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_WARRIOR"),
6: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_STONESPEARMAN"),
7: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_SCOUT"),
8: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_WORKER"),
9: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_GATHERER"),
10: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_XP"),
11: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_HEALING"),
12: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_TECH"),
13: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_WEAKHOSTILES"),
14: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_STRONGHOSTILES"),
15: BugUtil.getPlainText("TXT_KEY_AUTOLOG_VILLAGE_RESULT_STONETHROWER")
}
message = BugUtil.getText("TXT_KEY_AUTOLOG_VILLAGE_RESULT", (GoodyTypeMap[iGoodyType], ))
Logger.writeLog(message, vColor="Brown")
and obviously would then also need some TXT_KEY work to support it as well. But seriously, these would be easy and you could get creative.
Adding the <EraType> and <bNaval> tags should be easy as pie. Once done, however, we'll want to yank out GoodyIslands.py completely and rely instead on the <bNaval> to isolate the naval results and define naval results individually in the Goody XML. <bNaval> should only apply to unit prompted results as well so that we don't have to make a <bNaval> version of a free tech result for example.