Difference between revisions of "Property talk:Studytime"

From Ring of Brodgar
(Studytime progress: Done)
(Studytime progress: Done+)
Line 195: Line 195:
 
* Implemented time-code support into related template.
 
* Implemented time-code support into related template.
 
* Changed/Update hour-float to time-code for studytime related pages.
 
* Changed/Update hour-float to time-code for studytime related pages.
Left overs:
+
* Limiting displayed studytime-infobox-output to hours and minutes only (''ie: ditch days part for H>23'')
* See about limiting displayed studytime-infobox-output to hours and minutes only (''ie: ditch days part for H>23'')
+
* Save "hH mM" text to separate property. (SMW table support)
* ...
+
* Switch SMW Curiosity tables to using "hH mM" time text. (''forced refresh on related pages'')
--[[User_talk:MvGulik|<i><font color="#666" size="2px">.MvGulik.</font></i>]] 10:57, 7 June 2019 (EDT)
+
... Think that's about it. --[[User_talk:MvGulik|<i><font color="#666" size="2px">.MvGulik.</font></i>]] 03:32, 8 June 2019 (EDT)

Revision as of 03:32, 8 June 2019

StudieTime Search

Main ns 'studytime' used values search:
Target RE Count Rem
Just StudyTime (?i)studytime 232
As template parameter (?i)studytime *= *[0-9]+ 227 Equals to Pages in category "Curiosity"
Decimal number (?i)studytime *= *[0-9]+\. 194
Integer number (?i)studytime *= *[0-9]+[ \n]*\| 33 277 = 194 + 33
Decimal part < 60 (?i)studytime *= *[0-9]+\.[0-5] 169 169 = 20 + 145 + 3 + 1(misfit: Troll page)
Decimal part > 59 (?i)studytime *= *[0-9]+\.[6-9] 25 194 = 169 + 25
Decimal part < 60, one digits (?i)studytime *= *[0-9]+\.[0-5][ \n]*\| 20
Decimal part < 60, two digits (?i)studytime *= *[0-9]+\.[0-5][0-9][ \n]*\| 145 Main target group.
Decimal part < 60, three or more digits (?i)studytime *= *[0-9]+\.[0-5][0-9][0-9]+[ \n]*\| 3
Decimal part == 00 (?i)studytime *= *[0-9]+\.00[ \n]*\| 24 121 = 145 - 24
Decimal part == 60 (?i)studytime *= *[0-9]+\.60[ \n]*\| 0
Specified search specs are a bit off/outdated.

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.
...
--.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)
>" or display on other pages (days part:yes/no/unsure)."
Display needs to be in Hours and Minutes. Players think about curiosities in terms of hours, even if in hundreds of hours. The Curiosity Table is the best example here - experienced players pay very close attention to the values generated by the curiosity table (LP/HR, LP/EXP/HR, etc) and need these values in terms of hours.
I feel the infobox should still have the D:H:M:S as a secondary display however. It's useful information - It just isnt immediately useful for calculation.
--Ricky (talk) 04:16, 20 May 2019 (EDT)


>"it's not reasonable to (the already complacent) players to do the math to translate the information into HH.ddd format."
Perhaps, but its no rocked science either (MM/60). The thing is that that "XX.YY" format technically demands it to be "HH.ddd", especially as its used as such in the curiosity calculation. Granted, the effect of calculation with "HH.MM" data instead of "HH.ddd" data only effect those values that use minutes(as decimals), and the offset on the calculated results are relative low to minor. But that don't changes the fact that its still a bad idea (and bad Math/Arithmetic to boot).
>"The game does display time in an HH.MM format"
Technically is display hours and minutes separately, ie: "HHh MMm" format which is not the same as "HH.MM" format. Perhaps a minor detail, but its details like that that (in my view) makes discussions harder than they need to be. (Ref Img)
>"I think two separate fields would be best"
Maybe, I'm not sure yet (I'm still somewhat in collecting and evaluating ideas mode). One problem is that I'm currently not interested to dig into SMW's records. And storing the Hours and Minutes in separate properties is also not really a solution I like.
Technically "HH:MM" (as data input) could be seen as two fields (with (:) as field delimiter). And, its none ambiguous. Although I initially saw it as troublesome, that is changing. I just need to do some testing to see where potential problems might arise when using "HH:MM" as input.
>"Perhaps a pain to update all the pages initially"
Not really. Creating a Bot process to do that job seems not that troublesome. Its the data verification part that's the real painful part.
>"I can't tell whether or not you've already changed the StudyTime values from HH.MM to HH.ddd."
I have not changed any data. You are however putting your finger right on the current troublesome part. Only if a StudyTime value (with some decimals) has a decimal value above 59 it is clear its using a "HH.ddd" value. For all other cases with some decimal value its unclear, and it could be either "HH.ddd" or HH:MM" (The page revision history could potentially reveal in some cases which it is, but I have not looked at that part yet. Not looking forward to that part either, although some coding might help out here (for later).)
>"It appears some have been changed to .ddd (their D:H:M:S calues read correctly) while some are still in .HH"
(?:".HH", assuming you mean ".MM" here)
1) Aha, right. Now there is something that can be used to speed up the verification process. (I don't play the game, as such some parts get overlooked by me => (Ref Img))
2) Some users defaulted to inputted "HH.ddd" value data, other users defaulted to inputting "HH.MM" value data.
(... In case Kitsuneg might still be among the readers. Ergo-1: The need for a full re-validation of the StudyTime data. Ergo-2: The need to get everyone on the same page in relation to the need to just use one and the same value format. (where by "HH.MM" type data is out, as that was source of the mess in the first place. And for an actual minutes input instead of hour.decimals input some other option/changes needs to be implemented (which takes time and thinking))
... Running out of steam, and getting hungry.
Think my comments also answer most of the rest of the post. (if not re-ask)
Ok. Days is out for final main infobox output on StudyTime.
Additional time notations (including actual input value while where still on HH.ddd data) could be dumped into a note-pupup. (or maybe two lines, one for main HHh + MMm only data, and a second one for a/the more detailed time notation.)
...
Current plan: ... (WIP. Need to write it down, than look at it again. So probably tomorrow)
...
Addition Notes:
No Undoing the occasional(!) user that's adjusting the StudyTime data. If need be add a dummy-edit with info in the edit-summary on the direction of the change (in case the user did not provided that info/summary themself).
Remember that this is probably the only page on RoB stating anything about any standard for the input on StudyTime. (preceded by talk at Kitsuneg)
--.MvGulik. 15:06, 20 May 2019 (EDT)


Dunno how long it will take, i still not done with sats and now re-validate all curious? oh god.
Just put a notification like on sats on all curious where value above 59 before redone this.
There is no any back-up, data dump or something, before this was implemented? re-validate all this.. something to make work not that big.
Feel like Sisyphus.
--Kitsuneg (talk) 16:57, 20 May 2019 (EDT)


Kitsuneg. Please don't be like a sour grape.
You still don't seem to get something. The ambiguity problem is not with the StudyTime's above .59, Its with those below .60.
It was more or less implemented the moment StudyTime started being used for calculation additional curiosity data. (At 25 March 2011 by Breon => [1] + [2])
Now ... I don't care who (re)started with using HH.MM input data for StudyTime. I just know it needs to be straitened out, and that's what I'm doing.
--.MvGulik. 01:21, 21 May 2019 (EDT)


Ok.
Below, right. I understand this just mistake in wording.
--Kitsuneg (talk) 02:59, 21 May 2019 (EDT)


Roger --.MvGulik. 02:55, 22 May 2019 (EDT)


Process: (v1)

  • Stage one part one: (Curiosities with decimal value below 60.)
    • Dedicated StudyTime wiki-table (on separate page) for bulk verification.
      • Fields: curiosity/Page name/link, hour decimal, converted HHh MMm time, validation field: HHh MMm / HH:MM.
    • Page-notation on related pages. Redirecting to related wiki-table page for StudyTime editing. (as verifications there are going to overrule related curiosity page StudyTime edits)
  • Stage one part two: (All curiosity pages)
    • Rename parameter "StudyTime" to "StudyTime_hd".
      • Using current used "StudyTime" values, convert to xx.yyy format (to break hh.mm(hh:mm) similarity)
    • Explore implementing support for "StudyTime_hm" parameter" (HH:MM)
  • Stage two: (depending on verification activity, after "StudyTime_hm" availability is determined (and implemented if feasible).)
    • Merge StudyTime wiki-table verifications back into curiosity pages.
      • Using "StudyTime_hm" if available.
    • Drop related Page-notation on verified cases.
    • Change related Page-notation for leftover cases from redirection to verification note.


Hoped I could add the needed studytime pagenotice change at this moment. But I'm running out of time to do any follow up checkups. So delaying it to after work. --.MvGulik. 02:50, 27 May 2019 (EDT)

STUDYTIME Pagenotice added to target pages (121) (phew).
A word about the addition changes applied (should actually go at some other page I think. Not sure where at the moment, maybe later).
Infobox parameters where a bit regrouped, with groups separated with a blank-parameter-line. And all data parts where outlined on the "=" character.
Headline where adjusted so they have one blank line before and after them.
Some pages also have a lot of minor edits. These where removed trailing spaces in lines.
... time to start working on the merging back part.
--.MvGulik. 17:33, 27 May 2019 (EDT)

Studytime progress

I think I've figured out the raw code parts needed to potentially support both hour-floats(H.ddd) and time-codes(H:MM) as input for the Infobox_* StudyTime parameter.
Initially thought about using two separate parameters to support both input times (Studytime_hd, Studytime_hm), But did not really liked that option.

The input will have some rules. Like a time code will have to have at least one hour decimal, and 2 minute decimals, so ":MM" would give you a bad-input err/message (correct input would be "0:12").
For hour-floats the same deal will apply for the integer part. And for the float part a minimum of 3 decimals will be enforced. The why relates to: 1) making sure to block the potential H:MM similarity, and 2) Precision. H:MM has a precision of one minute. Hour-float's that have a lower or ~equal precision should use the time-code. (The precision for an hour-float is: 6 minutes for decimal 1, 36 seconds (0.6m) for decimal 2, 3.6 seconds for decimal 3 (0.36 (~1/3) seconds for decimal 4) as such righthand-zero-padding is required for values like 1.2 => 1.200. (Math note: 1.2 and 1.200 might be the same value (to a calculator), there notation indicate significant different precisions)

The reasons for maintaining hour-floats at this moment are: 1) Potential down sides of using H:MM (property related, to be looked at), 2) (minor) Smoother transition, 3) Allowing for a higher then minutes precision input option (if its deemed to not be needed (probably), this can be ditch later on. But at least there is some history record of how something like that can be implemented if the need arises again)

When I get the Studytime change to work, I will also change all hour-floats to time-codes (to the nearest/rounded minute)
A personal note about the Property:Studytime/verification page. If there are users that intent to use it (in the way its intended). Its probably a good idea to let me know (one way or an other). ... I roughly figure it currently might have a lifetime of about a week. --.MvGulik. 07:33, 31 May 2019 (EDT)

Kitsuneg: Thanks for your verification updating support. :-)


Bot stuff verified & ready to be run:

  • Updating Studytime parm from hour-float to time-code. (all 200+ pages)
    • Importing & using verified times from Studytime/verification page.
      • Diching STUDYTIME pagenotice tag for those cases.

... So only thing left is adding that time-code support to RoB. (pretty much on expected schedule. Expecting to finalize the job on Friday (my first next free day))
--.MvGulik. 07:28, 2 June 2019 (EDT)


RoB Effects: (kinda nts/todo's/lookinto)

  • Infobox Doc Examples issue: #show needs saved property (effected items now showing default value). Saving them for Doc example might be a problem. Potential alternative would be to used an already saved case (not sure yet if that would/could work ... letting it simmer for now)

--.MvGulik. 13:18, 3 June 2019 (EDT)


Oops, it just hit me that I can't really exclude single digit decimal cases from being targeted as being potential dubious/ambiguous cases. (~20+ cases)
Manually updated bulk-verification table with them. Erm ... not sure at the moment if I 'pre-add' a STUDYTIME page-notification to those pages becouse: 1) I kinda reused the code in question (lol/idiot), and 2) the planned final update run is just a few days away. Will of course adjust the current code to add a page-notice to them in the final update run when needed.(Done: 'pre-add' STUDYTIME page-notification)
--.MvGulik. 15:09, 4 June 2019 (EDT)


Done
  • Implemented time-code support into related template.
  • Changed/Update hour-float to time-code for studytime related pages.
  • Limiting displayed studytime-infobox-output to hours and minutes only (ie: ditch days part for H>23)
  • Save "hH mM" text to separate property. (SMW table support)
  • Switch SMW Curiosity tables to using "hH mM" time text. (forced refresh on related pages)

... Think that's about it. --.MvGulik. 03:32, 8 June 2019 (EDT)