Playtime Tracking #5224
Playtime Tracking #5224
Conversation
|
A system that is based on the time people having playing the game, rather than just logging in and then not playing just to get full access is a smart move, especially in pushing towards a more reliable set of players for positions whom are expected to know the role, actually giving them time to learn how things on Paradise are done (like SOP, Space Law, and general demeanor) vs pulling their behavior from other servers and expecting nothing to come of it, for people to be the same way. We have a level of roleplay and competence, and knowing a role well, through playing the lesser roles first, definitely helps us make sure they have time to learn the role first through observation, rather than just doing. With a system like this, positions can also open up to players far sooner than before, if they show the aptitude to play the game, and the drive to do so, instead of waiting for the day counter to be up. This would actually prove beneficial to players of other servers who know how to do a role, and focus on a role to unlock it in a timely fashion, but theoretically initially focus in a department to do so, which can likely lead to players being better at something singular than just moderate at different roles. This would also, very likely, make it so someone who focuses RD or CMO doesn't suddenly get HoP or HoS, but has no actually knowledge of how to do the position, and if they only intend to focus one or two departments, don't get thrown into departments they've not yet played as an expected head role from the positions they normally get getting taken by due to RNG. And if they are in a department they've never played, it'd be in a lesser role than the big one, expected to know how to do everything when they know nothing. This means our players in general are better protected, and people looking to ask questions of their boss on how to do things have a much better chance of getting the pointers they actually need than a 'I don't know' response. |
|
Feels more of an administration thing here I feel like |
|
Fox-McCloud
added
the
Administration
|
I do not play too often which would lead to me not having unlocked security and forcing me to play something i do not want to so i can get something i want. Just for this aspect i am saying i do not like it. |
|
I really think this is completely unnecessary, and can be infinitely better enforced by administrators doing their job and monitoring for shitty heads/security. |
|
👍 This is a needed change- time since first join is a bad metric and there's been a general increasein bad command players recently. |
|
I'm not 100% sure how we'd implement the locking, or if we'd turn it on at all. The logging though, please yes so much. |
|
@Necaladun @TheBeoni I may be wrong, but I believe that Kyets plan is, if this gets merged, to just let it run in the background for about a month or so without locking anything, to give regulars/semi-regulars plenty of time to get enough time logged on to unlock stuff. |
|
@tigercat2000 No, not really. Our current job unlock system is ridiculously faulty. This at least offers a viable solution. |
|
Quite frankly, we don't need an additional system to track which jobs are the most popular; we already have a perfectly viable system that does that, as is..and we don't use it. Stats tracking is good, but there's no point in cluttering up the code with additional systems that we will likely never use (especially when an existing system is already in place for logging). This has come up before with PDAs and several other things. Invariably the data just sat there and was completely unused, whereupon we yanked said logging out at a later point. We already don't use the data available to us, this won't be any different. |
|
@TullyBurnalot The concept isn't about player experience. It's about preventing low-effort griefing. |
|
👍 I've been requesting this for a long, long time. |
| @@ -246,6 +246,7 @@ | |||
| if(!is_job_whitelisted(src, rank)) return 0 | |||
| if(!job.player_old_enough(src.client)) return 0 | |||
| if(job.admin_only && !(check_rights(R_EVENT, 0))) return 0 | |||
| if(!has_exp_for_job(src, rank)) return 0 | |||
There was a problem hiding this comment.
Do not put the statement on the same lien as the if statement.
|
@tigercat2000 So I can log in. Then either sit there doing nothing. And that would count. |
|
@TullyBurnalot Actually, this pr doesn't count time when you are inactive. |
|
@TullyBurnalot that still fucking prevents low-effort griefing |
|
In theory, I can understand the Captain requirement needing every Command job unlocked first. In practice, it's dumb too restrictive and sends the wrong the message to Captains on how they should manage the crisis. Captain job should be unlocked by x hours of play across command in total, a sum that can be reached by playing one job or all 5 (8 if you count karma jobs) Captain should never feel like the most skilled person on the station, but requiring Captain to have experience in all departments is going to reinforce that feeling. The Captain's job is to command. If there is a problem, direct the departments to fix it, and lacking a Head of Department, find someone capable to do the job. Engine not set up? Ride the CE's ass or have the HoP hire new engineers from other personnel, or maybe ask the RD if any Engi Cyborgs have been made that can wire the solars. The Captain should never feel "well I can do it myself faster than I can ask someone else to do it." It's bad play, power gaming, and leads to the Captain often nicking gear from various departments to make themselves Super Captains without any real cause or justification for any of it. tl;dr a good Captain doesn't need to know how to RnD, set up an engine, run cargo or how to do surgery or the various niche parts of Space Law and SoP for every department. A good Captain just needs to know these things exist and where to find people to do these jobs. I.E. COMMAND. |
@Davdichan
|
|
2h != 240 mins by the way. I like this, especially since it puts emphasis on actually, you know, playing the game. So if you want to actually be active and try to learn the game you can, and get to have a job with responsibility. |
|
If this is linked to an adminverb I see it as a very useful tool for just getting info on a player quickly. Whether to lock jobs behind it or not is an administrative thing to be discussed elsewhere, the code itself here seems good and useful. |
|
I'd much rather not have Job tracking, unless it's not horribly restrictive in time compared to some of our CURRENT ones (30 days for Antag, seriously?). But time based tracking entirely something we need. That will keep people from making multiple accounts and having a plethora of accounts open to them to grief with. My only problem are people who are coming back from breaks in the server and suddenly having jobs locked out. |
|
I am absolutely in love with the idea of all this being logged. Locking a lot of the jobs behind random timers is...questionable at best to me. Botany has arguably one of the highest potentials for mass-grief, for example. An officer might annoy a few people if they're especially terrible, botany could end a round. I like the concept of something like the Captain or specific Head roles needing a barrier of entry given they can massively influence a round by doing absolutely nothing. But randomly locking other jobs out just feels like it'll kill off potential interest in the server. Why would I want to play somewhere that has everything I consider interesting locked out to me for a long time? It keeps closing in the community to smaller and smaller sets of people. Not that I'm saying the current system is any better.
I think that's honestly the best use of it, at least at first. Any random schmuck can get a quick transfer or get the materials to grief or be terrible easily enough from pretty much any job but head roles have an extra layer of responsibility and requirement to them. A scientist going and shooting people up with syringes and throwing grenades is a nuisance in the round. Losing the RD is potentially crippling. |
|
@Earthdivine @IcyV @Necaladun @TullyBurnalot @Vivalas @Spacemanspark @Fox-McCloud @theColdflame @Twinmold93 @FreeStylaLT @monster860 @Davdichan Changes made today in Update 2:
Overall:
|
|
I did look at Yogs' system, but the ideas in Yogs' system were mostly the same ones we'd already discussed and rejected. |
TheDZD
added
the
SQL Change
|
By a few hours how many hours exactly |
|
@TheDZD Fixed merge conflict that arose recently from changes to admin_verbs.dm in another PR. goofball: The description was out of date. I have updated it. Non-head jobs like sec officer have no requirements defined in this PR. The only jobs that do are head-level jobs. Even those requirements are disabled by default and have to be specifically enabled. If enabled, 10 hours of playing any combination of crew jobs will unlock all head jobs. That's 5 shifts. Assuming a new player plays only three shifts per week, they'll still pass this 10 hour requirement in two weeks, an entire week faster than they'd pass the existing 21-day account-age requirement. |
|
What's the plan for this PR at this stage? |
|
My plan: wait for the maintainers to merge it. |
| @@ -250,6 +250,7 @@ CREATE TABLE `player` ( | |||
| `nanoui_fancy` smallint(4) DEFAULT '1', | |||
| `show_ghostitem_attack` smallint(4) DEFAULT '1', | |||
| `lastchangelog` varchar(32) NOT NULL DEFAULT '0', | |||
| `exp` mediumtext, | |||
There was a problem hiding this comment.
What will this be? What will be inserted into this row, and why is it ´mediumtext´
There was a problem hiding this comment.
"exp" is a comma-separated list of name/value pairs. It tracks the number of minutes that the player has spent in each stats category. Example value from my test database: "Living=610&Crew=610&Special=0&Ghost=30&Exempt=0". Translated, this means I've spent 10h10m as a living mob, 10h10m as a crew member, 30 minutes as a ghost, no time as a special role, and I'm not flagged exempt. Records like this will be set for each active player. The field type is 'mediumtext' because that's the type used for similar storage fields like 'be_role'.
TheDZD
added
the
Configuration Change
| for(var/text in jobs_locked) | ||
| return_text += "<LI>[text]</LI>" | ||
| return_text += "</UL>" | ||
| return return_text |
There was a problem hiding this comment.
If you're going to be making a large string using a bunch of +=, especially for a dynamic matter like this, I recommend you use the List.Join technique to make this work much faster.
| else if(href_list["getplaytimewindow"]) | ||
| if(!check_rights(R_ADMIN)) | ||
| return | ||
| var/mob/M = locate(href_list["getplaytimewindow"]) |
| if(mob.mind.assigned_role in exp_jobsmap[cat]["titles"]) | ||
| play_records[cat] += minutes | ||
| if(announce_changes) | ||
| to_chat(mob,"<span class='notice'>You got: [minutes] [cat] EXP!") |
There was a problem hiding this comment.
Cat XP, the most important experience
There was a problem hiding this comment.
oh no, I accidentally got cat xp removed
time to commit sudoku 😢
5 3 _ | _ 7 _ | _ _ _
6 _ _ | 1 9 5 | _ _ _
_ 9 8 | _ _ _ | _ 6 _
------+-------+------
8 _ _ | _ 6 _ | _ _ 3
4 _ _ | 8 _ 3 | _ _ 1
7 _ _ | _ 2 _ | _ _ 6
------+-------+------
_ 6 _ | _ _ _ | 2 8 _
_ _ _ | 4 1 9 | _ _ 5
_ _ _ | _ 8 _ | _ 7 9
|
Wow is this the US government or Paradise? Way to see a great idea be watered down to nothing because of useless bureaucracy. Don't have even the slightest of the idea why the staff are so vehemently against job tracking based on department and role. |
- Adds UID - Removes cats - Adds .Join
|
@Crazylemon64 All the changes you requested are done. |
Added 5h playtime requirement to play sec officer, warden, or borg. Discussed on staff chat, proposed as easy way to mitigate recent tide of bad security play.
|
Two small updates:
|
|
Clean by me - nothing looks like it's become obsolete, either, so I'll go ahead and get the database prepared for the change, then merge this |
| ##Unhash this to enable playtime requirements for jobs that have them defined. | ||
| #USE_EXP_RESTRICTIONS | ||
| ##Unhash this to allow admins to bypass job playtime requirements. | ||
| #USE_EXP_RESTRICTIONS_ADMIN_BYPASS |
There was a problem hiding this comment.
This should either be
A) Uncommented by default
B) Changed to be an option of "DISABLE_EXP_RESTRICTION_ADMIN_BYPASS", and make the bypass on by default in the configuration controller.
|
@tigercat2000 Changed |
Our current jobs unlock system isn't great, for several reasons:
This PR:
Please note:
The stats tracking added in this PR could be useful for things other than gating job access. They could also help detect people who cryo every round they don't get antag, for example. It could also be used to identify new players with old accounts.
The main benefit, though, is the new gating system - basing access to jobs on experience, rather than simply account age. This measures playtime far more accurately, and should dramatically reduce the number of cases of people playing Head roles without understanding the department they've signed up to manage.
POST-PATCH INSTALL INSTRUCTIONS
Add the col to the player table:
ALTER TABLE
playerADDexpmediumtext NOT NULL DEFAULT ''(Optional) Grandfather all active players, so they won't lose any jobs if the unlock system is enabled:
UPDATE player SET exp='Exempt=1' WHERE lastseen >= '2016-04-01'
Copy the USE_EXP_TRACKING section from config/example/config.txt to config/config.txt
Be sure to enable the USE_EXP_TRACKING directive.
🆑 Kyep
add: Added tracking for how much playtime each player has.
add: Added the ability to lock jobs based on playtime. E.g: must play for 10 hours to unlock HoS.
/:cl: