frnsys / half_earth

Half-Earth Socialism: The Game, for Half-Earth Socialism (Verso 2022)
GNU Affero General Public License v3.0
39 stars 7 forks source link

Changes in production does not go through in first cycle #287

Closed maltegartner closed 3 months ago

maltegartner commented 3 months ago

First cycle: I change production mix in electricity, fuel and crops by removing 20% from one (biofuels 15% and coal 5%, for example) and adding to another (natural 20%). Only 15% of that goes through. In electricity, nothing goes through on the first cycle.

A note at the bottom says "These changes will tale 1 planning cycle to take effect". It doesn't.

If there's some logic to the game that the changes can't happen after all, it would be interesting to learn something from it - resource need or whatever.

sgitkene commented 3 months ago

I had the same issue, see https://github.com/frnsys/half_earth/issues/277

The changes to calorie production (crop and livestock agriculture) don't seem to go through at all.

AutumnIsilme commented 3 months ago

I've been trying the website version out today, and it looks like only one category of production changes per planning cycle, with a priority order of Fuel > Electricity > Crops > Livestock. This means that if you have any changes lined up in Fuel, then nothing else goes through.

In the itch.io version, sometimes things would take longer than suggested to build out or wind down, particularly industrial agriculture would often show as 1 cycle to decrease after the places it had been changed to had built out in actually 1 cycle, but all the categories were built separately.

AutumnIsilme commented 3 months ago

Update: On a cursory glance at the code, I think the culprit will be the update_processes function at game.rs:295. The rem_pts and add_pts are set once then used for all the changes, so only 5 points of each are allowed across all types of production. Also, the while loop only continues while there is still budget for both removing and adding production, so when one goes to zero before the other, the loop stops but in theory there should still be budget to continue.

The reason for the priority order is probably the order that the production category Output type is defined, at kinds.rs:392, although this is not actually that relevant.

If this issue is not an intentional change, I think modifying update_processes to something like

for (_output, changes) in changes.iter_mut() {
    let mut rem_pts = consts::PROCESS_POINTS_PER_CYCLE;
    let mut add_pts = consts::PROCESS_POINTS_PER_CYCLE;
    while (rem_pts > 0 || add_pts > 0) && !changes.is_empty() {
        for (process_id, change) in changes.iter_mut() {
            if *change < 0 && rem_pts > 0 {
                rem_pts -= 1;
                self.change_process_mix_share(
                    process_id, -1,
                );
                *change += 1;
            } else if *change > 0 && add_pts > 0 {
                add_pts -= 1;
                self.change_process_mix_share(
                    process_id, 1,
                );
                *change -= 1;
            }
        }
    }
}

My rust is a little rusty (sorry), so I'm not submitting a pull request right now, but feel free to use this if it is correct or useful to any degree. It should allow exactly PROCESS_POINTS_PER_CYCLE additions and PROCESS_POINTS_PER_CYCLE subtractions for each Output/production category type per planning cycle.

EDIT: My logic the other day was severely flawed. I actually downloaded and ran the project this morning, and this new version actually works.

sgitkene commented 3 months ago

I think if the steam/itch.io versions are the "model", there were 5 points each category. Here's a short video what it looks like: https://youtu.be/R3f76gnOrDs

frnsys commented 3 months ago

Thanks for the report and the help investigating--i was able to create a test reproducing the problem and have a fix that I'll deploy after getting through some of these other issues