Military Advisor

I like the WHEOOH as a multiplier. Building in complicated tech differentials is possible but I'm not sure I want to hard code those. Maybe I include key military techs (Copper, Iron, CS+Mach, Rifling, Industrialisation, Tank tech) in a similar way that I am including strategic resources. I am not putting in modifications for known nut-cases (Monty, Boudica, etc) as the player has to think about this themselves. Actually, we could make this a configuration (list of leaders with level adjuster ... -1, 0, +1) and include that in the ini file (not the option screen).

I think that they have a different reason for not trading war declarations if they are already in a war.

arent there AI weights in the xml associated with more important resources and techs. Maybe that could used in the point system for the threat level.
 
arent there AI weights in the xml associated with more important resources and techs. Maybe that could used in the point system for the threat level.
No. That information is not available via the usual interface and so I don't think that we will be reflecting this information. Actually, this is another argument against having any leader adjustments included. Hmmn - as such, I don't think the 'production' version of BUG will include this but I think that we should include the ability for this so that the user can adjust it - just to stop requests coming in - thoughts?
 
I'd recommend leaving out the per-AI user adjustments and focus on the main features. I'm already used to keeping an eye on Monty, and I bet others are as well. Put it into the feature tracker and we can hit it later.
 
MA status ...

  • threat index - need to settle on the initial calculation routine and put it into play
  • hide threat index if cannot see power - could include comment "n/a"?
  • strategic units on the main screen
  • hide strategic resource information if no tech and resource trading - see if I can include comment
  • scrolling - looked at this last night, copied the code and it didn't work - will look again and then probably put it aside - done and committed (revision 645)
  • Add list of leaders that the current leader has a DP with
  • Add list of leaders that the current leader has vassalaged
  • Adjust Threat Index to include reduction value for DPs (say, 0.6?)
  • Adjust Threat Index for leaders that are vassals (duplicate their masters or completely remove?)
  • master icon - do we want this?

MA status for future release ...

  • free up the main sort criteria (currently unit combat type) so that the user can select what it is - need drop down, refresh button and auto-refresh check box
  • glance screen
  • worst enemy icon (only when patch has been released)
Currently working on threat index.
 
Main sort criteria on the deployment tab ...

Currently, the main sort criteria is unitcombattype. Non combat units (workers, settlers, etc) have a combat type of 0. The other units have a combat type of 1, 2, etc. This makes it really easy to use the combat type as an index (0, 1, 2, 3, ...) and that is the way the code has been set up.

I want to free up the main index (leave the other 3 as they are - which are unit, array of all units, unit count). There are also some sub-routines (is that the right name) that control if you select a group, then you also select the subsets of that group. The parameters are very inconsistent in that some take the unit id, some take the unit type, others take the unit pointer. I want to consolidate all of those items and make it a single type ... unit pointer.

Now, if python was like C, or Visual VB, we could use a text value as a pointer to an array value (or the key to a member of a class). However, to the best of my knowledge, we cannot do that. So - here is what I am thinking regarding the main index ...

  • it needs to be a number .. 0, 1, 2, 3, ...
  • it should be open ended and anything could be it
So, in my advanced programing skill (HAHA!), here is the method that I developed that will do this ...

create an array called PrimaryIndexKey. Use that index to hold the values that reflect the main index and use the array index for that value as the index for the unitlist index. Maybe an example would be clearer ...

Example

Say you want to use the following as your main index ...
  • Own City
  • Own Territory
  • Foreign City
  • Foreign Territory
  • Other

... then you would need to execute the following code (pseudo) ...

PrimaryIndexKey = []
call getPrimaryIndexValue (pUnit) which does the following:
  • determine the type of key you are looking for (in this case, one that is unit location based)
  • check PrimaryIndexKey to see if the value this unit has (ie Own City) is in the array (loop over the PrimaryIndexKey array
    • if it is, just return the index and the fact that you found the index and you are done
    • if it isn't, append the value and return the index and the fact that you had to append the value.
... now, back to the calling subroutine, then you get back a true / false and a number. If the boolean value is true, then you need to append an array to the unitlist array (I think it is [0,0,[],0 but check the code). Then use the number you get back from getPrimaryIndexValue to add that unit to the unitlist array.

The following is the code that zero-ises the unit list array ...
Code:
for iUnit in range(gc.getNumUnitInfos()):
     self.unitsList[iUnit] = (gc.getUnitInfo(iUnit).getUnitCombatType(), iUnit, [], 0)

obviously, we cannot use this, thus we need to go with ...

self.unitList = [[]]

... and when we append a unit, we add something like this ...

x = getprimarykeyindex

self.unitlist.append(x, unit.unittype, [], 0)

Well - that was my thoughts but feel free to laugh and tell me the right way to do it. When we do it, I thing that the first that we should code up is the type of key = unitcombattype (ie what it is now) and then we should have the code exactly replicate what you currently see.
 
Now - regarding the screen - I was thinking that we move the map down a touch, put in a drop down that contains the possible primary keys available, a check box that says "auto refresh" with hover "auto refresh when changing the drop down or using F5)" and a Text "Refresh" that is visible when the list box is dirty and not there when it is not.

Layout would be ..

[-----------drop down----------------]
[------check box-----][---refresh-----]

[-------------MAP -------------------]
[-------------MAP -------------------]
[-------------MAP -------------------]
[-------------MAP -------------------]
[-------------MAP -------------------]
[-------------MAP -------------------]
[-------------MAP -------------------]

[---GREAT GENERAL -PROGRESS BAR---]
 
I'll start with the easy part first. :)

. . . a check box that says "auto refresh" with hover "auto refresh when changing the drop down or using F5)" and a Text "Refresh" that is visible when the list box is dirty and not there when it is not.

Why is this needed? The only reason to change the primary key index is to refresh the list. If there were multiple selection criteria, e.g. filtering checkboxes and such, then it may make sense. Also, it isn't necessary if it is quick to run.

That being said, I understand all that you said there and am on the same page. Now that tougher part.

First, as I understand you, the primary key index is the criteria by which the list groups units. Initially we'll have combat type, but others could be location, promotions, whatever. Okay, I doubt we'd do promotions, but it could be done.

ruff_hi said:
Now, if python was like C, or Visual VB, we could use a text value as a pointer to an array value (or the key to a member of a class).

I think by this you mean a Python dict(tionary) class. It is like an array in that you use an index to locate an item, but it is different in that the index can be anything -- a string, an int, a float, a Butterfly or PyPlayer object, whatever you want. Also, with Python you can mix them in the same dict, which I do not recommend.

PHP:
units = {}
units["Warrior"] = [CombatType.MELEE, gc.getUnitInfo(...)]
units["Archer"] = [CombatType.ARCHERY, gc.getUnitInfo(...)]
...
print units["Warrior"][1].getName()
The only naughty point is that dictionary keys are not ordered, so you have to sort them some other way. This is pretty straightforward, but not as trivial as when using an array.

PHP:
# print out unit names, sorted by combat type above
keys = units.keys()
keys.sort()
for key in keys:
  unit = units[key]
  print unit[1].getName()
Now I poked around the code a little when looking at the GG thing, and my first impression is :eek:. It is horribly inefficient and needlessly complex. It would not take much to rewrite it, and I highly recommend doing so in order to make adding more grouping types.

I'm quite happy to do this part if you don't mind. I think what I can come up with will then be far easier for you to add more groupings to.
 
Why is this needed?
The F5 takes a long time to load because it is populating the array prior to displaying it. I can easily see the situation where the user wants to display units by location (say) but the last time he used F5 it was set up to show by level. He hits F5, has to wait until the stupid array is populated just to change the primary key and wait again.

I think by this you mean a Python dict(tionary) class.
Did you read the part about me being a hack coder and not actually understanding anything that I am doing?

I'm quite happy to do this part if you don't mind.
Be my guest. Are you planning on linking the dropdown to the bug.ini file - that was what I was thinking.
 
He hits F5, has to wait until the stupid array is populated just to change the primary key and wait again.

Ah good point. I hadn't thought of it applying between F5 hits. I also realized there are other filters: the leaders you select. The user may want to click a few leaders and then load the list.

Did you read the part about me being a hack coder and not actually understanding anything that I am doing?

You've done some good stuff so far, so don't sell yourself short. I just wanted to make sure I understood what you were saying so I could explain the right thing.

Are you planning on linking the dropdown to the bug.ini file - that was what I was thinking.

How about an option to set the default selection that gets used each time you start civ? I would just rather not rewrite the .ini file every time they select a new option in the MA itself. I'm going to do the same thing for Raw Commerce -- you will set a BUG option to determine the default when civ loads, but switching it in the city screen won't change that default. Cool?
 
How about an option to set the default selection that gets used each time you start civ? I would just rather not rewrite the .ini file every time they select a new option in the MA itself. I'm going to do the same thing for Raw Commerce -- you will set a BUG option to determine the default when civ loads, but switching it in the city screen won't change that default. Cool?
Sounds good.

As I read the code, all visible units (regardless of leader) are loaded into the array at the start so selecting the leader is just a matter of refreshing the list box and you don't have to loop over the units again.

I'm at the stage of removing junk from the MA but I haven't touched the deployment subroutines for ages. Feel free to work from the version in the SVN. I only have the strategic resources columns to go and then I will upload what I have.

Edit: Oh, have to revisit the index too and ... oh, just see the latest status post above.
 
Here is a screenie from the sit rep from the latest version ...



  • little fist shows WHEOOH
  • strategic advantage is when you can build a unit and the AI player cannot
  • strategic disadvantage is when the AI player can build a unit and you cannot
  • two hidden columns that should get displayed if they become required (vassals, defensive packs)

Note re no player water units in above pic: the units to build are generated from the capital city so if the capital city doesn't have water access, then no navel units can be built and it appears that the AI has an advantage. I'm going to include code to cycle thru the units and include all combat units that can be built anywhere - this will remove this problem.

Note re strategic disadvantage of out of date units: I'm currently just checking on a 1 to 1 basis, I need to remove a unit if a player can build it or one of the units that that unit upgrades to. This will remove (say) the horse archer from Monty because I can build the knight.

The threat index is as per above but now includes:
  • not shown if AI player is a vassal
  • multiplied by 20% if AI player has a defensive pact with human player
 
MA status ...

  • threat index - need to settle on the initial calculation routine and put it into play
  • hide threat index if cannot see power - could include comment "n/a"?
  • strategic units on the main screen
  • hide strategic resource information if no tech and resource trading - see if I can include comment
  • scrolling - looked at this last night, copied the code and it didn't work - will look again and then probably put it aside - done and committed (revision 645)
  • Add list of leaders that the current leader has a DP with
  • Add list of leaders that the current leader has vassalaged
  • Adjust Threat Index to include reduction value for DPs
  • Adjust Threat Index for leaders that are vassals (duplicate their masters or completely remove?)
  • master icon - not enough room
  • remove strategic units if player can build an upgrade of a unit
  • cycle thru cities so that all units possible are included
  • expose all text to XML for multi-language support

MA status for future release ...

  • free up the main sort criteria (currently unit combat type) so that the user can select what it is - need drop down, refresh button and auto-refresh check box <-- EmperorFool has stuck his hand up for this one - good luck!
  • glance screen
  • worst enemy icon (only when patch has been released)

Currently working on improving the strategic unit list for improved units and water units.
 
That looks so good Ruff... I wouldn't be suprised if this gets rolled into the next patch for BTS. BTW - Are you using the US's comical threat index names?:)
 
That looks so good Ruff... I wouldn't be suprised if this gets rolled into the next patch for BTS. BTW - Are you using the US's comical threat index names?:)
Yes - see post a page or two back. Using that terminology and colour scheme.
 
Note re no player water units in above pic: the units to build are generated from the capital city so if the capital city doesn't have water access, then no navel units can be built and it appears that the AI has an advantage. I'm going to include code to cycle thru the units and include all combat units that can be built anywhere - this will remove this problem.

It will also remove problem of capital city not been connected to some resource to which the other cities instead are connected.

Note: last commit in SVN seems to have a bug (I think in IconGrid_BUG.py), no interface at all using it, everything ok reverting to previous one.
 
oops - that is what happens if you change a statement with zero testing. Fixed.
 
@ruff:

Sit - Rep is not working ATM for me - if I try to change to it all I get is a the map from the overview page and the rest is blank. Tried clearing the cache too...
 
That looks so good Ruff... I wouldn't be suprised if this gets rolled into the next patch for BTS. BTW - Are you using the US's comical threat index names?:)

+++
Really awesome. :D

Just a small suggestion: I think it would be better to show the threat index even when the civ is an ally or vassal, maybe as empty bar with a title that tells that the civ is an ally or vassal respectively. That way it wouldn't look as if the index is broken or something. :)
 
+++
Really awesome. :D

Just a small suggestion: I think it would be better to show the threat index even when the civ is an ally or vassal, maybe as empty bar with a title that tells that the civ is an ally or vassal respectively. That way it wouldn't look as if the index is broken or something. :)

I support this. And it gives the info of them being ally or vassal witthout the need of other columns.
 
Wow, Ruff, this looks really nice! Here are a couple suggestions from the screenshot:

  • Change "Strategic" label on top line to "Strategic Advantage" and change the labels below to "Theirs" and "Ours". I assumed the advantage showed their advantage, so this would make it totally clear I think.
  • Perhaps include a modifier to the TI for WE? +10% maybe (1.1)?
I also agree that this looks like something Firaxis should include. :goodjob:
 
Top Bottom