ruff_hi
Live 4ever! Or die trying
I tried both of those differences to zero change in the unit icon.
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". 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.
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
This is really good to listen!
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! ).
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.
English lesson of the day: You listen to someone so that you can hear them speak. So it's "good to hear."
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
1. Why can you build Maceman, UU Pikeman, and Crossbowman now that you have Rifling?
since these units can upgrade to Grenadier you can continue to build them
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.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.
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?
The pop number and buildings are also accurate.
pPlot.isWater() and not pPlot.isLake()
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
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.Code:pPlot.isWater() and not pPlot.isLake()