Draft: Store prototype API
black0441 last edited by
For the nuker, you could have it charge instead of store-so the ghodium is lost when added to the nuker, instead of when it's used.
Labs are trickier. Maybe add a .store.maxMineralType/.store.maxMineralAmount that returns the mineral with the highest count (not including energy, power, etc)? That way it would always work like .mineralType/.mineralAmount does now on labs, plus it would be useful for storage, terminals and creeps too.
Xenofix last edited by Xenofix
Maybe a non-general-purpose and multiple-resource structure needs
getFreeCapacity()just makes sense for general-purpose (Storage, ...) and single-resource structures (Tower, Extension, ...). For all structures with mixed resources (powerSpawn, lab, nuke, ...) there needs to be more methods. Maybe
getFreeCapacityFor(resourceType). These can be implemented for general-purpose
Store, too. So that the API for both types is the same.
QGazQ last edited by
I must say I'm for this change, and after a period of transition removing the old ones. It did confuse me a lot originally, and though I now have prototypes that handle most of it removing them will simplify things.
As others have mentioned there needs to be some way to define the limits for Labs and Nuker, as others have mentioned a single store object would be my preference with some kind of per resource limit field. The other "important" thing I do a lot is to check what resource type is in a lab, at the moment this is a simple
.mineralType. I'd rather not have to iterate over the store / supportedResources and ignore energy to be able to get it in the new way of doing things (though if it were the only way I could add a prototype of
.mineralTypewhich did it and cached the result).
deft-code last edited by
I really like the unification of carry, store and energy as well as the inclusion of total and free methods.
The beauty of unified store is marred by StructureNuker and StructureLab, we need a little more consideration here.
I think everyone dislikes separate properties. I think @Xenofix's idea of extending the Store interface deal with the two oddballs is best.
How about extending the
getFreeCapacityto accept an optional resource type argument and adding a
That way I can easily write uniform transfer and withdraw code by always including the resource type.
nuker.store.getTotalCapacity(RESOURCE_GHODIUM) => 5000 nuker.store.getTotalCapacity(RESOURCE_ENERGY) => 300000 nuker.store.getTotalCapacity() => 305000 // or 0 or whatever make sense creep.store.getUsedCapacity(/*anything*/) => the same value // look how nice labs work out. lab.store.getUsedCapacity(RESOURCE_UTRIUM) => 1000 lab.store.getTotalCapacity(RESOURCE_UTRIUM) => 3000 lab.store.getTotalCapacity(RESOURCE_KEANIUM) => 0 Store.capacity === Store.getTotalCapacity() Store[RESOURCE_ZYNTHIUM] === Store.getUsedCapacity(RESOURCE_ZYNTHIUM)
I would never need to use
getTotalCapacityanswers that same question, and for the most part
supportedResourceis statically known based on
I think we'll still want a
.mineralTypemember on the lab, but that could just be implemented with
This change is long overdue, seriously but a couple of things:
For God's sake use "storage" or "stored", "store" is a incorrect definition and prone for misunderstandings.
It maybe it should be super class for all entities that contain something so that it is possible to directly call withdraw on them without the need to punch .store/storage/stored. between object and call.
This way all resource handling can be done central in one class without the need to fiddle in the endusers object code.
I have a lot more in mind but I'm tired so that will it be for now.
@artch would it be possible from the users script to modify the storage object of a creep and reset the cache? That would be nice because I currently already patch the creep object for example on successful withdraws, pickups and stuff like that so decisions made after that are based of the new values ( I know those can still fail when multiple creeps for example withdraw, so that should not be automatic maybe ) but I use it only for the decision to move to the creeps next target for example in the same tick.
If this is a breaking change ( and there are already other mentions in the docs about deprecated stuff like the transfer method on structures, the old spawn function,... ) maybe it's time to create a second selectable runtime? I don't know how much work that would be but perhaps it would also allow us to get one with lodash 4 already included ?
@w4rl0ck Properties will be set with
configurable:true, so yes, you can modify them.
@deft-code I like this idea! Although, I would rename
getCapacityand remove the
.capacityproperty at all then. The top post updated, check it out!
I still don't like it to be called Store since it is used a lot in other contexts.
Hence I like to propose to use a term that makes it very clear we talk about non stationary stuff:
Cargo <- This is short, pregnant and definitive.
If you think I'm nitpicking, think again.
Clear terminology is key for a good and comprehensible Codebase that is supposed to be used by others.
@mrfaul Are you a native English speaker? I'm not, so I use dictionaries a lot. This is what the Oxford Dictionary gives for "store":
A quantity or supply of something kept for use as needed.
‘the squirrel has a store of food’
Looks valid to me.
MrFaul last edited by MrFaul
I'm not a native speaker and butcher the grammar frequently but German is really not far from English.
(for those native tongues who learning German and cursing me right now for that statement, sry for us the complexity goes down )
This is not about its definition, it is about distinction in context.
I have a B.E. in machine design and this is one of the biggest challenge in my profession.
German by its nature is a very precise language, this keeps a lot of potential misunderstandings in check since we have a word for almost everything.
However when translating this in English, a lot (I mean a shit load) of this precise information is lost since English simplifies and reuses a lot of words to a degree that they are able to have very different meanings.
To combat this we have to make sure to use distinctive terminology in international conversations.
Now "Store" and "Cargo" are very similar with the distinction that "Cargo" is exclusively used for "stuff that is being transported"
This is the better term in this case since it will be used by structures and creeps.
Decide for your self what is easier to distinguish in a non written conversation or when you are hunting for bugs which may include typos:
"store" is a completely valid term but since it is already used it shouldn't be given a additional meaning.
P.S. And don't get me started on the difference between "american" and "british" English that deserves it own rant
Storage.store[RESOURCE]does look much better to me than
Storage.cargo[RESOURCE]. "Store" is a more abstract term (e.g. an idiom "to have something in store"), and "cargo" is indeed mostly about transportation (thus irrelevant to game structures).
I think we're fine with
store, but it's interesting to hear some native speakers' opinion.
MrFaul last edited by MrFaul
@artch said in Draft: Store prototype API:
"Store" is a more abstract term (e.g. an idiom "to have something in store"),
You do realize that it is exactly what I'm bitching about, don't you? Too abstract.
and "cargo" is indeed mostly about transportation (thus irrelevant to game structures).
How is this irrelevant, every fucking resource has to transported in this game before it can be used...
It only stops being cargo when it is used up, and that is the moment you call an intend with it.
Before that you can move it around freely.
That said your call
Davaned last edited by
As a native english speaker, I've never had an issue with store. I agree with @artch, "cargo" definitely has in transit connotation, eg. something being delivered. To me terminal.cargo doesn't make sense @MrFaul.
A word like contents might make slightly more sense due to being specific to the object itself (eg. the storage.contents, the contents of the tower), but tbh to me the extra characters probably wouldn't be worth it.
Store can be used as in "grain stores for the winter" and in my mind "store" was being used to represent a stockpile. My only qualm would be that terminal.store has an active verb definition of "to store" which is what comes to mind first, but it's a nitpick at best. The exact word choice isn't an issue, as what it's meant to be is clear, so I'd stick with store. My 2¢ on it.
I would also prefer
store.. it's short and I think it fits.
@davaned I know this seems like nitpicking but trust me I have seen markets shut down because of such little things like confusing naming conventions. (they switched logistic software)
Oh and cargo on a terminal makes perfect sense, just ask a port worker of your choice ^^
And again I'm not bitching about the term, I'm bitching about the lack of distinction.
I guess I'm just sensitized to filter out those problems early... ( That day mentioned above was a fuck up above 7 digits)
Davaned last edited by
- Tower.store - has verb implication, valid word choice
- Tower.cargo - has incorrect implication, not getting transported
- Tower.contents - most accurate, extra characters
Would you describe something stored in your pantry as "cargo"? Between the contents of the pantry and the cargo of the pantry I know which makes sense. Store is a little clunky, but I would not bother changing to an incorrect definition.
deft-code last edited by
More bad options:
hold. Same verb problem as
store, same transit problem as
cargo. less characters
resources, almost as good as
contents, but longer, resources is often used abstractly in common english.
quanta, technically as correct as contents, horrifically confusing.
bikeshed, terrible, but think of the story we could tell new players
stuff, also a verb like
store, but most often used as a noun, often used to end bikeshed arguments.
Seriously though, the consistent use will be a huge boon to those learning the API. The debate about which name is truly just bike shedding. There are bad options, many good enough options, and no objectively best options. More important than picking among good enough names is that the devs remain productive and this gets rolled out before the next crop of new players shows up.
If switching to
contentsspeeds up the refactor, awesome. If leaving it as
storemeans less work overall even better.
wtfrank last edited by
Renaming commonly-used variables 5 years into a project is often a terrible idea
Orlet last edited by
.storeis my preferred way of