Do containers themselves ever have charges?

[JayThirtySeven]

Related to the discussion from Option to reverse the naming order of containers and their contents:

I’ve been working on how item names are generated and assembled and came to an odd consideration: Do containers ever have charges? I don’t mean the charges of whatever is stored in the container, I mean the container itself. It’s a little weird.

Like imagine if I had some kind of battery-powered self-cooling aluminum can. When empty it would be an “alumicooler can (100)” to indicate that it’s fully charged. If full it would be “alumicooler can (100) of orange soda (2)”. Or if/when my new code is in use it would be “orange soda (2) in alumicooler can (100)”.

I thought of this while trying to write translation notes and I realized that I needed to clarify that “charges” in some cases meant “charges of the container, NOT its contents”.

It gets a little weird because charges of a container can be synonymous with charges of its contents (guns/magazines) but that doesn’t always seem to be the case. The charges variable is also used for the countdown timer on grenades among other things.

TL;DR; Do existing containers have charges? Should any container ever have charges? Am I misunderstanding how charges are used in the code?

[Arche_Zwei]

Interesting question. My guess is that are two different classes of objects, some with charges, like flashlight. Others add to your carrying capacity, like duffel bags.

And yet others can store other items inside, like scabbards.

That begs the question of how a merged class, that increases your carrying capacity, can add items to it, and has an electric charge would behave.

I mean, if I find a cooling box, will all my inventory be refigerated? What if its a very small box, and I transport 15 Pizzas through a summer? Will they spoil slower? Can they be frozen?

[JayThirtySeven]

Yeah, that sort of portable cooler is exactly what I was imagining. It would make sense to have a powered container that preserves the items inside it or gives them properties like (hot) or (cold).

To be clear, though, there is only one item “class” in the programming sense of the term. All items share the same code and the differences between them are all in the data stored with each instance. So the classes are already “merged” and it’s hard to tell what would happen if you tried to create an item that combined behaviors that normally don’t appear on the same item.

I haven’t been working on the code for this game for very long but what I’ve seen so far is that the code works and is well optimized but it also has the scars of being tweaked and patched for a long time by many different people. There are some weird parts in there for sure and I think this is one of them.

(P.S. please don’t think I’m criticizing the coders who work on this project. It’s an old code base for a very complex game; it would have gone all to hell a long time ago if the coders working on it weren’t skilled people putting in lots of effort.)

[Litppunk]

The closest thing I can think of to something like that would be the minifridge, but its “furniture” or a vehicle tile and thus, I think not considered a “container” in the traditional sense but cheats and just gives the tile X amount of storage space, and everything in that space is refrigerated as long as it has power, but I don’t code dive, so I could be HORRENDOUSLY wrong. I think currently such codding is avoided, and workarounds found.

One such workaround comes to mind… think it was the tablet, that was given “apps” in the programming but depending on the ‘state’ on-off became a ‘different’ object and thus something about the charges changed… or maybe things changed when it changed ‘modes’ or something…? Remember something about that. Been a while since I’ve heard anything in the area. Hope this helps in some fashion.