Military Advisor

I'm heading out for the weekend, returning Monday, but off the top of my head I'm guessing that you need to put the target Civ into the TradeData.iData field.

PHP:
tradeData.iData = iLoopLeader
# Check if it will trade, and if not, grab the DenialType
Sorry for the lack of detail. Check MoreCiv4lerts for examples of checking the status of a trade. I think that's all you're missing.

BTW, if you want to match your naming style with the rest of the BUG code (and most mods I've seen so far), here are a few changes.

  • Use "p" as a prefix when "pointing" at an object instead of "gc".
  • Technically, iLoopLeader is actually a player #; you'll see iLoopPlayer a lot. The pPlayer you get from gc.getPlayer(iLoopPlayer) has a method, getLeaderType() which returns a LeaderHeadType, technically the Leader #.
I can't wait to check it out when I get back. This will be a really nice addition to the game.
 
noted on the player / leader thing ... I've only recently been using leader so it shouldn't be a biggie swapping that back. re pointer ... as soon as I figure out what a fracking pointer is ... I will start using a 'p'.

Thx for the trade info ... I'm off to watch the mets v braves ... will look at it when I get back or tomorrow.
 
A pointer is the address of some object in memory, whether that's an int, a string, or a CyPlayer.

Think of an address like the address to your home. The address is not your home -- you cannot live in it, and it has no bedrooms. It only "points to" your home. Given your address, I can find your home.

If you want me to come to your home, you don't describe your home in every detail, thus "giving me" your home. That would take too much time; it's an "expensive" operation. Instead you give me the address.

The same goes for objects like CyPlayer. The code uses the address in memory of the object as a reference to it. It can pass the pointer to other functions cheaply since it's a small amount of data. If it were to pass all of the data in the CyPlayer each time, it would be more expensive.

Pointers serve other more important purposes, however. By passing a pointer, the function that receives it can modify the original object.

For example, if you tell me your house is blue, I can't change its color. But if you give me your address, I can go to your home and paint it.

On a related note, the ever popular prefix in Windows coding "sz" means "string, zero-terminated." That means that the variable holds a string of characters ending in a special "this is the end" character that has ASCII value zero.

The practice of using standard prefixes in variable names is called Hungarian Notation. It became popular with the introduction of loosely-typed languages like VB. Python is loosely-typed as well. Languages like C, C++ and Java are strongly-typed: you have to tell the compiler exactly what each variable can hold.

This is acceptable, though confusing, in Python

PHP:
x = 5  # holds an int
x = x + 3  # ok, now it holds the int 8
x = "Bob"  # now it holds a string
x = x + 4  # runtime error, "cannot concatenate str and int"
You won't find the problem until you run the code. In Java, it won't even be runnable at all.

PHP:
int x = 5;  // can only hold an int
x = x + 3;  // ok
x = "Bob";  // compile error, "cannot assign String to int"
Each type of language typing rules has its advantages. Most people shy away from Hungarian Notation (clear documentation is far preferable), but almost all of the code pulled into BUG uses it, so I did as well when changing things. You'll see much of the new BUG code doesn't use it.
 
Just uploaded the latest version of the military adviser. The only (!) outstanding items are the threat index and the strategic resources.

 
For example, if you tell me your house is blue, I can't change its color. But if you give me your address, I can go to your home and paint it.
Actually, the house is gray and it does need a paint. Thx for your offer - I will be in contact to take you up on that ... gee I hope you paint well.

Anyway - back to pointers - very nice description above. That just leaves me with the problem of when is a variable a pointer and when is it an int :D
 
I'm at a bit of a cross roads about what to do with the strategic resources column. Initially, I thought to show the strategic resources they didn't have and / or the number that they did. Then I thought that the resources don't hurt you - it is the units they can build that do. So, I could show the units that they can build in this column - that would be a lot in the late game and devalue this column.

So, now I am considering showing the units that they can currently build (that you cannot build) based on their known tech and known resource. Thus, if they know bronze working and have copper but you cannot build axemen, then this column would show axemen in that list.

Thoughts / comments / input?
 
I like the last option best.
Thinking further about this ... it should be pretty easy.
  • Get the list of units that the other leader can build (excluding non-combat units - workers, spies, missionaries, settlers, etc)
  • Get the list of units you can build (excluding non-combat units)
  • Compare lists removing duplicates
  • Remove units from the list where the player does not know, or cannot research, the required tech
  • and you are done (I think)
 
I like that a lot as well. It sums up their military technological advantage. I wonder how easy it will be to code up, however.

Consider that cities that are not attached to their trade network will have a different set of buildable units. I know this is very rare in the late game where the list could get large. A good source of example code will be the code in CvMainInterface that draws the build order section in the bottom-center of the screen.

About the "denial reason" column, I wonder if this has any value as is. Clearly, if they are WHEOOH, that needs to be shown. I believe if they say that about AI X, they say it about all AIs.

However, the other denial reasons will vary based on the AI, so a single reason is misleading and I dare say unimportant. Perhaps this just needs to be a WHEOOH column by itself. Sure, it's in the threat index, but I think it's important enough to be called out separately. I still want to add it to the scoreboard.
 
Some people have been talking about how unbalancing a WHEOOH alert is. I wanted to display the info but make the user work a little bit for it. Oh - by the way, the underlying denial for WHEOOH is 'DENIAL_TOO_MANY_WARS' which is interesting. It is generated when the AI is at war and has too much to do to. I guess it is also generated when the AI is planning for war. I was thinking of wrapping the text to fix the overflow problem but maybe we just go with the WHEOOH option and put a little fist beside the leader head.
 
I understand the argument about it being an unbalancing feature, but I disagree somewhat. If you have the patience to check each AI each turn, you will get the same feature.

Thus, being uber patient or having nothing better to do with your time is an unbalancing feature. Similarly, being a good tactition is an unbalancing feature.

This alert would actually balance it so everyone -- even impatient people -- can use this information. As it stands, I only benefit from the info now if I happen to randomly check and they have it. That's not skill -- it's luck, and I don't want luck where it's not needed.

In any case, make it an option and we satisfy everyone. :) I know, that wouldn't satisfy everyone, but it sounds good.

And ya, I was thinking the fist, too.
 
MA status ...

  • threat index - need to settle on the initial calculation routine and put it into play
  • strategic units on the main screen
  • scrolling - looked at this last night, copied the code and it didn't work - will look again and then probably put it aside
  • 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

I'm not above asking for help so if anyone wants to chip in, feel free. I'm going to be looking at the main sort criteria today so the other items are free for your pleasure.
 
MA status ...

  • threat index - need to settle on the initial calculation routine and put it into play
  • strategic units on the main screen
  • scrolling - looked at this last night, copied the code and it didn't work - will look again and then probably put it aside
  • 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

How do you return 2 items from a function?
 
How do you return 2 items from a function?

PHP:
def getXandY():
    return 2, 5

def printXandY():
    x, y = getXandY()
    print x
    print y
In the above the return statement creates a tuple (an unmodifiable list) containing the two values 2 and 5. Using "x, y = ..." breaks apart the tuple. You could also do

PHP:
def printXandY():
    values = getXandY()
    print values[0]
    print values[1]
but I generally reserve that for when the returned items truly form a single item, for example a 3D point (x, y, z).
 
Thx EFool - that will come in useful. I've split my work into first release and future release so that I am forced to concentrate on getting a version finished as opposed to playing with future features.

MA status ...

  • threat index - need to settle on the initial calculation routine and put it into play
  • strategic units on the main screen
  • 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)
  • hide strategic resource information if no tech and resource trading
  • hide threat index if cannot see power

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
Currently working on threat index.
 
MA status ...

  • threat index - need to settle on the initial calculation routine and put it into play
  • hide threat index if cannot see power
  • strategic units on the main screen
  • hide strategic resource information if no tech and resource trading
  • 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)

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
Currently working on threat index.
 
@ruff:

Here is a shot from my recent game.



Right now it doesn't weight defensive pacts correctly. I have defensive pacts with Mehmed and Ramesses (both are friendly towards me) which means they can't declare on me right now - so the threat index should be guarded/green. Also Monty is a vassal of Mehmed and can't declare, yet the threat index is high... This is with latest revision 654 (or 652?) from the SVN.

Imhotep
 
Threat index is calculated from:

relationship ... -15 to +15 is rescaled to 0 to 38
strength ... 50% to 150% (us / them) is rescaled to 38 to 0
threat is sum of above times 1.3 if WHEOOH

(38+38) * 1.3 is approx 100 which is what I was aiming for.

5 categories are delimited by ...

  • < 15 then Low
  • >= 15 and < 35 then Guarded
  • >= 35 and < 55 then Elevated
  • >= 55 and < 75 then High
  • >=75 then Extreme

I am more than happy to take suggestions into the make up of this threat index to include other items and to change the cutoff positions.
 
First is to define exactly what "Threat Index" means in subjective terms (not numbers). For example, is it the likelihood that an AI will DoW on you or the danger they would pose if you were warring?

If it's the former, than having a PA should eliminate the index, and a DP with them should lower it (can they not declare war at all, or just less likely to?). Also, perhaps them having a DP with other civs would lower their likelihood of DoWing and losing the DP (dunno). Being a vassal would eliminate the index since they cannot DoW.

If it's the latter, having a DP with a civ other than you should possibly increase the index because it only matters if you DoW on them. Having a PA with another civ should increase the index as well.

Actually, I can see the argument against both of these as long as the player keeps in mind to consider the index of all civs that will be involved in the war. It would be difficult to quantify how the index should change as a result of a DP or PA, since it should really change based on the index of the other civs, but that then causes a feedback loop.

I think were aiming for the latter, not trying to guess the likelihood of a DoW but rather just judging the seriousness of being in a war with each civ.

Suggestion: Maybe PAs should be denoted in the screen somehow, perhaps by grouping those civs together. At least have some sort of mark so you are aware that you may be fighting multiple civs.
 
I view the threat Index (TI) as an indication of the likeihood of a war declaration combined with how bad that would be. I think that we should include DP and Vassals in the calculation - maybe combine the calculation for PAs. All of the calculation inputs should be opened to the user so that they can turn things off but we should definitely have a view on what it is. I'll think about this and post more later (maybe the weekend).

Also, allow for an adjustment by leader.
 
Top Bottom