Uncommon Valor and Bug Reporting

[Mike Wood]

Hello...

Matrix Games announced that patch 2.50 would be the last for this game. I did the final patch, 2.50 and fixed all the known bugs, but I would be happy to fix any remaining bugs in UV.

Please keep in mind that by definition, a 'bug' is a piece of computer code that does not do what the programmer intended. Questionable game behaviors might be bugs, design decisions with which you disagree, scenario data entry errors, scenario data decisions with which you disagree, legitimate game rules you do not understand or player error.

To determine which of these the behavior in question is, I need a save of the game on the turn before the reported error occurred. Without a save, it is not and cannot be a bug. It is an ugly rumor.

I also need a bug report. It must contain the game version you have, the type of game (human/human, computer/human, computer/computer) and the side the you are playing, where relevant.

It must also have a description of the reported error, such as, "Game crashes to destop, when 'Load Supply' is evoked". And, a description as to how to reproduce the error, such as, "Start the turn as Allied player, select to Task Force #13, and click on 'Load Supply'. Game will then crash to desktop".

A bug report, such as, "This game sucks", is of little use to me.

A bug report, such as, "This game sucks because it always crashes", is a little better, though not much.

I need to be able to reproduce the error, so that I can run the program through a debugger and study variables, in order to determine what, if anything, is wrong with the code. A save after the reported error verifies an error occurred, but I need a save before the error occurs, so that I can trace it through.

If you have a save for a 'bug' send it to me, along with a description of the reported error and a description as how how to make it occur. I will look at it and report back to you what and why things happened the way they did and if the reported error was a bug, will fix it.

Sample Bug Report:
See attached save.
1) Game version 2.50
2) Allied human vs. Japanese computer opponent.
3) Game crashes to destop, when "Load Supply" is evoked.
4) Start the turn as Allied player, select to Task Force #13, and click on 'Load Supply'. Game will then crash to desktop.

Thanks...

Michael Wood

mikew@matrixgames.com

[borner]

A bug report, such as, "This game sucks", is of little use to me.

A bug report, such as, "This game sucks because it always crashes", is a little better, though not much.


 
has anyone posted such a note in reply to your postings?
 
 
I posted a few I have run into in other threads.... In addition. I am in 5 games now, and will be happy to post things here as we run into them. As for fast transport, and AP task forces for Japan, they often will sail empty when set to auto-convoy between Truk and a given base.
 
In a recent game with IKE, an allied AP TF out of townsville had one AP loaded with CD unit for Japan
 
 
I urge anyone out there playing games and reading this to post about bugs. It does seem Matrix is willing to look into the issues we have been discussing for a long time. Lets take full advantge of this!!!!!
 

[borner]

The Japanese A6M5-B ZEKE recieves no replacements in the game. This is probably not a bug but was overlooked and I think he could fix easily.

Also, when units are given marching orders and are march say 20 kilometers and are attacked, their marching distance resets to zero.

For example, in one game, a unit was marching from Lae to Nadzab and had 28 kilometers marched to the distance. the US dropped a parchute group on them and attacked to recon my forces in Lae. All marching distance reset to zero so they never could leave Lae. This happens all the time.

[Mike Wood]

Hello...

The Japanese A6M5-B ZEKE receives no replacements in the game. Nor do the early B-17 squadrons starting in Australia. These were decisions made by the fellow who did the historical research when he wrote the scenario. I hesitate to second guess him. He may have meant it and it may have been an oversight. Do not know. As programmer, I had nothing to do with scenario generation, as it had nothing to do with the game code. I wrote a scenario editor and gave it to historians, who wrote the scenarios. I haven't even looked at any of them, except for the long campaign that I played. What might be more useful, would be to release an editor that would allow the end user to modify or create his own scenarios. Will talk to David about that.

"...when units are given marching orders and are march say 20 kilometers and are attacked, their marching distance resets to zero"

Yes, that is how I programmed it. That is the rule. That is how it is supposed to work. I do not know where the units have moved within the 60 mile hex, during combat or how long it would take the elements of the units involved to reorganize and return to travel mode. This rule was tested by the quality control folk, during game development and they liked it. You do not seem to.

I do not wish to stifle discussion, so do please continue to post issues as they come to mind and if you can find a bug with a save send it to me.

Thanks...

Michael Wood

ORIGINAL: borner

The Japanese A6M5-B ZEKE recieves no replacements in the game. This is probably not a bug but was overlooked and I think he could fix easily.

Also, when units are given marching orders and are march say 20 kilometers and are attacked, their marching distance resets to zero.

For example, in one game, a unit was marching from Lae to Nadzab and had 28 kilometers marched to the distance. the US dropped a parchute group on them and attacked to recon my forces in Lae. All marching distance reset to zero so they never could leave Lae. This happens all the time.

[borner]

yes, and one that allows us to adjust the various strengths of planes a bit to correct what many of us see as issues there. this would be wonderful

[borner]

another bug we had was a Japanese land unit was landed at Luganville in a game with IKE, and defeated. It then kept re-appearing there for a couple of weeks.
 
On another point, I understand IKE was put in a "time out" for misconduct, but as one of the most experienced players around, I would urge he be allowed to give his imput. I also hope Tocall, Nopmad and others will chime in when they read this. As I said, this is a great opportunity, and one many of us have been waiting for.

[borner]

this one is from IKE, but it a great point.. the combat replay for the Allies will commonly differ greatly from that of Japan. This gives the Japanese player a huge advantage in knowing accurate combat details, where the US player cannot.  example: replay for Japan shows 1 bomb hit on Akagi, US replay shows 5. So, while Japan knows Akagi is slightly damaged, the US player really does not.
 
 

[Nomad]

I'll chime in Brian, but I doubt you will like what I have to say.

There are some design issues with UV, but Mike is not going to fix that directly. It might be possible for them to resurrect a better editor and that would help. I have seen some of the out of sync problems, but they have worked on those from the beginning and it was even in WitP and they have never completely eliminated it. I have spent hours trying to help track down that problem with little effect. I don't remember who I worked with and I believe that they have found multiple things that could cause it.

As far as other 'bugs' I haven't really seen any. I have seen times when the program did something I didn't like and I have had opponents complain about what happened, but as far as I could determine, the program was operating as designed. Now, as to whether the design was right or not, that is a completely different matter.

Note, that I did not play UV for 2 or 3 years and then last year I played 5 or 6 games with no problems that spoiled my game. I am no longer playing UV so I will have no save games available.

[Mike Wood]

Hello...

This is due to design limitation. The comabt replay is not a special kind of file. It is just a copy of the saved game with a toggle set. That means it replays every time the same, unless a player hits a key requiring a random dice roll, since the random generator seed is saved with the game. The only way to fix this is to lock the keyboard during execution of PBEM game. I did this in a WIP patch. Could do it with UV. The effect would be no hitting ESC to ignore a combat. Both players would have to sit through all combats. Would need some other players to claim they wanted this before I would do it.

In the example you gave the Allied player ignored the citation I gave concerning the issue and hit escape at some point. After that, the replay was off by at least one one randon die roll and showed garbage.

I just talked myself into doing it. Will fix, by locking keyboard. That should eliminate most out of sync issues.

Bye...

Michael Wood

ORIGINAL: borner

this one is from IKE, but it a great point.. the combat replay for the Allies will commonly differ greatly from that of Japan. This gives the Japanese player a huge advantage in knowing accurate combat details, where the US player cannot.  example: replay for Japan shows 1 bomb hit on Akagi, US replay shows 5. So, while Japan knows Akagi is slightly damaged, the US player really does not.

[borner]

Nomad -
 
Bug or game design, but did you and Tocaff not have a game recently where a lot of your TF's went off and did things against orders? I need ot go back through the ARR's and see if I am right, but I am almost sure of this.
 
glad to hear from you though, hope all is well

[fuelli]

ORIGINAL: Mike Wood

Hello...

This is due to design limitation. The comabt replay is not a special kind of file. It is just a copy of the saved game with a toggle set. That means it replays every time the same, unless a player hits a key requiring a random dice roll, since the random generator seed is saved with the game. The only way to fix this is to lock the keyboard during execution of PBEM game. I did this in a WIP patch. Could do it with UV. The effect would be no hitting ESC to ignore a combat. Both players would have to sit through all combats. Would need some other players to claim they wanted this before I would do it.

In the example you gave the Allied player ignored the citation I gave concerning the issue and hit escape at some point. After that, the replay was off by at least one one randon die roll and showed garbage.

I just talked myself into doing it. Will fix, by locking keyboard. That should eliminate most out of sync issues.

Bye...

Michael Wood

ORIGINAL: borner

this one is from IKE, but it a great point.. the combat replay for the Allies will commonly differ greatly from that of Japan. This gives the Japanese player a huge advantage in knowing accurate combat details, where the US player cannot.  example: replay for Japan shows 1 bomb hit on Akagi, US replay shows 5. So, while Japan knows Akagi is slightly damaged, the US player really does not.

I have to report that this thing happens also when no one ever touches the keyboard. My opponent RGIJN and I have to deal with it since weeks and we both have taken care of this work around but it did not work.

[Mike Wood]

Hello...

A work around would be for the Japanese player to send his combat report to the Allied player, who can rename it and look at it.

Will work on it...

Michael Wood

ORIGINAL: fuelli

ORIGINAL: Mike Wood

Hello...

This is due to design limitation. The comabt replay is not a special kind of file. It is just a copy of the saved game with a toggle set. That means it replays every time the same, unless a player hits a key requiring a random dice roll, since the random generator seed is saved with the game. The only way to fix this is to lock the keyboard during execution of PBEM game. I did this in a WIP patch. Could do it with UV. The effect would be no hitting ESC to ignore a combat. Both players would have to sit through all combats. Would need some other players to claim they wanted this before I would do it.

In the example you gave the Allied player ignored the citation I gave concerning the issue and hit escape at some point. After that, the replay was off by at least one one randon die roll and showed garbage.

I just talked myself into doing it. Will fix, by locking keyboard. That should eliminate most out of sync issues.

Bye...

Michael Wood

ORIGINAL: borner

this one is from IKE, but it a great point.. the combat replay for the Allies will commonly differ greatly from that of Japan. This gives the Japanese player a huge advantage in knowing accurate combat details, where the US player cannot.  example: replay for Japan shows 1 bomb hit on Akagi, US replay shows 5. So, while Japan knows Akagi is slightly damaged, the US player really does not.

I have to report that this thing happens also when no one ever touches the keyboard. My opponent RGIJN and I have to deal with it since weeks and we both have taken care of this work around but it did not work.

[fuelli]

I usually receive the combat report from my opponent, therefore I have the information that are in the combat report. But the little things that happen during the combat replay that are not mentioned in the combat report get lost.

ORIGINAL: Mike Wood

Hello...

A work around would be for the Japanese player to send his combat report to the Allied player, who can rename it and look at it.

Will work on it...

Michael Wood

ORIGINAL: fuelli

ORIGINAL: Mike Wood

Hello...

This is due to design limitation. The comabt replay is not a special kind of file. It is just a copy of the saved game with a toggle set. That means it replays every time the same, unless a player hits a key requiring a random dice roll, since the random generator seed is saved with the game. The only way to fix this is to lock the keyboard during execution of PBEM game. I did this in a WIP patch. Could do it with UV. The effect would be no hitting ESC to ignore a combat. Both players would have to sit through all combats. Would need some other players to claim they wanted this before I would do it.

In the example you gave the Allied player ignored the citation I gave concerning the issue and hit escape at some point. After that, the replay was off by at least one one randon die roll and showed garbage.

I just talked myself into doing it. Will fix, by locking keyboard. That should eliminate most out of sync issues.

Bye...

Michael Wood

I have to report that this thing happens also when no one ever touches the keyboard. My opponent RGIJN and I have to deal with it since weeks and we both have taken care of this work around but it did not work.

[Puhis]

If I try to air transport for example japanese base force, always at least 2 support group is left behind. Planes just don't transfer these groups.

Is this bug, or is it programmed rule?

[Mike Wood]

Hello...

Don't know circumstances. Send me a save and bug report.

Thanks...

Michael Wood

ORIGINAL: Puhis

If I try to air transport for example japanese base force, always at least 2 support group is left behind. Planes just don't transfer these groups.

Is this bug, or is it programmed rule?

[Miller]

Any chance of opening up the aircraft stats for modification as in WITP.......would give any potential modders out there the chance to breath new life into the game.

[Mike Wood]

Hello...

Maybe later. Production is concentrating on the WIP expansion, right now.

Bye...

Michael Wood

ORIGINAL: Miller

Any chance of opening up the aircraft stats for modification as in WITP.......would give any potential modders out there the chance to breath new life into the game.

[borner]

as a regular issue I will select TF's in truk to load units, and even though they have more than enough room, only partial units are loaded. Is this a bug or game feature?

[Kingfisher]

For what its worth, here is a thread discussing Japanese LRCAP and refusal of LBA to strike TFs covered by said CAP:

tm.asp?m=1945397

It appears Hans has moved on to WitP so I doubt a saved game file exist.

[Mike Wood]

Hello...

Just read thread. Wouldn't need a save for the long range combat air patrol (LRCAP) and land based aircraft versus task forces covered by combat air patrol (CAP) issues. The rules of the game allow CAP and LRCAP to cover task forces. Single and twin engine aircraft will not attack such a task force without fighters flying escort. Four engine bombers will fly in the face of CAP or LRCAP without escort.

The rule has changed a number of times during the development of the series and patches.

I have always preferred to allow attacks on bases or task forces with no concern for CAP. This does allow a player to sucker the other into attacking a base or task force and destroy the single and twin engine bombers by the drove. Those who oppose the rule say it allows one player to exploit the rule using bait, such as 5 empty cargo ships with 500 fighters flying LRCAP or 6 carriers stationed at Rabaul flying 90% CAP along with 500 land based fighters flying LRCAP at a range of zero. Every B-25 and B-26 available would be shot down in short notice.

The alternative is what we currently have. The bomber groups have really good Intel as to how many fighters are flying CAP and LRCAP and refuse to get slaughtered. They will not fly without fighter escort. This allows a player, in the early game the Japanese, who has long ranged fighters in large numbers to cover task forces and make them pretty much immune to attack until the other player gets long ranged fighters to fly cover. Proponents of this rule would argue that the task forces are really immune anyway and this way, they don't loose 50 or 60 B-25 bombers for nothing.

Have tweaked this a number of times over the years and do not feel that any changes that could be made would suit all, as so far none have.

Bye...

Michael Wood

ORIGINAL: Kingfisher

For what its worth, here is a thread discussing Japanese LRCAP and refusal of LBA to strike TFs covered by said CAP:

tm.asp?m=1945397

It appears Hans has moved on to WitP so I doubt a saved game file exist.