Personality Archtypes

[RidetheSpiral23]

Well okay yeah either option should work fine in my opinion concerning the averaging or not discussion. Looking at the leader head files I don't personally see the need for hat much diversity seeing as there currently isn't that much diversity in them now. Anyways either way is good.

Concerning the traits, yeah I can see the whole ying yang thing and I get it. I just think it would be best if all the traits were just pure traits. You pick a positive trait and a negative trait every time. I guess that really doesn't matter to much for the archetypes though so I'll focus on this. I'm going to continue working on finalizing the archetype types for each subcategory for now. Then a decision can be made on averaging or not and that can finished off. It is very nice that this wouldn't mess with the current structure and that the archetypes can be slowly mixed it with the normal leader head setup correct?

 

[Thunderbrd]

It is very nice that this wouldn't mess with the current structure and that the archetypes can be slowly mixed it with the normal leader head setup correct?

Yep That way it doesn't take a huge overnight rework to get it put in place And doesn't mess with the plans of others.

 

[ls612]

Yep That way it doesn't take a huge overnight rework to get it put in place And doesn't mess with the plans of others.

I'd prefer that the Archetypes only be used on LHs with no pre-defined behavior. Leaders from Firaxis or good LH packs already have somewhat reasonable personalities and I see no reason to change them.

 

[Thunderbrd]

Well, they wouldn't HAVE to be, except that there's still the issue of having to then update all of the ones we have so that they take into consideration some of the additional Flavor features, and 'Favorite Trait' features that will be added at that time. It's not absolutely necessary to do this with Flavors but they'd be a bit uniformly similar by not considering the full scheme there. Nor would it be absolutely necessary to update with a Favorite Trait, but they would not have as refined a mechanism for working with traits if these steps are overlooked on the originals.

There's still reason to continue with this structure nevertheless but hopefully we can at least review those two.

Also, a BIG reason to adjust the current leaders we have to this mechanism... it would save us an enormous amount of upload data and a bit of startup time. It also shouldn't be impossible to make their picks end up being very similar or identical to the original settings they have now as I'm sure some of the Archetype settings would be based on the leaders we already have. (RtS... how true do you think this will end up being?)

 

[RidetheSpiral23]

(RtS... how true do you think this will end up being?)

Very true. I have been reading over and over all the variables in the leader head files and I can say that once I am done finalizing my subcategories that I could easily and accurately simulate the normal personality of any of the firaxis leaders. There will even be categories for the extreme variables that occur only on certain leaders, for example mansa musa's willingness to always trade techs or Brennus' high attack odds that make him willing to attack almost anything.

 

[Thunderbrd]

I presume that's why you're saying we shouldn't require the averaging effect huh? How much room do you feel there is for some entirely new Archetypes representing new leader personality approaches that haven't been utilized yet?

Admittedly, if we don't utilize a blending effect, if it's really not necessary, it'd make the system much simpler. And if you feel we don't have anywhere near that kind of diversity as it stands then perhaps it is entirely unnecessary.

 

[RidetheSpiral23]

I'm hoping that I will have just about every feasible shade of personality in each of the subcategories. The nice thing about this new system would be that archetypes could easily be added to the subcategories in the future if they are found to be lacking and all that would need done is to change one variable in the leader head file!

The averaging may cause some issues in the variables that are very specific and you are correct in saying that that's why I don't feel it's necessary.

 

[Thunderbrd]

Ok. I'll eliminate the averaging mechanism in my thinking and in the programming then. But I'd welcome you to invent some additional diversity. PLEASE do!!! If you understand these settings, you're a unique asset on this team as I'm not sure any of us have taken the time to really figure out what they all mean yet.

Another thing this is intended to resolve is the overlooked 'Memory' tags. I grabbed this list from the dll enums:

	MEMORY_DECLARED_WAR,
	MEMORY_DECLARED_WAR_ON_FRIEND,
	MEMORY_HIRED_WAR_ALLY,
	MEMORY_NUKED_US,
	MEMORY_NUKED_FRIEND,
	MEMORY_RAZED_CITY,
	MEMORY_RAZED_HOLY_CITY,
	MEMORY_SPY_CAUGHT,
	MEMORY_GIVE_HELP,
	MEMORY_REFUSED_HELP,
	MEMORY_ACCEPT_DEMAND,
	MEMORY_REJECTED_DEMAND,
	MEMORY_ACCEPTED_RELIGION,
	MEMORY_DENIED_RELIGION,
	MEMORY_ACCEPTED_CIVIC,
	MEMORY_DENIED_CIVIC,
	MEMORY_ACCEPTED_JOIN_WAR,
	MEMORY_DENIED_JOIN_WAR,
	MEMORY_ACCEPTED_STOP_TRADING,
	MEMORY_DENIED_STOP_TRADING,
	MEMORY_STOPPED_TRADING,
	MEMORY_STOPPED_TRADING_RECENT,
	MEMORY_HIRED_TRADE_EMBARGO,
	MEMORY_MADE_DEMAND,
	MEMORY_MADE_DEMAND_RECENT,
	MEMORY_CANCELLED_OPEN_BORDERS,
	MEMORY_TRADED_TECH_TO_US,
	MEMORY_RECEIVED_TECH_FROM_ANY,
	MEMORY_VOTED_AGAINST_US,
	MEMORY_VOTED_FOR_US,
	MEMORY_EVENT_GOOD_TO_US,
	MEMORY_EVENT_BAD_TO_US,
	MEMORY_LIBERATED_CITIES,
	MEMORY_INQUISITION,
	MEMORY_RECALLED_AMBASSADOR,
	MEMORY_WARMONGER,
	MEMORY_MADE_PEACE,
	MEMORY_SACKED_CITY,
	MEMORY_SACKED_HOLY_CITY,
	MEMORY_ENSLAVED_CITIZENS,
	MEMORY_BACKSTAB,
	MEMORY_BACKSTAB_FRIEND,

It was pointed out by GodEmperor that many of these were overlooked in the current leader profiles and that this was problematic. I'd ask you to take it into account that repairing this is one of our goals.


I'm working on a large set of traits tags right now but this is the next project up after that. So I feel we're making really excellent headway here and dude... you rock! Thank you!

 

[RidetheSpiral23]

I read through the modiki on the leader head files and dug through leaders I knew we'll to get a good grasp on each of the variables. Ironically, the latest thing I have been working is contact rands, contact delays, and memory decays. I am currently working on getting those seperated into the subcategories. Most of the memory decays are going into diplomacy but some aren't, like raze holy city into religion and memory warmonger in military.

I need a little more time to go over the subcategories to make absolutely certain they all belong in their categories. I want to make sure that this set up works as you and I intend. After I'm sure of them ill start fleshing out the exact variables in the archetypes. I will also post a comparison of a leader with the old style and the new to show how well they match up when I have the appropriate files done.

 

[Thunderbrd]

Awesome!

One thing:

Most of the memory decays are going into diplomacy but some aren't, like raze holy city into religion and memory warmonger in military.

I'm not entirely sure we can split those since its all under one tag... Well... I can think of a way but it wouldn't be enforced which would make it very critical that only someone who really knows the structure be working the structure (like yourself ) If I were to make it an enforced thing I'd have to do some hardcoding I would not want to do. What I mean by 'enforced' is that by putting the Memory tag in more than one Archetype file type, it would be possible for an xml programmer to break the 'rule' as to which memory types would go in which Archetype file and that could create some odd results as some archetype files would take precedence over others in such a case where two referred archetype files have a value on the same memory type. Just something to keep in mind as to a 'flaw' that could emerge in the structure of the system.

 

[ls612]

Well, they wouldn't HAVE to be, except that there's still the issue of having to then update all of the ones we have so that they take into consideration some of the additional Flavor features, and 'Favorite Trait' features that will be added at that time. It's not absolutely necessary to do this with Flavors but they'd be a bit uniformly similar by not considering the full scheme there. Nor would it be absolutely necessary to update with a Favorite Trait, but they would not have as refined a mechanism for working with traits if these steps are overlooked on the originals.

There's still reason to continue with this structure nevertheless but hopefully we can at least review those two.

Also, a BIG reason to adjust the current leaders we have to this mechanism... it would save us an enormous amount of upload data and a bit of startup time. It also shouldn't be impossible to make their picks end up being very similar or identical to the original settings they have now as I'm sure some of the Archetype settings would be based on the leaders we already have. (RtS... how true do you think this will end up being?)

The load time factor from this is really minor for most players (who use the normal version and have caching). And the Firaxis LHs at least were specifically designed to have personalities using the stuff that was ignored for the custom ones. So please don't change those.

 

[Thunderbrd]

using the stuff that was ignored for the custom ones

please clarify.

 

[ls612]

please clarify.

The whole point of the personalities is that many of the memories and stuff aren't used on many LHs. So if a LH was made by Firaxis and uses everything, there is no need to change it.

 

[Thunderbrd]

In most cases, those that are 'ignored' are due to being included AFTER the design of those leaderheads and the fact that they are not used is not intentional but an oversight. It's part of the goal to fix that and do it in a way that's very easy on us all.

This is presuming that for the most part you're talking mostly about Memories settings. All leaders should have a value defined for all memories. If they don't its an oversight and one that is not good for the game's processing - leaders that never forget certain events. PART of the point here is that such an overhaul and update is already necessary, and that probably counts particularly for the originals made by Firaxis before all the mods this one is built on went and added more Memory entries that have never been updated for those leaders.

Reference some discussion on this subject within the first 10 pgs of the Rocks2Rockets forum. I'll go try to find the spot and give you a link.

As for 'and stuff' its hard to know if there's anything you're pointing at there.

Load time is a fairly insignificant issue there yes. But download time isn't. When I was not using the SVN, each version release would require 12 hrs of download time or more and somehow I'd have to make sure that never got broken - my internet was a bit better back then. Sure we have some that come along and seed but if and when that's not happening... a little less information where it can be shaved is a good thing in general, particularly if:

a) it won't change any of the values (except perhaps to add some needed updates)
and
b) if its not adapted to this system, it won't break anything.

Honestly, updating the existing leaders is probably the last step and may never be done. But not doing so will leave those leaders undefined in a number of places they should have definition.

 

[Thunderbrd]

Ok, for reference, the conversation we had with God Emperor on this subject of memory decays:

Another thing that's come up (and feel free to say "take this to C2C") is that in my view no diplomacy hit (or benefit) should be permanent in duration. It's all very well in ordinary Civ, but it does seem to stretch credibility that in 2500 AD, Hattie will hate you because you burned down three of her cities in 20,000 BC; in particular, it's a very poor fit with C2C/R2R's very long game to be able to make other civs into permanent enemies. Diplomacy durations are in the SDK, not XML, or I'd fiddle with it myself. I don't have a problem with the existing permanent diplomacy modifiers being of very long duration, but I do feel they ought to go away eventually.

I was thinking it was all done in the code too but apparently a lot of the forgiveness rates are done in the leader personality profiles in leaderheadinfos.xml. Perhaps you might find the ones you were looking to tweak there. I haven't done a thorough look through of that system structure yet so if you find what you're looking for, let me know... would be a good learning experience for both of us I agree that in C2C/R2R some of the diplomatic penalties aren't forgiven fast enough generally.

The durations of the various modifiers are controlled (at least mainly) by the MemoryDecays section of the leaderhead info.

Part of the problem is that they are the chance per turn of forgetting 1 instance of an event of that type. If it says 200 then the base is a 1 in 200 chance per turn. In the early game, turns represent a lot of time. (Example: Alexander has a 200 for you giving him help and a 100 for you refusing to help.) The realistic diplomacy option and the ruthless AI game option both modify the chance of forgetting (the "realistic" makes them forget faster, "ruthless" slower).

As for the rest of the problem: There are apparently a few defaults set, but only for the ones Afforess added. Other than those, the ones that are not specified for a specific leaderhead default to 0 and value which is 0 (or less) means "never forget". So Alexander, who has no decay value set for MEMORY_DECLARED_WAR will never forget you declared war on him. I don't think any of them have a value set for this, or some of the others - like MEMORY_DECLARED_WAR_ON_FRIEND and MEMORY_RAZED_CITY. Well, I only looked at the main leaderhead file - the modular ones could specify these values (but probably don't).

woah... that's a fairly large area that requires some serious auditing then. Sheesh - a bit of a mess huh?

Can you PLEASE expand on the Leaderhead stuff please, i am going to add in C2C, 10 Civs to on upwards the # of leaderheads, and this is a major factor then i need to know about, thx.

If you look in CIV4MemoryInfos.xml you will see that there are 42 different memory types defined (they are also hardcoded in the DLL - you cant just change them in that XML file, in case you were wondering).

If you look in the CIV4LeaderHeadInfos.xml for any leader you will find a section whcih looks like this:

			<MemoryDecays>
				<MemoryDecay>
					<MemoryType>MEMORY_GIVE_HELP</MemoryType>
					<iMemoryRand>200</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_REFUSED_HELP</MemoryType>
					<iMemoryRand>100</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_ACCEPT_DEMAND</MemoryType>
					<iMemoryRand>50</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_REJECTED_DEMAND</MemoryType>
					<iMemoryRand>150</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_ACCEPTED_RELIGION</MemoryType>
					<iMemoryRand>100</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_DENIED_RELIGION</MemoryType>
					<iMemoryRand>50</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_ACCEPTED_CIVIC</MemoryType>
					<iMemoryRand>100</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_DENIED_CIVIC</MemoryType>
					<iMemoryRand>50</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_ACCEPTED_JOIN_WAR</MemoryType>
					<iMemoryRand>150</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_DENIED_JOIN_WAR</MemoryType>
					<iMemoryRand>100</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_ACCEPTED_STOP_TRADING</MemoryType>
					<iMemoryRand>100</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_DENIED_STOP_TRADING</MemoryType>
					<iMemoryRand>50</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_STOPPED_TRADING_RECENT</MemoryType>
					<iMemoryRand>30</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_MADE_DEMAND_RECENT</MemoryType>
					<iMemoryRand>20</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_CANCELLED_OPEN_BORDERS</MemoryType>
					<iMemoryRand>10</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_TRADED_TECH_TO_US</MemoryType>
					<iMemoryRand>100</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_RECEIVED_TECH_FROM_ANY</MemoryType>
					<iMemoryRand>20</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_VOTED_AGAINST_US</MemoryType>
					<iMemoryRand>10</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_VOTED_FOR_US</MemoryType>
					<iMemoryRand>10</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_EVENT_GOOD_TO_US</MemoryType>
					<iMemoryRand>50</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_EVENT_BAD_TO_US</MemoryType>
					<iMemoryRand>50</iMemoryRand>
				</MemoryDecay>
				<MemoryDecay>
					<MemoryType>MEMORY_INQUISITION</MemoryType>
					<iMemoryRand>25</iMemoryRand>
				</MemoryDecay>
			</MemoryDecays>

That is the one for Alexander. If you count the MemoryDecay entries you will find that there are only 22 of them. It looks like all of the leaders in that file have 22 defined, although I suppose they might not all be the same 22. (I used the "count" function in the search dialog in Notepad++ to count how many "MemoryDecays" (the plural wrapper around that section) there are and multiplied that by 22, I then did the same check to find out how many "MemoryDecay" entries there are and it was that same number: 1364.)

So that means that each leader in CIV4LeaderHeadInfos.xml has 20 memory types that never decay because a decay value is not specified. If you do something that triggers one of those types of attitude change (good or bad) the leader will never forget it.

Well, there might be some that are specifically handled outside the normal mechanism, which checks the specified decay chance once per turn as that player's turn is processed. I didn't search the DLL's code for every reference to "MEMORY_" to see if any were specially handled elsewhere. Based on playing seeing things happen while playing, I suspect that when someone becomes a vassal some of the memory types might be zeroed. I seem to recall seeing some of the attitude modifiers go away when that happens.

 

[RidetheSpiral23]

Thanks for posting that conversation, I had not seen that yet. I for sure want to make sure that all memory decays are being utilized.

Hum so how dangerous would it be to split up the memory decays and contact rands into different subcategories. You would know better than I but I assumed that as long as they weren't duplicated then it wouldn't cause a problem. Can you please elaborate on the coding repercussions of tht method for me?

@ls612

I think it's odd that you would be using the argument that we shouldn't change what firaxis made originally against this new system. Why are even working on a mod then if we don't want to change stuff? The memory decays can be improved with this new system. Right now there is a major issue with them as was pointed out in the above conversation.

 

[ls612]

<snip>
@ls612

I think it's odd that you would be using the argument that we shouldn't change what firaxis made originally against this new system. Why are even working on a mod then if we don't want to change stuff? The memory decays can be improved with this new system. Right now there is a major issue with them as was pointed out in the above conversation.

Because of what we have now they are the most complete. So if we mess with them at all it should be last.

 

[Thunderbrd]

Hum so how dangerous would it be to split up the memory decays and contact rands into different subcategories. You would know better than I but I assumed that as long as they weren't duplicated then it wouldn't cause a problem. Can you please elaborate on the coding repercussions of tht method for me?

It's not that its particularly dangerous, just potentially confusing for designers. I'd have to establish an order in which Archetype categories were checked for a value and if any have a determined value, then the first result is what would override all others. Thus if a given entry type was used in two different Archetype Category files, one would be ignored. So, if we can be sure to include a note somewhere at the beginning of the XML file, we could make sure that future designers understand to only use particular denoted entries on those tags.

 

[RidetheSpiral23]

Okay great thanks for clearing that up. If we note it then it shouldn't be a problem. I don't plan on duplicating any variable in multiple subcategories so that should work out. I should be able to do quite a bit of work on Sunday night. Im going to focus on one subcategory at a time so I can post an attachment so you can get a better idea how much diversity we can get out of this system.

Also clear up some of this structural stuff for me please. Do we have to make just one archetype info file or is it possible to split them up?

 

[Thunderbrd]

Better to split them up into differing classes/xml files if we're going to have each category have differing entries and we're abandoning the averaging system.