Issues with minerals
-
In the following I list a few things that sprung to me, while experimenting with the new minerals (the original list yesterday was longer, but you already fixed some issues):
- All minerals have the same (white) color when stored (in labs/storage) - I would like to see this changed to the "real" colors.
- Indicators for mineral deposits missing on mini map (also colored)
- RESOURCES_ALL lists a few the minerals incorrectly - instead of O (the letter) they have a 0 (the number) (e.G. XKH20 instead of XKH2O), while in REACTIONS it is stated correctly.
- the lab is missing a general transfer(target, resourceType, [amount]) method - just to be consistent with the other buildings. Atm I have to build an exception for the unintuitive method transferMineral (which you could keep as alias to transfer)
- with all the new resource types, now I am really missing a Creep.transferAll / Creep.dropAll
- "boosted" parts don't receive the boost - creep with 5x ATTACK only did 150 dmg instead of 270 which it should do with 4 boosted parts. See https://screeps.com/ptr/#!/room/W18S13 creep William and the extension to its top left.
...probably to be continued
-
> All minerals have the same (white) color when stored (in labs/storage) - I would like to see this changed to the "real" colors.
This is intended.
> Indicators for mineral deposits missing on mini map (also colored)
There is a "Minerals" display type on the world map.
> the lab is missing a general transfer(target, resourceType, [amount]) method - just to be consistent with the other buildings. Atm I have to build an exception for the unintuitive method transferMineral (which you could keep as alias to transfer)
This is also intended, since the lab cannot contain more than one mineral type at the same time.
> RESOURCES_ALL lists a few the minerals incorrectly - instead of O (the letter) they have a 0 (the number) (e.G. XKH20 instead of XKH2O), while in REACTIONS it is stated correctly.
Fixed.
We'll look into other points, thanks.
-
> All minerals have the same (white) color when stored (in labs/storage) - I would like to see this changed to the "real" colors.
This is intended.
I guessed so. However I think it might be helpful to see on the first glimpse, which minerals are processed in which lab (esp. when having a lot of labs in a lot of RCL8 rooms). Also, this would help brighten the overall look of the otherwise very minimalistic look of the game.
> Indicators for mineral deposits missing on mini map (also colored)
There is a "Minerals" display type on the world map.
Missed that one. Looks good, thank you!
> the lab is missing a general transfer(target, resourceType, [amount]) method - just to be consistent with the other buildings. Atm I have to build an exception for the unintuitive method transferMineral (which you could keep as alias to transfer)
This is also intended, since the lab cannot contain more than one mineral type at the same time.
I prefer consistent API and rather deal with according error codes than having to hard code exceptions for certain structures. Why don't you implement transferMineral as alias/shorthand for transfer? The most disturbing point is, that the transfer method is available for labs (of course, as it's part of the structure prototype) but in the method you hardcode the structureTypes and throw an error (I was checking if the method was available for labs and was wondering, why this was the case but the method throws an error).
> RESOURCES_ALL lists a few the minerals incorrectly - instead of O (the letter) they have a 0 (the number) (e.G. XKH20 instead of XKH2O), while in REACTIONS it is stated correctly.
Fixed.
We'll look into other points, thanks.
Thanks!
-
I'm with chris on both helping brighten up the place and the consistent API, an issue I brought up back when the transfer methods were first implemented and links didn't/don't offer it. I too had to write an exception for only links when dealing with creeps that utilize them.
-
I very much agree that a consistent API would be very welcome. I also feel there's an rather annoying inconsistency between structure.energy, structure.store.energy and creep.carry.energy already that I'm running into again and again...
-
Structure.transferMineral has already been replaced with Structure.transfer for labs. As to carry and store properties, please see this discussion.
-
oh I get why carry and store were needed, and I support that. My issue is that some buildings still only offer Structure.energy though. The inconsistency I am talking about is most evident when looking at the difference between Storage and Labs.
Storage:
Structure.store[RESOURCE_ENERGY], Structure.store[RESOURCE_OXYGEN]
vs
Labs:
Structure.energy, Structure.mineralAmount (with the extra need to check and make sure Structure.mineralType === RESOURCE_OXYGEN)
...why?
-
Ideally, the API should make no difference between energy, power, and all those fancy new resources. Individual structures then can send error codes when trying to add stuff to them that they aren't supposed to store or take stuff out that you aren't supposed to take out. And the way you access energy should be the same for every building, be it Storage, Labs, or Links.
-
Properties of each of the structures clearly highlight the semantics of the work of this structure. If some structure works with energy only, adding a `store` property containing the sole `energy` property and incapable of containing any other properties would confuse the API user. This structure just needs energy to work, it has no “storage” to store anything, it’s just an energy device. So this API expresses structure functions in a more consistent and clear way. As for the labs, they can’t contain more than one type of minerals, and this also should be evident from the API.
You just shouldn’t interpret different structures in the same way as you work with their objects. Especially because they should be handled differently from the gameplay viewpoint.
