UberFunBunny

Switching the files helps but isn't a complete solution. There was an excellent mod that fixed this for CMBB. It left the ' > ' and ' " ' icons as is, but switched the words "Play" and "Pause". This allowed for normal behavior - eg, when playing, there is a flashing ' > ' icon and the word "Pause". The way it is setup by default is nonsensical. The button should have written on it the action if you were to push it, not the word for the action that it is currently doing. To *pause* the game, the user should push the "Pause" button, not the "Play" button !!

Arghhhhh! Mod, anyone?

Does BFC accept gold? -------------------- UberFunBunny [ October 10, 2003, 11:55 PM: Message edited by: UberFunBunny ]

Good question....

Cassino.

No worries. I signed up with my nick without knowledge of this other poster; had I known of him I wouldn't have chosen a similar name. He seems to have caused a lot of grief!

I'm a little disappointed that it won't be in CMAK, but thanks for the comment Madmatt.

...or it tells you that we've been around this block a few times already. I independently thought up with the same fix you mention above; I see no problems with it; I agree with you complêtement. The answer to MikeyD's objection is simple and natural: If a "better" HQ comes along, whom you WANT to "take over", then you simply move BetterHQ closer-- give Mortar Man an order to ceasefire-- in limbo, MM is by default under the closer, BetterHQ's command-- give a new Target command-- all is well. IOW, the "stickiness" is only for the duration of the current Target command. It seems like an all-benefit-with-zero-cost fix to me. Eden [Edit: Oops-- need to update my sig file] </font>

A tactic I used once to remove an "unwanted" HQ from my mortar was to send him out into open ground to be cut down by machine guns. The lack of response to this thread tells me that using the above type of unrealistic tactic (another example being redwolf's area fire) is preferred to actually fixing the problem.

Any comments on my "stick with HQ until it loses command range" tweak for teams (or mortars only)? I think it would be better than the current situation, and shouldn't be too hard to code. -------------------- UberFunBunny [ August 28, 2003, 03:41 AM: Message edited by: UberFunBunny ]

A Company HQ won't grab command of a platoon from a Platoon HQ if the Platoon HQ has command range (even if the Company HQ is closer). As you can see there is already an exception to the "closest HQ takes command" feature. I'm also really talking about teams, and in particular mortars. -------------------- UberFunBunny [ August 27, 2003, 08:00 PM: Message edited by: UberFunBunny ]

How about this: Once a team has an HQ assigned by the AI, it will stick with that HQ until it loses command range. In other words, if another HQ comes within command range, that new HQ won't grab the team until the current HQ loses command range. This, hopefully, would be a relatively simple "behind the scenes" tweak (as opposed to a player assigning HQs which could be difficult to code). Edit: Possible consequences of this change? -------------------- UberFunBunny [ August 27, 2003, 07:34 PM: Message edited by: UberFunBunny ]

Twat, No.

There are some quirks in CMBB that are annoying, but none more so than the way teams grab an HQ. Any chance of allowing players to designate teams to an HQ in command range for CMAK? As for the other quirks, I can put up with those.... [Edited to rephrase.] -------------------- UberFunBunny [ August 28, 2003, 06:44 PM: Message edited by: UberFunBunny ]

A good idea would be to allow the option of extending the game at the end of "regular time" if both players agree to it. I think *auto*-ceasefire should be a setup option or dropped completely.

YOU owe ME!!!! </font>

MD: Any chance you could send me a turn??

Seconded!

This is obviously a bug.

Not sure if this has come up, but how about a "continue game" option if both players agree to it at the end of regular time?

Let's hope it's not a case of the "difficult second album"....

Thanks guys.

Fuerte: Thank you! What a wonderful program. Again, thank you!

What he said. </font>

The main problem with the autoceasefire "feature" is that it exists at all.