Planning for Demos 7 & 8

[LDiCesare]

For D7, I propose that we put the relevant parts of military and technology files into the scenario files (the civilizations are already done that way).

I will try it. I agree that the files should be per scenario. The way civ2 handles things, with an event.txt, a rules.txt, etc. is quite good, although rules contains too many things. It allows for easier modding and scenario installation. I would like to point out that the images xml file may need some scenario-specifics too. Just think what does a modder do? Mainly draw a map, fill it, add images (sounds, movies...), military units, modify techs, set up events. This requires a separate, scenario-specific file for the map, its content (can be a save game), images, military, tech. All these it must be possible to add to without editing a reference file.
Putting everything in a single file is OK considering xml is easy to browse, but I don't like it. Scenarios will often need images, so it will be a zip anyway. I think I'd like a folder for scenario files better.

About population: Considering it is a win condition, I'd like to see it on top. It is really not intuitive to search for it in econ frames. Actually, I think a report of all victory conditions, where it makes sense, should be available every time one wants them. For instance, you could know your population, the number of objective cities you control, your treasury, ... at a glance. In civ2, there is a panel for that (civ score), though you have to save/quit/reload to see the power graph.

[Mark_Everson]

Originally posted by LDiCesare
About population: Considering it is a win condition, I'd like to see it on top. It is really not intuitive to search for it in econ frames. Actually, I think a report of all victory conditions, where it makes sense, should be available every time one wants them. For instance, you could know your population, the number of objective cities you control, your treasury, ... at a glance. In civ2, there is a panel for that (civ score), though you have to save/quit/reload to see the power graph.

Hi Laurent:

I agree longer-term with doing a good job on this area. Do you have a proposal for what to do for D7? We could for example use the events box as Gary suggested, and just have the info you describe come up in the detailed version. One other idea I had is to show total population in the Details box at the lower left of the screen in the blank space beneath the tile image. The balance of victory conditions plus population could be shown in a Victory Condition item in the event box. It could say "Victory Conditions: 0 of 3" meaning that you have achieved 0 of the three conditions.

[Lemmy]

have you considered making the demo fullscreen?
it would give you more space to show all the info..

[Richard Bruns]

I think that I had always sort of assumed that each scenario would have its own individual tech tree. I fully support making a seperate tree for each scenario. This will be the best way to eliminate the difficulty we've had with the differences in tech growth in the two scenarios. If each scenario has its own individual tech tree, all we have to do is change the global growth rate and upkeep so that the big Roman civ grows as fast as the small Dawn civ.

[Gary Thomas]

Another portmanteau response.

Mark:

"Difficulty levels" as in the sort of nonsense in civilization are in fact a long-term goal of mine. I want to be able to play a whole-history game, and be able to give any arbitrary advantages to the computer players that I deem necessary. If I spend a good chunk of a decade working on Clash, and can beat it every time, I will consider it an utter waste of my time.

If that happens, then the scenario is badly designed - correct the faults in the scenario and try again.

On your third post, covering global data files vs. scenario-specific ones, I still, as in the past, prefer the global ones.

I would point out that you are the ONLY one with this view, and have NEVER advanced any reasons in favour of it. Are there any?

However, if you are willing to code this central warehouse in which a catalog of items can be kept and drawn upon for scenarios, my objections are a lot less severe.

I understood that some of the new coders were approaching the matter of a scenario editor. I am prepared to arrange a design, but not, at present, code an editor. The same effect can be achieved by copying the appropriate code into each scenario (there are only two).

Laurent and Richard (if he cares) are the major stakeholders in the current approach. I guess if they go along I've got no big problem with it.

I understand that both of them agree with my approach.

I frankly think your arguments by-hyperbole about 10,000 types of units are stretched extremely thin.

Do you want me to list them?

I have to be honest in that there are a lot of things I would prefer to see before save and restore games. Getting the tech and government models, which are very far along, actually working in the game and with interfaces come to mind. I have never yet had a desire to save the game of Clash because simply not very much happens so far. Until we get to the point where a single game can hold someone's interest for more than a half hour, I maintain there is little point in save games. The only exception I can think of is if those save games are supposed to serve as scenarios for others. Axi is also hot on getting save games, and it's still eludes me why the two of you want them at this point.

I don't want it - I dread it. But the longer it is put off, the worse the resulting chaos will be. I direct your attention to the difficulties we had in adapting existing and simple code in the economic model to be able to be read in from an xml file. By casually dismissing critical infrastructure considerations, unless you are prepared to accept that games will never be saved or restored you are gratuitously adding a substantial amount of work for some poor coder (probably me) to have to cope with in the future. On the other hand, if you are prepared to accept that games will never be saved or restored, I will not mention the matter again.

As to the specifics of your save game plan, I've expressed my reservations with various parts of it when it was discussed earlier this year. It seems to me that keeping track of "what has changed" will require an enormous amount of code infrastructure that is much more likely to generate huge amounts of bugs and code confusion than anything a difficulty levels system could.

I suggest that I am the expert in this area, and that your estimate of likelihood is incorrect. The complexity is in saving/restoring at all, not in how it is done. I do agree that saving/restoring is more complex than implementing difficulty levels. Which, however, do you think is more important? It seems to me that your estimate of huge amounts of bugs and code is a demonstration that you have not considered the matter in any but the most superficial manner.

I have to admit that the concept is intriguing. Frequently however there are very good reasons why nobody else does it a particular way...

For example:

• *They haven't thought of it
  *They don't know how to implement it
  *The money people say "stick to the tried and true - anything that isn't a close clone of Civilization 1 is unsafe"

It occurred to me while I was mowing the lawn today that there are no economic specials of any sort in either of the scenarios. (Aside from the possibility of making in Dawn either horse or wheat or both specials in an economic sense.) I seem to recall that you were pretty much ready for specials quite a while ago in the XML. Is there any reason I can't grab some of gar's images and put some specials in our scenarios? If I am overly-favorably remembering where progress is in this area, I'm willing to skip it. But if everything's basically done I'd like to go forward with it. I may even be able to do something with merchants on a quick basis... and would like to if I can come up with something worthy of the player's notice. Anybody got any good ideas on this?

As far as I know it is all there. On the other hand, anything to do with economics code scares me spitless...

Laurent

I will try it. I agree that the files should be per scenario.

Mark take note.

The way civ2 handles things, with an event.txt, a rules.txt, etc. is quite good, although rules contains too many things. It allows for easier modding and scenario installation.

Combined with a proper scenario editor we would have a good system.

I would like to point out that the images xml file may need some scenario-specifics too.

I agree, and have this in my sights.

Just think what does a modder do? Mainly draw a map, fill it, add images (sounds, movies...), military units, modify techs, set up events. This requires a separate, scenario-specific file for the map, its content (can be a save game), images, military, tech. All these it must be possible to add to without editing a reference file.
Putting everything in a single file is OK considering xml is easy to browse, but I don't like it. Scenarios will often need images, so it will be a zip anyway. I think I'd like a folder for scenario files better.

I had in mind a zipped directory tree. It all has to be read in to the program anyway.

About population: Considering it is a win condition, I'd like to see it on top. It is really not intuitive to search for it in econ frames. Actually, I think a report of all victory conditions, where it makes sense, should be available every time one wants them. For instance, you could know your population, the number of objective cities you control, your treasury, ... at a glance. In civ2, there is a panel for that (civ score), though you have to save/quit/reload to see the power graph.

Again, I agree completely. It is just a matter of getting around to doing it.

Lemmy:

have you considered making the demo fullscreen?

Yes, and rejected it out of hand. Personally I have not ever seen any valid reason for doing this. It makes it harder to do other things while the game is running, and harder to hide the game when your boss (or wife) walks into the room. You can't just iconize it while you answer your email, and so forth.

it would give you more space to show all the info..

No it wouldn't, all you get is the little frame round the outside.

Richard:

I think that I had always sort of assumed that each scenario would have its own individual tech tree. I fully support making a seperate tree for each scenario. This will be the best way to eliminate the difficulty we've had with the differences in tech growth in the two scenarios. If each scenario has its own individual tech tree, all we have to do is change the global growth rate and upkeep so that the big Roman civ grows as fast as the small Dawn civ.

Thanks Richard. Mark, please take note.

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
Another portmanteau response.

For this culturally challenged Yank, what does that mean? Sorry, but I will have to defer my responses to your various questions and demands that I state my point of view until later...


I've only got a little bit of time, and want to get my revised to-do lists up for debate, and four people to pick their own assignments. This should explicitly not include Gary, since he already has an entirely too large list of things he needs to do. I'm going to put the latest versions of the full bugs and features lists up in the demo seven testbed for now, although I may not get to it tonight. The updated demo 7 to do lists will go after this post. Man, my dictation programs really doing lousy today, and I don't have time to fix all the errors, so please bear with me.

I understood that some of the new coders were approaching the matter of a scenario editor. I am prepared to arrange a design, but not, at present, code an editor. The same effect can be achieved by copying the appropriate code into each scenario (there are only two).

I hadn't meant to give the impression that I expected the "scenario generation warehouse" anytime soon. As you say, we'll be limited to a handful of scenarios for the near future, so it would not really be needed. None of the new coders are trying to scenario editor, AFAIK I just put that up as an example for something someone might care to do. It's in the "small projects" area of the to do list. There is a new guy named Richard coming online, but he expressed interest in bugs fixing, and since we have in excess of need of those particular activities right now, I thought bug fixes would be a good thing for him to start out on.

[Mark_Everson]

Updated D7 todo list -- Bug-hunters wanted!

D7 todo list v5 - June 11

The list is not in priority order. A preponderance of the items are discussed in posts in the D7&8 thread if the short version doesn't make it clear what needs to be done. X = done. I have eliminated most of the old ones that have been taken care of, and only leave Xs if some small part remains to be done.

Numbering scheme changes after 18 to that in bugs and features lists, any further D7 todos will go in either the bugs (- prefix on number) or feature list (f prefix) and be handled with those numbering schemes.

If anyone wants to sign up for particular bugs, just list the number(s) you want to go after. Some of you new coders could help with this when you finish or want a break from your starting projects.

Comments, criticisms, and suggestions for additions and deletions welcome!

2. Ship boarding GUI (Gary)

3. Small AI improvements per my suggestions in the D7&8 thread (I'll do this if nobody else takes it)
Plus AI takes over just plain squares once cities taken (Mark)
More AI stuff detailed below.

6. As far as indicating that units have settlers, I have tracked down a wagon picture and will arrange it as a small overlay on a settler carrying unit. Done on map, needs to be done in Units Box (Gary)

7. Dawn tutorial (Dale)
(some requests for manual description in feature doc at bottom, prefixed with 'M' for manual/tutorial)

8. Use events to put barb incursions into Dawn1 (Gary)

9. use discovery of the horses tile plus generation of horse technology research points (say once you settle the horse square, or given as a big blob of RPs upon discovery (Gary)

10. specify technology levels for civs at the start of the scenario. The Dawn scenario is pretty much ok starting at minimum tech levels, but levels for many techs in delenda should start near a value of 10 or so. (Gary)

11. Victory Conditions Dawn1 - add achieving building of a chariot unit (Gary)

12. Give civs default economic orders that will use their production capacity effectively. (Gary for xml, Mark for specific orders )
Gary said: Mark, if you would write out for me the GovtEconOrdersInfo calls needed to achieve this (with a single float parameter where needed) I will add them to BuildingOrders. This seems to me to be the only way this can be achieved for D7.

13. Difficulty levels as separate scenarios for now. FE Dawn1 and "Dawn1 Hard". There may need to be two versions of the Hard one in Delenda, since there could be a "hard playing Romans", and similarly for the other side. (Mark)

14. Even though Hannibal is a large task force/command with phalanx and light horse components, the light horse always outruns the phalanx, giving Hannibal much less odds than would be the case if the TF moved together. I think that's a bug it's important to change to give the AI some punch. Another confusing feature of this behavior is that when you click on a square with any component of the Hannibal force, you see the whole thing. (Mark or Gary if I can't figure it out!)
Gary said: Make sure that they are put in the same task force. If they still outrun, it is a bug which I will attack.

15. Another AI problem was that sometimes AI forces just sat there even when there were plenty of city targets available. (Mark or Gary)

-----------------------------------

Numbering scheme changes here to that in bugs and features lists, any further D7 todos will go in either the bugs (- prefix on number) or feature list (f prefix). Name in parentheses at beginning is person who identified/requested the bug or feature. Name in brackets at end is person who has taken on fixing it. Volunteers needed!

-125 Next TF button doesn’t work if no TF is selected. Should go to some TF to start if none selected. Perhaps TF closest to current selected square? [medium priority, D7] *** [Mark]

X -129 Got message that roads were planned but none set aside even though I did have an order for road building, and was part way through building one. I had other orders that preempted it. [med D7] ***[Mark]

X -138 Pop-up box that says roads were planned but none set aside is really annoying, and for unknown reasons I sometimes get it nearly every turn even when funds are allocated and not all roads are built. Please change this message to an Econ Event [medium priority, D7] ***[Mark]

-141. (Axi) Pathfinding doesn't seem to take advantage of roads. [high, D7] ***

-144 (Richard) The "Move to nearest enemy" should be recalculated every turn. Now they just go to where the unit was when tne order was given.[medium, D7] ***

-150 make education do something in terms of generating RPs [medium, D7] ***[Mark]

-151 remove Econ Options item on toolbar, since it does nothing. [medium, D7] ***

-152 either eliminate Ruler button or mark gui as "Don't Touch, for Display Only" or some such [high D7] ***

f72 Economic consequences of battle -- The two armies share the square, fighting every turn. But there seem to be no economic consequences to this raging battle. [medium D7 feature, mark will try to implement] ***[Mark]

f127 Minimum power circle size is a bit too large. I can’t tell from PC if there are one or two full-strength legions in a square. Suggest minimum be shrunk to about 2/3 of current minimum. [high priority, Mark is happy to do if you tell me where it is..] ***[Mark]

f149 (Richard) There should be some kind of home field advantage. Cities fall over way too easily. Maybe in city battles we should generate free horde units to represent militia. When the city is attacked, the units join the defending TF. Then they return to civilian life when the battle is over. [medium priority d7, we have talked recently about an auto-mustered militia]. ***[Mark]

F150 (Richard) The "Move to nearest enemy" should be recalculated every turn. Now they just go to where the unit was when tne order was given. [med D7] ***

F151 Road building delay needed, so roads can't be flash-built. Also way to figure out how much resources to use... Too long to duplicate here, see feature list.

f159 (stickdude) I don't know how far along the economic model is, but it would be nice to see some highlights in the "Information frame" at the end of each turn, like income, spending, and current cash balance, units to be produced next turn, etc. [med d7] ***[Mark]

-----------------------------------


Small coding projects

map editor

xml editor

[Mark_Everson]

One of many responses to Gary's issues. I propose that if we go any further on the topic we dig up or create a thread on scenarios so this discussion doesn't get lost later on...

I said:
On your third post, covering global data files vs. scenario-specific ones, I still, as in the past, prefer the global ones.

Gary said:
I would point out that you are the ONLY one with this view, and have NEVER advanced any reasons in favour of it. Are there any?

Gary:

While I never did IIRC explicitly advance reasons in favor of my approach, I have, in fact, expressed my reasons why your preferred way wasn't necessary. That's in an email exchange with you that is at the bottom of this post.

I think the main difference between us on this is that you believe that if there is a core global file that Everything in the whole game that ever could happen in any scenario must be in it. That is where what I interpreted as argument by hyperbole with the 10,000 units and all came in. It might be that your interpretation of the global is the only possible way to do it with the existing code... But generally my view was that the "global" data is what is needed for a core whole-history game a la civ. Only the core tech tree, units (maybe 500), economic info, etc. would go in that.

Individual scenarios would then have two paths in my view:
1. use the core file but tweak it by adding something, or defining something doesn't exist. 2. start from scratch in the scenario file and ignore the core global data.

This approach would make it easy IMO for those who just want to tweak the core whole-history game with a compact scenario file. It seems based on our discussion of regimes in the quoted email below that one can do it this way with the existing parser at least for regimes, and my thought was it could be generalized. FE for the Dawn scenario Richard's point about making a given tech change come from a lesser amount of RPs than in Delenda could be accomplished by having the Dawn scenario file overwrite the global that defines tech growth from RPs.

It seems that the scenario genration warehouse would satisfy most of my concerns about what I thought was your approach. And I admit it does have the advantage of encapsulating the xml. Since everyone else has agreed on it, I'll shut up on the topic.

Email conversation c. Feb 8 2002
Gary said:

My dislike of the regimes being globally specified, as opposed to
specified
per scenario, is logistical. Suppose Jack invents a neat new
scenario that
requires a Martian Madness regime, He modifies the global file to add
>it. Then John makes a scenario which requires a Freds Fantasy regime. So he adds
that to his file. Then Philbert expresses an interest in both these
scenarios, and asks for them. Jack's files arrive first and Philbert duly
installs them. Then John's files arrive and he installs them. Whoops, Freds
Fantasy has over-written Martian Madness, but done so in an unannounced and
generally invisible way. What happens is that when he tries to run Jack's
scenario, it cocks up in an unpredicatable manner.

Mark:
>
>I already said that scenario-specific regimes should be read
>in from the Scenario file!!! You may have missed it amongst the pages of
>prose that have passed between us recently... IMO Standard regimes go in
>the social xml file (or government or whatever) and scenario-specific ones
>go in the scenario. If the names are the same the scenario one should win,
>allowing designers to alter the standard ones in their scenario only.

G:
But aren't ALL regimes scenario specific? If you have an ancient scenario,
why do you need Italian Fascism or whatever?

M:
>So what? Italian Fascism will never be known to the people, never become
>active in the scenario... I think its simpler that way rather than always
>having to add standard regimes to Every scenario. But if you're so sure
>you're right, go ahead. Its not a vital issue, and can be easily fixed
>later when you see the error of your ways! ;-)

G:
My problem has been that I either have the xml read in a regime, or a regime
name. We can't have both because of the way the parser works. However, it
has occurred to me the if the tag was if it was a reference to
a standard regime, and if it was followed by an actual regime
specification. Since the regime readin already works. Though I notice that
in the SocialModel.xml, most of the regimes are just copies of the merchant
prince one. Would that differing tag system be OK?

M:
>OK, if the flexibility is still there, then I have no objections to doing
>it your way!

G:
Actually, I am doing it your way! I might change it one day...

[back to the present] And that day seems to have arrived

[LDiCesare]

Mark,

1. use the core file but tweak it by adding something, or defining something doesn't exist.

Doesn't work as it doesn't allow you to remove stuff.

2. start from scratch in the scenario file and ignore the core global data.

Yes, but how do you specifically ignore it? You have to say that instead of using file ZZZ.xml you use either nothing (i.e. everything is in the scenario file) or a new file. This effectively makes the ZZZ.xml file "optional", as you could say: <militaryResoure>military.xml</militaryResoure> to say you do want the default file. But then, it is as easy to replace that in the scenario by <militaryResoure>myMilitary.xml</militaryResoure>.

If I understand well, Mark wants a ZZZ.xml file with all the standard stuff in it. Gary says this is actually a particular scenario file, and shouldn't be imposed onto other scenarios. I am not clear whether Gary wants the file to disappear and be included in the scenario file instead. I would like the "default" files to remain, but the scenario would have the option of pointing to it. Just precise somewhere in the scenario file which other files you want to read. Since we'd have to make the scenario a zip because of the images, I'd rather have several files if I could because I could reuse some from one scenario to another (typical case being enriching an existing scenario, like just adding three units in the civ2 rules.txt).

[Gary Thomas]

If I understand well, Mark wants a ZZZ.xml file with all the standard stuff in it. Gary says this is actually a particular scenario file, and shouldn't be imposed onto other scenarios. I am not clear whether Gary wants the file to disappear and be included in the scenario file instead. I would like the "default" files to remain, but the scenario would have the option of pointing to it. Just precise somewhere in the scenario file which other files you want to read. Since we'd have to make the scenario a zip because of the images, I'd rather have several files if I could because I could reuse some from one scenario to another (typical case being enriching an existing scenario, like just adding three units in the civ2 rules.txt).

Well, as I understand it, Mark wants some one scenario to have special status, and to be read in every time, then ignored or modified in almost every case. This seems to be based on the notion that it is easier to a have small modification file to produce another scenario, rather than merely copying and modifying the base scenario.

He is wrong. Merging 2 files is always going to be more complex than operating from a single file. This complexity is not just in the code, but in the difficulties of the scenario designer keeping everything in hand.

My perception of the ultimate goal for scenario design has a scenario editor which has a series of available base scenarios (perhaps twenty) covering a number of interesting possibilities: random map or earth map, actual historical civilizations (Americans in 4000BC anyone?) or possible ones based on culture, various levels of events and so forth. The notion that there is a single whole history scenario is wrong. It cannot even be considered until we have some idea of how new civilizations appear. A whole history scenario becomes another Civilization clone - you are the French in 4000BC, led by Joan of Arc, for heavens sake, and you have to survive to 2050AD.

Careful thought leads me to the conclusion that the only civilization that existed in 4000BC and which still exists is the Laplanders. They win! Even without spaceships.

I still believe very strongly that every scenario file should be self-contained, "Hey, Fred, here's my new Tierra del Fuego takes over the World scenario", a single file, not dependent on modifications to somebody else's core files, and not corrupted by them

I like, rightly or wrongly, to think that most of the things I advocate are based on simplicity, maintainability and a minimum of code breaking dependencies. Not on some vaguely expressed notion that a substantial number of modified files is better than a single file, because it might save somebody some time somewhere somehow. Maybe.

Cheers

[Gary Thomas]

D7 todo list v5 - June 11, my comments on my chores. Done a few more things since I wrote this, so edited.

2. Ship boarding GUI (Gary)

Still meditating on the A* algoritm. Probably, as Mark suggested somewhere, D7.1.

6. As far as indicating that units have settlers, I have tracked down a wagon picture and will arrange it as a small overlay on a settler carrying unit. Done on map, needs to be done in Units Box (Gary)

Done in my code.

8. Use events to put barb incursions into Dawn1 (Gary)

Done in my code.

9. use discovery of the horses tile plus generation of horse technology research points (say once you settle the horse square, or given as a big blob of RPs upon discovery (Gary)

Done, both activate the technology and add research points - two different possible actions.

10. specify technology levels for civs at the start of the scenario. The Dawn scenario is pretty much ok starting at minimum tech levels, but levels for many techs in delenda should start near a value of 10 or so. (Gary)

This is done in the sense that the technology file has this option. I am not at all happy about writing a lot of code so an existing technology is modified. In effect, if we move to per scenario files, this will be done, otherwise not.

11. Victory Conditions Dawn1 - add achieving building of a chariot unit (Gary)

Next job.

12. Give civs default economic orders that will use their production capacity effectively. (Gary for xml, Mark for specific orders )
Gary said: Mark, if you would write out for me the GovtEconOrdersInfo calls needed to achieve this (with a single float parameter where needed) I will add them to BuildingOrders. This seems to me to be the only way this can be achieved for D7.

Waiting on Mark.

14. Even though Hannibal is a large task force/command with phalanx and light horse components, the light horse always outruns the phalanx, giving Hannibal much less odds than would be the case if the TF moved together. I think that's a bug it's important to change to give the AI some punch. Another confusing feature of this behavior is that when you click on a square with any component of the Hannibal force, you see the whole thing. (Mark or Gary if I can't figure it out!)
Gary said: Make sure that they are put in the same task force. If they still outrun, it is a bug which I will attack.

Will check this.

15. Another AI problem was that sometimes AI forces just sat there even when there were plenty of city targets available. (Mark or Gary)

Will think about this on alternate Tuesdays if the wind is from the West.

-125 Next TF button doesn’t work if no TF is selected. Should go to some TF to start if none selected. Perhaps TF closest to current selected square? [medium priority, D7] *** [Mark]

There was a bug in the code which is now fixed. The program now selects the largest task force if none is selected.

X -138 Pop-up box that says roads were planned but none set aside is really annoying, and for unknown reasons I sometimes get it nearly every turn even when funds are allocated and not all roads are built. Please change this message to an Econ Event [medium priority, D7] ***[Mark]

The bug should be fixed, but I always forget to set aside money for roads, so I need it. I suspect that most people are like me.

-141. (Axi) Pathfinding doesn't seem to take advantage of roads. [high, D7] ***

Will need to check this.

-144 (Richard) The "Move to nearest enemy" should be recalculated every turn. Now they just go to where the unit was when tne order was given.[medium, D7] ***

As I explained long ago the reason for this is to stop the following tactic:

• *Put a single light cavalry unit nearest to the enemy.
  *Wait until they start following it.
  *Lead them off into the blue yonder somewhere.
  *Clobber their cities.

Unless the change has a solution to this problem, DON'T DO IT!

-151 remove Econ Options item on toolbar, since it does nothing. [medium, D7] ***

Will do.

-152 either eliminate Ruler button or mark gui as "Don't Touch, for Display Only" or some such [high D7] ***

Why?

f127 Minimum power circle size is a bit too large. I can’t tell from PC if there are one or two full-strength legions in a square. Suggest minimum be shrunk to about 2/3 of current minimum. [high priority, Mark is happy to do if you tell me where it is..] ***[Mark]

I will do it. In fact I have done it in my code.

f149 (Richard) There should be some kind of home field advantage. Cities fall over way too easily. Maybe in city battles we should generate free horde units to represent militia. When the city is attacked, the units join the defending TF. Then they return to civilian life when the battle is over. [medium priority d7, we have talked recently about an auto-mustered militia]. ***[Mark]

I am really keen on this.

F150 (Richard) The "Move to nearest enemy" should be recalculated every turn. Now they just go to where the unit was when tne order was given. [med D7] ***

Close resemblance to -144

F151 Road building delay needed, so roads can't be flash-built. Also way to figure out how much resources to use... Too long to duplicate here, see feature list.

I always wanted this. There should be a labour resource too.

To this list I will add something that I intend to do anyway - upgrade the Attila scenario and release that with D7. I have to get some fun out of this.

Cheers

[Gary Thomas]

What about getting rid of the confusing map square economy gui for D7?

Cheers

[Gary Thomas]

I fixed the settler wagon bug, and put the wagon behind the figure where it annoys me less.

Cheers

[Gary Thomas]

quote:

11. Victory Conditions Dawn1 - add achieving building of a chariot unit (Gary)

Next job.

Done as an event (not a Victory condition). We might not want to end the scenario at that point - what about using the chariot to wipe out the barabarians?

To make it a victory condition:

<buildunitevent>
  <unit>
    chariot
  </unit>
  <savecondition>
    <condition>
      builtchariot
    </condition>
  </savecondition>
</buildunitevent>
<victory>
  <win>
    <conditionending>
      builtchariot
    </conditionending>
  </win>
</victory>

Cheers

[Gary Thomas]

Yet another post!

This is a quote from an email from me to the coders:

Also will add a Bulletin class like the display, but using HTML code, so Dale's pretty messages will appear properly

I forgot to add this to the list. It is quite important, and the next job for me.

Cheers