Cobby wrote:Just as a FYI we had this same exact argument years ago that we needed to slow movement speed down for the same exact reason (which is how I know things get impacted by movement speed changes).
The game was even faster than it is now and it probably needed to go down for gameplay reasons anyways, but I don't think anyone EVER praised the slowdown for the RP gained aspect. In fact, the game continued to go into less and less RP even with the slowdown, so much that there was enough people in the community that we could make a server dedicated to returning to more medium RP standards and it stay populated.
I would be more for this idea if there was some quantifiable way that it did what it was meant to do like make it take X amount of time to get from arrivals shuttle to default escape shuttle on meta, but I don't know how to track "people RP more" and correlate that to a movement speed change in the same way that I can see medical changes and the length it takes for a patient to get out of medbay for instance.
Asking for a 25% or 50% slowdown is huge and I would highly recommend running those kinds of values over multiple rounds (and play in those rounds yourself) before you come to the conclusion that such a steep slowdown is necessary to facilitate more RP.
Secondary issue is on the code end which i mentioned before, do be warned there will probably be a cringe transition period where people will need to PR config-based scaling to previously set hardvalues.
Since the original post I've found that yeah 25% to 50% was likely too extreme and finer tweaking is necessary. I think that the information that MSO has provided here is sufficient to satisfy my interest at this time. The headmins have also indicated that they aren't interested in this on policy bus, so this definitely will not be realized any time soon and likely shouldn't in the way that the original post specified.
Having said all that, a lot of great discussion has been coming out of this and I'd prefer to see this thread lock out of eventual disuse as discourse fades rather than a decisive vote and lock from the headmins.
As for config-based scaling to previously set hardvalues, isn't that something that needs to be done if we are going to claim that we do support speed configs? I hope that we can address this oversight, and if anyone had examples of such hardvalues I'd be very interested in hearing about them.
Thanks for all the thinking and concern you've put towards this issue Cobby, I really appreciate it.