Military Model VI

[LDiCesare]

Excerpt from the code:

private boolean tookTooMuchDamage()
{
if (isMilitia())
return false;
UnitClass unit = (UnitClass)getUnit();
float personnel = unit.getArchetype().getManpower(unitType);
if (manPower * (1f + getMorale()/20f) < (personnel/10f))
return true;
return false;
}

That doesn't seem to have a lot of effect. Everytime an element is damaged, this check is done and the element will die. This is already in as of current code you got, but has little impact. The formula is thus this one:
If current health < max health / (10 * (1 + morale/20)), then die. Morale is on average 10, so that translates to:
maw health / 15. For elephants (morale 4) it's max / 12. I will change that to max health/morale. Morale of 1 or less will be treated as 1. Thus it will be easy to mod things, just change the morale to set the threshold.

Also, I've set a -nopatrol command-line switch. If not enabled, then militia will raise to help the defender even if they are not the same ethnicity or there's no discrimination.

[LDiCesare]

That code was right except the getMorale multiplied morale by personnel, so it was squared, which explains why it never worked properly. It's now way better. I made the simpler personnal > manpower * morale check as it's easier to tune through resources/scenario files than the previous formula.
My first test showed this works well. I managed to get rid of Hannibal in a reasonable time. The bad news for Rome is that Carthage foudn out all by itself it should build siege weapons and they breached the walls I had built in Marsaglia. First time I see them do that in this scenario. I'm quite happy with it. The Romans may not, though.

[Mark_Everson]

Hi Laurent:

Your mod sound great, and I look forward to checking them out.

Originally posted by LDiCesare
Also, I've set a -nopatrol command-line switch. If not enabled, then militia will raise to help the defender even if they are not the same ethnicity or there's no discrimination.

The switch availability sounds really good. I'm not sure I can parse your short statement correctly. It reads fine until the "no discrimination" part. Could you be more explicit in the effect discrimination has on militia support of defenders?

[LDiCesare]

Militia is raised if they have a chance to make win the party they support. That party is chosen as follows among the 2 fighting civs:
If one civ has ethnic + religious discrimination against a particular ethnic group, that group will fight for the civ whose total discrimination is twice as low or lower than the other. So if you have discriminations of 10 for one civ and 24 for the other, the EG will help the civ that discriminates less (10). If both are 0 or if they are similar (say 10 and 12), the EG won't help.
Then if the EG is the preferred ethnicity of a given civ, it'll help that civ. This may cause problems with civil wars, so I start checking the defending civ first.
Without the switch, the militia will then systematically try to help defenders if it didn't decide otherwise with the previous checks.

[Mark_Everson]

Thanks Laurent:

That sounds good for a first cut and it. The only suggestion I would make is that it should be either double, or a difference of twenty points (Or something like that) in discrimination that triggers a preference. Otherwise the relatively small difference between twenty and ten is found to be more significant than the difference between seventy and forty discrimination level which is at least as important.

[LDiCesare]

Yes a minimum would do.

[alms66]

Can someone give me a detailed example of how movement works?

I've asked Laurent, he gave me this:

This is strategic movement. The exact cost in movement points depends on the
square cost: For instance flat terrain has a movement cost of 2. Now what these
values mean or are is, to me, frankly weird (I didn't code that part): Code
excerpt:
* Calculate the raw (road level) ticks for an archetype. The movement value
* is the distance, in kms, the element can travel in one day. Each turn is
* 30 days and each tick three days. Each square (measured orthogonally)
* is 100km.
float movement = archetype.getMovement().getBaseLevel();
(horrible stuff removed)
float ticks = 100F / (3F * movement); (...)
ticks /= 2F;
There are other factors which make the resul very fuzzy. I guess 17 means 17
kms/day...

But that doesn't really do it for me...

[Mark_Everson]

Alms:

You could try Gary on the movement code. I'm not in any way familiar with that code. You could just look over the code yourself, and if you figure it out, let us know.

Sorry I can't be more help. . .

[alms66]

This is something I'd like to have, though since it may or may not be demo 8.1 material, I'll put it here.

Note that this isn’t vital to continuing the Tech Test scenario, it’s just something I’d like to have, like that ‘Raid’ order I mentioned here in the AI thread, but the vision radius stuff doesn't seem too difficult.

Cities currently have a vision Radius of 3 (they can see two tiles out), while other owned tiles have a radius of 2 (they can see adjacent tiles only). I have an 'Outpost' wall-type (fortification-type), which I'd like to make useful, by giving it a Vision Radius of 3 like the city. This would require a Vision Radius tag in the wall structure (we should probably add it to units (or elements) and cities as well, if not other things that I'm not thinking of at the moment).
But...(and there's always a but)
I'd also like a small change to the way Vision Radius works. Normally you can see everything, but I'd like to remove units/TFs from that. Thus the only time you'd see enemy units, is when they are adjacent to a tile you own or a unit you own. Therefore, we'd need two Vision Radius tags, one for units and one for everything else. For outposts, I want to make the unit vision radius dependent on technology, increasing the radius as tech increases. This would make it advantageous to build them along the border, in the same way the Romans did, for instance.

The only other ramification I can think of from this is that over time, borders will expand, making the outpost obsolete in the middle of your territory, so we'd need a way to disband the outpost (so you no longer have to pay maintenance on something that isn't useful anymore - assuming we're paying maintenance now that is). eventually we could have some way to automate this process of build outpost – expand border – disband outpost – repeat.

Building a wall (that is Great Wall type of wall, not City Wall type of wall) in the spaces between the outposts would be a cool feature too. It would severely hamper border expansion, forcing expansion to occur at outposts only.

It would also be nice to have these outposts act as they have historically as population centers. They would have a tendancy to draw in population from surrounding tiles, eventually forming a city (possibly), in a similar way to that of the Boolean variable “isCity” I mentioned in the Expansion and Settlement thread, here:

http://apolyton.net/forums/showthread.php?postid=3018996#post3018996

there was some discussion on this afterwards.

With city creation slated for demo 8.1, I thought it would also be a good idea to remind Laurent about this variable before he starts coding it (I think he's doing it anyway).

[LDiCesare]

I'm currently revamping the code which handles the ai's vision of the map, which means I'll have to rewrite the drawing of the map, so I cna put some of these things in as I develop. I thought briefly about vision range for units myself as I refactored the code (like CtP2 has, by the way). Adding walls would be possible.
The question is: If military info is not complete, how do you show the square? Fogged? Not fogged? Something in-between (a "light" fog)?

[alms66]

Originally posted by LDiCesare
I thought briefly about vision range for units myself as I refactored the code (like CtP2 has, by the way).

Civ3 has this as well, though they do a line-of-sight type of thing, where if your vision radius is two and you are on low elevation you can't see past higher elevation, but if you are on high elevation overlooking lower elevation, you can see one tile farther. I'd prefer to follow Civ3's way, rather than CTP2's way on this one.

[Mark_Everson]

Originally posted by LDiCesare
If military info is not complete, how do you show the square? Fogged? Not fogged? Something in-between (a "light" fog)?

A light fog could work. Or a little dot on the square center. I'm comfortable with whatever looks good to you. At least for now. . .

[LDiCesare]

Small bump:
I changed the way sieges work.
First I corrected a bug where a wall wouldn't be conquered if there was no defender.
Then I decided to go for a system like Dominion, (which also happened to be the easiest thing to code):
If the attackers' forces are stronger than the defenders', then the defenders are "locked" in the fortress, and lose control of the square, but keep the fort. This will prevent armies besieged from producing units.

[Mark_Everson]

Originally posted by LDiCesare
If the attackers' forces are stronger than the defenders', then the defenders are "locked" in the fortress, and lose control of the square, but keep the fort. This will prevent armies besieged from producing units.

Hi Laurent:

Sounds good for the time being. At some point I think the city itself should be able to create units, but only with it's own internal resources. But for now that is more complicated than it's worth.