Question of probability

[qmjs]

Those are leftover entries where the odds were changed to 0 from a previous value, usually because a particular area or site ended up having too much available. The correct method would have been to set them to

Resources Max="0" Min="0" Name="" Odds="0" RoomRestriction=""

 

There are quite a few coding mistakes in the xml. Most, like this one, don't have any adverse effect.

[pasmon79]

What does "Weight" represents in "Search.xml" ? Is it the probability of some sort?

[qmjs]

Search is a very messy, inefficient file.

 

The items on a given list are checked starting at the top, and weight is read as a probability. If it succeeds, that item is generated, otherwise it moves to the next item in the list and checks that one.

 

This causes a lot of issues, mainly that items at the bottom of a list, particularly a long list, almost never appear.

 

What you need to consider is that for an item to appear, it has to pass the weight check, and it also needs all above the checks above it to fail.

 

For example, looking at a simple list:

<SearchItemList Cap="4" Fallback="" Id="Guns.Sidearm" Min="2">
<ItemDefinitionReference Id="Pistol_M11" Weight="12" />
<ItemDefinitionReference Id="Pistol_OHWS40" Weight="12" />
<ItemDefinitionReference Id="Pistol_M9" Weight="12" />
<ItemDefinitionReference Id="Pistol_P226" Weight="12" />
<ItemDefinitionReference Id="SMG_MP5K" Weight="12" />
<ItemDefinitionReference Id="SMG_Super_Z" Weight="12" />
</SearchItemList>

 

Pistol_M11 has a 12% chance of appearing.

Pistol_OHWS40 has a 12% chance if the Pistol_M11 fails, which happens 88%, so net chance is 10.56%

Pistol_M9 has a 12% chance if the Pistol_M11 fails, which happens 88%, and the Pistol_OHWS40 fails, also 88%, for a net chance of 9.29%

Following the same process Pistol_P226 has only a 8.17% chance, SMG_MP5K has 7.19%, and SMG_Super_Z a 6.33% chance.

 

Referring to a post I made a long time ago on the UL forums:

"Because of the way it works though, the term Weight is somewhat misleading... it really should be considered a percentage chance to appear, and has nothing to do with a weighted list. It is odd, though... some of the SoD code does uses weighted lists correctly.

 

These sort of probability issues are often easier to understand by looking at the chance that it does not happen instead of the chance that an event does happen.

If you want 5 items to have about the same chance to appear...
Item A, weight 20, 20% chance to show up on the first check, so 80% chance it is not A.
Item B, weight 25, 25% chance to show up on the second check, or 25% of the 80% chance it is not A... 20% chance overall, and there is now a 60% chance itis not A or B.
Item C, weight 33, 33% chance to show up on the third check, or 33% of the 60% chance that it is not A or B... 20% chance overall,and there is now a 40% chance it is not A, B, or C.
Item D, weight 50, 50% chance to show up on the fourth check, or 50% of the 40% chance it is not A, B, or C... 20% chance overall, and there is now a 20% chance it is not A, B, C, or D.
Item E, weight 100, 100% chance to show up on the fifth check, or 100% of the 20% chance that it is not A, B, C, or D... 20% chance overall.

This works out to 1/5, 1/4, 1/3, 1/2, 1/1 in terms of fractions.
For 10 items, it would be 1/10, 1/9, 1/8, 1/7, 1/6, 1/5, 1/4,1/3, 1/2, 1/1
This is because you are saying essentially, give me an equal chance for each remaining item in the list to show up at each step.
First step in five items has a 1/5 chance. After that fails, four items are left, so you have a 1/4 chance for the next one. Then 1/3, 1/2,1/1.

 

In a true weighted list, imagine a bowl... you put 1 piece of paper in the bowl with an item name on it for each number of an items weight, shake it up, and pick one slip of paper.
So, say just three items, Item F weight 5, Item G weight 10, Item H weight 20. You have 5 chances of F, 10 chances of G, 20 chances of H, 35 chances total. So... it then would randomly pick a number between 1 and 35, then count up from 1 to figure out what it got."

 

The net result is that for the default search, with longer lists, the values for the first few items are way too high, so nothing near the end ever appears from that list.

[pasmon79]

A great target for modding. Anyway the way we have to traverse several breakdown levels, the items with low probability will appear anyway.

[qmjs]

Not really. It depends on how often the list is called and how many items it contains.

 

The guns.case list has 41 items all weighted at 12, but there are not that many gun cases on the map. To generate the last item on the list has a 0.07% chance of happening each search, and with only a few searches, it is quite likely that even after 100 levels you would not have found one. (That is roughly 1 out of 1,385 checks of the list.)‬

Edited April 5, 2020 by qmjs

[pasmon79]

In

<FateDeck DeckEnabled="false" DeckName="Danger_Payoff" DrawDelay="10h" HandSize="20" PlayCooldown="10h">
<FateCard Id="FoodContamination" Quantity="10">

I can safely assume that "Quantity" is the same as "Weight" used with "Resources"(Search.xml) , "Odds" with "WantList " and "Prop" and "AltOdds with "Alt".

 

What do we mean by "DeckEnabled", DrawDelay and HandSize?

[qmjs]

No, fatecards is entirely different.

 

It literally attempts to mimic a deck of cards. It is a true weighted list, as above "In a true weighted list, imagine a bowl... you put 1 piece of paper in the bowl with an item name on it for each number of an items weight, shake it up, and pick one slip of paper. So, say just three items, Item F weight 5, Item G weight 10, Item H weight 20. You have 5 chances of F, 10 chances of G, 20 chances of H, 35 chances total. So... it then would randomly pick a number between 1 and 35, then count up from 1 to figure out what it got."

 

In a given deck, there will be a number of cards of each type. (Id="Fear_Remind" Quantity="20")

 

At the start of a game load (every time, so exiting and starting again immediately counts) each FateDeck will have an empty hand.

Every (DrawDelay="6m") period, a card is selected using the weighted list. This is placed into the hand for that deck.

This will happen until the hand contains (HandSize="20") a specific number of cards. (Some will be used during the time, so the number goes up and down, starting at 0 and reaching HandSize maximum.)

Every few minutes (PlayCooldown="15m") a card will be selected from the hand randomly (equal chances of the cards already in the hand) and used, which works exactly like any other action.

 

Each deck is independant of all of the others.

 

Active fatedecks (DeckEnabled="true") start working immediately.

 

Inactive fatedecks only take effect when called by code in other actions (FateDeck DeckEnabled="false" DeckName="Daily_Offline"), and they immediately draw one card and play it when called.

 

The various cards have requirements to have any effect, so each card played may possibly have no actual effect in game. This mechanism allows a particular problem to not have an effect for some time, as a card referring to it may not be in the hand, may not be played, or a different card for a different issue may occur. It is a variant, more complex, form of randomization.

Edited April 6, 2020 by qmjs

[pasmon79]

Wow, thanks for explanation.

DrawDelay="5m" HandSize="30" PlayCooldown="20m"

Above code implies that each card is drawn after "5m" and it reaches the maximum "handsize" amount in "150m" i.e "2 1/2" days and is "played"(executed) almost 7 times with a spacing of "20 min".

 

What happens when all the cards are played with "Deck enabled" for a certain day?

Edited April 6, 2020 by pasmon79

[qmjs]

Nothing.

 

(Some will be used during the time, so the number goes up and down, starting at 0 and reaching HandSize maximum.)

 

If below HandSize, another card will be drawn.

[pasmon79]

Most of the fatecards in game draw and run after "10h". This is 50 minutes for ingame, which is too long!

 

It is a game that is meant for a person who plays day and night without interrupting to get a taste of full features(Why?)