The bot purchases large amounts of energy trying to fulfill a very high threshold

[DefaultO]

https://github.com/The-International-Screeps-Bot/The-International-Open-Source/blob/a0b7b980ea14975a822f7f6cfc1f97e15e551546/src/room/commune/commune.ts#L1154

I think that min shouldn't be there. Inside the max function are 3 parameters. This is supposed to get the highest amount between those three values. "min" is set to the max capacity of our storage and terminal combined I think. So we are using the highest value out of those three "20% of store structures capacity", "something around RCL * 6000 + threat level calculated energy" and last "max capacity of our storage + terminal". The last one isn't supposed to be there I believe. Or you meant to use the "min" instead of "max" function here.

Room Examples: https://screeps.com/a/#!/history/shard1/W56N59?t=50929000 https://screeps.com/a/#!/history/shard1/W57N59?t=50929000

Let me know if you need some more debug information. I think I pointed directly at the broken code. But if you need memory stuff, I can provide you with it.

[DefaultO]

Nvm. The min isn't the max capacity. Forget this for now. I have to debug this more.

Edit 1: The energy min value seems to be pretty high. I will investigate why.

[!WARNING] [10:38:04][shard1]preTickRun: {"min":{"battery":6500,"energy":1170000,"H":13000,"O":13000,"U":13000,"K":13000,"L":13000,"Z":13000,"X":13000,"UH":0,"UO":0,"KH":0,"KO":0,"LH":0,"LO":0,"ZH":0,"ZO":0,"GH":0,"power":2600,"ops":13000,"metal":0,"biomass":0,"silicon":0,"mist":0,"ghodium_melt":0,"composite":0,"crystal":0,"liquid":0,"alloy":0,"cell":0,"wire":0,"condensate":0},"max":{"battery":19500,"energy":1170000,"H":35100,"O":35100,"U":35100,"K":35100,"L":35100,"Z":35100,"X":35100,"UH":13000,"UO":13000,"KH":13000,"KO":13000,"LH":13000,"LO":13000,"ZH":13000,"ZO":13000,"GH":13000,"power":19500,"ops":26000,"metal":0,"biomass":0,"silicon":0,"mist":0,"ghodium_melt":0,"composite":0,"crystal":0,"liquid":0,"alloy":0,"cell":0,"wire":0,"condensate":0}}

[!WARNING] [10:38:04][shard1]createTerminalRequests: {"min":{"battery":6500,"energy":1170000,"H":13000,"O":13000,"U":13000,"K":13000,"L":13000,"Z":13000,"X":13000,"UH":0,"UO":0,"KH":0,"KO":0,"LH":0,"LO":0,"ZH":0,"ZO":0,"GH":0,"power":2600,"ops":13000,"metal":0,"biomass":0,"silicon":0,"mist":0,"ghodium_melt":0,"composite":0,"crystal":0,"liquid":0,"alloy":0,"cell":0,"wire":0,"condensate":0},"max":{"battery":19500,"energy":1170000,"H":35100,"O":35100,"U":35100,"K":35100,"L":35100,"Z":35100,"X":35100,"UH":13000,"UO":13000,"KH":13000,"KO":13000,"LH":13000,"LO":13000,"ZH":13000,"ZO":13000,"GH":13000,"power":19500,"ops":26000,"metal":0,"biomass":0,"silicon":0,"mist":0,"ghodium_melt":0,"composite":0,"crystal":0,"liquid":0,"alloy":0,"cell":0,"wire":0,"condensate":0}}

Edit 2: Nevermind. I was right. min is getting set to 90% of the max combined storage and terminal capacity.

[!NOTE] [11:23:34][shard1]DEBUG resourceTargets W57N59 [11:23:34][shard1]storingStructuresCapacity: 1300000 = 1000000 (storage) + 300000 (terminal) [11:23:34][shard1]resourceTargets: RESOURCE_ENERGY (min) = 1170000 [11:23:34][shard1]resourceTargets: RESOURCE_ENERGY (max) = 1170000

[DefaultO]

Yea so here is a quick fix: I think you forgot an extra 0 after the comma when you declared resourceTargets.min[RESOURCE_ENERGY] = this.storingStructuresCapacity * 0.9. But regardless of that, the check doesn't seem to work because 1170000 max energy shouldn't fill up my storage to nearly 1000000 energy, nor my terminal to nearly 300000 energy.

get resourceTargets() {
        // ...
        const storingStructuresCapacity = this.storingStructuresCapacity;
        let min;
        // ...
        min = resourceTargets.min[RESOURCE_ENERGY] =
            this.storingStructuresCapacity *
                0.9;   
        resourceTargets.max[RESOURCE_ENERGY] = Math.max(storingStructuresCapacity * 0.5, this.minStoredEnergy, min);
        // ...

get resourceTargets() {
        // ...
        const storingStructuresCapacity = this.storingStructuresCapacity;
        let min;
        // ...
        /* min = resourceTargets.min[RESOURCE_ENERGY] =
            this.storingStructuresCapacity *
                0.9;
        */        
        min = resourceTargets.min[RESOURCE_ENERGY] = this.minStoredEnergy;
        resourceTargets.max[RESOURCE_ENERGY] = Math.max(storingStructuresCapacity * 0.5, min);
        // ...

[CarsonBurke]

The min energy is intentionally very high. Right now I'm planning on adding more nuance to resource targets and how they determine when to purchase vs when to just internally request. I don't expect this to be done until after Season 6.

[DefaultO]

The min energy is intentionally very high. Right now I'm planning on adding more nuance to resource targets and how they determine when to purchase vs when to just internally request. I don't expect this to be done until after Season 6.

Couldn't you have not pushed that before actually implementing the system that can handle it? ^^

I thought I heard you say you wanted to make the bot more stable. This would be an example of what not to do. It deadlocks your bot in its current state since the haulers don't know what to do with their energy when the storage and terminal are full. It also burns an insane amount of credits. Went from 1,000,000,000.000 credits to 431,000,000.000 credits. The trend is a sink with no increase in sight for at least a few weeks until the energy in the containers is burned (which is hard to do in an RCL8 room) and for it to buy all the minerals it wants, to then also start with power processing. Probably will have to create a few sell orders to fix the poisoning.

Sure. This is the development branch. You probably would argue that it has to be expected to contain broken code. But you aren't running this version yourself. And you make it look like this acts as a work-in-progress storage for you to fall back on if your local version gets broken (if you threaten it like that, make another branch that you merge into development when everything is ready and needs to get tested intensively until it gets merged with main). You don't want me to compare this with Overmind. But the Overminds development version is by far more stable and predictable, even if there are features in it that were never finished. Maybe all the suggestions by Panda and me didn't stick at all with you. /shrug

[!IMPORTANT] TLDR: I am willing to fix stuff myself. But this wasn't necessary (even if this is the development branch) after I learned that this is part of an upcoming change that you haven't started programming yet. Hope we can agree on that.

Also not sure why. But the first time switching back. It unclaimed a few of my RCL8 rooms. Most likely due to score. Is that necessary? Maybe the logic should be more like "make the bad RCL8 rooms help build up a colony in a better room until they are at RCL8 themselves if the GCL supports this (possible to claim more rooms)". That was a considerable setback. ^ Probably should make an improvement issue for that.

[CarsonBurke]

The min energy is intentionally very high. Right now I'm planning on adding more nuance to resource targets and how they determine when to purchase vs when to just internally request. I don't expect this to be done until after Season 6.

Couldn't you have not pushed that before actually implementing the system that can handle it? ^^

I thought I heard you say you wanted to make the bot more stable. This would be an example of what not to do. It deadlocks your bot in its current state since the haulers don't know what to do with their energy when the storage and terminal are full. It also burns an insane amount of credits. Went from 1,000,000,000.000 credits to 431,000,000.000 credits. The trend is a sink with no increase in sight for at least a few weeks until the energy in the containers is burned (which is hard to do in an RCL8 room) and for it to buy all the minerals it wants, to then also start with power processing. Probably will have to create a few sell orders to fix the poisoning.

Sure. This is the development branch. You probably would argue that it has to be expected to contain broken code. But you aren't running this version yourself. And you make it look like this acts as a work-in-progress storage for you to fall back on if your local version gets broken (if you threaten it like that, make another branch that you merge into development when everything is ready and needs to get tested intensively until it gets merged with main). You don't want me to compare this with Overmind. But the Overminds development version is by far more stable and predictable, even if there are features in it that were never finished. Maybe all the suggestions by Panda and me didn't stick at all with you. /shrug

[!IMPORTANT] TLDR: I am willing to fix stuff myself. But this wasn't necessary (even if this is the development branch) after I learned that this is part of an upcoming change that you haven't started programming yet. Hope we can agree on that.

Also not sure why. But the first time switching back. It unclaimed a few of my RCL8 rooms. Most likely due to score. Is that necessary? Maybe the logic should be more like "make the bad RCL8 rooms help build up a colony in a better room until they are at RCL8 themselves if the GCL supports this (possible to claim more rooms)". That was a considerable setback. ^ Probably should make an improvement issue for that.

I am running this version myself. The lack of energy usage is likely due to a known logistics but that I have nearly resolved.

As for credits usage, please consider using the disable market usage setting of the not is using more credits than you are comfortable with.

One option to make this more pleasant might be to allow a setting for disabling market for certain resources. For example, you could disable market logic for energy and batteries but not minerals, boosts, commodities, etc. Would that address your concerns?

If you want a more stable version of the bot, the main branch was recently updated and is fairly efficient

Help would be appreciated. I'm more busy now with University, and my plans for terminal resource sharing isn't as defined and dynamic as I'd like. If you have ideas on how to design the system I'd appreciate them.

As for the unclaiming rooms, that definitely sounds like a bug. Can you make a separate issue describing what happened, what version you were on and the set of room RCLs you had? Thanks

[DefaultO]

One option to make this more pleasant might be to allow a setting for disabling market for certain resources. For example, you could disable market logic for energy and batteries but not minerals, boosts, commodities, etc. Would that address your concerns?

Help would be appreciated. I'm more busy now with University, and my plans for terminal resource sharing isn't as defined and dynamic as I'd like. If you have ideas on how to design the system I'd appreciate them.

I can't help you with complex stuff like logistics and whatnot. That's a system you built up from the ground yourself. I don't understand it. An issue that we always had when you asked us to contribute.

As for the unclaiming rooms, that definitely sounds like a bug. Can you make a separate issue describing what happened, what version you were on and the set of room RCLs you had? Thanks

Since #772 is marked as closed. This seems solved now. Hopefully. Maybe I missed something. But there wasn't anything else that could have caused it.

[CarsonBurke]

Then understand it, or stop offering to help.

[DefaultO]

Then understand it, or stop offering to help.

Not offering to help really. Since I won't bother wanting to understand undocumented code.

I am sorry that it looked like I could replace you.

Pretty much just fixing the bugs I encounter myself. I can't do better than that. In order to fix a bug it has to show itself and I have to believe that it is one. Which was obvious with the transfer-bug I helped you with the first time, and with the few more that came after that.

If you don't want me to report those or add suggestions. Let me know.