Victory Screen Mods

[mystyfly]

* if both candidates are at 'friendly' status, votes for one with highest attitude
* if neither candidate is at 'friendly', abstains

I'm not 100% sure, but: I think these two points can be wrong:
1. If the player has higher displayed modifiers, the civ in question could still vote for the competitor as it has better relations with it with peaceweight etc. This would be misleading.
2. I don't know, but there may be AIs that need to have +8 to be at friendly. So if one of the competitors has crossed that magical +7 line, the civ in question will vote for it.

I would rather leave info away that can be rarely wrong but is right often as I'm sure there will be ppl that complain that BUG didn't foresee the results properly.

edit: XPost with EF. His ideas seem solid.

 

[EmperorFool]

I don't know, but there may be AIs that need to have +8 to be at friendly. So if one of the competitors has crossed that magical +7 line, the civ in question will vote for it.

Does each Leader have a different cutoff for each attitude level? Or are you referring to the hidden diplo modifiers?

The problem we're wrestling with is that the visible attitude value (sum of known diplo modifiers) doesn't directly determine the state (Pleased, Friendly, etc). You first must add the hidden diplo modifiers, and I believe it's this actual total attitude that determines the vote.

However, using the attitude state you can work out minimum and maximum actual attitude values. Using this we can attempt to work out the winner with only partial information. I think we all get this, I'm just restating it so we're on the same page.

If indeed each AI has a different cutoff -- Monty is Pleased at +9 actual attitude value but Mansa at +7 -- then this whole thing is flawed.

 

[mystyfly]

Heh, don't follow your thoughts completely beer but my thinking is: The hidden modifiers can screw up the info you're getting from the visible modifiers. You could change "Will vote for" to "Will probabely vote for" ...

Or you just also consider the hidden modifiers. I'm pretty sure they're available to the player. There are enought posts on AI-AI relations like the one ruff quoted so it shouldn't be that hard for the human to determine the AI's exact attitued - like other things BUG helps with - info available but hard to come by.

 

[Dresden]

Does each Leader have a different cutoff for each attitude level? Or are you referring to the hidden diplo modifiers?

The problem we're wrestling with is that the visible attitude value (sum of known diplo modifiers) doesn't directly determine the state (Pleased, Friendly, etc). You first must add the hidden diplo modifiers, and I believe it's this actual total attitude that determines the vote.

However, using the attitude state you can work out minimum and maximum actual attitude values. Using this we can attempt to work out the winner with only partial information. I think we all get this, I'm just restating it so we're on the same page.

If indeed each AI has a different cutoff -- Monty is Pleased at +9 actual attitude value but Mansa at +7 -- then this whole thing is flawed.

The friendly cutoff is +10. For everyone. That is written in stone (or at least in the DLL ). As you said, we can't see the actual attitude value so you might see someone listed as Friendly with only +5 (or even less) in visible modifiers and you might see someone as Pleased with +15 or more in visible modifiers. But the attitude state is guaranteed accurate. If you see "Friendly" their true attitude is >= 10 regardless of what the visible attitude summary shows.

 

[EmperorFool]

The friendly cutoff is +10. For everyone.

Okay, this is how I understood it as well. Great, it means we're going down the right track. While you can't know the exact actual attitude value, you can use the attitude level to figure out bounds. If X is Friendly toward A and Pleased toward B, you can be certain that X has a higher actual attitude value for A than B.

This is what I'm getting at. We ignore the visible modifiers except in the one case where both candidates have Friendly. In this case the only thing we can use is the visible attitude value, and this will sometimes be wrong. Probably more likely to be wrong the closer they are.

Or you just also consider the hidden modifiers. I'm pretty sure they're available to the player. There are enought posts on AI-AI relations like the one ruff quoted so it shouldn't be that hard for the human to determine the AI's exact attitued - like other things BUG helps with - info available but hard to come by.

This is exactly what I was getting at several posts back. Do we want to make hidden information available that is easily determined by reading the SDK. I think this crosses the line into spoiler information. Sure, you can learn all the rules and calculate some of them yourself, but this goes beyond calculating the whip overflow I think. Whip overflow is a simple game rule calculation; the hidden diplo modifiers sometimes depend on individual Leader traits in the XML and other game details that I feel should not be visible.

 

[Dresden]

Here's an updated algorithm with EF's suggestions and suggested wording to alleviate mystyfly's concerns about confusing people.

1. AI votes for itself if it can -- "Will vote for" (i.e. it's Definite)
2. AI votes for a team member if it can -- "Will vote for" (i.e. it's Definite)
3. AI votes for its master, if it is a vassal -- "Will vote for" (i.e. it's Definite)
4. if the AI attitude to one of the candidates is 'friendly' and the other is 'pleased' or less, AI votes for 'friend' -- "Will vote for" (i.e. it's Definite)
5. if both candidates are at 'friendly' status, votes for one with highest attitude -- "Will probably vote for" (i.e. hidden diplo modifiers can turn this into the other candidate or even an abstain.)
6. If both candidates are at Pleased, don't try to guess. -- vote "Undecided" (like before vote could go any of 3 ways but a guess is even less likely to be right so undecided is a good call.)
7. If candidate A is at Pleased, B below Pleased, vote "maybe A" -- "Might vote for" (i.e. we really can't tell if they will vote or abstain but if a vote is cast it's going to be for A)
8. if neither candidate is at 'pleased', abstains -- "Will Abstain" (This is definite, as EF notes in a later post. My bad.)

The #7 situation of one Pleased and the other Less-than-Pleased may be less confusing if it's also called "Undecided" but "Might Vote For" tells you more about the situation.

This is exactly what I was getting at several posts back. Do we want to make hidden information available that is easily determined by reading the SDK. I think this crosses the line into spoiler information. Sure, you can learn all the rules and calculate some of them yourself, but this goes beyond calculating the whip overflow I think. Whip overflow is a simple game rule calculation; the hidden diplo modifiers sometimes depend on individual Leader traits in the XML and other game details that I feel should not be visible.

I agree that hidden diplo modifiers are too much of a spoiler. While some of them are easily determined such as those based upon score rank (assuming you've met everyone and can see their scores) others can in some cases not be at all available to the player. I think specifically of the War Success modifier which is based on how many units each nation has lost to the other in battle and the XML-based modifiers which are unknown if you play with random personalities.

 

[mystyfly]

Like your ideas dresden, I'd just switch 'probabely' with 'likely' as it IS quite likely

 

[EmperorFool]

Very good wording and clear list.

if neither candidate is at 'pleased', abstains -- "Probably Abstains" (i.e. you can actually get a +8 listed as cautious but that'd be extremely rare so this case will almost always result in abstention.)

I think this is a definite Abstain. I don't know the real number for maximum Cautious, but I'm pretty sure it's less than +8 which is the minimum for a vote. Again, we can totally ignore the visible diplo modifiers except in a Friendly tie.

 

[ruff_hi]

gees - I catch a plane and you guys go crazy. Dresden's list is just about what I coded up. I used the list I posted on the prior page which is just about the same as Dresden but I don't show 'might' - I just don't add the votes into the candidate column. Effectively, I've coded up Dresden's 1-5 (the are the same as my list) and have 6-8 returning '-' in the vote column.

coding has been committed to the svn

 

[Dresden]

if neither candidate is at 'pleased', abstains -- "Probably Abstains" (i.e. you can actually get a +8 listed as cautious but that'd be extremely rare so this case will almost always result in abstention.)

I think this is a definite Abstain. I don't know the real number for maximum Cautious, but I'm pretty sure it's less than +8 which is the minimum for a vote. Again, we can totally ignore the visible diplo modifiers except in a Friendly tie.

Doh! Right you are. I got my visible and invisible attitude values mixed up on that one. The max for listed cautious is either +2 or +3 (too lazy to look it up right now ) so it would be a definite Abstain.

 

[Aristos]

something is wrong with the Victory Screen now. It only shows the EXIT button, and incomplete info on first screen.

I have the last SVN version (just updated).

 

[ruff_hi]

guess I wrecked it - will check and upload a working version.

 

[ruff_hi]

just uploaded a new version - there are still some issues with some of the column headings on the member tab but it works for me.

 

[Aristos]

does not work in my save game (attached). I tried a new game, and I see the complete Victory Screen (although I can't test its new functions). I also tested in another savegame that is only in its early turns, and it works there. But in the attached savegame, already in the late stages, it does not work. Test it, please.

BUG is not supposed to "corrupt" savegames, so something weird is going on here with the latest version of this screen. Before this latest version, I could see your new ideas working in this very same savegame.

 

[Aristos]

ok, quick update:

I tried the vainilla VS with that same savegame, and it works fine. There is obviously something wrong with your latest version. The previous version, with some of your new ideas already implemented, worked fine. I guess you just need to compare the two versions and find out what is different.

I sense the problem lies somewhere within the APollo stuff and the spaceship...

Keep us posted.

 

[EmperorFool]

BUG is not supposed to "corrupt" savegames.

BUG modifies saved games using Civ's built-in script-data capability. Further still, I strive to make the code fault-tolerant, meaning that if BUG corrupts its own save data, BUG will ignore it when loading the game.

You should always be able to load a saved game without BUG. The previous CTD in the log was caused by SimCutie's CIV4ColorVals.xml. The file itself is fine, but it changes the order of existing colors, so if you then play without it, problems arise.

 

[Aristos]

see my last post. It has nothing to do with the savegame, as it works fine with the vainilla Victory Screen. Some code messed up the latest version, and the more I look into it, the more I feel it is the new code for the Apollo Project and the spaceship.

 

[EmperorFool]

Yes, I was just clarifying for everyone that BUG won't be corrupting anyone's saved games.

 

[ruff_hi]

does not work in my save game (attached). I tried a new game, and I see the complete Victory Screen (although I can't test its new functions). I also tested in another savegame that is only in its early turns, and it works there. But in the attached savegame, already in the late stages, it does not work. Test it, please.

Thanks for the save. I'll try and look at it tonight or on the train tomorrow morning.

 

[ruff_hi]

does not work in my save game (attached). I tried a new game, and I see the complete Victory Screen (although I can't test its new functions). I also tested in another savegame that is only in its early turns, and it works there. But in the attached savegame, already in the late stages, it does not work. Test it, please.

Fixed. Try it now. Edit: belay that - svn is down.

I also added the following at the bottom of the 'members' tab to try and illustrate that the vote predictions are an estimate.

"The latest BUG poll has %s leading %s by %i votes." % (sWin, sLose, nMargin)