Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
DefaultO opened this issue Jan 22, 2024 · 8 comments
Assignees
Labels
Problem Not necessarily a bug, but not ideal behaviour

Comments

@DefaultO
Copy link
Contributor

DefaultO commented Jan 22, 2024

resourceTargets.max[RESOURCE_ENERGY] = Math.max(storingStructuresCapacity * 0.2, this.minStoredEnergy, min)

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

This comment has been minimized.

@DefaultO

This comment has been minimized.

@CarsonBurke
Copy link
Member

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.

@CarsonBurke CarsonBurke changed the title MarketUsage won't stop buying energy The bot purchases large amounts of energy trying to fulfill a very high threshold Jan 23, 2024
@CarsonBurke CarsonBurke self-assigned this Jan 23, 2024
@CarsonBurke CarsonBurke added the Problem Not necessarily a bug, but not ideal behaviour label Jan 23, 2024
@DefaultO

This comment has been minimized.

@CarsonBurke
Copy link
Member

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

This comment has been minimized.

@CarsonBurke
Copy link
Member

Then understand it, or stop offering to help.

@DefaultO

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Problem Not necessarily a bug, but not ideal behaviour
Projects
None yet
Development

No branches or pull requests

2 participants