V37

Status
Not open for further replies.
After v36 Release:
-Continue to make Crime adjustments to the Individual crimes.
-Start more in depth review of all Properties that activate crime, like Tourism. 1 adjustment has already been made there.
-Review all Crime giving and crime reducing buildings.
-Start review of Pests and their individual effects thru :yuck:, :mad:, and other effects like Commerce and Gold.
-Diseases, would like to do more here, but will most likely have to wait for DH's Plague Mod.
-Review Pollution both water and air
-Continue Review of Tourism

Most likely other things related to crime will show up as these goals are approached.

JosEPh
 
Is anyone currently planning to work on the naval review (that's as neutral a question as I can make it...:mischief:)?
 
If you're keen and fully aware of what the plans are in the naval review, and you look deeply into the Law/Healer/Crime review, you'll find that many steps are being taken to setup the naval review for full implementation as well.

Either one can come first but a void of early crime control and smooth transition stages for both law enforcement and disease control are lacking so severely that it becomes the most glaring balance error for the mod at the moment (imo). For that reason, functions that will be useful for the naval review are being included while this property control sector gets the center stage for this version.

Naval will probably have to wait yet longer for finalization as military land units take the next step but there again it's preparing for numerous features planned in the naval review as well. The AI must be made more intelligent on land or the naval game doesn't matter much anyhow.

Then I imagine, Naval will have its full day in the sun and all the planning will come to fruition there.
 
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.
 
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.

Era would be a decent first step, but it doesn't really cover this. I'm not sure if other eras are the same, but Ancient Era for example has at least three phases where unit tech is concerned ie. pre-Copper Working, Copper to Bronze, and post-Bronze. And there is the further complication of units being dependent on resources.

I wonder if you could use the logic that is already there for drafting units, as it seems to know what the basic unit is for the current point in the tech tree.

Then again, since goody huts and islands might be expected to have rather primitive tech, maybe it's best as is, ie that you have to get the unit home before "modernizing" it.
 
Era would be a decent first step, but it doesn't really cover this. I'm not sure if other eras are the same, but Ancient Era for example has at least three phases where unit tech is concerned ie. pre-Copper Working, Copper to Bronze, and post-Bronze. And there is the further complication of units being dependent on resources.

I wonder if you could use the logic that is already there for drafting units, as it seems to know what the basic unit is for the current point in the tech tree.

Then again, since goody huts and islands might be expected to have rather primitive tech, maybe it's best as is, ie that you have to get the unit home before "modernizing" it.
Thanks for the feedback. I'd been thinking on some similar things. Goody huts have always given the rare opportunity to get some units that are a little more advanced than you are and the spectrum within an era that you speak of can be fully covered by differing results.

The logic for drafting units is what I was talking about with iConscript on units, however, I believe that's been allowed to become a bit of a mess and would take some further cleaning up if it were to be utilized here.

Goody Huts and Islands aren't all we're looking at here. LATE game goody huts can be assumed to be offworld on unexplored planets like the moon perhaps.

I'm also wanting to enable us to potentially mod goodies so that they don't all come in at once but rather get seeded every so often where they can emerge. Thus they may be something you could find throughout the majority of ages. Underwater goody huts may exist for example.

This is scratching the surface, therefore, of plans to come. To pull some of this off though I must mention that it may well be a little imbalancing to have free techs available as results for all eras.


Anyhow, I'm moving through projects quickly today... I've already got these two suggested new tags for goodies programmed and compiling now.


EDIT: Note that when Goodies spawn a unit for or against the player, it doesn't care at all about prerequisites so that cuts down a lot of unnecessary processing.
 
Publicola has posted in the ideas/discussion thread about how there are many resources - including cultures - that are currently empty. Can we get a project going to fix this? I can help with research and XML, but that still leaves swathes of the task that I personally don't fancy tackling, especially alone.
 
Publicola has posted in the ideas/discussion thread about how there are many resources - including cultures - that are currently empty. Can we get a project going to fix this? I can help with research and XML, but that still leaves swathes of the task that I personally don't fancy tackling, especially alone.

If you have time then please create similar google data sheet for resources:
https://docs.google.com/spreadsheets/d/1j0DAgEwTFG1MbWnPNS_o7BbxjQe0Monz3j0ioGkbog0/edit#gid=0
 
Added an executive summary to the OP showing stuff we are planning to do and have on the SVN for testing. I don't have it all but I do want to keep it at the executive summary level rather than the actual detail.
 
8923
  • Introduces the Ambush command.

Now units that are overlapping enemy units they can see and attack can initiate an ambush and attack them from the same plot.

There is some question in my mind as to whether this 'command' should be converted to a 'mission'. But it works nicely as it is. One quirk that making it a mission may solve, aside from perhaps working better for the AI, would be that the player CAN have multiple units selected when taking this action but it will only have the first unit in the selected group attack. That's probably not exactly the BEST way to go about this - I'm thinking at least the best attacker in the selected group should be the first to attack. But I didn't want them ALL to attack in sequence since that would potentially lead to players inadvertently making an unwise attack. It'll give you the odds on the confirmation button though and since large stacks aren't likely to initiate this kind of attack since it generally requires stealthy units to pull it off, this may not be a very prominent 'problem'.

Some feedback by any with programming insight as to whether I should take the steps to convert this to a Mission would be appreciated. I kinda appreciate the simplistic approach making it a command was able to take.

Notes on what's next:
  • There's some bugs to address that I may now be able to work on.

  • Add a combat modifier, Stealth Combat, that applies for units attacking other units on the same tile and attacking units that don't see them.

  • Add a new form of 'first strike', dubbed 'Stealth Strikes' that act just like first strikes except that they only help the unit that is attacking other units on the same tile or units that don't see them. (These modifiers and stealth strikes will also be able to assist LE units making arrests, for example.)

  • Once I figure out if this is fine as a command or needs to be converted to a mission, I'll introduce an Assassinate option for some specialized criminal types to be able to launch an attack on the same stack even if they are in a city and have blend into city (currently the ambush doesn't allow this.) Obviously, the unit should first target the unit types it would normally target first if a normal attack is being made, keeping the option from being completely imbalanced in that some units are already setup to be good 'rear guard' defenders that would come up before the most vulnerable of the specially targeted unit types.

  • At this point I think I would be able to start working on implementing the unit review.
 
It is the main one in Python because most of the mods added don't apply to barbarians or their units. Luckily there is also an isAnimal() test so we may be able to just add that in as an or condition on the isBarbarian() test in most cases. I just remembered it as I was looking at some code.
 
Luckily there is also an isAnimal() test I just remembered it as I was looking at some code.

Could this be used with another tag, so animals can spawn or enter a Civ's territory.

The other tag being:

Animal_CanNotAttackCity()

Or something similar.

On smaller maps animals not being able to enter a civ's cultural area - is a huge downside.

For players on Huge or Gigantic or above maps - no problem.
 
Status
Not open for further replies.
Top Bottom