Page 1 of 1

Worklist purging behaviour changes 2.6 -> 3.0 (civ2civ3)

Posted: Sat Jan 11, 2020 9:35 am
by chippo
In version 2, if a building (not units - we're only talking about buildings in this message) is in a worklist, has already been built and comes to the front of the queue, then, the building is purged from the worklist, a message telling you this appears in Messages, and the city continues building the next thing.

In version 3, this is changed and you get "City can't build Improvement from the worklist; reason unknown! Postponing..." in Messages, the building stays at the front queue and the city keeps building it. You must then manually delete it from the worklist.

The new behaviour can be useful in two edge cases, but there are so many other reasons that it's real bad, that I think that the new behaviour is unintentional and therefore a bug.

The two edge cases where the new behaviour is an improvement are the power-problem and the sewer-shit.

The power-problem is where you mess up and unnecessarily build more than one power station for a city. There are several ways to get this wrong and several ways to correctly-intentionally get it right (build more than one). The most irritating is when you own the Hoover Dam (somewhere), have Hydro in this city, and the city happily goes on and builds a redundant Solar. The new behaviour prevents the power-problem, because earlier on you got the above message and have already been forced to think about it.

The sewer-shit is caused by the requirement of having to have 9 pop to build the sewer. You get 9, you queue a sewer, you get hit by plague (the exact problem you're trying to solve) and when sewer gets to the front of the queue it won't build. With the new behaviour you're forced to think about it, and sort it out somehow.

For everything else, the new behaviour is bad. In fact, one of my solutions for the sewer-shit (and other problems) was (when I noticed it) to just throw a worklist of all improvements at the city and it'll purge the one's it has and build the ones it hasn't. With the new behaviour, this just doesn't work at all.

Does anyone agree with me? Can I raise it as a bug on hostedredmine? Or is there (again) something I haven't read that makes the new behaviour sensible?

Re: Worklist purging behaviour changes 2.6 -> 3.0 (civ2civ3)

Posted: Sat Jan 11, 2020 11:46 am
by JTN
The appearance of the "postponed" worklist messages:
  • was intentional (hrm #846514);
  • changed between 2.6.0 and 2.6.1, it's not new with 3.x (NEWS-2.6.1: If a city starts to build an improvement from the worklist whose requirements are not yet met (for instance, its technology is not yet known), it will now be left on the worklist, rather than purged. The city will accumulate production points until the requirements are met or the player intervenes. (This is a longstanding feature, but has been broken for a long time.)
  • isn't ruleset-specific (so I've moved this topic).
It's longstanding code that we noticed wasn't being enabled due to a bug. We re-enabled it, under the assumption it was working and sensible code. But I've since noticed various trouble with it, including the "reason unknown" with duplicate buildings that you mention, as well as trouble when a not-yet-buildable unit comes to the head of the worklist. Clearly it needs more work.

I haven't had the effort to characterise exactly what's going wrong, though. Please do raise bug(s) on hostedredmine with reproducible case(s) where it's doing something silly, and describe what you would expect it to do instead.

Re: Worklist purging behaviour changes 2.6.0 -> 2.6.1 (& 3.x)

Posted: Wed Jan 15, 2020 9:27 am
by chippo
JTN wrote:The appearance of the "postponed" worklist messages:
  • was intentional (hrm #846514)
  • changed between 2.6.0 and 2.6.1, it's not new with 3.x
  • isn't ruleset-specific (so I've moved this topic).
Thank you for moving the topic. You should have also changed the subject... which I'll attempt now...
JTN wrote: It's longstanding code that we noticed wasn't being enabled due to a bug. We re-enabled it, under the assumption it was working and sensible code. But I've since noticed various trouble with it, including the "reason unknown" with duplicate buildings that you mention, as well as trouble when a not-yet-buildable unit comes to the head of the worklist. Clearly it needs more work.
Since I originally posted, I've had more experience and like more of the new behaviour. In fact, the behaviour I'd like the most ('specially since it should be easy to implement) is, use the new behaviour with one additional test - if we have already built this exact building, don't print the 'postponed' message, rather just purge it.

I haven't seen any unit-trouble, yet, but my worklists tend to have a caravel in the position I want a transport built, so that that worklist can be used under various tech-levels and produce a caravel, galleon or transport as appropriate.
JTN wrote: I haven't had the effort to characterise exactly what's going wrong, though. Please do raise bug(s) on hostedredmine with reproducible case(s) where it's doing something silly, and describe what you would expect it to do instead.
I shall, with a savegame and all. I just wannu play with not-yet-buildable units a bit first, so that my bug report might be more complete and consistent than several recent ones...