-
Notifications
You must be signed in to change notification settings - Fork 66
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
Vehicle auto refuel (part 2) #577
base: dev
Are you sure you want to change the base?
Conversation
fixed insert code to put as much as possible into the vehicle
rebase dev
hiding unused recipe/item and some lib patches
…ve wrong icon_size (#508)
doubled braking force instead, so added the offset
…vanilla mechanics
fix miss tech and solder checks
Adjust starting items for Bob's characters
PR updated to the latest state of #464:
|
end | ||
end) | ||
|
||
script.on_nth_tick(60, function() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a follow up on @Pezzawinkle's #464 (review) comment:
I'm not sure if we want to increase the tick count a bit higher but im fine with it now.
The thing to consider, is realistically, how many "stacks" of wood do we want to stick in per second?
My suggestion would be more like this:
- Have a new equipment, named
Burner Refueler
(which could consume a small amount of power) - Instead of iterating through each vehicle burner, I would iterate over each refueler, where every refueler:
- Attempt at filling each burner generating equipment in that equipment grid
- Stop filling equipment if:
- All the equipment is full of fuel (can't insert anymore)
- Has no more fuel to insert (inventory out of fuel)
- Has inserted more than X amount of KJ worth of energy (this can be coded)
- Has insufficient energy to insert more fuel (see next bullet)
- This 'laser' equipment (with 0 range) will have a buffer that we can drain for energy:
- By base game, steady drain for 'idling'
- By code, taking a bit of energy for each insert action (measured in KJ/item)
- Depending on the how much items/s we want to auto insert (this can be a low number), we can tweak how much ticks pass between attempts
- Player can speed up the filling process by adding more Refuel equipments in a certain equipment grid. Because insertion is measured in items/s, more refuelers are needed for wood compared to higher fuel yielding items.
The code that is here already is the major part of the work, this only requires small tweaks (and addition of a new equipment item) in order to work. This would also resolve incompatibilities with existing vehicle(burners) in existing savegames...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From testing it was not moving single items, rather full stacks, but that may have just been doing all 600 transitions in the same tick (in the case of carbon).
I really like the idea of a refilling item, but at the same time it is functional and unless you have a substantial amount of crawlers running around, I don't see it being a major issue, was just a hypothetical.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From testing it was not moving single items, rather full stacks, but that may have just been doing all 600 transitions in the same tick (in the case of carbon).
it is not. it checks for how much it can insert and then removes that amount and then inserts that amount or max items available which ever one is less.
it is functional currently but i could see adding the fueler equipment as a decent option as then we dont need to care about tracking the generators and only keep track of the fueler equipment which would simplify mod compatibility. i know the og version wasn't setup at all for mod compatibility and wont even work with bobs equipment.
When both reviewees approve of the current state of #577 compared to #464, branch |
Continuance from #464 taken before @kingarthur91 rebased from
dev@f22bea2
This PR is forked at 0f20991, where the last commit was done before the rebase happened...