I encountered a bit of an annoying behavior. I was at war with the french and they won 9 out of 10 battles no matter what the initial odds were. The only battle I won was with an armed and mounted free colonist from within a heavily armed town against an unarmed lumberjack.
The same unit (then veteran dragooner) mounted and armed _lost_ in open field to an unarmed expert carpenter. And after the next round my unit was slaughtered when attacking a town without any special defenses again by an unarmed unit, while the french without problem captured my town which had a veteran unit in it.
This is not really fun, as I don't really know how to change the odds in these single fights more in my favor such as to actually win a couple of them.
We are not even speaking of independence fights here.
Any hints?
Cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, sorry, now I saw that -- under a non-conclusive subject -- this was discussed already a couple of weeks ago. I should mention though that this was in "normal" difficulty, since I am only starting with the game, so I did not want to go for the hard thing.
Still I find the behavior highly unsatisfactory in an otherwise very nice game.
Cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Doesn't happen, but feel free to review the code for yourself: All calculations are done in SimpleCombatModel.java:generateAttackResult(), and accessed once in InGameInputHandler.java (both linked below).
Despite various complaints on the forums, I have never actually been able to observe problems with the combat model myself. Unless you have better proof than your gut feeling that you SHOULD have won, the code isn't going to be changed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only thing I can think of that might help with complaints about the combat system is improving the RNG. Assuming FreeCol uses the Java equivalent of C's rand(), you could try a different algorithm (e.g. Mersenne Twister). It may help with the Civ-style "spearman beats tank" phenomenon. I say "may" because FreeCol doesn't seem to have that stark a contrast in fighting ability (I assume a single die roll as opposed to Civ's multiple rounds of combat), so players may not notice a difference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have encountered this bug many many times in the original version of Colonization, and
there is no question at all that it occurs with freecol too. The odds simply do not result in a reasonable conclusion many times. This is what occurs: if a unit loses a battle and you re-load the file to try again, the unit will consistently lose no matter what the odds or how many times you try. Not only that, but ALL units will lose all attacks if one does, (for that turn.) Sometimes, often, I will attack a colony with a dragoon, lose, and not be able to even attack it for another turn or two. There is definitely a bug in the game which affects the real odds, and if one loses, one cannot even attack that colony again for a turn or two. The odds are logically that if a dragoon attacks a non-stockaded colony which is undefended, he should win. If a regular attacks a free colonist soldier, (or attacking with artillery), he should win. I do not wish to be argumentative, because I have been playing Colonization for many years, and this is a great replica, with many improved features. However, I am not from another planet, and I know what I have experienced literally hundreds of times--the attack/defense odds simply do not play out like they are designed to. By the way, I playing the game on both Win XP and on Vista, on two different pc's and with two different versions of freecol. Both demonstrate the same problem. In fact, it is the only
problem with the game in my opinion. I cannot stand losing battles when the odds are greatly
on my side--it doesn't make sense. Please believe the contributor who complained about this because it is all too true. I do not belong to this forum, but I just dropped in to see if anyone was asking about this issue, and about why I can't run the newest version on my Vista laptop with Gforce graphic card. Thank you. The Wrath of God
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's a difference between losing _one_ battle against odds (which can and should happen, otherwise the game would be very boring), and losing a great number of consecutive battles, each one against odds (which should not happen, or at least not happen very often).
For example, if the attacker, with all boni applied, has an attack value of 8, and the defender has a defense value of 2, then the attacker will win with a probability of 80% (8/[8+2]), and the defender with a probability of 20%. This means that there's a not overwhelming, but still "good" chance of the defender winning an individual battle.
However, make that 10 consecutive battles, and the probability of the defender winning ALL battles will be 0,2^10 ~ 0. That situation just shouldn't occur.
Still, the probability of winning any single engagement in that 10-round battle is 20% for the defender, so expect at least _some_ units of the attacking force being lost.
Please note that, after reloading a savegame, the units that lost before are still expected to lose if you're repeating the same steps. This is done to avoid cheating, as well as to help the developers debug the game. It's not a bug itself.
So, if you encounter a very improbable "losing streak", please provide a savegame from directly before that streak, and let us know which battles to perform in which order.
For the record, I did an (admittedly small) test of the random number generator just 1-2 weeks ago, and it looked reasonably fair to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a question on mechanics of a fight.
I know that the odds are calculated (using the above example 8 human 2 computer 80/20%.)
When doing the random function, does the human always get the same end of the stack (ie get below your number) or does it follow the attacker (ie the attacker always gets that same end of that stack),
I was thinking that this could (stress could) make a difference in the appearance of randomness. Follow my thoughts here. I assume it folows the Attacker/defender. IF the human attacks, they need an 80 or less for a win (and get a 90 roll) but then the computer at 2 attacks and needs a 20 or less to win (and gets a roll of 10). The rolls are therefore 'statistical' but the outcomes seem asymetric only because the possition of attacker and defender change.
This would cause a greater than normal expection of losses, although it would be for large numbers of combats equally skewed the other direction. Of course I don't notice that I've had no losses (with an 80/20 split I should still loose about 2 in 10) But I do notice a string of 3 in a row, despite the random function throwing out numbers from all over.
Again since I didn't program the system, I'm only speculation from the description of how combat is supposed to work.
AC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure how reversing or not reversing roles (while keeping the correct probabilities intact) might lead to overall skewed results. Can you explain?
For the record, combat is resolved in the following way:
The "victory" probability of the attacker is calculated as att_strength/(att_strength+def_strength). This is a floating point number in the range [0..1].
Then, a random integer number "R" in the range [0..99] is chosen.
Then, this number is compared to some values:
R <= victory*20 //GREAT_WIN, for example instant sinking of an enemy ship
R <= victory*100 //WIN, for example damaging an enemy ship
...the rest are evasions and losses.
One can easily see that the probability of winning as the attacker really _is_ proportional to the "victory" value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe that the current system of fighting odds is "The "victory" probability of the attacker is calculated as att_strength/(att_strength+def_strength)." as mentioned.
Then, the explanation in the manual; If the attack value of the attacker is greater than the defence value of the defender, the attacker wins; is wrong and should be changed.
I also found minor misprints. In "Skills and Education" section, the manual says "the Expert Fur Trapper, ... all require at least a College." But Fur trapper can be taught in Schoolhouse.
That should be "Master Fur Trader" instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The combat mechanism of FreeCol is very simple: Each unit has an attack strength and a defence strength. Attack bonuses and defence bonuses granted by terrain, fortifications or Founding Fathers are added to the base values of the units. A random element is then added to the calculations in order to determine the winner of the battle.
Where's the other statement from?
Fixed the Trapper/Trader mixup, thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have had to sacrifice several Dragoons to beat a single colonist in a town square, on several occasions... Even when the town has no defensive buildings. I have seen this same phenomenon in Indian Villages too...
It appears that the RNG gets stuck at times..... Of course it ALWAYS appears to be stuck against the player.. But then, it is human nature to only remember the negative and forget all those times when you won ten in a row against equal or superior forces...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
please understand I am only talking about the appearance of the randomness, not the actual randomness.
If the combat is resolved as described. Where basically R <= target value then attacker wins, I assume else defender wins. (ie no draws)
So player makes 3 attacks, then the computer makes 3 attacks, and the player looses all of them, it could be 3 high rolls (R> target) then 3 low rolls (R<=target) since the in the first 3 the player needed low rolls to win as attacker <= and in the second 3 he needs high rolls > target to win.
Again this gives the appearence of no randomness ie human 'always' loose but the reality is the underlying randomness is there (some high, some low) just the desired result for the human - ie they want a low result or high result changes based on what role they are in the combat of attacker or defender.
And I agree with Cyber Troll with the 'human nature to only remember the negative...'
Although my personal experience has been strings of bad results for me, and strings of good results, very few times where I have alternating results. And in those strings the results were I'd say 'mixed' meaning sometimes the individual results went with the odds and other times against the odds.
AC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, now I see where you're coming from - yes, you're right, for a "losing streak" across turns (both attacking and defending), the RNG will pretty much have to generate numbers from the whole range. I assumed that most complaints in that regard were specifically about player action (=attacking), though.
To repeat, the code regarding combat resolution, as well as the RNG output itself, doesn't show any signs of weakness. If you still encounter unexplainable "losing streaks", this may be a bug hidden elsewhere - for example miscalculating some unit defense strength, or some other exceptional condition leading to seemingly invincible units. If something like this happens, a savegame from directly before would really be helpful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Um, I think I know where the confusion comes from. Col is/was a weird game in terms of fighting ods, as in fact many of Micro Prose/Firaxis games.
It's creators apparently don't like to leave too much to bare chance so they throw in hidden rules, and modifiers which cause this eerie feling when playing Col; sometimes you just know, you are going to win in a given situation although the official odds may seem to be stacked against you... . Or Vice Versa.
I'd reccomend testing Col combat in cheat/debug mode so that the multiple hidden modifiers are exposed. I'm not arguing that FreeCol must necessarily copy those, never the less, it would shed some light on how the odds really work... .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another thing about the odds that bothers me is no availablity of a draw in land combat - In sea combat the other ship sometimes 'sails away' or whatever the phrase is.
I was thinking that a flat value of 1 would be put into all the combat odds calculations so attacker has after mods a 2 and defender a 2 so the break would be 40/20/40 Attacker/Draw/Defender. With more skilled combatants on both sides leaning towards engagement and less skilled trying to avoid it/getting killed. At Attacker 5, Defender 4 it would be 50/10/40 for Attacker/Draw/Defender.
We can debate if green troups are more likely to try and get a draw verses veterans, but I was thinking that they would and that's why I was thinking a flat 1 rather than a flat % per combat.
Since I am only an enjoyer of the game and not a programer, the programers can ignore me. ;)
AC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well - both bug reports were submitted over a decade ago (so are most likely fixed by now), and additionally describe situations that don't really match the "problem" here.
Also, as I stated earlier in this thread, tests of the RNG so far showed no signs of any considerable weakness. These tests were done by, for example, patching the battle outcome calculation to not get one random number, but 10K and averaging them up - or by calling nextInt(10) several thousand times and counting the different outcomes.
So, if it's a Java problem, it's one that doesn't exist in the version on this computer. ;)
Other than that, it could only be an unrelated bug in the game that just appears as "strange odds" under specific circumstances (in which case, we'll definitely need a savegame!) or, more likely, just wrong expectations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>abartels
>The manual currently states: ...
Where's that manual?
The manual I have (PDF contained in the 0.8.4 version), the HTML and PDF on freecol.org;
all three documents say "If the attack value of the attacker is greater than the defence value of the defender, the attacker wins; is wrong and should be changed." http://www.freecol.org/documentation/freecol-user-manual.html
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, have just had fun on debians freecol 0.8.4 trying to kill a single SpanishVetDragoon. It has already killed like .5K of my horses (almost all of them were ridden by veterans as well) and still stands right there before my city. Too bad I didn't save right before the massacre. Neither did I expect him to win (in a row):
1 attack vs. fortified non-vet in a fortress (6 to 7.5 i guess, 44%)
6 defences vs. veteran goons in a prairie (4.5 to 6, 42.8%)
2 defences vs. non-vet soldiers (4.5 to 3, 60%)
Ouch.
Yes, it would have been incredibly helpful to have a savegame of that situation.
Did you perhaps save directly after this happened? That save would be less useful, but perhaps not completely useless, either.
Also, do you still have the log file of that game? Log files get overwritten when starting the game, so if you haven't done that since that bug, it may still be available (it's the file FreeCol.log in the directory that also contains the save/ subdir).
If possible, please provide either or both by creating a new bug report on the tracker. Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I encountered a bit of an annoying behavior. I was at war with the french and they won 9 out of 10 battles no matter what the initial odds were. The only battle I won was with an armed and mounted free colonist from within a heavily armed town against an unarmed lumberjack.
The same unit (then veteran dragooner) mounted and armed _lost_ in open field to an unarmed expert carpenter. And after the next round my unit was slaughtered when attacking a town without any special defenses again by an unarmed unit, while the french without problem captured my town which had a veteran unit in it.
This is not really fun, as I don't really know how to change the odds in these single fights more in my favor such as to actually win a couple of them.
We are not even speaking of independence fights here.
Any hints?
Cheers
Ok, sorry, now I saw that -- under a non-conclusive subject -- this was discussed already a couple of weeks ago. I should mention though that this was in "normal" difficulty, since I am only starting with the game, so I did not want to go for the hard thing.
Still I find the behavior highly unsatisfactory in an otherwise very nice game.
Cheers
Any possibility the attacker and defender roles are getting switched by accident prior to the RNG? That's easy to do (and fix)....
Try a bunch of battles where your forces should get killed and see how well they do :)
Re:Accidental role switching
Doesn't happen, but feel free to review the code for yourself: All calculations are done in SimpleCombatModel.java:generateAttackResult(), and accessed once in InGameInputHandler.java (both linked below).
http://freecol.svn.sourceforge.net/viewvc/freecol/freecol/trunk/src/net/sf/freecol/common/model/SimpleCombatModel.java?view=markup
http://freecol.svn.sourceforge.net/viewvc/freecol/freecol/trunk/src/net/sf/freecol/server/control/InGameInputHandler.java?view=markup
Despite various complaints on the forums, I have never actually been able to observe problems with the combat model myself. Unless you have better proof than your gut feeling that you SHOULD have won, the code isn't going to be changed.
The only thing I can think of that might help with complaints about the combat system is improving the RNG. Assuming FreeCol uses the Java equivalent of C's rand(), you could try a different algorithm (e.g. Mersenne Twister). It may help with the Civ-style "spearman beats tank" phenomenon. I say "may" because FreeCol doesn't seem to have that stark a contrast in fighting ability (I assume a single die roll as opposed to Civ's multiple rounds of combat), so players may not notice a difference.
I have encountered this bug many many times in the original version of Colonization, and
there is no question at all that it occurs with freecol too. The odds simply do not result in a reasonable conclusion many times. This is what occurs: if a unit loses a battle and you re-load the file to try again, the unit will consistently lose no matter what the odds or how many times you try. Not only that, but ALL units will lose all attacks if one does, (for that turn.) Sometimes, often, I will attack a colony with a dragoon, lose, and not be able to even attack it for another turn or two. There is definitely a bug in the game which affects the real odds, and if one loses, one cannot even attack that colony again for a turn or two. The odds are logically that if a dragoon attacks a non-stockaded colony which is undefended, he should win. If a regular attacks a free colonist soldier, (or attacking with artillery), he should win. I do not wish to be argumentative, because I have been playing Colonization for many years, and this is a great replica, with many improved features. However, I am not from another planet, and I know what I have experienced literally hundreds of times--the attack/defense odds simply do not play out like they are designed to. By the way, I playing the game on both Win XP and on Vista, on two different pc's and with two different versions of freecol. Both demonstrate the same problem. In fact, it is the only
problem with the game in my opinion. I cannot stand losing battles when the odds are greatly
on my side--it doesn't make sense. Please believe the contributor who complained about this because it is all too true. I do not belong to this forum, but I just dropped in to see if anyone was asking about this issue, and about why I can't run the newest version on my Vista laptop with Gforce graphic card. Thank you. The Wrath of God
There's a difference between losing _one_ battle against odds (which can and should happen, otherwise the game would be very boring), and losing a great number of consecutive battles, each one against odds (which should not happen, or at least not happen very often).
For example, if the attacker, with all boni applied, has an attack value of 8, and the defender has a defense value of 2, then the attacker will win with a probability of 80% (8/[8+2]), and the defender with a probability of 20%. This means that there's a not overwhelming, but still "good" chance of the defender winning an individual battle.
However, make that 10 consecutive battles, and the probability of the defender winning ALL battles will be 0,2^10 ~ 0. That situation just shouldn't occur.
Still, the probability of winning any single engagement in that 10-round battle is 20% for the defender, so expect at least _some_ units of the attacking force being lost.
Please note that, after reloading a savegame, the units that lost before are still expected to lose if you're repeating the same steps. This is done to avoid cheating, as well as to help the developers debug the game. It's not a bug itself.
So, if you encounter a very improbable "losing streak", please provide a savegame from directly before that streak, and let us know which battles to perform in which order.
For the record, I did an (admittedly small) test of the random number generator just 1-2 weeks ago, and it looked reasonably fair to me.
a question on mechanics of a fight.
I know that the odds are calculated (using the above example 8 human 2 computer 80/20%.)
When doing the random function, does the human always get the same end of the stack (ie get below your number) or does it follow the attacker (ie the attacker always gets that same end of that stack),
I was thinking that this could (stress could) make a difference in the appearance of randomness. Follow my thoughts here. I assume it folows the Attacker/defender. IF the human attacks, they need an 80 or less for a win (and get a 90 roll) but then the computer at 2 attacks and needs a 20 or less to win (and gets a roll of 10). The rolls are therefore 'statistical' but the outcomes seem asymetric only because the possition of attacker and defender change.
This would cause a greater than normal expection of losses, although it would be for large numbers of combats equally skewed the other direction. Of course I don't notice that I've had no losses (with an 80/20 split I should still loose about 2 in 10) But I do notice a string of 3 in a row, despite the random function throwing out numbers from all over.
Again since I didn't program the system, I'm only speculation from the description of how combat is supposed to work.
AC
I'm not sure how reversing or not reversing roles (while keeping the correct probabilities intact) might lead to overall skewed results. Can you explain?
For the record, combat is resolved in the following way:
The "victory" probability of the attacker is calculated as att_strength/(att_strength+def_strength). This is a floating point number in the range [0..1].
Then, a random integer number "R" in the range [0..99] is chosen.
Then, this number is compared to some values:
R <= victory*20 //GREAT_WIN, for example instant sinking of an enemy ship
R <= victory*100 //WIN, for example damaging an enemy ship
...the rest are evasions and losses.
One can easily see that the probability of winning as the attacker really _is_ proportional to the "victory" value.
I believe that the current system of fighting odds is "The "victory" probability of the attacker is calculated as att_strength/(att_strength+def_strength)." as mentioned.
Then, the explanation in the manual; If the attack value of the attacker is greater than the defence value of the defender, the attacker wins; is wrong and should be changed.
I also found minor misprints. In "Skills and Education" section, the manual says "the Expert Fur Trapper, ... all require at least a College." But Fur trapper can be taught in Schoolhouse.
That should be "Master Fur Trader" instead.
The manual currently states:
The combat mechanism of FreeCol is very simple: Each unit has an attack strength and a defence strength. Attack bonuses and defence bonuses granted by terrain, fortifications or Founding Fathers are added to the base values of the units. A random element is then added to the calculations in order to determine the winner of the battle.
Where's the other statement from?
Fixed the Trapper/Trader mixup, thanks.
I have had to sacrifice several Dragoons to beat a single colonist in a town square, on several occasions... Even when the town has no defensive buildings. I have seen this same phenomenon in Indian Villages too...
It appears that the RNG gets stuck at times..... Of course it ALWAYS appears to be stuck against the player.. But then, it is human nature to only remember the negative and forget all those times when you won ten in a row against equal or superior forces...
Abartels and all others,
please understand I am only talking about the appearance of the randomness, not the actual randomness.
If the combat is resolved as described. Where basically R <= target value then attacker wins, I assume else defender wins. (ie no draws)
So player makes 3 attacks, then the computer makes 3 attacks, and the player looses all of them, it could be 3 high rolls (R> target) then 3 low rolls (R<=target) since the in the first 3 the player needed low rolls to win as attacker <= and in the second 3 he needs high rolls > target to win.
Again this gives the appearence of no randomness ie human 'always' loose but the reality is the underlying randomness is there (some high, some low) just the desired result for the human - ie they want a low result or high result changes based on what role they are in the combat of attacker or defender.
And I agree with Cyber Troll with the 'human nature to only remember the negative...'
Although my personal experience has been strings of bad results for me, and strings of good results, very few times where I have alternating results. And in those strings the results were I'd say 'mixed' meaning sometimes the individual results went with the odds and other times against the odds.
AC
Ah, now I see where you're coming from - yes, you're right, for a "losing streak" across turns (both attacking and defending), the RNG will pretty much have to generate numbers from the whole range. I assumed that most complaints in that regard were specifically about player action (=attacking), though.
To repeat, the code regarding combat resolution, as well as the RNG output itself, doesn't show any signs of weakness. If you still encounter unexplainable "losing streaks", this may be a bug hidden elsewhere - for example miscalculating some unit defense strength, or some other exceptional condition leading to seemingly invincible units. If something like this happens, a savegame from directly before would really be helpful.
Um, I think I know where the confusion comes from. Col is/was a weird game in terms of fighting ods, as in fact many of Micro Prose/Firaxis games.
It's creators apparently don't like to leave too much to bare chance so they throw in hidden rules, and modifiers which cause this eerie feling when playing Col; sometimes you just know, you are going to win in a given situation although the official odds may seem to be stacked against you... . Or Vice Versa.
I'd reccomend testing Col combat in cheat/debug mode so that the multiple hidden modifiers are exposed. I'm not arguing that FreeCol must necessarily copy those, never the less, it would shed some light on how the odds really work... .
Another thing about the odds that bothers me is no availablity of a draw in land combat - In sea combat the other ship sometimes 'sails away' or whatever the phrase is.
I was thinking that a flat value of 1 would be put into all the combat odds calculations so attacker has after mods a 2 and defender a 2 so the break would be 40/20/40 Attacker/Draw/Defender. With more skilled combatants on both sides leaning towards engagement and less skilled trying to avoid it/getting killed. At Attacker 5, Defender 4 it would be 50/10/40 for Attacker/Draw/Defender.
We can debate if green troups are more likely to try and get a draw verses veterans, but I was thinking that they would and that's why I was thinking a flat 1 rather than a flat % per combat.
Since I am only an enjoyer of the game and not a programer, the programers can ignore me. ;)
AC
I have an interesting discovery to announce.
The combat odds in Colonization are rigged. They depend on difficulty setting.
Enter the following search string in Google:
java random number bug
The first two results are addresses at bugs.sun.com
I suspect the freecol code is just fine (though I haven't looked at it), and java is the culprit.
Roger
Well - both bug reports were submitted over a decade ago (so are most likely fixed by now), and additionally describe situations that don't really match the "problem" here.
Also, as I stated earlier in this thread, tests of the RNG so far showed no signs of any considerable weakness. These tests were done by, for example, patching the battle outcome calculation to not get one random number, but 10K and averaging them up - or by calling nextInt(10) several thousand times and counting the different outcomes.
So, if it's a Java problem, it's one that doesn't exist in the version on this computer. ;)
Other than that, it could only be an unrelated bug in the game that just appears as "strange odds" under specific circumstances (in which case, we'll definitely need a savegame!) or, more likely, just wrong expectations.
>abartels
>The manual currently states: ...
Where's that manual?
The manual I have (PDF contained in the 0.8.4 version), the HTML and PDF on freecol.org;
all three documents say "If the attack value of the attacker is greater than the defence value of the defender, the attacker wins; is wrong and should be changed."
http://www.freecol.org/documentation/freecol-user-manual.html
Ah, I see. This had been changed in the development version in May already, so will be a part of the next major release: http://freecol.svn.sourceforge.net/viewvc/freecol/freecol/trunk/doc/FreeCol.tex?r1=5403&r2=5429
Oh, have just had fun on debians freecol 0.8.4 trying to kill a single SpanishVetDragoon. It has already killed like .5K of my horses (almost all of them were ridden by veterans as well) and still stands right there before my city. Too bad I didn't save right before the massacre. Neither did I expect him to win (in a row):
1 attack vs. fortified non-vet in a fortress (6 to 7.5 i guess, 44%)
6 defences vs. veteran goons in a prairie (4.5 to 6, 42.8%)
2 defences vs. non-vet soldiers (4.5 to 3, 60%)
a screen of it: http://img529.imageshack.us/img529/1517/freecol.png
and that combination is about to happen only in 0.1% of times if I'm not wrong in math. I guess I'm feeling lucky today! :-D
Ouch.
Yes, it would have been incredibly helpful to have a savegame of that situation.
Did you perhaps save directly after this happened? That save would be less useful, but perhaps not completely useless, either.
Also, do you still have the log file of that game? Log files get overwritten when starting the game, so if you haven't done that since that bug, it may still be available (it's the file FreeCol.log in the directory that also contains the save/ subdir).
If possible, please provide either or both by creating a new bug report on the tracker. Thanks!
Here you are:
https://sourceforge.net/tracker/?func=detail&aid=2851013&group_id=43225&atid=435578