Actual Promotion System - Denied

[HuntR]

What are you suggesting?

The implementation of a proper "hard-coded" promotion system. The idea is simple: You have a menu, and a command member can access this menu. Upon issuing a promotion (whether it be through pasting a steam id or some other method), the person automatically gains access to the relevant jobs (I.E. a new Police SGT automatically unlocks Police NCO when promoted instead of having to be whitelisted).

This system would also automatically change their name while on specific jobs to a specific format (I.E. upon being promoted, their name automatically changes to "SGT John Doe" or "CERT SPC John Doe", etc). This name would change depending on what job they flagged onto and what rank they were in said job (I.E. "PD CPL John Doe" is also a CERT PFC, he flags up to the CERT job and it automatically changes his name to "CERT PFC John Doe".

This name and job would obviously be editable because everybody likes their name and stuff different. This would also ideally work for sub-branches as well (I.E. an State CPT flags up to SPMU and their name and rank automatically change)

How would this change better the server?

It makes promotions easier for all Branch CMD, instead of having to copy and paste a SteamID into a bunch of different jobs, they just promote them through the system and everything is automatic and smooth. Additionally, it is significantly more convenient for branch members, because instead of having to deal with the issue of forgetting to change your name, your name is automatically changed

Are there any disadvantages of making this change to the server? If so, explain. 

Would likely be coding intensive and might take extensive time for SMT to set up simply due to the number of jobs and ranks on the server. Additionally, implementing this alongside the HUD could also be a bit difficult. May also require coding from the ground-up.

Who would this change mostly benefit? 

All branch members (Command, NCO's, Enlisted, etc)

Please link any workshop content, screenshots, or anything that you think may be helpful to those who view this suggestion

Several example add-ons of things that this system could sort of look like are attached below (if I had to pick, the MRS advanced rank system is probably the best)

https://www.gmodstore.com/market/view/rankup-advanced-rank-system

https://www.gmodstore.com/market/view/v1-3-3-job-ranks-system-customizable

 

Credit to @Einfor this suggestion on SCPRP. Was going to write one of these for the MRS rank system, then realized it had already been suggested on SCPRP!

Link to original post: 

 

 

 

[Nicc]

-Support. Overall sounds like a waste of time for developers.

The GAS menu that we use for whitelist is already working great. SteamID's are easily accessible by doing rp_lookup (name) in console, and it doesn't take a lot of time to add people to jobs no matter which of the 3 methods we currently use.

For PD and FBI, there are certain whitelist for each rank. Combining these into Enlisted / NCO / Command categories would overall mess up those jobs, as the system would most likely not be able to differentiate these different ranks, unless there are sub categories which would require extra work to sort on dept commands side.

With most TAC / ATAC there would be an issue with the above statement aswell. Specifically when it comes to specialty whitelists.

When it comes to automatically naming the person when they hop over to the other job, they would almost always have to change their name anyways. The system you are suggesting most likely would not be able to set specific ranks correctly if they fall under generalized ranks and would not be able to set callsigns for most departments.

 

Overall, while this system might work for SCPRP, I do not see any way of it being able to function on PRP.

[Jack Simmons]

3 hours ago, Nicc said:

-Support. Overall sounds like a waste of time for developers.

The GAS menu that we use for whitelist is already working great. SteamID's are easily accessible by doing rp_lookup (name) in console, and it doesn't take a lot of time to add people to jobs no matter which of the 3 methods we currently use.

For PD and FBI, there are certain whitelist for each rank. Combining these into Enlisted / NCO / Command categories would overall mess up those jobs, as the system would most likely not be able to differentiate these different ranks, unless there are sub categories which would require extra work to sort on dept commands side.

With most TAC / ATAC there would be an issue with the above statement aswell. Specifically when it comes to specialty whitelists.

When it comes to automatically naming the person when they hop over to the other job, they would almost always have to change their name anyways. The system you are suggesting most likely would not be able to set specific ranks correctly if they fall under generalized ranks and would not be able to set callsigns for most departments.

 

Overall, while this system might work for SCPRP, I do not see any way of it being able to function on PRP.

 

[MJTHEOG]

4 hours ago, Nicc said:

-Support. Overall sounds like a waste of time for developers.

The GAS menu that we use for whitelist is already working great. SteamID's are easily accessible by doing rp_lookup (name) in console, and it doesn't take a lot of time to add people to jobs no matter which of the 3 methods we currently use.

For PD and FBI, there are certain whitelist for each rank. Combining these into Enlisted / NCO / Command categories would overall mess up those jobs, as the system would most likely not be able to differentiate these different ranks, unless there are sub categories which would require extra work to sort on dept commands side.

With most TAC / ATAC there would be an issue with the above statement aswell. Specifically when it comes to specialty whitelists.

When it comes to automatically naming the person when they hop over to the other job, they would almost always have to change their name anyways. The system you are suggesting most likely would not be able to set specific ranks correctly if they fall under generalized ranks and would not be able to set callsigns for most departments.

 

Overall, while this system might work for SCPRP, I do not see any way of it being able to function on PRP.

[Jay Chavez]

4 hours ago, Nicc said:

-Support. Overall sounds like a waste of time for developers.

The GAS menu that we use for whitelist is already working great. SteamID's are easily accessible by doing rp_lookup (name) in console, and it doesn't take a lot of time to add people to jobs no matter which of the 3 methods we currently use.

For PD and FBI, there are certain whitelist for each rank. Combining these into Enlisted / NCO / Command categories would overall mess up those jobs, as the system would most likely not be able to differentiate these different ranks, unless there are sub categories which would require extra work to sort on dept commands side.

With most TAC / ATAC there would be an issue with the above statement aswell. Specifically when it comes to specialty whitelists.

When it comes to automatically naming the person when they hop over to the other job, they would almost always have to change their name anyways. The system you are suggesting most likely would not be able to set specific ranks correctly if they fall under generalized ranks and would not be able to set callsigns for most departments.

 

Overall, while this system might work for SCPRP, I do not see any way of it being able to function on PRP.

 

 

[Scor]

4 hours ago, Nicc said:

-Support. Overall sounds like a waste of time for developers.

The GAS menu that we use for whitelist is already working great. SteamID's are easily accessible by doing rp_lookup (name) in console, and it doesn't take a lot of time to add people to jobs no matter which of the 3 methods we currently use.

For PD and FBI, there are certain whitelist for each rank. Combining these into Enlisted / NCO / Command categories would overall mess up those jobs, as the system would most likely not be able to differentiate these different ranks, unless there are sub categories which would require extra work to sort on dept commands side.

With most TAC / ATAC there would be an issue with the above statement aswell. Specifically when it comes to specialty whitelists.

When it comes to automatically naming the person when they hop over to the other job, they would almost always have to change their name anyways. The system you are suggesting most likely would not be able to set specific ranks correctly if they fall under generalized ranks and would not be able to set callsigns for most departments.

 

Overall, while this system might work for SCPRP, I do not see any way of it being able to function on PRP.

 

[MiniEpic]

4 hours ago, Nicc said:

-Support. Overall sounds like a waste of time for developers.

The GAS menu that we use for whitelist is already working great. SteamID's are easily accessible by doing rp_lookup (name) in console, and it doesn't take a lot of time to add people to jobs no matter which of the 3 methods we currently use.

For PD and FBI, there are certain whitelist for each rank. Combining these into Enlisted / NCO / Command categories would overall mess up those jobs, as the system would most likely not be able to differentiate these different ranks, unless there are sub categories which would require extra work to sort on dept commands side.

With most TAC / ATAC there would be an issue with the above statement aswell. Specifically when it comes to specialty whitelists.

When it comes to automatically naming the person when they hop over to the other job, they would almost always have to change their name anyways. The system you are suggesting most likely would not be able to set specific ranks correctly if they fall under generalized ranks and would not be able to set callsigns for most departments.

 

Overall, while this system might work for SCPRP, I do not see any way of it being able to function on PRP.

Agreed,

honestly everything is fine as is.

[David]

- Support

I like what we have already.

[Jimmy James]

Denied. The SMT team for this server has decided against adding this suggestion for performance reasons, the benefit to the server, or another unstated reason.