Remove vendingmachines mapgen syntax, replace existing VM with nests, replace active VM with turned off (in vanilla)

[GuardianDll]

Summary

Balance "All energy is off, why vending machines are still on?"

Purpose of change

Vending machines do not use any magic power source, therefore they should be turned off when entire energy grid is turned off

Describe the solution

Replace the vendingmachines syntax with manually crafted nests
Replace all instances of vendingmachines with nests
Maybe remove the old syntax entirely

Describe alternatives you've considered

Make it via code, but i the way it is made currently is very inflexible

Testing

TBD

Additional context

[PatrikLundell]

Sorry, but I think you're heading in the wrong direction here.

I think it's the wrong approach to replace all vending machines with "looted" ones with stuff on the ground because the current syntax doesn't seem to allow for them being turned off most of the time. Among other things, this negates the need to get into them.

To start with the basics:
As far as I can see, we probably have a few useful cases (with machine kind and contents permutations, of course):

• Working machine: contains goods and resides in a powered facility. May be cooled to preserve goods, but that's optional. This is the only powered case.
• Unpowered and unlooted machine: Has the stuff still in it, but obviously not refrigerated. You have to mine it or smash it to get at the stuff.
• Smashed but unlooted (zombie work): Goods spilled under the machine (or around it, as that's what I would expect bashing to do).
• Smashed and looted: Little if any goods under the machine, and most of what's there is empty wrappings of the appropriate kinds.

A chunk approach would be fine for the looted machine cases, but then you should really include the goods in the chunk, i.e. both the machine and the goods on the tile defined together, and named appropriately (i.e. predominantly or completely "food" and "drink").
I suspect the unlooted case is better dealt with by extending the vending machine syntax to specify whether it's powered or not. You may still want to make them into chunks to make their usage on par with the looted one (to make it easy to have X chance for a looted chunk and Y chance for for an unlooted one).

Another option for zombie smashing would be to add the probability for it to be bashed a randomized number of times, and so start out with an unlooted machine in this case (could even be powered in the specification when appropriate, as I would guess a machine bashed to spill its contents would result in a damaged machine that's always unpowered). However, the result of bashing a machine would need to be tested to see if the goods spilling is implemented.

[GuardianDll]

I pretty much miss the point you are trying to make. Do you mean you think the vendingmachines syntax should be preserved? Because under the hood it doesn't do anything different from what i have here. Expanding that code would be, from other side, really complicated and not benefitial at all: for once it doesn't do anything we can't replicate in nests, and secondly, it has only three states: spawns generic machine, spawns looted version that can be unlooted with a little chance, and spawns armored version. That's it, that's all the things the code does, and expanding it further with powered off check would result in either it being able to spawn only unlooted off version of vending machine, or me making 8 permutations for each combination of each boolean being on and off - very possible, but why bother, if nests can do this already without hoops of checks

I can handle all the cases you described via nests either, which is probably something i will do a bit later in this PR

I would also probably simplify and replace nests with a two three new one, one for drinks, one for food, and one with little of both - this will handle 99% of all use cases we have right now in vanilla, but would left a place for modders (like backrooms has a super cool mutagen and cbm vending machines, and aftershock may add some 24/7 armory because why not)

[PatrikLundell]

Are you saying that spawning items on the same tile as a nested machine causes the items to end up inside the machine and be available only through mining and bashing if unpowered and through purchase as well if powered? If that's the case, yes, nesting should provide all the functionality needed.

Edit:
However, unless I misunderstand things further, you're systematically replacing lootable vending machines with looted ones.

[GuardianDll]

Yes, the game correctly put stuff inside the vending machine, and you can access it only by smashing it

The actual issue that i found just right now (which is actually something that was here all the time) is that right now you can't see what's inside of it untill you smash it - i can't find how trailhead does it's magic, i do not see any specific flag that can handle it

[PatrikLundell]

Thanks for the answer.

I'm guessing you're mentioning of trailhead magic refers to the board with a map in it. If that's the case it's simple: "f_board_map" has the flag "TRANSPARENT", which is also shared by display cases. The problem with the vending machines is that you'd want to see into them, but not through them, which I don't think is supported. On the other hand, given that vending machines are typically placed against a wall, seeing through them may not be that much of an issue.

[PatrikLundell]

Removing the "CONTAINER" flag seems to make the vending machine contents visible according to my testing. The flag is described as hiding items from view until looted, but you can normally see them when standing next to the tile in my experience. However, it doesn't work that way with the vending machine, and I guess that's because it's SEALED, although I haven't tested that (as it's something we don't want to remove anyway). I tried to drag the vending machine, and the clean water bottle I hacked inside it remained inside. The examine interaction brought up the sale UI as normal. Without the "CONTAINER" flag the contents was visible from two tiles away (the distance I spawned the machine at), so it would presumably be visible from any distance. Trying to pick up items when next to the machine told me there wasn't anything to pick up.

[GuardianDll]

it is interesting, because f_board_map i mentioned before has both TRANSPARENT and SEALED, but no CONTAINER flag

[John-Candlebury]

Why remove the hardcoded placement function?
Its incredibly more convenient to use vs the json nest replacement you are proposing here, not everything needs the fine granularity and extra complexity of a nest.

Map making is already a very time consumiong tasks, we should look for ways to make it more automated, not remove our few autotools in favor of even more manual defined stuff.

[GuardianDll]

Why remove the hardcoded placement function?

Because it cannot handle vending machines, that are turned off, again - the code behind the function doesn't do anything different from nest, and made in a way that do not allow different permutations (like using both looted and reinforced booleans would result in just reinforced vending machine spawned), and adding 6 more permutations just because i want to add one more booleanis not something i think would be good, when someone in the future would try to add another new boolean and will be left with a choise to add even more permutations

we should look for ways to make it more automated

My pr is just

      "place_vendingmachines": [
        { "item_group": "vending_food", "x": 31, "y": 6, "lootable": true },
        { "item_group": "vending_drink", "x": 32, "y": 6, "lootable": true }
      ],

->

      "place_nested": [
        { "chunks": [ "nest_vending_machine_looted_food" ], "x": 31, "y": 6 },
        { "chunks": [ "nest_vending_machine_looted_drink" ], "x": 32, "y": 6 }
      ],

, i don't see how it "remove our few autotools"

[John-Candlebury]

Checking and accounting for a powered boolean within the C++ function would be trivial. I rather spend time doing that tonight that have to bother with placinf and updating nests from now on.

[GuardianDll]

What about powered off looted vending machines? What about powered off reinforced one? What when someone would need to add another type of boolean? At which moment it would stop to be trivial and will be a burden? Imo this moment is right now
Besides, i don't really understand why we treat vending machines differently from, let's say, lockers, crates, display racks and fridges, that all can be of a difference type or state, and also store stuff inside. Is it the path you think we need to follow?

[John-Candlebury]

No need to worry about that #75078

[GuardianDll]

sigh