Talk:Search odds condensed

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)

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)