Denied Investigate (& Implement) A Method To Externally Read VTime Data (Or Otherwise Get Player Hours)

This suggestion has been denied and will not receive development.
Status
Not open for further replies.

What does this suggestion change/add/remove:

If at all possible, implement a system that allows things like Google Sheets to retrieve the hours that SteamIDs have been on a job for, in a given timeframe (For that day would be a good minimum, but given the way activity checking works (at least in (UK) E-11), most preferred would be to specify hours, but make that part of the call optional).

The process would ideally look something like:
  1. A department's roster makes an API call to the server (I think we would need some kind of basic support on how to set up this call, maybe a guide if possible?), provides a timeframe, a list of SteamIDs and I guess some kind of ID that refers to departmental/regimental jobgroup (E-11, Nu7, DEA, etc.)?, i.e.:
    For the date of 01/01/1970 [and optionally, between the hours of say, 14:00 & 20:00], provide the hours on E-11 for STEAM_A:X:XXXXXXX, STEAM_B:X:XXXXXXX & STEAM_C:X:XXXXXXX.

  2. Server returns the date, SteamID & the hours that SteamID has played that job during the supplied timeframe (without including time marked as AFK if possible), i.e.:
    01/01/1970, STEAM_A:X:XXXXXXX, 3.85
    01/01/1970, STEAM_B:X:XXXXXXX, 0 [maybe don't return ones with 0 or less hours (yes, "less than 0" sounds stupid, but is probably entirely possible, knowing all the systems we work with)]
    01/01/1970, STEAM_C:X:XXXXXXX, 0.75
Alternatively to reduce API calls, there could be a spreadsheet resource made available to departmental/regimental roster managers, in which the server regularly posts that info, so every few hours it would spit out date, jobgroup ID, SteamID and hours - Which could then be read from by departmental/regimental spreadsheets:

01/01/1970, E-11, STEAM_A:X:XXXXXXX, 3.85​
01/01/1970, Nu7, STEAM_Z:X:XXXXXXX, 11​
01/01/1970, DEA, STEAM_H:X:XXXXXXX, 6.7​
01/01/1970, E-11, STEAM_B:X:XXXXXXX, 2.6​
and so on.​
Departmental and regimental spreadsheets would then from that, just look at the ones relevant to their department/regiment. This method would mean not having to distribute the method for making API calls to the server and decrease the likelihood that it could be abused by a malicious actor.

Has something similar been suggested before? If so, why is your suggestion different?:

Closest previous suggestion I could find was this accepted suggestion from Kwan (presently in the Dev Tracker Backlog) about making /vtime display job-specific time - This suggestion is sort of querying and if possible, suggesting to create a way of externally retrieving a given SteamID's time spent on a job (likely via an API call). Additionally, their suggestion reasoning is more about presenting that information in applications for positions, whereas mine is about using that data in activity logging.

Possible Positives of the suggestion (At least 2):

The option of being able to automate activity logging in this manner would improve the following for departments that choose to implement it:
  • Increased appealability of being in a department/regiment & Convenience for the individual - Where some departments have to currently manually log hours with forms (or however other departments the track activity do it; I know (UK) CI right now uses the built-in regimental activity thing that shows how many days ago someone was online which really only works for them, as there are only CI jobs in the CI faction (assuming that only tracks when you were last in the faction, if it checks when you were last on the server, then... I mean it still works for them to see if that person is active, but it's still imprecise to the level where it's inappropriate for some use cases, such as in (UK) E-11 where we want to make sure you're active on the job)), this expectation placed on players from department leadership to regularly clock in hours typically discourages them from wanting to stay in that department/regiment, as the chore is too bothersome for them, which prevents that department from having as populous as it could be and is ultimately an impact on server health - Players may also have commitments to other roles and positions they have in the server, especially staff (Draw a Venn Diagram of staff members and MTF operatives and be surprised how populous the middle section is) who have to do a lot already without the added responsibilities of being in an MTF (an in UK E-11, logging your hours is one of those responsibilities). Implementing automation of activity logging overcomes this issue.

  • Improved means to track activity on a job - In addition to current departments that track activity, the possibility for automatic tracking enables potential solutions for other departments that would like to track activity, but are already doing too much and would find the prospect of having to manually log hours otherwise unwieldy or unreasonable to implement.

  • Harder to fake hours - Switching from manual hour logging to automatic hour logging means that someone can't forge the amount of hours they played for, the later point about abuse not withstanding.

  • Impossible to forget to log - Can't forget to log hours if they're done for you.

  • Decreased/complete elimination of roster griefing - Since it would be based on an in-game activity and you can't manually log hours after the switch, someone (especially any discharged person that still has the form link - or anyone that's like otherwise received the form from being given the link - ideally people shouldn't just be distributing activity form links like that for this reason but it's not like we can stop someone from just flagging d-class and throwing it out in chat for people to grief: i mean, if we (the CO team) find out that someone's doing that, that's 100% a blacklist, but again, we can't stop it from happening) can't then just fill out the activity forms with IDs of people currently on the roster and a bajillion hours. This has been an occurring issue with (UK) E-11 and (UK) Nu-7 in the past and so far our only solve is to delete the relevant logs; Recently we (E-11) ended up just making a new form altogether because it became an increasingly recurring issue. And of course, new official document, new ownership transfer request to Ventz. Which leads into my next point:

  • Less document transfer requests for Ventz - So ignoring the one spreadsheet for the alternative method of getting that data to the departmental spreadsheet as detailed above for now (which Ventz would also need to own), Ventz has to own every official form or GDrive resource, including things created for things like activity logging. Again, not sure how other departments do it, but it's likely that Ventz needs to own that material, too.

  • Less VTime check sits for staff - Frees up staff time to do other important things and might also make staff work less dull if they're getting a bunch of these.

Possible Negatives of the suggestion:

  • Dev time to implement - Might not even be possible, fully understand if so.

  • Ability of department to implement this into their roster if they want to - Ideally this shouldn't be the case with a well-written enough guide, but I get that not everyone can roster good.

  • API calls - Depending on how it's implemented on the roster side, might be too much traffic. Would have to be set up right and responsibly. Also depending on distribution, that API call could be used improperly and is an avenue for a DDoS attack.

  • In-game abuse - It would be easier to cheat the system by just sitting AFK/otherwise doing nothing on a job for the required amount of hours instead of doing what they're supposed to; But the onus for catching and dealing with this is on the individual departments - Same as when if someone tries to fake their logs. This is an IC issue and should be dealt with as such.

  • Underutilisation - It's possible that not enough departments would use this system to warrant its implementation.

Based on the Positives & Negatives, why should this suggestion be accepted:

It's time to discuss the elephant in the room.

At least in UK, the biggest thing holding a significant portion of people back from joining departments/regiments that have activity requirements, is after putting the hours in, having to log those hours with their department. We recently cut down our activity logging form in UK E-11 to just date, SteamID and hours a few months back and that has improved things, but the prospect still seems unsavoury to a lot of people. I have had recruits actually ask me if I was joking, when I told them that they have to log hours.

If this is at all possible, please pursue this with urgency. I get this sounds weird coming from the best performing department on the UK server right now and while I'm always looking for ways to improve, I'm also looking at things holding us back. This is one of them.
 
Last edited:

Billy Boy

Active member
Sep 22, 2023
41
4
21
+support
On top of making logging hours potentially easier it also makes it easier to check if someones logged the right hours or made a mistake etc
wouldnt be a need for checking if they logged incorrect hours, as it could be automated

i think an alternate to this would be investing a bit of developer time in creating a system either in-game or on a web page that replaced the need for spreadsheets, spreadsheets are ugly, and so is having documentation outside of the game, the more you can keep in-game the better.

a menu in-game that allowed for group management to view promotion requirements, activity, etc and any other analytics that are found on any of the divisional rosters

allowing for everything to be auto-updating with accurate data, rather than someone in every division learning to code to handle the API response for their roster
 
spreadsheets are ugly
excuse you, we put effort into making the E-11 roster look as good as it does. if someone's roster looks bad, that's a skill issue and you are to point and laugh
and so is having documentation outside of the game, the more you can keep in-game the better.
hard disagree, again, it would stifle RP and community growth if not implemented to the exact same flexibility and accessibility as the external resources we have
 
+support
View attachment 12696
chatGPT cooked hard with this suggestion ?
694380769615020132.gif

please
 
I'm going to bump this with a relevant finding that I've recently determined and I'm also going to mention @Gregory McCain and @ThatOneSaltyGerman here, for reasons that will become obvious as I go on (and also @Kayla in case you want to confirm this story and help prove my point here):

Recently in E-11, I had an issue with a recruit who, despite their attempts to log hours as mandated by the regiment, was not able to due to issues with Google Forms - after some troubleshooting with them, the conclusion was that Google Forms simply didn't like something about their specific internet connection, as it was giving incorrect formatting as well as just straight up not forwarding their submissions to Google Sheets, meaning that information was not able to be submitted, in a way that is not only out of control of both the end user and the regiment, but also not easily detectable by either. And I realised that the upshot of that is, how many other people has this applied to under what circumstances and what information that should have been sent, simply wasn't, as a result of Google... Just not behaving as expected for people selected seemingly at random? With zero indication that anything was wrong, unless if you specifically check the destination for your submission and see that your information has simply just not ended up there, despite the fact that you sent it.

TL;DR:
Google Forms is no longer a reliable method of collecting important data.

I would also as a result like to stress, the urgency of pursuance for what I've suggested here. I'd probably say it's a bit more urgent now because of this.
 
Last edited:
  • Like
Reactions: Skittles and Niox

Kayla

Administrator
Administrator
SCP-RP Staff
Resources Team
Oct 20, 2023
227
50
21
I'm going to bump this with a relevant finding that I've recently determined and I'm also going to mention @Gregory McCain and @ThatOneSaltyGerman here, for reasons that will become obvious as I go on (and also @Kayla in case you want to confirm this story and help prove my point here):

Recently in E-11, I had an issue with a recruit who, despite their attempts to log hours as mandated by the regiment, was not able to due to issues with Google Forms - after some troubleshooting with them, the conclusion was that Google Forms simply didn't like something about their specific internet connection, as it was giving incorrect formatting as well as just straight up not forwarding their submissions to Google Sheets, meaning that information was not able to be submitted, in a way that is not only out of control of both the end user and the regiment, but also not easily detectable by either. And I realised that the upshot of that is, how many other people has this applied to under what circumstances and what information that should have been sent, simply wasn't, as a result of Google... Just not behaving as expected for people selected seemingly at random? With zero indication that anything was wrong, unless if you specifically check the destination for your submission and see that your information has simply just not ended up there, despite the fact that you sent it.

TL;DR:
Google Forms is no longer a reliable method of collecting important data.

I would also as a result like to stress, the urgency of pursuance for what I've suggested here. I'd probably say it's a bit more urgent now because of this.
Can confirm this was the case for me. It took 5-6 of us more than a day to try and find out what the issue was. I physically cannot log my hours on my computer or even on my phone while connected to my WiFi. For 2 days I was having to ask CO's to log them for me. I have to disconnect my phone from the WiFi for it to work.
I don't use a VPN, and my settings are as they should be. It's frustrating.
 
  • Like
Reactions: Emilia Foddg
Dec 3, 2023
72
5
21
+support

Would be nice for rosters. Implementing this in a decent way would be challenging though (especially considering the timeframe thing & making it storage efficient).
With regards to storage, the rosters only log hours for 7 days for the playtime. So technically it could just delete the data after the 7 days, so it only has to hold 7 days worth of storage at a time. Not an expert but that could be a way around it ?‍♂️
 
With regards to storage, the rosters only log hours for 7 days for the playtime. So technically it could just delete the data after the 7 days, so it only has to hold 7 days worth of storage at a time. Not an expert but that could be a way around it ?‍♂️
this is not accurate and does not reflect how we use activity data, at least in UK E-11 - in E-11, activity data is stored indefinitely for potential historical review in the future, whether that be reviewing the data directly or via a lookup system to gauge an individual's historical activity. however, this does not mean the server would need to hold that data.

as i said before, the storage isn't a part of this - the suggestion is about the method of retrieval. the roster is where the data is ultimately intended to be stored. with regular requests to the server for this data, there isn't a need for the server to retain that data for longer than is necessary.

essentially, the data can be copied over from the server to the roster on request, which is where it will remain and be processed. the server can then do what it likes with it.
 
Last edited:

Yeke

Community Manager
Community Manager
Group Moderator
Mar 20, 2022
966
5
233
71
Suggestion Denied


Hi @Emilia Foddg

Thanks for taking the time to make a server suggestion.
We have chosen to deny your suggestion due to the following reasons.

After review, this would be a costly addition to the network financially due to the amount of API calls that would be occurring regularly, the benefit to this would not outweigh the cost in this scenario.

Your suggestion will now be locked and marked as denied.​
 
  • Sad
Reactions: Emilia Foddg
Status
Not open for further replies.