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):

---

---

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)