30-06-2002 04:27									#31
	Got spare money?

I want to discuss three related matters here. All relate to movement. These are:

• Loading and unloading ships.
  
• The fact that horses outrun other units in the same task force.
  
• Apparently roads are not working (I haven't seen this myself, and, frankly, it seems unlikely).
  

	30-06-2002 05:48									#32
	Full PM-box? Change here!

Hi Gary:

Thanks for the code fixes, I'll check 'em out shortly, and merge our xml files for Dawn.

quote: Originally posted by Gary Thomas Apparently roads are not working (I haven't seen this myself, and, frankly, it seems unlikely).

I have seen it myself, and its very easy to demonstrate. Roads in fact seem to never make a difference in the current code. At least every time I've attempted to test their function they do nothing. The only reason they appear to work upon casual inspection is that roads are built along the same default paths used by units (one of the infantry ones IIRC). So a Phalanx will tend to look like its using the road, but only because the road was built along the path the phalanx would use anyway, road or no road.

Here's how you can see that roads do nothing. Pick any two points such that the path between them will have at least two equal-movement-cost alternatives. The easiest case is all the same terrain, using a "knights move" from chess (considering a knights move as a two-square process with one common-edge move, and one diagonal). For concreteness I'll specify that the path NW then W gets to the target square. Take a unit and see what the path obtained by the A* is. When I did it in Dawn the NW then W path is the preferred one. However the same unit has an equal-cost path of W then NW. If a road were to break the symetry then the unit should prefer to go on the road. Steps of the demonstration are;
1. Find prefered path for the unit
2. Cancel units orders so it dosn't actually take preferred path
3. Build a road on the non-prefered path. (must use two segments to get it to build this way, otherwise it wants to be on the preferred path.)
4. Now order movement to the target square.

The unit will still take the previously preferred path over the one with the shiny new road. I have done this for a Warrior with all-grassland and also for a rolling-broken-broken path in Dawn.

Roads are either not used in pathfinding, or their effect on the cost is at least very often zero. Which is the problem, I don't know.

On current movement approach...

Wow, I had no idea it was done that way. I admit I'd always assumed that a TF was treated as a whole, until the Hannibal thing came up. Do you intend to make it so? It seems from your post that you do, and I agree, but I just want to make sure.

And what is your approach for how to save the naval conunrum? Can we just prohibit naval units from merging if they come from topologically different coasts? I hope you know what I mean, I can elaborate if needed.

	30-06-2002 16:26									#33
	Support Apolyton or Terrorists Win

quote: Originally posted by Mark_Everson The unit will still take the previously preferred path over the one with the shiny new road. I have done this for a Warrior with all-grassland and also for a rolling-broken-broken path in Dawn.

Oops, just realized rolling-broken-broken doesn't really have equivalent paths since one will be diagonal rolling-broken, and the other across a square edge. I just redid it with all rolling and the result was the same.

	06-07-2002 20:10									#34
	Full PM-box? Change here!

quote: Originally posted by Mark_Everson Longer-term we need a way for little squares to have a chance of automatically surrendering, but we ain't there yet. FE if the provincial capital is taken, and x% of the rest of the province, and the military balance is working against, a lot of squares could just willingly change hands. This would involve some social and governmental factors as well as military ones. I think its important we have this to fulfill our low micromanagement pledge to players also!

I agree with that and would like to add that these chances are probably based on the same factors as those needed to know whether the square will raise a militia for or against an invading army. Doing that first in-square and then extending it to "neighbouring squares" or province looks like a good way to go.

	09-07-2002 07:46									#35
	Support Apolyton or Terrorists Win

There is a problem with the code, arising from someone noticing that Hannibal's cavalry outran the rest of the army. In the way the code worked at the time each unit followed its own orders, regardless of others. So orders could be given to a task force, but each unit would interpret the orders individually.

To prevent the outrunning bug, I refactored the movement system so task forces move together. Because there was no way, using the gui, to give individual units orders, I didn't see any problem with this, and bypassed individual unit orders.

Unfortunately the military code, when a unit retreats, gives the unit an order to move. Because I had thought of orders as "orders from headquarters" I had not covered this situation. The way the code is at present such orders are never executed.

There are a variety of ways of fixing the problem:

• Revert the code to the way it was, which leaves the outrunning bug.
  
• Leave the code the way it is, but check for individual unit orders and execute them, a lot of work.
  
• Take the retreat code outside the order system and deal with it separately.
  

	09-07-2002 13:00									#36
	Support Apolyton, buy Call to Power 2

quote: Take the retreat code outside the order system and deal with it separately. I am in favour of the last, because I envisage the orders system as covering situations in which a higher command issues an order, and no higher command is going to issue an order to "panic and run away". My personal preference is to merely teleport the retreating unit to the destination square which will be the one it was last in and hence an adjacent square to the one in which the combat occurred. As far as the code is concerned it will take less than two minutes to implement this.

I am against teleportation. This is because retreat takes time and shouldn't be instantaneous. It allows attackers to hunt down enemies until they manage to leave the square, thus getting one or two more ticks of fight. It is important because otherwise, the combat will end soon and you will never be able to destroy an enemy army, which leads to terrible gameplay.

The higher command has to adjust its orders anyway, so I would rather keep the order system. In this view I can do it two ways:
I could remove the units from their previous command and put them into a new one, "fleeer command". I could use it for one turn and would have to put the units back into their original commands once they have retreated correctly.
Or I could look for the order which effectively gives the order and change it. Is it possible to locate rapidly these "stack" commands?

I have to say that the outrunning bug was IMO mostly a display bug, i.e. we displayed all the units of the TF instead of all units in the square. The "moving fast" part never bugged me. Would it be possible to revert to the old code but display properly as an alternative? I am afraid that long-term we will have trouble making high level commands with the current system, which effectively limits us to stacks.

	10-07-2002 03:36									#37
	Increase the size of your Attachments

I have been rather working toward a system in which a task force is always in a single square. I realize that this is a reversal of my previous view, but at the time I was overly influenced by the code that existed at the time. Now that we have a flexible command system, an order like "assemble at Rome" can be given at a higher level, although there is no gui to do that now, I hope this will be available reasonably soon.

Accordingly, my preference is to transfer a retreating unit to a new task force and give that task force the retreat order.

quote: put them into a new one, "fleeer command"

Apart from my suspicion that "fleeer" isn't English, we do not want all the fleeing units (which may be a continent apart) to be in a single task force. I would have a task force per unit and give the task force the same name as the unit. Multiple units retreating from the same square will nevertheless not have sufficient organization left to form a coherent task force and should be in separate task forces.


Cheers

	10-07-2002 12:20									#38
	Support Apolyton, buy GURPS/ Alpha Centauri

I thought of one command per square, not one for all. It is actually easier to put each unit in a different TF. I would like them to return to their previous TF after the fight, because players won't like to regroup them all in a single TF. I will try that and see if there are problems when the reformed TF tries to resume its orders.

	11-07-2002 07:41									#39
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

It causes the whole task force to retreat, not just the fuyards.

Cheers

	12-07-2002 21:26									#40
	Support Apolyton

Hi Gents, I hope my comments are still timely...

First, Laurent, I have to apologize, but you weren't available when Gary and I discussed the refactoring to make the TFs work as expected. IMO its quite clear that the outrunning bug is not simpy a display bug. The TF is really broken up into different packets which can then attack a square separately. This is quite distinct from the desired behavior of a TF attacking all at once. Since the combined-forces TFs when split up are militarily less powerful than the whole TF, the outrunning bug has serious effects on gameplay. That's why we thought it needed to be fixed. I think we should not return to the old code where different TF components go at their own speed and by their own routes. That leaves us with the issue of what to be done about retreating units.

On the topic of how to handle retreating units, I have my own proposal, that takes some elements from each of your positions. First, I want to make a distinction between units or even elements that flee from battle, and tactical or strategic withdrawls that take place under the normal military command structure. Units that flee from battle IMO should not leave the square immediately. They have just broken off from battle, and are in some position that is removed from the battle location. IMO the best way to handle fleeing from battle is just to mark the unit as being outside the scope of the battle temporarily. (They might be back in the battle on the next tick). The case of the local command making a decision to break off from battle is utterly distinct from a morale failure that leads to units withdrawing. When the local commander orders breaking off, it would cause the entire friendly force to try and disengage. It would then leave the field, and have to make for another square. This would be done by TF similarly to what Laurent has outlined above.

In more detail, my proposal is:

Retreating units are marked as outside the battle. Laurent may already have a way of handling this, and I just don't know what it is... I think it best that units with broken morale remain in their TF and simply do not contribute to the combat values of it. There are many details that need to be sorted out eventually such as: under what conditions can a victorious army hunt down these units; and when might a unit with broken morale recover to the extent that it can rejoin the battle in a subsequent tick. But for now, we can just take them out of the battle without being out of the square. Units with broken morale do not leave the square on their own or as part of a newly-constituted TF.

I think the decision to break off, which is a local Command decision, can be handled sensibly in the general way Laurent outlined that we've been discussing for quite a while. It consists of three steps.

1. AI simulating local commander makes decision as to whether to try to break off/ retreat
2. If answer to 1 is yes, an attempt is made to avoid battle (if it hasn't started yet) or disengage (if battle has started and odds have gone against them) This is what is now like a 25% chance as I understand it. This would become more nuanced in time.
3. Orders are given to withdraw to a particular location by a specified route. These orders replace whatever previous attack orders the unit may have had. Long-term I am with Laurent that the units withdrawing should not teleport away, but as a temporary expedient, I don't have any major problems with it.

I've got to run, will try to add to this later.

Cya,

Mark

	12-07-2002 23:57									#41
	Get a bigger avatar today!

I think I ended up covering most of the important stuff in my previous post. I'll just have to wait to see if the two of you think that approach is workable.

Laurent, on your criticism of teleporting (in terms of it taking too long to wipe out an opposing army) we can IMO just change the chances for a successful break-off to give decent play balance pending doing things right.

Also, I have a question. Do the current attack-odds limitations apply before the TF moves into the square? FE if I send a two-Legion TF to beat on a single legion, and then four more join the single one before my TF moves in, is it smart enough to know not to make the final move? If not, that is an important part of having the automatic attack odds stuff work right.

	13-07-2002 02:14									#42
	Tired of ads?

Hi Mark!

quote: First, I want to make a distinction between units or even elements that flee from battle, and tactical or strategic withdrawls that take place under the normal military command structure. Units that flee from battle IMO should not leave the square immediately. They have just broken off from battle, and are in some position that is removed from the battle location. IMO the best way to handle fleeing from battle is just to mark the unit as being outside the scope of the battle temporarily. (They might be back in the battle on the next tick).

That is how it works in the code. Elements who didn't make a morale check are removed from the fight for this tick and stay in the square. Then, at the end of the tick, the command looks at its odds and decides whether to flee or not. It is always successful now, subject to playtest. Its order to retreat allows it to flee. Note that if ALL elements fled in a fight, the command will always want to flee and leave the square. Subject to change.

The odds are taken into consideration only when in-square, thus fights are fought, but the army will try to disengage after a single tick. Since move is simultaneous, it would be hard to do it otherwise. It is possible, but in some situations, you would move when you shouldn't and vice versa.

	13-07-2002 04:53									#43
	Increase the size of your Attachments

Thanks for the quick response Laurent! Its good to be back in communication.

quote: Originally posted by LDiCesare That is how it works in the code. Elements who didn't make a morale check are removed from the fight for this tick and stay in the square. (snip)

That sounds sensible to me. My only quibble is that they automatically succeed in withdrawing (I think that's what you're saying). It should IMO only be a chance. In the future the chance should depend on force composition and other factors. But for now it can certainly be just a fixed percentage.

quote: The odds are taken into consideration only when in-square, thus fights are fought, but the army will try to disengage after a single tick. Since move is simultaneous, it would be hard to do it otherwise. It is possible, but in some situations, you would move when you shouldn't and vice versa.

I see your point. The thing that really bothers me is when fights start that just wouldn't happen because the're Stupid . I think the two sides moving into the square is ok because of the complications you cite. But as I understand it the first check of whether someone wants to withdraw is not made until after the battle has run one tick. how about making the first tick of a battle special, in that there would be a Pre-battle withdrawl check? That way the local commander is making a decision whether to go forward with an attack based on whatever info is available (now the information is perfect, but that will change in the future). If the odds were not good enough to go forward with an attack, the TF would attempt to withdraw immediately, and should have a fairly good chance to do so IMO. They would also get chances to withdraw after the battle has been joined, but this can be a lot more difficult.

	19-07-2002 14:48									#44
	naval / land combined TFs Support Apolyton, buy Civilization 2

This isn't essential for D7, but I wanted to put up the idea before I forgot it.

Gary said in email:

quote: [He, in the current code,] stopped land and sea units being combined in the same TF.

It seems to me that forming a TF of land/naval units is a rational way to allow loading of troops onto ships. You would only be able to form the TF if the land units could be carried with the ships.

On a related note, in Demo 4 we used to have combined military/land TFs that could have any composition, but then could only move on coastal squares. (That was the case if there were more land units than the boats could carry.) Post D7 I think we need a way to keep naval and land TFs quite close to each other. Ideally a land force and naval force should be able to proceed along a coast together in some fashion. This is a thing that was very common in ancient warfare as I understand it.

Presently there is no graceful way I can see to do that. This is an unforseen effect of requiring a naval unit to go straight out to sea, rather than moving directly from coastal to coastal square. One possible fix is to loosen the restrictions on naval movement so that naval units can move along a coastal square. I think if we consider carefully we can have a system where naval movement is a little less rigid than having to move directly out to sea to the square you came from as it is now, and yet still render impossible ships jumping over isthmuses.

What do you guys think in general? I definitely Don't want to slow down D7 with a detailed discussion of this now.

	20-07-2002 08:30									#45
	Full PM-box? Change here!

quote: It seems to me that forming a TF of land/naval units is a rational way to allow loading of troops onto ships. You would only be able to form the TF if the land units could be carried with the ships.

Then the land units would fight like ships.

I have already had to fix a few oddities in the system, like loading a land unit onto a trireme, then loading that trireme onto another trireme, and another again...

Presumably if we had a land transport unit we could then load the whole lot onto a wagon and transport it overland.

quote: On a related note, in Demo 4 we used to have combined military/land TFs that could have any composition, but then could only move on coastal squares. (That was the case if there were more land units than the boats could carry.) Post D7 I think we need a way to keep naval and land TFs quite close to each other. Ideally a land force and naval force should be able to proceed along a coast together in some fashion. This is a thing that was very common in ancient warfare as I understand it.

It wasn't as far as I know. In any case, they could not fight together. If they were in the same task force we get the peculiar situation of a battle with heavy infantry, cavalry and triremes in the front line, supported by archers in the second line.

Troops loaded on triremes (which, of course never happened) could assist them to some extent, but there is no way that a trireme could help in a land battle.

Since the triremes move a lot faster than troops, moving out to sea them back will not cause them to lag behind.

Soon (ha!) I will implement the notion I had in designing the command system. There is nothing to prevent a higher level command having a land and a sea element, and getting a single move order which will cause them to move together if they are able.

I am not sure how the fighting takes place now. The Encounter class just gets all the units belonging to a civilization and in the same square as a single undifferentiated list.

On another tack, I am having a great deal of difficulty with loading units onto transport. The problem is that loading is done on a unit to unit basis. So, in general, a land task force will get split up among different sea task forces, perhaps going to different destinations, and perhaps with some left behind. With disastrous results.

My preference is to restrict boarding to the task force level. That is, an entire task force boards another task force and thus stays together. There is nothing to stop someone splitting the land task force up if they want to, and putting it on different sea task forces. Splitting up the sea task force will automatically also split up any land task force it is carrying.

Cheers

	20-07-2002 11:44									#46
	Support Apolyton, buy Civilization 2

Yes, loading on a ship is terrific as you don't know what happens to units, elements, TFs...
As far as I know in D4, ships fought in the first round of fight.
I haven't tackled sea combat yet, and there is no model for it. It is fairly easy to prevent boats from fighting by putting them in reserve with a specific preferred order like "going to sea".

	21-07-2002 18:48									#47
	Tired of ads?

Hi gents:

I'm not going to reply in too much detail or attempt to make much in the way of proposals since I don't want to slow down D7 work. But here are a few quickie responses.

quote: Originally posted by Gary Thomas Then the land units would fight like ships.

I had envisioned a more sophisticated combat system, where naval and land fights in a square can be distinct, as Laurent has outlined. I believe the same general problem occurs in running fights even where land and naval TFs are distinct.

quote: Since the triremes move a lot faster than troops, moving out to sea them back will not cause them to lag behind. Soon (ha!) I will implement the notion I had in designing the command system. There is nothing to prevent a higher level command having a land and a sea element, and getting a single move order which will cause them to move together if they are able.

I agree that the higher-level command capabilities you talk about is good stuff, and is of importance longer-term.

quote: On another tack, I am having a great deal of difficulty with loading units onto transport. The problem is that loading is done on a unit to unit basis. So, in general, a land task force will get split up among different sea task forces, perhaps going to different destinations, and perhaps with some left behind. With disastrous results. My preference is to restrict boarding to the task force level. That is, an entire task force boards another task force and thus stays together. There is nothing to stop someone splitting the land task force up if they want to, and putting it on different sea task forces. Splitting up the sea task force will automatically also split up any land task force it is carrying.

That sounds good to me! Laurent?

[/QUOTE] (Laurent said) As far as I know in D4, ships fought in the first round of fight.[/QUOTE]

IIRC ships fought in all rounds, but got a bonus in the first. The idea was to give a mobility bonus to the side that had the ships. The biggest factor this was supposed to simulate is that if a landing of troops was attempted that the naval forces of an opponent could try to contest it before the troops disembarked. This was a very simple early implementation, and I'm sure well do a lot better this time!


When looking at the D4 manual I came across this oldie:

"Currently, moving an attacking force costs $2 per point of Military Power, and a defending force $1. " The cost was meant to represent organizational costs that go beyond supplies, and also weapon/ammunition destruction/depletion. We should include some notion of this sort of thing eventually in the supply model. Perhaps a cash cost and also an increased supply cost for combat? Just a discussion starter, meant more to indicate a discussion point after D7.

	22-07-2002 14:46									#48
	Lose 30 kilos (of popups)

quote: On another tack, I am having a great deal of difficulty with loading units onto transport. The problem is that loading is done on a unit to unit basis. So, in general, a land task force will get split up among different sea task forces, perhaps going to different destinations, and perhaps with some left behind. With disastrous results. My preference is to restrict boarding to the task force level. That is, an entire task force boards another task force and thus stays together. There is nothing to stop someone splitting the land task force up if they want to, and putting it on different sea task forces. Splitting up the sea task force will automatically also split up any land task force it is carrying.

That seems OK from a Command and UI point of view.
Note that soon (probably D8) I will have to redo the boarding code as it now considers an element as a measuer of size. An element place on a ship should be based on the number of men in it times a scale factor (like ! for infantry, 3 for cavalry and 10 for elephants). This goes along with the single element with a number of men-code refactoring. This leads to long-term problems as, right now, a trireme (which we all know should be replaced by a round ship for transporting troops) has enough elements to carry any unit, but...
Now a funny situation: You have a 1000-man unit and 2 transport units able to carry 500 men each. Can you board them? From a TF point of view, you should, as everyone has the place aboard. Now what if you split the transport TF at sea? How do you split the unit? Having a land unit on a single sea unit will probaby waste space but avoid bugs. Thus I'd rather stick with it at least short term.
Otherwise, I'd have to have weird OrphanUnits who are created by splitting of their unit and who remember who they used to be... or I kill the buggers on all ships but one.

About single element with variable number of men in it: How do we handle morale? Right now elements flee as a whole, and the unit flees as a result of all their elements having fled. The same behaviour with a single (bigger) element will lead to more random fights as people will flee en masse, unless the model proposes a better way to handle morale failure. I can for example give a current morale value to the unit and each time a morale check is required increment the current morale number of the unit. When it reaches a limit, the whole unit would break. I can also make a fraction of the manpower flee, but I don't think it right to have a few persons flee in an element while others continue fighting.

	23-07-2002 06:35									#49
	Avatar Enlargement: We've got the solution

quote: That seems OK from a Command and UI point of view.

It is simple to code - I will assume that each task force can carry exactly one task force. I will also make a carrying task force unable to be split until it has unloaded. This will work until we have sea combat, and I can think about the next step then.

quote: Note that soon (probably D8) I will have to redo the boarding code as it now considers an element as a measuer of size. An element place on a ship should be based on the number of men in it times a scale factor (like ! for infantry, 3 for cavalry and 10 for elephants). This goes along with the single element with a number of men-code refactoring.

I am fully in favour of this.

quote: This leads to long-term problems as, right now, a trireme (which we all know should be replaced by a round ship for transporting troops) has enough elements to carry any unit, but... Now a funny situation: You have a 1000-man unit and 2 transport units able to carry 500 men each. Can you board them? From a TF point of view, you should, as everyone has the place aboard. Now what if you split the transport TF at sea? How do you split the unit?

Just say you can't do it.

quote: Having a land unit on a single sea unit will probaby waste space but avoid bugs. Thus I'd rather stick with it at least short term.

I am quite sure that the contortions necessary for this will cause bugs, not avoid them.

quote: Otherwise, I'd have to have weird OrphanUnits who are created by splitting of their unit and who remember who they used to be... or I kill the buggers on all ships but one.

As I said, don't let them split.

quote: About single element with variable number of men in it: How do we handle morale? Right now elements flee as a whole, and the unit flees as a result of all their elements having fled. The same behaviour with a single (bigger) element will lead to more random fights as people will flee en masse, unless the model proposes a better way to handle morale failure.[quote] Use the number of survivors as a morale effect. They flee when they have a certain proportion killed. Higher morale units would have a higher proportion of sustainable losses, right up to Leonidas whose morale could not be improved upon. [quote]I can for example give a current morale value to the unit and each time a morale check is required increment the current morale number of the unit. When it reaches a limit, the whole unit would break. I can also make a fraction of the manpower flee, but I don't think it right to have a few persons flee in an element while others continue fighting.

See above.

Cheers

	23-07-2002 11:57									#50
	Support Apolyton, buy Civilization 2

Do you mean I must know I cannot split the TF? I would have to look at every unit in the command everytime I look at a Command for it to split, and check if it is not perchance carrying part of the same unit. I hope the splitting/removing from a command code is centralized in a single method then, but somehow doubt it. That also means I must be able to report an error message to the player saying he can't split his TF because it cannot split unit XXX between the would-be TF's. That means an error mechanism (probably an Exception) which must be thrown by the Command objects when splitting/changing father command. This will have to be caught by the UI to show an explanation somewhere, and the AI in case it tries to act silly.

	24-07-2002 06:29									#51
	Increase the size of your Attachments

You can only split a command by clicking on on one of "assign unit to new TF", "assign unit to selected TF", "merge all", or "disband TF" in the task force popup.

None of these choices will appear in the Task Force popup if the selected TF is carrying a TF or being carried. So you actually CAN'T do anything illegal.

Cheers

	24-07-2002 11:28									#52
	Support Apolyton, buy Civilization III: Complete

I don't like the idea much. Preventing the UI from splitting is, IMO, a patch. How do I make sure the AI doesn't try the same things without going thru the UI? How do I warn it the splitting didn't work?
From a player point of view, why shouldn't a player be allowed to split a fleet at sea? Agreed, knowing which land unit goes where may be difficult. Probably I'd want to split a sea TF by splitting the land units and the non-transport/empty ships.

	24-07-2002 15:32									#53
	Support Apolyton, buy Alpha Centauri

Can we just use the TF rearrangement UI when a loaded naval TF is at sea? I am not up on the most recent restrictions Gary has put in but here's a proposal for how the UI could work in the near-term. We can work on an ideal solution for the long-term later. However I think my idea may be useful in the long term also.

Lets say I have a 3-transport TF at sea, carrying a 3-unit TF, and I want to split off one transport with one unit and send it elsewhere. What I do is a synthetic unloading. In the TF window it looks like my army units are sitting in the sea. Perhaps they have some kind of red symbol that indicates if they're not 'embarked' again that they will be lost. Now I can use all the normal TF-rearrangement options to change the land and sea TFs to what I want. Then finally I load the new land TFs on the new sea TFs and voila! This allows for detailed player control, if they want it. The AI, when up to it, could use tis approach also.

	24-07-2002 16:01									#54
	D7 retreat problems Avatar Enlargement: We've got the solution

Gary Said (from an email re D7):

quote: Combat still behaves very oddly, with, I suspect, too many retreats, and often for no good reason. This is how it seems to happen: you are following a smaller enemy unit. You move ito its square from the square it last moved from, and beat it up. It retreats to the last square it was in, that is, the square you just left. So the two units swap placfes. The swapping does not happen in movement, but in combat. In cases where you try to move onto a square with an enemy in it, and fail, theer are two possibilities. Either you did move and then retreated from combat back to your previous square, or, alternatively, the enemy was trying to move into your square, then you lost the race for the border, so your orders were cancelled, the enemy entered your square, lost the battle and retreated back to its previous square. In both cases it looks as though you did not move. One solution is to prevent retreat on the first turn in a square.

Getting the retreats squared away is definitely a top issue. I take responsibility for promoting it but its not ready for prime time, and seriously reduces the playing experience. I still think it is somewhat realistic, but in a game, it needs to also be fun, and it ain't right now. My preferred solution even before this was having a TF look at the odds Prior to moving, and if its attack would be suicide to switch orders. That was thought to be impractical short-term in our discussion of the issue on the forum.

I think one possible quick fix would be to put in a global that gives the probability of a TF retreating when it would otherwise like to. Effectively now that parameter seems to be 100% per round of fight, or maybe its just 100% at the start of fights? I think it could well be that with that chance in the 20-40% range it might work ok. Having to chase a unit occasionally would not be a big deal IMO, its when it happens continuously that it's mind-numbing.

Another quick fix that I think we should use longer-term is to Charge any Retreating TF for the ticks it uses in the withdrawal. That would both be realistic, and lead to some interesting pursuit dynamics. Details TBD. I don't know if this is something that can be done quickly for D7. If it is, I'd be in favor of implementing it. In conjunction with the reduced probability of flight I think it would give us an interesting and unique system that as an added bonus doesn't annoy the player

	25-07-2002 05:25									#55
	Avatar Enlargement: We've got the solution

quote: I don't like the idea much. Preventing the UI from splitting is, IMO, a patch. How do I make sure the AI doesn't try the same things without going thru the UI? How do I warn it the splitting didn't work?

When we have an AI I will answer that question.

quote: From a player point of view, why shouldn't a player be allowed to split a fleet at sea?

One reason is that it has never happened to a transporting fleet in the entire history of the human race. To me that is sufficient reason.

quote: Agreed, knowing which land unit goes where may be difficult. Probably I'd want to split a sea TF by splitting the land units and the non-transport/empty ships.

I have no problem with allowing sea units that are not carrying land units to be split off and see no problem with the implementation.

Cheers

	25-07-2002 13:34									#56
	Support Apolyton, buy Galactic Civilizations

quote: Another quick fix that I think we should use longer-term is to Charge any Retreating TF for the ticks it uses in the withdrawal. That would both be realistic, and lead to some interesting pursuit dynamics. Details TBD. I don't know if this is something that can be done quickly for D7. If it is, I'd be in favor of implementing it.

It is already done. Retreat is done through an order, thus it takes some ticks to get done.
Cancelling orders is there to allow pickets, so it should stay.
The simplest thing is to allow retreat to fail: It is currently a low probability per round of fight, and 100% at the end of each tick. At the end of a tick, this means new move orders are issued. Giving less than 100% (I think 10% probably is best - consider there are 10 ticks per turn) would make things better, but swaps would still happen.
If it is possible to delay an order by replacing it with itelf (hopefully losing all ticks of movement accrued), then I can prevent a unit from fleeing to the square its opponent comes from or wants to go to. That would be better I think.

Reordering units in TFs at sea:
I wouldn't allow reordering of land units among boats. That is totally unrealistic: Army 1 jumps to water while army2 moves in their ship, then army3 moves to army2 previous ship and army1 swims to soak up on army3 previous ship?
TF-level boarding can be done, but I will throw an Exception of sort (an Error if needs be) if someone wants to split a TF which has somebody boarded on it or which is boarded by someone. Just to be sure.

	25-07-2002 17:12									#57
	Support Apolyton buy from Amazon

quote: Originally posted by LDiCesare The simplest thing is to allow retreat to fail: It is currently a low probability per round of fight, and 100% at the end of each tick. At the end of a tick, this means new move orders are issued. Giving less than 100% (I think 10% probably is best - consider there are 10 ticks per turn) would make things better, but swaps would still happen. If it is possible to delay an order by replacing it with itelf (hopefully losing all ticks of movement accrued), then I can prevent a unit from fleeing to the square its opponent comes from or wants to go to. That would be better I think.

That sounds ok to me

quote: Reordering units in TFs at sea: I wouldn't allow reordering of land units among boats. That is totally unrealistic (snip)

It wasn't meant to be realistic, it was meant to be fun and relatively easy for the player and in the code.

Gary said:

quote: One reason is that it has never happened to a transporting fleet in the entire history of the human race.

Wow, you have knowledge of every naval transport operation ever in history, I'm Impressed . I agree that switching around units on fleets happens way too often in civ. And also that trasport fleets generally throughout history only move an attacking army something like 250 km or less. Nonetheless, I think long-term the system needs to be flexible. But we can put off a detailed handling of that for a bit due to other pressing issues.

Gary's by-TF method seems to me quite adequate for D7 or D7.1

	25-07-2002 23:34									#58
	Support Apolyton buy from Amazon

I am going to check the retreat bugs tonight. I don't know about the TF boarding. I can provide TF level API for the GUI to be easier to code. I won't refactor the code beneath yet because that will have to wait for the element/manpower refactoring, which I will do for D8 as it may take a bit of time.

	28-07-2002 06:26									#59
	Support Apolyton or Terrorists Win

I will do this (after D7 is released) - I have already figured out how to do it and it does not affect the game.military code at all.

Cheers

	13-08-2002 12:24									#60
	Manpower Support Apolyton, buy Galactic Civilizations: Deluxe Edition

I changed the manpower management in units. Now 1 element in the xml file describes the stats for one man. In turn, the number of elements in a unit is actually the number of men. Thus, for instance, a horde which was made of 8 warriors + 2 cavalry skirmishers is now made of 4000 warriors + 1000 cavalry skirmishers. The difference is 1 warrior used to say it was made of 500 men, now it no longer does. That doesn't change much the outside appearance of a Unit, but it raises some points regarding combat and particularly morale.
Previously, elements morale was checked per-element, and if an element fled, the unit lost part of its manpower for the fight. For instance, the horde could lose 1 warrior, thus 500 men, on a bad morale check. Now, the same code would make all the 4000 warriors to flee as they are coded as a single element with a number of 4000. Needless to say, 4000 morale checks are totally out of hte question.
The current morale system doesn't fit, because the random factor affects much greater numbers and you may end up with units made of 999 of 1 element and 1 of one other, and you could have situations where one single man would stand while the other 999 would flee.
Gary suggested in a mail a breakup number. For instance, your unit has 1000 men and will flee if it falls below 500.

The current morale model is rather complicated. The code surely is. Refer to the Military Coding thread to see what is indeed implemented.
We can probably simplify the whole morale stuff along Gary's lines:
Checks would be:
1)Appraisal of strengths, flee based on odds and current orders (independent of actual morale).
2)At the end of each round of fight, check per unit the number of casualties. If the unit is below a threshold, it tries to flee.
Odds to manage fleeing are always less than 100%, I don't change that.
The problem with 2) is that, right now units don't heal. Thus, a unit which fled once will always flee. This can be mended by adding unit healing. This healing of unit is, however, a problem, as it should require men and production/services/food for the unit to heal. Units probably don't heal in foreign territory. Healing units could be taken from the existing military econ orders to start with, but that could lead to wounded units being fully replenished after a battle, at a cost to the economy. The player may or may not want to spend huge sums on one given turn to heal a victorious army he will disband the next turn.
Considering the little response there was to my previous healing posts, I will end up doing this if noone says anything against it. We will then see if a separate heal/upgrade econ order is needed to give the player more control over his armies.