Survius Forums

Full Version: Looting system suggestion
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Few issues with the current loot spawning:
- People will login to an empty server and find key places totally empty. Mainly new players. 
- The host player has to be connected in order for loot spawning to happen.
- In other places loot piles up ridiculously.

My suggestion is the following:

If  we could have an invisible trigger object in places like wardrobes, counters, car, fridges and other furniture. You walk up to any of these furniture and you get a "Press action button to search" and it opens up the content like a crate.

Every invisible trigger object is stored in the database, its state is stored, that is:
a last time looted timestamp and the items it contains.

Basically works like a crate, it keeps tracks of the content it has but also keeps track of the last time it was looted (When its content changed). 

So now, only when a player triggers it, the invisible trigger object will fetch its state from the db, its content and the last time it was looted. Say we want a player to be able to loot the invisible trigger object every 2 hours. So upon triggering it:
Check if it was looted 2 hours ago ? if no, will simply show its stored content, if yes, it will override itself and generate new content. overriding is simply to avoid piling up loot.

Generating new loot is simply randomly picking from built-in collections of items in the game client. You could have preset collections of items in the game client. Eg:
Collection1 : Can of corn, chocolate bar, Drink..
Collection2: Pistol, spiked bat, ammo...
Collection3: bandage, med, ...

Each invisible trigger object will be associated to one or more of these collections depending on its location.

So basically, you can think of it as having invisible boxes in cars and other house furniture that you can "search" (similiar to opening a box) and that will open the interface and show its content. Only difference is the content of these invisible boxes's logic.
The logic would be for example: after being triggered, check the last time it was looted, if it was never looted, generate new items, if it was looted and there is a timestamp, check if it was looted longer than 2 hours ago, if yes then override its content and generate new items, if no just simply fetch the available content. Update its new state after being closed and saves it to the db.

Hopefully this can be more optimal than the current spawning system, and guarantees to find new loot ON-DEMAND.
I would love having item containers to loot in houses. It would add more immersion, and 7DtD has it as well.

There are 3 ways to generate the loot I can think of:
1) The host actually generates it as it goes like every other loot - slow, would increase lag a lot
2) The looter gets the status from the DB, then has the host generate the loot - slow, would increase lag a bit
3) The looter gets the status from the DB, then the looter generates the itself - faster, only causes lag for the looter

Since the DB can't (and shouldn't) generate loot, option 3 would be the best way to handle it and not lag everyone else. So that would look something like...
- Looter accesses container
- DB sends back packet with reset header and no loot list
- Looter's game generates new loot
- Looter's game send DB new loot list
- Looter takes/leaves what they want
- Loot's game updates DB again

It would be great to have loot containers in the game as long as they don't cause much lag, and/or and duplication or item deletion bugs.
(11-13-2019, 07:53 PM)Mohenjo Daro Wrote: [ -> ]3) The looter gets the status from the DB, then the looter generates the itself - faster, only causes lag for the looter

This is exactly what this thread is describing.

In more details it would look like this:
- The invisible containers appear in-game for the first time ever, the key idea is that their state is persisted in the DB. So initially the looted_at property could be set to null or some old default timestamp (unix epoch or whatever). Can also have an update_time property that specifies when each container should "respawn loot" (or u can have a global one for every containers, i.e all loot should regen every 2hours for example)
- The first looter ever comes, approaches the invisible container and gets a "Press action [E] to search"
- the status bar changes to "searching..." upon clicking on it, and the game client will execute the following logic:
  •       fetches the container's state from the db, checks the looted_at date that is null or way past the update_time, therefore will randomly pick a number of item of off a list of items to pick from, instantiate them and assign them to the container. (might not save them to the db yet since they exist in memory and the player hasn't yet looted)
  •       player receives the available loot, the content might change based on player decision, whatever modification is gonna get saved once the player is done. the state of the container is saved and its looted_at timestamp is updated
-  next player that comes to loot again, same thing after triggering it, fetch the state, check if the difference between current time and the looted_at is smaller than update_time ? return the content of the container, if it's longer than update_time, client will randomly pick items again, instantiate them, assign them to the container (and override any possible previous items to avoid piling up loot). Will save the updated content of the container after the player closes the container. update the looted_at timestamp.