Military Advisor

I tried both of those differences to zero change in the unit icon.
 
I thought of a solution to the 'not enabled' icons looking the same as the enabled icons this morning. Finally! How about we add an icon at the start of the list with a '?' (thx NikNaks) on it to represent that the following icons are estimates.

This isn't perfect but it is better than what we have now.
 
I really like the new ordering options, thanks a lot EF! ^_^

It's a pity that it's not possible to avoid the unwanted multiple selection (it would be perfect to be able to select groups of units according to the choosen criteria... but maybe with filters it will be possible)... but at least now ()thanks to Ruff I'm able to select single units :D

Is it possible to increase the width of the pannel containing the units name? (there is a lot of empty space on the right that can be used) As you can easily immage, in Italian all the unit entries nowc are multi-lines ones...
 
It's a pity that it's not possible to avoid the unwanted multiple selection.

It's definitely possible. I just need to recode it (what's new, eh?) to be aware of this. I'm still using the original game's selection logic, and it doesn't handle items that show up in multiple places or have similar values.

An example of where this gets really strange is that in a recent large test game of mine, selected "Level 11" to see where my uber-Infantry is at, it also selects my single "Mining Inc. Executive". :confused: So yes, I gotta fix this issue.

As for widening the screen, I would like to do that. I'm hoping to wait until I add filtering, but I think I'm going to hold off on the filtering for a while. There are a lot of other features I'd like to add which will be a) smaller and easier and b) more interesting to work on. So I'll see about widening the list as it shouldn't be hard.
 
It's definitely possible. I just need to recode it (what's new, eh?) to be aware of this. I'm still using the original game's selection logic, and it doesn't handle items that show up in multiple places or have similar values.

An example of where this gets really strange is that in a recent large test game of mine, selected "Level 11" to see where my uber-Infantry is at, it also selects my single "Mining Inc. Executive". :confused: So yes, I gotta fix this issue.

This is really good to listen! :) :) :)
If this issue can be adressed, the filter stuff becomes secondary... still intereresting to have it sooner or later, but sure not a priority.

As for widening the screen, I would like to do that. I'm hoping to wait until I add filtering, but I think I'm going to hold off on the filtering for a while. There are a lot of other features I'd like to add which will be a) smaller and easier and b) more interesting to work on. So I'll see about widening the list as it shouldn't be hard.

Just to be sure... I'm speaking of widening the list of units, not the full screen (for higher resolutions).
And what about the "disappearing units bug"? Is it supposed to be fixed? I ask this to know if I have to report disappearing units or not :)
 
Just to be sure... I'm speaking of widening the list of units, not the full screen (for higher resolutions).

The screen already widens itself for higher resolutions. Are you saying that on a wider screen, it should take up all that empty space on the right? This is easily doable and I'll probably do it in a day or so unless someone takes a stab at it (please! :D).

Are you saying that on normal resolution (1024x768) you want the unit list to be wider, to take some space from the minimap? This will take some reworking of the screen -- laying out the components to have less space between them and playing with the coordinates. It's this extra work that I'd rather do just once, but it's not difficult if someone wants to take it on.

And what about the "disappearing units bug"? Is it supposed to be fixed? I ask this to know if I have to report disappearing units or not :)

Yes! I am now using the correct way to iterate across all units. If there were no disappearing units on the original MA, there shouldn't be any now (same code). However, if you do find a missing unit, please post about it. :)

This is really good to listen!

English lesson of the day: You listen to someone so that you can hear them speak. So it's "good to hear."
 
The screen already widens itself for higher resolutions. Are you saying that on a wider screen, it should take up all that empty space on the right? This is easily doable and I'll probably do it in a day or so unless someone takes a stab at it (please! :D).

Are you saying that on normal resolution (1024x768) you want the unit list to be wider, to take some space from the minimap? This will take some reworking of the screen -- laying out the components to have less space between them and playing with the coordinates. It's this extra work that I'd rather do just once, but it's not difficult if someone wants to take it on.

To tell the truth, my suggestion/request was limited to the first thing :)


English lesson of the day: You listen to someone so that you can hear them speak. So it's "good to hear."

Thanks! :)
 
back to the issue of the sit rep strategic icons disappearing when you declare war. EF and I have discussed this and have developed the following solution ...

conversation offline between EF and Ruff said:
ruff_hi (7/10/2008 2:16:04 PM): so, in suido-code ...
ruff_hi (7/10/2008 2:16:13 PM): if have iron-working:
ruff_hi (7/10/2008 2:16:26 PM): if not trade-network: icon grey
ruff_hi (7/10/2008 2:16:37 PM): if trade-networking + iron: icon solid
ruff_hi (7/10/2008 2:16:46 PM): if trade-networking, no iron: no icon
ruff_hi (7/10/2008 2:16:55 PM): with the last 3 ifs indented
emperor.fool (7/10/2008 2:17:04 PM): ya essentially
emperor.fool (7/10/2008 2:17:16 PM): I think you can genericize it and get some help from canTrain()
ruff_hi (7/10/2008 2:17:47 PM): right - that that we (YOU!!) have completely re-written how this code works out YES / NO by unit, I'll take a look to see if we can do the above
emperor.fool (7/10/2008 2:18:20 PM): if canTrain() if connected: solid else: grey elif canTrain(False) -- the one that checks if *could* train with rsrc grey else: hidden
ruff_hi (7/10/2008 2:18:23 PM): yes - the cantrain has a paramater that controls if it cares about the resource

We tried to grey out the icons but the mechanism we are using to add the icons (appendmultilistButton) doesn't seem to like us. It has the ability to have enabled / disabled icons but (for reasons unknown), the icons look exactly the same on our screen. Don't tell me that they are different under the city screen - we know - we just don't know why.

Anyway, we've decided to add a '?' icon at the front of the list when you are unsure of the resources (iron, etc). I'll post some examples after we have it in the system.
 
I've updated the code, pulled up one of my test games, gave someone (the bottom guy) all the techs and checked the sit rep ...



I then declared war (note, he has some vassals) ...



2 things jump out at me ... I can build riflemen but he can build infantry. However, as I don't know that he can build infantry, sit-rep is showing I have the advantage with riflemen. Do we want to leave that in - or is removing riflemen a spoiler?

2nd - I declare war and now I have an advantage due to ivory? I'll have to dig into the game to see what the elephant situation is pre war.
 
I see a few strange things.

1. Why can you build Maceman, UU Pikeman, and Crossbowman now that you have Rifling? I do tend to follow a very similar tech path each game (except my current game, but I haven't reached Rifling yet), so maybe this is possible. I usually hold off on Military Science (Grenadier) until much later (trade), so your lack of it shouldn't be an issue.

2. War Elephants should show up as gray for the vassals because you don't know if they have Ivory or not, but you do know they have the tech to build it. This points out a case we hadn't covered: when you can build something that they might be able to build if they have the resource. Or maybe you did think of it.

3. Zara has Infantry, but you don't have the techs required to know that he has them. Fine, but you do know that he has Rifling, so why is Rifleman (and indeed the units in (1) above) displayed for you?
 
yeah - all good questions. Something is logically wrong with this. I'll dig into it.
 
1. Why can you build Maceman, UU Pikeman, and Crossbowman now that you have Rifling?

Because you can. You'd think I would get used to the idea, but I think what happens is that once I get Rifling I never consider building these other units. It's only in the early game when I want to build Warrior instead of Axeman or Spearman, but then of course I cannot. :crazyeye:

I guess that since these units can upgrade to Grenadier you can continue to build them.
 
Issues to be investigated ...
1) where did the elephant come from?
2) our riflemen v Zaya's infantry.

Mr Magic Elephant
Well, this is an easy one. I made a mistake with the 'canTrain' function - got the true / false conditions around the wrong way.

Here is Asoka's units that he can train ...
MA SitRep Unit List - Indian Empire (with the non unique units crossed out)
Maceman
Knight
Pikeman - upgrades to rifleman
Caravel
Musketman
Catapult
Trebuchet
Trireme
Longbowman - upgrades to rifleman
Crossbowman
Galleon

And the list that the player can train ...
MA SitRep Unit List (Human) - Holy Roman Empire (with the non unique units crossed out)
Maceman
Knight
Landsknecht
War Elephant
Rifleman
Catapult
Trebuchet
Trireme
Caravel
Crossbowman
Galleon

The actual picture shows Landsknecht, War Elephant, Rifleman for the human and nothing for Asoka.

Now - if I declare war, I lose my trade information about Asoka. Thus, I don't know that he cannot build a War Elephant and I should lose that as a strategic advantage.

I don't think that this is correct.

If resource trading is available, then the current situation works. If resource trading is not available then it doesn't. I think that all units that require a resource should be placed after the '?' sign regardless of which strat adv (ours or theirs) it is.

In this way, the war elephant would be moved after the '?', Asoka would also gain a war elephant icon after the '?' - indicating that both leaders have the technology, but the resource situation is unknown.
 
If resource trading is not available then it doesn't. I think that all units that require a resource should be placed after the '?' sign regardless of which strat adv (ours or theirs) it is.
That isn't going to work as there is no way that I can easily tell if a unit requires a resource. In the case of the elephant, I've changed to code to just remove the icon - you know that the AI has the tech to build the war elephant - you just don't know if he has the resources - thus this unit might or might not be a strategic advantage to you.

Fixed the rifleman / infantry issue. We were removing all units where the player didn't know (or couldn't research) the required tech - thus causing the problem. I removed that code and left those units in. Now, when we are looping through the AIs advantage, we check if the human knows the tech (or can research) before displaying the unit icon.
 
I've recoded how Strategic Advantages are chosen, and I'm almost done with the last piece: using rival cities to choose whether or not the player can tell for sure that a rival unit can build the unit.

I had to code my own implementation of CyCity's canTrain() function, and it's working fine so far. I just need some input on how exact to make it. Also, does anyone know how much information is revealed about cities that you have seen at some point but remain in the fog of war?

For example, if you see Thebes once, will it update to show you the religions and corporations that get spread to it even when it remains in the fog of war? I seem to recall that this is what happens, but I do not know for sure. Does anyone know the actual rule or has looked at the code?

Another issue is with training ships. I can check if you have seen a city. I can check if the city should be able to build ships. I cannot easily check if you should be able to tell yourself if the city should be able to build ships. The game rule is that it has access to a water area of at least X units large (depends on the unit, but typically 20).

As humans we can scan the tiles around the city and figure it out, but I'd rather not code up that logic. So the easy way out is that if you can see at least one water tile adjacent to the city, allow you to know if that city can build ships or not. Another easy option is to assume the city can build ships if it has at least one adjacent water tile, even if it's too small. The last option is to always show ships as "possible" Strat. Adv. (after the ? icon).

Let's summarize:

  • Use code to check when water visible: possible spoiler, perfect UI
  • Assume buildability when water visible: no spoiler, possibly incorrect UI for maps with lots of lakes and no ocean
  • Assume no ship building ever: no spoiler, likely incorrect UI
Those are the only cases where I need to make a decision whether or not to use the API to get the actual information about a city:

  • Religions
  • Corporations
  • Water
Once we decide these issues, it's as good as done. :D
 
Also, does anyone know how much information is revealed about cities that you have seen at some point but remain in the fog of war?

For example, if you see Thebes once, will it update to show you the religions and corporations that get spread to it even when it remains in the fog of war? I seem to recall that this is what happens, but I do not know for sure. Does anyone know the actual rule or has looked at the code?

I haven't looked at the code (and am not even sure if I can since the graphics and citybar appear to be handled almost exclusively by the engine) but from testing by giving free missionaries and corp execs to an AI whose cities are in the fog, the religious and corp icons do indeed update. The pop number and buildings are also accurate.
 
The pop number and buildings are also accurate.

Oh, I hadn't even considered allowing you to know about the buildings. I can spot some of the larger buildings, but many escape me. Are all of the buildings visible, or do some not get drawn (even in your cities) due to space requirements?

Thanks for the confirmation of the religion and corps. This is my recollection as well, so I'll code it that way.

What about the water units? That's the only one that really needs input from others as we need to make an information leak versus UI correctness decision.
 
My understanding is that they are supposed to be there. At least every time I've zoomed in on one of my large cities and tried to locate a certain building, I've been able to find it. Sometimes they can be hard to actually see if they are behind larger buildings or blocked by terrain though.

However, after doing some testing it looks like population also seems to play a role. If I WB a size 1 city with a crapload of stuff, not all of it seems to show, but if I crank the pop to 20 all the missing stuff miraculously appears. So perhaps we should assume buildings are not reliable enough to be known.

As for water units, we can tell whether the visible water tile is fresh or salt water, right? How about if there's an adjacent tile that satisfies
Code:
pPlot.isWater() and not pPlot.isLake()
then we assume ships can be built? Could still be potentially incorrect but if I had to eyeball a city on a map, that would probably be my test.
 
As for water units, we can tell whether the visible water tile is fresh or salt water, right? How about if there's an adjacent tile that satisfies
Code:
pPlot.isWater() and not pPlot.isLake()
then we assume ships can be built? Could still be potentially incorrect but if I had to eyeball a city on a map, that would probably be my test.

Yes, I like that a lot. :goodjob:

Without checking the code, I seem to recall that a body of water is a lake if the number of tiles it contains is 10 or less (or less than 10, whatever). Given that most ships (eyeball test) have 20 as the minimum area size, we'll show incorrect information occasionally still. However, this is a much smaller error than above.
 
Top Bottom