Talk:Search odds condensed

From The Shartak Wiki
Revision as of 00:54, 18 May 2006 by Arminius (talk | contribs) (→‎Terrain tags: class titles)
Jump to navigationJump to search

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)

Comments

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)