Difference between revisions of "Property talk:Studytime"

From Ring of Brodgar
(StudieTime decimals: + 'studytime' search)
(StudieTime decimals)
Line 34: Line 34:
 
:...
 
:...
 
:--[[User_talk:MvGulik|<i><font color="#666" size="2px">.MvGulik.</font></i>]] 22:25, 19 May 2019 (EDT)
 
:--[[User_talk:MvGulik|<i><font color="#666" size="2px">.MvGulik.</font></i>]] 22:25, 19 May 2019 (EDT)
 +
 +
::read through the discussions - The game does display time in an HH.MM format, and it's not reasonable to (the already complacent) players to do the math to translate the information into HH.ddd format.
 +
::I think two separate fields would be best. Perhaps a pain to update all the pages initially, but would be the easiest way to remove all ambiguity as to whether the infobox displays HH.ddd or HH.MM.
 +
 +
::I can't tell whether or not you've already changed the StudyTime values from HH.MM to HH.ddd. It appears some have been changed to .ddd (their D:H:M:S calues read correctly) while some are still in .HH
 +
::If you have changed the values to HH.ddd, could you roll them back until we get this sorted out? whichever option you decide, 1 field as HH:MM string or 2 fields separately, we need the original HH.MM values to populate these fields, and many of the items (curiosities) arent readily available to double check (in-game rarity/scarcity)
 +
::for what its worth, I enjoy the D:H:M:S field and would prefer to see that display in the infobox instead of (A very ambiguous) HH.MM or HH.ddd, but the users need to be able to input Hour and Minute data.
 +
::And apologies for not taking the time to discuss this with you beforehand. Real life has kept me busy (''As I'm certain you can understand'')
 +
 +
::--[[User:Ricky|Ricky]] ([[User talk:Ricky|talk]]) 04:16, 20 May 2019 (EDT)

Revision as of 03:16, 20 May 2019

StudieTime decimals

There seems to be no written documented/standard on RoB when it comes to the decimal part of the studytime value (and why that might be somewhat of an issue).

As where dealing here with a hours time value, its decimal part is potentially subject to personal interpretation. As in the decimal being the remainder of an hour in: 1) a hourly percentage (0.000 .. 0.999)(probably used by the majority of the related data), or 2) the remainder of an hour in minutes (ie: 0.00 .. 0.59)(spotted one such case due to it being corrected).

The problem with the one detected case here is that it shows/proofs the viability of the personal interpretation case. And unfortunately it also casts a shadow of doubt on all the other HH.(00..59)(2 digit decimals<60) values.

One possible way to lower that shadow of doubt could be to add a related Pagenotice to cases where this might be the case (all with a decimal value lower then 60). But that would not prevent it from potentially creeping in again, and as such its only a relative temporary resolution (if nothing else changes).

Adding a note to the StudyTime text about the intended/default decimal format in the infobox would also not completely eradicate the problem. It would potentially seriously minimise it. (to be implemented)

One additional option could be to not use 1 or 2 digits for the decimal part, but at least 3. As I doubt anyone would write a HH.MM value in a 3 digit format. (note: this could be used as a way to confirm potential HH.MM(2 digits<60) cases as being a correct HH.ddd case)

One additional side-note about using decimals is that they infer accuracy (especially with a default of 3 digits). Which kinda raises the question what the used source data is, and if its somehow related to in-game time data (custom clients?). The thing with in-game time data is that one could have used the general 3.0 ratio to get the actual/real time, or the more specific 3.29 ratio (as specified at Glossary#Day_and_Night_Cycle). ... Not knowing if 3.0 or 3.29 is used would kinda hinder/defeat the inferred decimal part purpose.

(Just in case. Technically, to not fall in said time-data ambiguity trap, one should always default to writing/displaying Hours plus Minutes data as "HH:MM" and not as "HH.MM")

--.MvGulik. 23:34, 31 March 2019 (EDT)


The point that it would be easier to use Hours and minutes as input data is valid. (User_talk:Kitsuneg#StudieTime)
Available Options seem:
- "HH:MM" string input. But that would need some way to convert it to an "HH.ddd" value for other uses. Preferably before storing it as property. Would probably also need a way to turn "HH.ddd" back to "HH:MM" for display on other pages (days part:yes/no/unsure).
- Separate HH and MM field input: ... Maybe, think that just splitting "HH:MM" string would/should do the trick.
...
Main ns 'studytime' search:
Raw - "(?i)studytime" 232 pages:
Tpl - "(?i)studytime *= *[0-9]+" 227 pages: (Equals to Pages in category "Curiosity")
Dec - "(?i)studytime *= *[0-9]+\." 194 pages:
Int - ("(?i)studytime *= *[0-9]+[ \n]*\|" 33 pages: (277=194+33) )
D<60 - "(?i)studytime *= *[0-9]+\.[0-5]" 169 pages:
D>59 - ("(?i)studytime *= *[0-9]+\.[6-9]" 25 pages: (194=169+25) )
...
--.MvGulik. 22:25, 19 May 2019 (EDT)
read through the discussions - The game does display time in an HH.MM format, and it's not reasonable to (the already complacent) players to do the math to translate the information into HH.ddd format.
I think two separate fields would be best. Perhaps a pain to update all the pages initially, but would be the easiest way to remove all ambiguity as to whether the infobox displays HH.ddd or HH.MM.
I can't tell whether or not you've already changed the StudyTime values from HH.MM to HH.ddd. It appears some have been changed to .ddd (their D:H:M:S calues read correctly) while some are still in .HH
If you have changed the values to HH.ddd, could you roll them back until we get this sorted out? whichever option you decide, 1 field as HH:MM string or 2 fields separately, we need the original HH.MM values to populate these fields, and many of the items (curiosities) arent readily available to double check (in-game rarity/scarcity)
for what its worth, I enjoy the D:H:M:S field and would prefer to see that display in the infobox instead of (A very ambiguous) HH.MM or HH.ddd, but the users need to be able to input Hour and Minute data.
And apologies for not taking the time to discuss this with you beforehand. Real life has kept me busy (As I'm certain you can understand)
--Ricky (talk) 04:16, 20 May 2019 (EDT)