BUFFY-3.19.002 Public Beta (Released!)

[Denniz]

Wrong attitude Denniz.

Those happy/unhappy faces give important info :
- when a civ goes cultural (extra besides the slider)
- when to use the unhappy spy operation
- to capture or to raze an enemy city (whip anger)
- to help vassals/ally with unhappiness in their cities
- to see which cities have the defy resolution penalty
- when a civ is in anarchy

With one look you'll have the un-/happiness status of the opponents.

Sorry but we have to balance the impact of the bug against the confusion/disruption of doing another release almost immediately to fix a single bug.

As for the happiness display, you can still see the net happiness (not the reasons) by hovering over the city bar. This affects foreign cities only, so you need to have Investigate city on that rival or have them be on your team or a vassal.

From what EF says, It sounds like you can get the basic information from the city bar hover. The current plan is to do a quick turnaround on .003 in a few weeks rather than doing something immediately. That way we have some time to flush out anything else that needs done.

 

[ZPV]

There is a bug with PreChop - it doesn't work when you are using more than one worker to chop a forest.

The current logic looks at the tile to see if there is 1 turn left after putting a turn of chopping in - this fails with multiple workers. It can be corrected by instead looking at the number of turns left on the mission (as displayed when hovering over the chop button). So the new logic would be: chop, check to see 2 turns left, if so cancel mission. With multiple workers, their mission times will increase as the first one cancels its mission, so it will continue down to 1 turn to chop.

 

[EmperorFool]

I have this commented in the code. I don't think what you propose would work.

1. Worker A chops
2. Worker A has 2 turns left, stops
3. Worker B chops
4. Forest removed

The real solution is that I must scan the plot for all Workers doing the same build order. There is no solution that doesn't get the two workers communicating somehow.

The temporary workaround until then is to group your workers that are pre-chopping the same plot. The entire group is stop with 1 turn remaining no matter how many workers are in the group.

 

[ZPV]

One of the workers would already have stopped on the previous turn, under my solution (the mouseover takes all working workers into account - this should provide a shortcut to scanning for all workers on the tile).

So (this example is on Epic Speed):

turn 1:
Worker A chops, 5t remaining
turn 2:
Worker B chops (player action), 2t remaining, action cancels
Worker A chops, 3t remaining
turn 3:
Worker A chops, 2t remaining, action cancels
Worker B becomes active for the player to direct.
turn 4:
Worker A becomes active for the player to direct.

 

[EmperorFool]

That leaves forests with 2 turns to complete the chop. And if you have more workers on the plot, it will be different. Plus it depends on the order in which you issue the orders.

Turn1
Worker A chops, 5t
Worker B chops, 2t, stops
Turn2
Worker A chops, 3t
Worker B free to do stuff, so what do you do? tell it to chop? have it move? Let's say you chop
Worker B chops, 1t
Turn3
Worker A chops, 1t
Worker B chops, forest cleared

Let's say you told worker B to leave instead
Worker B leaves
Turn 3
Worker A chops, 2t, stops
Turn 4
Worker A leaves, forest requires 2 turns to chop

In my book, a pre-chopped forest should be left with 1 turn remaining, otherwise it's only half-chopped.

Really, the workers need to be stopped as a group by the worker that chops the forest down to 1 turn left. I'll get to it eventually.

 

[ZPV]

What I mean by "2 turns left on turn n" is, it can't make the last turn of the chop until turn n+1 - even if it has already chopped this turn, so one extra worker-turn could finish the chop on turn n.

Basically, I'm just reading off the "traditional" tooltip from a worker working.

So:

Turn 1
Worker A chops, 5t left
Worker B chops, 3t left
Turn 2
Worker A chops, 2t left, stops
Worker B chops, 2t left, stops.

I see your point about the first example though - when a second worker arrives when the first has 3t left, it misses the trigger to stop, as I defined it. I guess that could be solved by moving the check to eot, but then it's starting to become a lot of work for what is really a fairly minor issue.

 

[EmperorFool]

It's much easier to just scan for all workers that are chopping and stop them. For now, just group workers if you want to have multiple pre-chop. However, it's inefficient to use more than 1 worker to pre-chop unless you are under a deadline. Each (non-fast) worker wastes 1 turn moving onto the forest.

 

[ZPV]

Certainly. I agree it's inefficient - I just noticed it since I was chopping regularly, with multiple workers, and they didn't stop.
I suppose I should really leave argueing about the best way to write the code to the people who actually do it.
Good luck!

 

[WastinTime]

Yes, leave the coding to EmperorFool, but he should leave the strategy to us! Multi-worker chopping is good strategy even if it's not "efficient". Having 3 workers chop a forest 6 turns faster means Oxford earlier, miltary sooner, etc. Totally off-topic for this thread, but I couldn't resist.

LOVE the pre-chop feature btw. Even a little buggy.

 

[EmperorFool]

Multi-worker chopping is good strategy even if it's not "efficient". Having 3 workers chop a forest 6 turns faster means Oxford earlier, miltary sooner, etc.

Notice that I said "multi-worker pre-chopping." But I do look to BUG's users for good strategies and useful features. I have a limited play style and certainly don't claim to know the best way to do anything.

 

[jesusin]

Hi.
I think I've found a new Buffy001 bug. I don't know if it is still existing in Buffy002.

When an AI sets up a new colony, you can't see the number of cities of the new civ in the lower right part of the screen.

The example save I have is from an active competition, so I'd prefer to send it to someone privately.

 

[EmperorFool]

When an AI sets up a new colony, you can't see the number of cities of the new civ in the lower right part of the screen.

There are a few cases where you cannot see the list of cities a rival has. In these cases BUFFY counts up the revealed cities on the map and adds the capital if it hasn't been revealed yet. This value is shown in cyan. Are you not seeing any value, or are you seeing a cyan value?

• Rival refuses to talk (e.g. after initial DoW or agreeing to embargo)
• Rival is a vassal/colony

 

[jesusin]

There are a few cases where you cannot see the list of cities a rival has. In these cases BUFFY counts up the revealed cities on the map and adds the capital if it hasn't been revealed yet. This value is shown in cyan. Are you not seeing any value, or are you seeing a cyan value?

• Rival refuses to talk (e.g. after initial DoW or agreeing to embargo)
• Rival is a vassal/colony

Ok, there's a logical explanation then.

I was seeing no number at all, even though I had direct visibility of one of the cities and religious visibility of another.

 

[EmperorFool]

Ok, there's a logical explanation then.

I was seeing no number at all, even though I had direct visibility of one of the cities and religious visibility of another.

Oh? No, in that case you should have seen a cyan 1 in the scoreboard (2 if that visible city wasn't their capital). It should never be blank because it can always assume a capital. Could you email/PM me a save please?

I hadn't considered religious visibility. How does that show up in the game?

I also didn't consider trade routes. Can you have a trade route to a city that you haven't revealed? My guess is no, and I don't need to consider them, but I'm not sure.

 

[hhhawk]

Hi.
I had problems at start BUFFY-3.19.002.
When game starts - there is no interface and no civilopdedia.
It was possible to find out that if to put english codepage for programs not supporting unicode the error disappears.

My OS - Win XP SP2 rus.
BUFFY-3.19.001 and others mods - work properly.

How to solve this problem, without compulsory installation of english codepage or installation any english OS?

 

[EmperorFool]

I didn't think I changed BugPath.py between BUFFY v1 and v2, but that must be the case. The only non-code solution would be to use the /AltRoot option in Civ4 to put your CivlizationIV.ini file, saved games, etc. into a folder that doesn't have a non-Latin character in it.

Otherwise I'll just need to fix this in v3 somehow.

 

[Sun Tzu Wu]

I appeared to be unable to start autolog.txt feature, but it seems that the conditions for the autolog.txt file creation and header writing have changed:

Under BUG Mod Options (CTRL-Alt-O), Logging Tab, Enable Logging and Start Automatically are checked.

Path: C:\Users\admin\Documents\My Games\Beyond the Sword\AutoLog
File: autolog.txt

Use Default File Name is unchecked.

Every game I start fails to write the expected autolog.txt file. I've also tried typing Alt-L and not typing Alt-L, but nothing seems to trigger any output to the autolog.txt file or create it, except ...

I just tried Alt-E and entered a player comment and that finally triggered the file creation, but I wouldn't think that one would have to force something into the log or take other action that is logged before the file is created. The log identifies itself as 3.19.002.beta2; is that correct?

For the Player Comment, the prefix "Player Comment:" with a ":' would be preferable to "Player Comment" without a ":".

I just got used to seeing a log file creation when ever a game is started (prior to any other logging event). This no longer happens now when one starts a Game to run MapFinder which doesn't do anything that is otherwise normally logged. The Game start was always logged in BUFFY-3.19.001, but this no longer happens in BUFFY-3.19.002 until some other event requires logging. I can live with it this trivial change in function, but it was totally unexpected and very confusing for a few hours.

Sun Tzu Wu

 

[ruff_hi]

The log identifies itself as 3.19.002.beta2; is that correct?

Yeah - we slipped up and forgot to change a text only description field. It also appears when you hover over the flag.

For the Player Comment, the prefix "Player Comment:" with a ":' would be preferable to "Player Comment:"

I'm missing something here - aren't your two prefixes the same?

I just got used to seeing a log file creation when ever a game is started (prior to any other logging event). This no longer happens now when one starts a Game to run MapFinder which doesn't do anything that is otherwise normally logged. The Game start was always logged in BUFFY-3.19.001, but this no longer happens in BUFFY-3.19.002 until some other event requires logging. I can live with it this trivial change in function, but it was totally unexpected and very confusing for a few hours.

To the best of my knowledge - we didn't change anything to do with the logger from .001 to .002.

 

[Sun Tzu Wu]

Yeah - we slipped up and forgot to change a text only description field. It also appears when you hover over the flag.

I'm missing something here - aren't your two prefixes the same?

Sorry, I posted the message before verifying it ... my comment should have read ...

For the Player Comment, the prefix "Player Comment:" with a ":' would be preferable to "Player Comment" without a ":".

To the best of my knowledge - we didn't change anything to do with the logger from .001 to .002.

Game starts with 3.19.001 were always logged, regardless of whether the Game was played, immediately terminated or MapFinder was started.

Game starts with 3.19.002 are now only logged when there is something else that needs to be logged. If nothing else needs logging, the Game start (BUFFY-3.19.002 header) is not logged whether the Game is terminated or MapFinder is run.

Although the difference is trivial, it was enough to convince me that either logging was broken or I was simply too stupid to turn it on. My point is it shouldn't take a competent Player two hours to turn on logging and verify that it was turned on. Simply starting a Game should cause the BUFFY-3.19.002 to log its header, but it does not do so. Check it out for yourself; its not that hard to verify this bug or new feature. Since you claim to have not changed the logging code and logging has changed, I suppose that makes it bug rather than a new feature .

Sun Tzu Wu

 

[EmperorFool]

I think I changed this as I viewed logging the header when nothing needed to be logged as a bug. I should have added it to the changelog for sure, and I completely forgot I had done it. I was just doing routine code cleanup while working on something else, and it caught my attention.