Talk:Search odds condensed

Separate Tables (Columns of Numbers) vs Condensed (Comma-separated Text List)

Perhaps I'm just tired of having to type:

poison dart, bundle of darts (5), bundle of darts (5), bundle of darts (7), healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, healing herbs, gold coin, gold coin, gold coin, gold coin, gold coin, gold coin, gold coin, gold coin, gold coin, gold coin, gold coin, machete, machete, machete, machete, empty blowpipe (0), empty blowpipe (0), empty blowpipe (0), knife, knife, knife, blunt machete, blunt machete, sharpening stone,

but I would like to switch to Tables for Search Odds, with a table for each important location. The tables would look similar to the following example.

Ammo Hut Searches:

Signature	AP	Nothing	Bullet	Box Bullets	Bottle Water	Bottle Beer	Sharp Stone	Knife	Blunt Machete	Machete	Gold Coin	GPS Unit	Rifle, Empty	Rifle, Partially	Rifle, Fully	Class	Location & Notes
Tycho44 06:32, 26 April 2006 (BST)	68	47	6	(4)	2	1	0	3	0	6	0	0	0	0	2	Settler	York
sig	ap	-	-	-	-	-	-	-	-	-	-	-	-	-	-	class	location
Total: 19:52, 31 May 2006 (BST)	394	245	43	39 b in 12 boxes	23	6	4	18	6	14	5	1	6	6	5	n/a	Total

A brief summary of the arguments for placing numbers of items in columns rather than using a comma-separated list of items.

• 1. Avoids spelling errors (typos in piece of driftwood, etc.)
• 2. Avoids notational conflicts

a. Capitalisation inconsistencies (hut, first aid kit, gps unit, etc.)

b. Pluralisation inconsistencies (herbs, darts, bullets, bundles, etc.)

c. Abbreviation inconsistencies (FAK, bundle / bundle darts / bundle of darts, bottle water, driftwood, etc.)

d. Box/load notation inconsistencies (bundle of 2 darts / bundle darts (2), partially loaded rifle / rifle (1) / rifle(1), etc.)

• 3. Easy to use (Ultimately, searchers would rather type "13" under a Mangos column instead of "mango, mango, mango, mango, mango, mango, mango, mango, mango, mango, mango, mango, mango" -- as evidenced by frequent use of "13 mangos" and "Mangos: 13" entries.)
• 4. Less prone to human error in data entry (Comma-separated lists are easy to cut/paste incorrectly and errors aren't easy to spot. Since the searcher mentally tokenizes the info as "13 first aid kits" it is easy to visually verify the table -- an error shows up as "31 first aid kits" or "13 gps units" and is more likely to be caught by the searcher.)
• 5. Allows a current running total of the most important search values (Casual visitors can eyeball the raw data to obtain an accurate sense of the search odds -- it is immediately apparent which items are available and roughly how frequently they are found.)
• 6. Can be easily cut/pasted into spreadsheets such as Excel (For an entirely automated process, tables would require separate scripts for each location. Generally speaking, however, the data is straightforward to transcribe under either recording method.)
• 7. Demonstrated to work in Urban Dead (And Shartak's similarities are more important than differences imho: players are very interested in a few specialized locations including Medical Huts, Ammo Huts, Ruins Huts, much like Hospitals and Malls.)

In my opinion, I would like to migrate Ammo Hut, Armoury, Dart Hut, Medical Hut, Large Cabin, Herbal Hut, Galley, Hold, Tree, Hut, Beach, Grassland, Swamp, and Water to individual tables. Exterior variable-density locations, specifically open Jungle and outdoor Village (with or without Hut, Shaman, etc.), would be the last to migrate, since they are the best suited to using comma-separated lists: (1) very large variety of very low probability items combined with (2) ancillary variables (density, presence of hut, shaman, signpost, etc.) to track.

Please add your comments, suggestions, votes, etc., about using number columns (Search odds) versus comma-separated text listing (Search odds condensed):

---

Comments

I like it, with one slight change: the format for bullet boxes and dart bundles should be "2 (5)", meaning 2 boxes holding a total of 5 bullets; likewise, the totals column would read something like "8 (31)", meaning 8 total boxes and 31 total bullets inside them. (Whether or not boxes/bundles are more likely to have a certain number of bullets/darts inside, such as 5, is irrelevant. Averages are what people care about.) Also, we should make sure the item columns are sorted (probably alphabetically: "bottle of beer", "bottle of water", "box of bullets", "bullet", etc.). — Elembis (talk) 21:48, 31 May 2006 (BST)

I also agree that all we need are the number of "box" finds, and the total number of bullets contained inside all boxes: "31 in 8" or "(31) 8" or "8 (31)". A concern is that someone who has never recorded and finds 2 boxes of 6 bullets each doesn't write: "2 (6)" or "6 6" by mistake. Similarly, it should be impossible to mistake whether or not to add loose (boxless) bullets into the total bullet find count. --Tycho44 00:42, 1 June 2006 (BST)

I see how notation could be a problem. A couple of bold notices will be all we can do; we need box and bullet counts until we know how many bullets are in each box, on average. (My guess is 5.) — Elembis (talk) 04:17, 1 June 2006 (BST)

As far as order of item columns, I find that decreasing find frequency is the most visually appealing, and decreasing item value is the most visually informative. However I believe that simple alphabetical is a smarter overall choice, since it is universally applicable and expected. --Tycho44 00:42, 1 June 2006 (BST)

Most contributors will probably be adding information to multiple tables over time, so the sort method that would make contributions easiest would be alphabetical. That would also let people looking at the tables find an item in a split-second without having to read more than a couple of headers or think about whether an item is common or not in the given terrain type or location. And sorting by find frequency would require occasional column swaps, distracting contributors and frequent viewers alike. — Elembis (talk) 04:17, 1 June 2006 (BST)

Tables are better for the reasons you mentioned, so I'm going to start putting all of the data on the page in tables. — Elembis (talk) 06:28, 7 June 2006 (BST)

Spreadsheet use (and writing a script to convert the lists to table format) will be easiest if boxes of bullets and bundles of darts are either placed in separate columns (which gives additional (if pointless) detail at the cost of even more horizontal screen space) or are poured into the bullet and dart columns (e.g., finding a 2 bullets and a box of 5 bullets will show up on the table as a find of 7 bullets). I recommend the latter option, since there's nothing special about finding bullets in a box. — Elembis (talk) 03:46, 8 June 2006 (BST)

Yes, there is something special about finding bullets in a box: we need to know the number of boxes vs loose bullets found in order to statistically analyze the effects of Scavenging, to compare Empty Huts to Resource Huts, and so forth. Boxes should be kept separate from Loose Bullets. I support two columns: "Bullets found in Boxes (total # bullets)" and "Boxes Found (total # boxes)", in addition to "Loose Bullets". The number of bullets in any particular box is immaterial (like you said earlier). (For example, a hut that generated 10% Box 8 Bullets would be different from a hut that generated 80% Rifle Bullet, especially for a character with 69 items in inventory.) --Tycho44 08:42, 8 June 2006 (BST)

There has been little activity here since 2006. In the more than two years since that data was added, many knew items have been made. I suggest an "Other" column, which would ask for you to list it in the notes. We may also want a "fungi" column. --TripleU 08:41, 10 January 2009 (UTC)

---

Earlier Comments

Collating

There is simply not a whole lot of interest in compiling these statistics, so I am not planning on collating at a set time anymore, but when there is a feeling that there is "enough" data.

If you have any comments feel free to leave them here or on my talk page -- fitzcarraldo|^T 12:12, 10 April 2006 (BST)

Class column

is there a feeling that the odds are different for each class of character? I understand with scavenging, but that could be fixed with a note.. I seem to have missed that the character type is needed to be tracked? The reason I don't necessarily want to add it is that it makes collating the results an exponential job meaning a search odd for d1 for native shaman, d2 ..etc.. then d1 native warrior.. ->oo (to infinity :) ).. that makes the need for *puts finger in the air wihtout looking at the numbers* hundereds of charts which becomes not useful, particularly with the lack of data received!? If I don't hear something more from you on this, I will revert that change you made adding classes. (copied this on your(tycho44) discussion page.. feel free to contact me here or on my talk page to discuss) thanks -- fitzcarraldo|^T 15:35, 26 April 2006 (BST)

• Yes, there is such a feeling. Someone said the scientist/shaman had a higher search rate -- without any supporting evidence, but we have no evidence against either. There were complaints & suggestions that the villager/settler was dominated by other character types, and should start with some advantage such as a higher search rate. By and large Simon appears to be implementing changes behind the scenes as fast as we can suggest them, so it is natural to suspect that starting Settler-0 has a higher search rate than Soldier, Pirate, et al. Currently my Settler finds are nearly 50% in buildings, which I believe is higher than for other classes. But we need to log the searches, because I could easily have gotten lucky. --Tycho44 17:53, 27 April 2006 (BST)

• KEEP--One of the main objectives of this 'condensed' version was to encourage data entry. That thought alone is what really drives my desire not to include another column as it is another place for people to possibly screw up or feel it is too difficult. Now, if it is needed as you say, then of course, leave it in, hence the "keep". For some background on what I have put together here.. I was aiming at a single table so one wouldn't have to hunt around for the right table for their specific data. A place to put any and all data and always in the same form, letting computers do the inane sorting later. I did some testing streamlining the table to try to make it as simple as I could for wiki data entry. Again, all of that was to encourage people to add data. Sadly, there is very little data added anyway.. even with it being on the front page for quite a long time now. The tables are saved as html and imported into excel and collated (for the most part) automatically into the graphs. If/when there was more interest I was planning to ask if the wiki could get a timeline plugin installed [1] I have worked a little bit on a preliminary version of an automatic graph maker for wiki sorted from the shartak data. It would remove the need for making the lame process of screenshot, cropping, import.. with this installed on the shartak wiki it would be a simple cut and paste of text directly into the wiki creating bar graphs automatically, and saving lots of time. -- fitzcarraldo|^T 01:04, 28 April 2006 (BST)

• To be clear, collating the data when the class info is there isn't more difficult - if you don't think it makes a difference, then collapse across those columns in your aggregate summaries. I'd be glad to help out with data collection and analysis. (also posted to your talk page) --Tycho44 17:53, 27 April 2006 (BST)

• As to collapsing, that isn't the issue, it is as I discuss above it is more the streamlining and simplification .. anyway, one can simply ignore the data as you say. Although it does become more of an issue later in that finding trends becomes just that much more complicated as the degrees of freedom increases. Based on my current experience and the quickly increasing number of variables in the mix, I think the data needs to be in a real database, not excel as it currently resides. Nonetheless, if you feel you want to work with this further, please do. Let me know what parts you want to do, if not all of it .. if we are both doing the same thing, I will feel as if work has been wasted which could be spent on something else for the common good. My time is limited at the moment as the lack of data has allowed me to reprioritize away from this project a bit. -- fitzcarraldo|^T 01:04, 28 April 2006 (BST)

• Another important thing to keep in mind: the Scavenging ability (and character class in general) probably only affects the chance of a successful item find -- it probably doesn't affect the distribution profile among different items. For example, if Scavenging gives a +50% chance of finding something in an Ammo Hut, then 20 AP of Scavenging will yield the same information as 30 AP of normal searches. Analysis gets simpler rather than more complex... --Tycho44 07:16, 16 May 2006 (BST)

Larger sample sizes

Perhaps 30 AP spent searching minimum? --Lint 18:17, 27 April 2006 (BST)

KILL-- I don't think a minimum is a good idea. A search of 1AP is as valuable in the overall statistics as each AP of a search consisting of 2000AP. For data collation it makes no difference, the more data the better! So if someone wants to include a search of 1AP I say let them! :) -- fitzcarraldo|^T 01:04, 28 April 2006 (BST)

Fine :P It should be noted that statistics was never my strong suit. --Lint 01:16, 28 April 2006 (BST)

Every little bit helps. However, when possible, people should plan in advance to log the search results. If the submitter is only half-hearted, then they might say to themselves after-the-fact: "Hey cool, 7 rifles in 10 searches!" or "Hey cool, a heavy sword!" and rush off to contribute to the wiki, whereas their less interesting search events don't get submitted. This isn't good: If someone only contributes on days when their search outcome is exciting or aberrant, then the data gets messed up. --Tycho44 10:50, 30 April 2006 (BST)

Terrain tags

The page is not entirely clear as to how to tag village terrain, disheveled huts, empty huts, ruins, oases, etc. I think this needs a clear key at the top of the page. Also, perhaps just let people copy and paste the description from their location, and then replace it with an appropriate code? I'd be happy to go through entered results and replace word/sentence terrain descriptions with specific codes if that makes your data processing easier. --Rotund 08:17, 5 May 2006 (EST)

I agree that copy/paste from the location description is probably the easiest way for a new searcher (unfamiliar with the lingo and the density overlay) to add in their location. Putting someone in charge of doing a global edit to unify entry codes would also be good. Oddball additional information that someone puts in their location column or class column can be appended to the NOTES column instead, where presumably the automated readers won't have problems with it. --Tycho44 18:12, 15 May 2006 (BST)

The three-letter codes for the character class seem needlessly confusing too. Plus there's alot of empty space in that column. So if anyone doesn't mind I'll go through and change all of them to "Soldier", "Shaman", "Settler w/o Scavenging" etc. Arminius 01:54, 18 May 2006 (BST)

That would work for me. --Tycho44 02:32, 18 May 2006 (BST)

From my experience, Jungle (d3), York (d3), and Dalpok (d3) searches are each going to have different search profiles, whereas Jungle (d3) and Jungle (d4) are likely to be the same. Here would be my first draft for Location Designators:

Jungle Terrain Designators

• d3 Jungle: empty Jungle space
• d2 Native Empty: empty space in a Native Village
• d5 Native Hut: outside a Hut in a Native Village
• d3 Outsider Empty: empty space in Outsider Village
• d0 Outsider Hut: outside a Hut in an Outsider Village
• d2 Ruins: outside Ruins icon (Hut 1/Hut 2/Hut 3 buttons) (assumes Ruins are always in the Jungle)
• d4 Jungle Hut: outside a Hut in the Jungle
• d1 Tree: (assumes Trees are always in the Jungle - or "d4 Jungle Tree")

Hut Designators

When inside a Hut, there is no Jungle density, but we need a description of which hut you are in... Here are some examples:

• in Hut, Empty Outsider
• in Hut, Dishevelled Native
• in Hut, Empty Jungle
• in Hut, Ruins #2
• in Hut, Temple Ruins #2

Wherever possible, we should put the GPS in the Notes column! (I was using the "in Hut" notation just to keep from confusion with searches outside of Huts.)

Uberhut Designators

• Ammo Hut: in Outsider Ammo Hut
• Medical Hut: in Outsider Medical Hut
• Dart Hut: in Native Dart Hut
• Healing Hut: in Native Healing Hut
• Trading Hut: in any Trading Hut (they're all empty)
• Large Cabin: in Shipwreck medical hut
• Armoury: in Shipwreck ammo hut
• Hold: in Shipwreck treasure horde
• Galley: in Shipwreck rum stockpile

Non-Jungle Terrain Designators

• Grasslands
• Beach
• Swamp
• Water
• Deep Water
• Mountain Path
• Cave
• Tunnel

Those would be my suggestions for the Location column. Other locations could be fully designated using a similar style. It is pretty complicated: locations may have a Jungle density, terrain name, detail name, an Outsider/Native designator, and a sub-detail (such as Empty or Dishevelled for the Huts). --Tycho44 02:32, 18 May 2006 (BST)

New style

Well I'm hopelessly confused now. Wasn't the original idea to put all the data into tables on the other page, Search odds? And to keep it simple here so that people could add search data with ease. Arminius 09:42, 8 June 2006 (BST)

I'm sorry you're confused. Did you see the new template? You should be able to copy and paste it without much trouble, but it may be harder than I think (since I made it). — Elembis (talk) 10:15, 8 June 2006 (BST)

The new style is good, but why not use this new style on Search Odds, as a final polished presentation of results for analysis, and go back to the old easier style for data entry on this page. I thought this page was just for dumping data and not the final search odds page anyway, so the goal here should by simplicity for entering data, not the best possible presentation of results, that should be on Search Odds. Anyone else agree? Arminius 18:00, 14 June 2006 (BST)

My goal was to make collation much easier without making submissions noticeably more difficult at the same time. I think the template is pretty straight-forward (edit your name, AP used, class and location, just as before, and add numbers on the appropriate rows). It's not that this table is necessarily a better presentation of the data, but it does make the data pasteable into spreadsheets, which in turn makes statistical analysis remarkably faster. If you'd like, I may add an old-style table in addition to the new one (while stating that the new one is preferred), or you can continue to add data as you have to this talk page. Thanks for the feedback. — Elembis (talk) 06:02, 15 June 2006 (BST)

I thought that the old "easier" style ("first aid kit, mango, mango, mango, mango, ...") was more difficult to submit -- and much more difficult to submit accurately -- than the new (tabular) format. It was my impression that Arminius was one of the people entering "28 FAKs, 10 others"-style entries which are much closer to the new tabular format, where you see a FAK column where you type "28". My proposal is to use separate tables for each of the Resource Hut locations, so that the number of columns in the table is reduced tremendously (to the half-dozen items that actually appear). In other words, I'm copying the model used by the Urban Dead wiki, which seemed to work well supporting a much larger number of submitters. The original (old) style here was designed to support easy collation, not simply to support easy data entry. At the time, the data was being collated by fitzcarraldo using his own automated script, and since no one else has that script, I leave him to defend the advantages of that system.

My perspective on the "new style versus old style" debate is presented much more fully in a huge section at the very top of this page, where further comments are welcomed. --Tycho44 07:08, 15 June 2006 (BST)

|- | style="font-size:75%;line-height: 1em " | Arminius 09:42, 8 June 2006 (BST) | | Soldier | | Ammunition Hut | | 65 | | 21 Successful searches (26 items)

Items List: 3 box of 2 bullets, 2 bottle of water, 2 bottle of beer, 2 blunt machete, 3 sharp stone, 1 rifle bullet, 1 machete, 2 gold coin, 3 gps unit, 1 knife, 1 rifle (2) (Total bullets found: 9) | | 32.3% success rate (40% item find rate), 13.9% bullet find rate (i.e., in 10 searches I could count on getting 1.4 bullets) |- | style="font-size:75%;line-height: 1em " | Arminius 09:42, 8 June 2006 (BST) | | Scientist | | Hut #1 at Ruins | | 100 | | 4 healing herbs, 2 gold coins | | |- | style="font-size:75%;line-height: 1em " | Arminius 09:42, 8 June 2006 (BST) | | Settler w/Scavenging | | Ammunition Hut | | 75 | | 42 successful searches (56 items)

Items List: 6 gold coin, 3 rifle (1), 3 rifle (2), 3 bottle of water, 14 rifle bullet, 1 box of bullets (2), 3 gps unit, 2 boxes of bullets (4), 1 blunt machete, 1 rifle (0), 1 box of bullets (5), 1 knife, 1 bottle beer, 2 sharp stone. (Total bullets found: 38) | | 56% success rate (74.6% item find rate), 50.7% bullet find rate (i.e., in 10 searches I could count on getting 5 bullets) |} </nowiki>-->

Should we rename the AP column to Attempts or something similar? I'm beginning to conduct searches in swamp terrain, but each attempt is costing me 3 AP. --Lint 01:33, 25 June 2006 (UTC)

Yes. — Elembis (talk) 03:31, 25 June 2006 (UTC)