Tracking for per-department playtime

[Kyep]

Tracks how much time players play in each department.
E.g: someone might have 10 hours played as Engineering jobs, 15 hours as medical, 5 as Science, 7 as Security, etc.

This is helpful because:

1. It provides more detailed stats tracking for admins. We'll be able to tell if someone is new at a department, or experienced at it, simply by looking at their playtime report. We could query the DB and calculate who the most experienced players are for each department.
2. It provides a framework we (or downstream servers) could later use to have a department-based progression system. E.g: HoS requires 10 hours played as security (not just ten hours in general) to unlock, Captain requires 10 hours played in head jobs to unlock, etc. This PR doesn't implement any new requirements at all, but it does provide the tracking such a feature would need.

🆑 Kyep
rscadd: Makes playtime tracking more granular. Now, we can tell how much time players spend playing jobs in each department.
/🆑

This PR was created partly because we had two shifts in a row where the Captain had to be demoted for gross incompetence. I'm interested to know, for incompetent command staff, what jobs they play, prior to trying to play Captain/etc.
In the second of these shifts, the Captain immediately grabbed their space suit, a matter eater gene, and then proceeded to eat EVERYTHING (including both their IDs, their space suit, their SOP book, etc) before being demoted. After this, I PM'ed them, to ask them how much they'd played command jobs before they played Captain this time. Their answer was "none". IE: they went to play Captain without ever playing a head of staff role before.
This PR would give us the tracking to be able to identify cases like this. It would also enable us to, later on, if we decided we want to, require people to play other heads of staff at least a little before being able to play Captain.

[ghost]

Yes <3

[Aurorablade]

A part of me finds it unfair to make the gate so steep that you play lock one department behind another. A department should unlock regardless of time played in another department. This includes heads.

[Kyep]

This PR just does tracking.

There is no gating in this PR.

Back in the day, the idea of department-based playtime was that being the head of a department required you to spend some time in that department, and being Captain required some time spent as heads. That's quite reasonable. It would certainly go a long way towards preventing "I played Assistant for 20 hours, now I can play Captain, right guys?" syndrome. That's just one idea, though. And just speculation at this point. I am not proposing any gating in this PR. I am simply proposing we track what people play as. If it turns out that most of the bad heads are people who've never really played their department, then I'll consider proposing gating then, on the basis of that evidence. If on the other hand, the stats prove me wrong, then so be it. Either way, we'll know based on the data, based on the tracking that this PR gives us, whether it is a good idea or not.

[Krausus]

This was shot down in #5224, because it doesn't track anything you'd actually want it to. Here's a quick rundown of what it doesn't do:

• Does not track job changes (depends entirely on your round-join job).
• Does not track time spent actually doing a job.
• Does not track time spent interacting with a job's department(s).
• Does not track experience with the different facets of a department's jobs.
• Does not track knowledge accumulated in-game or out-of-game.

The best example of what's wrong with this is geneticists, who count as time for medical and science, yet perform functions completely unrelated to anything else those departments do. You can have someone with 100 hours of medical "experience" (as a geneticist) who's worse at surgery than someone with 0 hours and some wiki reading. They might not even be any good with genetics. Playtime doesn't guarantee anything.

We'll be able to tell if someone is new at a department, or experienced at it, simply by looking at their playtime report.

We'll be able to make rough assumptions about their experience based on their playtime... eventually, since we can't retroactively track it.

I'm interested to know, for incompetent command staff, what jobs they play, prior to trying to play Captain/etc.
I PM'ed them, to ask them how much they'd played command jobs before they played Captain this time. Their answer was "none".
This PR would give us the tracking to be able to identify cases like this.

If you want to know what experience someone has, you can (and, apparently, do!) ask them. If they play a job horribly wrong, you can dispense warnings and/or job bans. How would someone's playtime change this? Do you intend to use this impersonal data to profile and bwoink players before they commit crimes mess up their job? That's an excellent example of why tracking this stuff at all is a bad idea - it encourages admins to make completely wrong assumptions about a player based on their "playtime".

I am not proposing any gating in this PR.
It provides a framework we could later use to have a department-based progression system.
It would also enable us to, later on, if we decided we want to, require people to play other heads of staff at least a little before being able to play Captain.
If it turns out that most of the bad heads are people who've never really played their department, then I'll consider proposing gating then, on the basis of that evidence.
I am not proposing any gating in this PR.

... but you do still really want to add that gating, even though there's still too many problems with this system to make it practical. Getting a foot in the door with just the tracking won't fix those.

[Kyep]

@Krausus

• No system will ever be perfect. I still maintain that having the information available, should we want it, is better than not having it.
• When you have a theory, and you check it against the data, that's the opposite of making an assumption. And it certainly beats "make assumption, have no evidence in any direction, continue assuming" - which is where we are right now. Don't pretend that manually asking people is a substitute for having objective data. It isn't.
• I need to look at the data, and see what it says, before I decide what, if anything, to propose. I consider that sensible. Even if you oppose that gating, there's no reason not to have tracking.

[Krausus]

When you have a theory, and you check it against the data, that's the opposite of making an assumption.

Incorrect assumptions about data and what it means are why concepts like "correlation does not imply causation" exist. You can't even make proper correlations when your data only tells half the story, though; you can't objectively measure everyone's competence, so you have to pick out specific examples, and it's all too easy to focus on the ones that match your expectations and miss the ones that don't. On its own, the objective data doesn't actually tell us anything helpful.

Even if you oppose that gating, there's no reason not to have tracking.

I'd like to know what, aside from gating, this tracking would actually be useful for. Knowing what jobs a player picks would be neat, even if only to satisfy curiosity, but this isn't that granular. How will it be used?

[Kyep]

Five examples of how we could use this:

1. Use comparitive snapshots of the data to visualize how popular the different departments are.
2. Use a list of top players in each department as a starting point for picking people we might approach first for feedback when considering major changes to that department. Or as a starting point for picking people we might encourage to apply to be mentors.
3. Use the ability to pull up a person's playtime report, with detailed department playtime tracking, to inform how we should interact with someone administratively. E.g: if the HoS is a comdom, being able to tell the difference between a HoS that has never played sec before, and one who obviously knows better as they have a ton of sec playtime. Similarly, if someone is having an argument that the command staff are all comdoms, and we pull their report and notice they never play command, that's a prompt to challenge them to do better, and perhaps not to be so harsh with players trying to play a job that they themselves have never tried to do well.
4. Use the playtime report to double-check if someone knows as much about a department as they claim. E.g: if they are arguing that they know exactly what to do with department X, or some job in that department, yet a casual report check shows they've never played it, that's kinda relevant to how seriously we should take their opinion. Opinions are easy to write. Experience is harder to attain.
5. Pick a sample of people, and follow their department EXP progression. If we did this for a selection of new players, we could actually chart how a typical newbie progresses through jobs. E.g. noticing that they first start as civ, then go into medical, then eng, then sci, then sec. Knowing the general trends in how newbies move through the departments could be helpful in informing how we should design them. As could knowing how experienced the members of the different departments are, on average, versus each other. All of this is information we might want to be aware of when doing game design. A department played almost exclusively by new players should probably be designed differently from a department played almost exclusively by veterans.

These are just five from the top of my head.
The data has almost no cost to store. This PR doesn't even contain any new code beyond definitions. It re-uses the existing code. There's really no reason not to have this.

[SamHPurp]

The best example of what's wrong with this is geneticists, who count as time for medical and science, yet perform functions completely unrelated to anything else those departments do. You can have someone with 100 hours of medical "experience" (as a geneticist) who's worse at surgery than someone with 0 hours and some wiki reading. They might not even be any good with genetics. Playtime doesn't guarantee anything.

And with the current system those people would have those roles unlocked anyway. The proposed system is /better/, but largely because the current system is shite.

[Krausus]

Use comparitive snapshots of the data to visualize how popular the different departments are.

You'd end up visualizing which department has the most job slots. If you were to track civilian playtime, it would conveniently end up the most "popular" by a large margin.

Use a list of top players in each department as a starting point for picking people we might approach first for feedback when considering major changes to that department.

This could work... at least, until the data is old enough that finding an active player on the leaderboard is more trouble than just asking whoever seems to play in that department a lot. Since the data is lumped together per-player, and can't be filtered by time (last 30 days, etc.), its usefulness in aggregate drops the longer we're collecting it.

Or as a starting point for picking people we might encourage to apply to be mentors.

You'd be picking the people with the most single-department playtime. Or trying to pick people with a mixture of department playtimes that looks fairly well balanced. In either case, the data doesn't track whether people are willing and able to actually mentor, so would it really work better than just encouraging everyone to consider mentoring?

Use the ability to pull up a person's playtime report, with detailed department playtime tracking, to inform how we should interact with someone administratively

being able to tell the difference between a HoS that has never played sec before, and one who obviously knows better

if someone is having an argument that the command staff are all comdoms, and we pull their report and notice they never play command, that's a prompt to challenge them to do better

See, this is the sort of Big Brother stuff that exemplifies why we don't want this tracking. "Obviously knows better"? Making assumptions about what someone should or shouldn't know based on their playtime is one thing, but letting that taint administrative decisions is terrible. And... we'll have the data to silence complaints on the basis of "put up or shut up"? Geez.

Use the playtime report to double-check if someone knows as much about a department as they claim.
a casual report check shows they've never played it, that's kinda relevant to how seriously we should take their opinion.
Opinions are easy to write. Experience is harder to attain.

Opinions are easy to write, which is why all opinions must be taken with a grain of salt. But it's insane to even suggest throwing out some peoples' opinions because Big Brother says they don't have enough experience with the subject to know what they're talking about. The data won't even be retroactive, and certainly not representative of meaningful experience.

Pick a sample of people, and follow their department EXP progression. If we did this for a selection of new players, we could actually chart how a typical newbie progresses through jobs. E.g. noticing that they first start as civ, then go into medical, then eng, then sci, then sec. Knowing the general trends in how newbies move through the departments could be helpful in informing how we should design them.

A department played almost exclusively by new players should probably be designed differently from a department played almost exclusively by veterans.

If we could accurately track this, we'd probably just see a trend towards players trying jobs as they get access to them, since the way we gate access naturally funnels them like that. Regardless, it makes way more sense to adjust the flow of the gating based on which departments are more newbie-friendly (which I'm pretty sure we already do) than to try and redesign departments to match up with it.

Anyway, this level of tracking wouldn't be sufficient, since it doesn't leave behind the sort of historical data we'd need. You could manually track the progression of some number of new players, but it would be impractical to track a useful sample size.

There's really no reason not to have this.

Sure there is - the very existence of the data encourages its use, but just about anything you'd actually want to use it for would be a misuse of it. We could attempt to prevent misuse, but it's simply not possible to stop subconscious stuff like, "the data says this guy should know better, so I'll punish him for his mistake". It's more likely to do harm than good.

[Kyep]

The original playtime PR was controversial. It still passed, though, and its changes were helpful. Now, its recognized as a major improvement. But it took a lot of pushing to get there.

This one gives me deja vu. I hope it too, can pass, and it too, will be proven helpful when we look back on it. Its a few definitions, no substantial code additions, and it is even trivial to remove if it doesn't prove helpful. The risk of trying it is low. What are you so afraid of? If there's a gating PR later, you can have your day arguing about that, then. This PR is simply stats tracking.

Give it a chance. I realize you may be skeptical, but c'mon. It is stats tracking. Stats only admins can even see, anyway. You've spent many more lines arguing about it, than are being changed in the PR (18). There are other PRs which change vastly more stuff, and have a FAR higher chance of breaking things. This isn't worth worrying about. Its stats tracking, for stats only admins can see.

[Krausus]

The original playtime PR was controversial. It still passed, though, and its changes were helpful. Now, its recognized as a major improvement.

It was controversial because you were trying to use department playtime to measure experience. It passed because you removed that experience measurement. It is a major improvement over the "account age" gating it replaced, because it requires/allows players to actually play to unlock jobs.

This one gives me deja vu.

No kidding. You're trying to re-add the exact same per-department tracking that wasn't allowed last time, for the same basic reason (it measures "experience"), with the same flaws.

it is even trivial to remove if it doesn't prove helpful.

Give it a chance.

Reverting this would still leave the data in the database, and "we can just revert it" has never been a good excuse to merge something.

You've spent many more lines arguing about it, than are being changed in the PR

If you think that's bad, you should see some of the one-line balance change PRs...

[Kyep]

I still believe in this idea.
I'm not alone. 5 other people have supported it so far. I'm sure more of the community would support it if they knew it existed.
There are only two people who seem to oppose it, and you're one of them.
That's fine. Nobody expects ideas to get unanimous approval. Everyone has their own opinion, etc.
Just understand that, from my point of view, you don't represent the opinion of the majority. Not even the majority of the coder/maintainer team. You represent the opinion of one person. Two at most. That is not good enough grounds for me to abandon this idea. No amount of opposition from you is going to kill this.
It will survive for as long as I think the majority supports it.

With regards to trying it, any playtime type that isn't currently valid is pruned out of someone's record during updates. So, if we tried this, then decided to remove it, everyone with these playtime types would have them removed at next update. Also, database space is incredibly cheap. To worry about slightly more data being stored in the database for a short period of time is... a little silly.

[warior4356]

See all of the reasons you are against it are reasons I am for it krausus, I want there to be data for the admins to see if someone has been playing a lot. Your objection of tracking overall department time could be easily solved by Just having it record total hours played in department divided by staff in department. Other wise? Whats wrong with simple tracking?

[FlattestGuitar]

This will allow us to better see what preferences people have in terms of different jobs and (even though this PR doesn't add it) later on implement sensible experience gates for heads of staff.

The current system is way worse than this, and while there won't be a perfect solution, this sure as hell is closer to what we should have implemented a long time ago.

I don't see why this is a feature argued for and against by non-staff, as this, again, is a purely administrative feature.

💯 x 👍 from me. I've wanted to see this for a long time.

[Doukhan]

NSA/10.

[SamHPurp]

I am wholly for this, and a good amount of the detracting arguements are making points I'd make as positive statements for it.

[Fox-McCloud]

I still believe in this idea.
I'm not alone. 5 other people have supported it so far. I'm sure more of the community would support it if they knew it existed.
There are only two people who seem to oppose it, and you're one of them . . . No amount of opposition from you is going to kill this.

You're making a very very strong bandwagon appeal here. An idea is not going to be approved, necessarily, if it has more supporters than detractors, it doesn't mean it's automatically going to go into the codebase. Stated otherwise, and more directly, PR approval process is not democratic in nature.

If the designers and direction-determiners of Paradise feel that and idea is more harmful to Paradise than helpful, it's not going to get merged in. Likewise, if an argument is being leveled against an idea and it has more validity and soundness than other arguments, that's going to weigh in heavily on the decision making process, as well.

Such is the case with @Krausus argument here. He has put forth valid and sound criticisms of this PR and has even backed it up with a PR of this same exact type being rejected, before.

If you'd like to give more support and credence to your position, I'd suggest you argue against his points rather than appealing to popularity.

[Kyep]

I never said that the PR approval process is democratic in nature.
Nobody claims it is. Nobody even claims it should be.

PRs get merged, or not, based on the opinions of only four people: the maintainers, and the heads. Everyone knows this.

You two see this as a step towards gating jobs based on department experience, and you're against that, so you'll oppose this PR no matter what. The actual details here don't matter, because you're not judging it based on the details, you're judging it on the basis of "does this go in the direction I want things to go in", and you have decided it doesn't. Krausus has posted reasons, sure, but ultimately those aren't the reasons you take the positions you do. Those are simply justifications for the real position you both hold, which is "any step towards gating jobs based on experience in that department is a bad thing". As long as you hold that position, stated or not, I'm never going to be able to convince you by arguing about details, and I am well aware of this.
That's why I wanted to reframe the discussion. My hope was that popular support could make you two re-evaluate your core assumption that this PR goes in the wrong direction, by making you compare your opinion to others. If I can't make you re-evaluate that core belief, then arguing over the details doesn't matter, because nothing I say will ever convince you as long as you hold that core belief.

Using words like "validity" and "soundness" gives the appearance of being objective, but this isn't an objective discussion, and it shouldn't be presented as one. Your opposing this idea isn't based on objective facts, it is based on the subjective belief that gating jobs based on department playtime is a bad idea. Similarly, most of the people who support this idea support it in the hopes of one day getting that gating.

Saying that this PR was rejected before isn't accurate, either. Fox was against the department tracking before, in a previous PR, so in the interests of getting something merged, I dropped that part of the PR at the time. There is a difference between "rejected" and "previously removed from another PR in the interests of expediency". Fox saying it was rejected before, so this should count against it now, actually translates to "I opposed this before, therefore I oppose it now, on the grounds that I opposed it before". That isn't "valid" reasoning, either. Neither is Krausus doing the same thing. His "this was rejected before" actually translates to "it did not get merged before, thus it must be a bad idea now" which, too, is a fallacy for multiple reasons. It would be like saying "we never enacted this policy before when it was proposed, so it must be a bad idea to enact it now". The former does not imply the latter. The former doesn't even imply it was a bad idea at the time. It is simply a statement that it did not happen previously. That's all. Arguments of that nature aren't valid at all.

Although I don't intend to go through Krausus' points in detail (as I believe it is pointless), most of them have the same answers.
For example: anything like "this does not track job changes", "this does not track time spent actually doing a job", "this does not track time spent interacting with a job's department", "this does not track experience with the different facets of a department's jobs", "this does not track accumulated knowledge", etc are all irrelevant. All of these objections all have the same basic reply: "This proposal is better than what we have now. It is not perfect, but given the challenges (measuring things like player knowledge), nothing can be. An improvement is better than status quo, even if it doesn't get us to perfection."
I'm not claiming this system is perfect. All I am claiming is that it is better than the system we have now. It measures someone's experience in a more granular way, and ultimately enables us to make better decisions regarding when someone is capable of playing a certain job. For example, playing X hours as a head of staff is a far better indicator of your ability to play Captain, than is playing the same number of hours as civilian, or a non-head job. Playing X hours as a medical job, any medical job, including geneticist, is a better indicator of your ability to play CMO than is the same number of hours playing Civilian, or a random smattering of jobs in other departments. You can argue about the details, but the basic principle seems undeniable: more granular tracking does a better job of predicting when someone is ready to take higher-level jobs, because it can distinguish between someone who is progressing, and someone who is playing assistant every round. It is very hard to deny that.
If you can think of a better way to measure someone's experience in a certain department, please, go ahead and post it.

[Krausus]

You two see this as a step towards gating jobs based on department experience, and you're against that, so you'll oppose this PR no matter what.

Krausus has posted reasons, sure, but ultimately those aren't the reasons you take the positions you do. Those are simply justifications for the real position you both hold

So this is a conspiracy now, and none of the problems with trying to skew this tracking for some other purpose matter. Great.

Similarly, most of the people who support this idea support it in the hopes of one day getting that gating.

Alright then, let's focus on that...

This proposal is better than what we have now.

the basic principle seems undeniable: more granular tracking does a better job of predicting when someone is ready to take higher-level jobs

Neither the age-based gating we had before, nor the playtime-based gating we have now, are meant to try and predict when someone is truly ready for a job. You tried to predict that with department tracking before, and were told, in no uncertain terms, to remove it. So, what do those accomplish? They...

• Prevent literally-brand-new players from bumbling straight into a job they could not possibly be even slightly prepared for.
• Prevent malicious players from making a new account and jumping straight into an easily-abused role.

... which means, people who have played for a while can jump into jobs they aren't really ready for. And they do! Sometimes they do fine, or at least good enough, and nobody notices. Sometimes they bungle it, and get yelled at, or warned, or even job-banned. And that's okay, because even though they screwed up, they probably learned a thing or two, and probably didn't completely ruin the round.

But some people think that's not okay. When someone incompetent plays a job, something should have stopped them. There should have been more hurdles, higher requirements, more specific requirements. But people will still unlock that job, and they'll still suck at it, and something should have stopped them. Something that raises the bar for everyone, even the good ones, just so maybe some bad ones will give up before they become an inconvenience.

What it comes down to is, SS13 gives players a lot of freedom to screw up, and generally, we try to avoid attempting to code that freedom away. If something goes really wrong, that's why we have admins to step in.

If you can think of a better way to measure someone's experience in a certain department, please, go ahead and post it.

You know, if you really want to make sure people are experienced... we could whitelist head roles. You can handle interviewing the applicants, and make sure they know everything they'd need to.

[Aurorablade]

I have some of the concerns fox and krasus have so seeing krasus points addressed might put us all at ease if explained well.

[Kyep]

@Krausus If someone tries a job that's just a little beyond their abilities, that's OK. They'll learn. If someone tries a job that's completely beyond their abilities (like HoS, when they've never even played Security), then they will probably just mess things up for everyone. Department playtime tracking doesn't ensure that everyone is competent at their job. If used to gate head jobs, it simply ensures that they've had enough experience that they have some hope. The rest is up to them. The goal of that gating system isn't to ensure everyone is definitely qualified - its to prevent the worst cases of people playing 10 rounds of assistant and then trying HoS, despite having never played security before.

It isn't about ensuring competence, it is simply about ensuring there is some hope of competence. Someone who has never played security, ever, has pretty much no chance of being a successful HoS.

[Krausus]

If someone tries a job that's completely beyond their abilities (like HoS, when they've never even played Security), then they will probably just mess things up for everyone.

And we can make sure they meet a minimum level of competence by...

Department playtime tracking doesn't ensure that everyone is competent at their job.

... oh, right, this doesn't measure competence.

The goal of that gating system isn't to ensure everyone is definitely qualified - its to prevent the worst cases of people playing 10 rounds of assistant and then trying HoS, despite having never played security before.

So this is only even good for nabbing the really low-hanging fruit - the sort of people so hopelessly clueless that it should be immediately obvious that they need to be demoted and replaced... which is covered by SOP. And the server rules, which can be enforced through job bans. Is this really a common enough problem that it's even worth trying to code away? Or was this just a knee-jerk reaction to seeing two bad captains in a row? "captain comdom, pls nerf"?

I do like the example you've provided, though. 10 rounds as an assistant. Did this hypothetical player, who wants to try playing HoS, spend any of those rounds as a job-changed security officer? That's a trick question, of course; the answer is, "doesn't matter, the system doesn't track that". The best part is how completely unintuitive it is that you can be a security officer, yet get no credit for playing security. I'm sure we totally wouldn't see issue reports about that.

[Kyep]

For the Nth time: I don't claim the system is perfect, I am simply saying its better than what we have now. Its an improvement on the current system.

The assistant-to-sec transfer example is silly, for many reasons:

• Sec almost always has free slots, so anyone looking to latejoin as sec is more likely to just join directly as sec, rather than join as civ and try to transfer. Its one of the jobs most likely to have free slots.
• Civilians are generally not hired into Security. HoSes aren't willing to. Its one of the jobs least likely to get incoming transfers.
• Not crediting job transfers incentivizes people to sign up as the job they want to play as. Getting a transfer is in no way guaranteed, so signing up as A to transfer to B isn't a good idea - because you've got good odds of being stuck in job A.

We already get adminhelps about the fact playtime gating now doesn't count experience prior to Jan 1st of this year, when it was merged, because we chose not to enable the grandfathering option. That's many, many years of play experience not being counted. Right now. We even get adminhelps about it regularly. Yet, nobody cares. If we don't care about that, its ridiculous to care about job transfers, which are a tiny amount of hours by comparison, and, unlike discounting historical playtime, has a very easy workaround: just sign up as the job you want to play as. As everyone is already encouraged to do.

This proposal isn't based on two bad captains in a row. It is based on the countless times I've seen heads of staff who seem completely clueless about how their department works. I don't ask for perfection. I don't even ask for guaranteed competence. All I ask is that, prior to letting someone take a head job, we at least ensure they have a reasonable chance of knowing what they are doing. Which means some hours played in that department. Because that's the best indicator available as to whether they know enough to be competent at a head job.

[Krausus]

For the Nth time: I don't claim the system is perfect, I am simply saying its better than what we have now.

It doesn't need to be perfect, but inaccurately tracking vague playtime demographics with the intent of misusing them as meaningful data is a far cry from merely imperfect. It's only better if you consider proactively excluding a narrow band of undesirable players from head roles to be the only consequence that matters.

The assistant-to-sec transfer example is silly, for many reasons

It's not about a specific example. Job transfers happen. Finding excuses for why they shouldn't happen won't stop that, and won't solve the issue of not accounting for them.

[Kyep]

I could equally say that the current system is more inaccurate, and mistakenly treats all playtime as equally qualifying, when it blatently isn't. That what we have now is a far cry from merely imperfect, and allowing the status quo to continue is only better if you consider proactively excluding a narrow band of edge cases to be the only thing that matters.

See? Just because you can phrase something strongly, doesn't make it a good argument. It doesn't make it convincing, or true. Don't reduce this (or any other) feature to the one point you disagree with most.

I am not opposed to job transfers happening. Job transfers, while they're mostly a poor solution to the "we do not have enough job slots!" problem, there are cases where they are useful, and this PR isn't aimed at them. It might slightly discourage them, sure, but I don't think that is a bad thing, considering they're largely a band-aid fix in the first place, and if it mattered enough, the job transfer tracking thing is solvable anyway.

My point is: job transfers are an edge case. Only a minority of the crew members in any given round get a job transfer, and only a minority of those would fail to get department experience that might actually help them unlock things, under a possible future gating system. That's three levels of IFs. Even then, there's an argument that isn't a bad thing either, as the job playtime requirements would be set low, and we've ignored VASTLY more playtime prior to this (literally all of it before Jan 1st), so seems more than a little silly to make a big deal about department experience relative to job transfers.

If it really matters (hint: it doesn't), then there's an easy fix, and its unrelated to playtime tracking. Simply make it so that when your initial, roundstart ID card is changed (ie: you change job), the updates also apply to your mob and mind variables. Currently, they don't, which leads to a roundstart Virologist who becomes an Engineer, for example, showing up as Virologist forever in the Player Panels, and any other job listing based on mob/mind vars rather than ID card vars. The bug isn't really a bug with playtime tracking, its a bug with how ID consoles don't update ALL the variables that track someone's job/assignment. They only update the vars of the specific ID card you put into them.

[Krausus]

I could equally say that the current system is more inaccurate, and mistakenly treats all playtime as equally qualifying, when it blatently isn't.

On the contrary - it's perfectly accurate. All it tracks is generic play time, nothing more, nothing less. Play time doesn't inherently make you qualified for anything, and the system doesn't make any such assumptions. It doesn't try to track what department or job you're supposed to be playing. You simply play, and it counts.

Don't reduce this (or any other) feature to the one point you disagree with most.

I reduced it to the point I agree with the most. If it were somehow able to only prevent players from taking head roles they are completely unprepared for, with no other side effects, it would absolutely be better than what we have now. But it doesn't (and, realistically, can't) do that, so that benefit has to be weighed against the other consequences and flaws of extra tracking and gating.

My point is: job transfers are an edge case.

Disregarding edge cases is never a good idea, no matter how unlikely they seem. Missing out on the progress you were hoping to make from a 2-hour shift because you got your job the wrong way would suck, and "whoops, we were pretty sure that wouldn't happen" wouldn't be much consolation.

there's an easy fix, and its unrelated to playtime tracking. Simply make it so that when your initial, roundstart ID card is changed (ie: you change job), the updates also apply to your mob and mind variables.

It's not this simple, though you've heard why by now. You have another plan (basing it on ID, if possible) that would work well in most cases, but would misbehave if someone isn't wearing their own properly-titled ID. Still, that would probably be good enough... but job transfers aren't the only problem.

[marlyn-x86]

The Headmins and Maintainers are not very enthusiastic about a system that would merely track global departmental playtime, and potentially facilitate further gating and department-based playtime unlocks. As a result, this shall be closed.