Allfd

What I like about Vampires is that they have a lot of room to RP by the lore. I don't necessarily mean nice, but conflicted about what they are doing. Lings have no such moral quandaries.

So if any of my characters are not in command or security, there is a 100% chance they are an antag. It works both ways.

Not all players are as interested in creating a character or social interactions.

I would like to add a significant number players are already always random

They have cortical stacks which houses "them". Perhaps it has a radio?

I agree it is a meta concern, in so much that I also have a character who if not in command or security is certainly a traitor. I like this system as it can help people to build defined charachters but still get antagonist. Which I view as a positive for RP.

Everyone complains about races not being unique, then everyone complains that any attempt to make them not unique is a buff and we need a non buffing way to make them unique that is not purely cosmetic. Nobody is able to offer such a way.

This is something I can look into after I fix up some of my existing PRs

If you ahelp it, it could be your job.

AHelp, The behavior described is against the rules. Being a clown is not an excuse to self-antag. The sooner it is ahelped the better. Its hard to do anything after the fact as much of what clowns do don't show up in logs as attacks and the admins have to actually witness it occur or its hard to prove later.

Agree with Xantholne, Great if we could somehow link it to RP, but absent that it introduces uncertainty.

I am looking into cortical stack changes, but it would probably be a good idea to figure out what is on peoples minds. In the mean time, I put up a not at all serious PR. https://github.com/ParadiseSS13/Paradise/pull/7202

A lore discrepancy was raised regarding the cortical stack. I will be working on a PR to address.

Nothing is stopping you from building a Rage Cage, Other then perhaps the department heads/captain/security/CentralCommand.

So the fat thing is difficult as there have been some who have wanted to increase the metabolism of Vulp which would come with some downsides of getting hungry faster/ect. The problem is its basically impossible to move things in one direction or the other on some of these PRs, we have an extremely democratic process for merging any given PR which creates a significant amount of friction. Essentially if something is going to have detractors it is super, super hard to get merged.

I would absolutely love to see TGs new engine ported, I think it would be a great shared project for both engineering and atmos. As for the changes, I put up the PR for phase 1 of atmospheric changes today by refactoring the air controller.

I really feel gas masks should protect you from breathing gas.

PMs are often sent in that players direction when this happens.

Getting it should turn you into a Vulpkanin,

If changes are made to LINDA in the code base, plasma fires will be adjusted to ensure a nice slow burn so that fires don't just flare out.

I think Shadykins is talking about occasional tests of the former. What happens is that everything is sped up, including the rate of combustion, the heat generation, and its diffusion. Things being lit on fire are handled with a different process. We don't have an easy way to decouple LINDA speed from the rate at which combustion occurs as far as I can tell, however I will look into the not easy ways.

I need to defer the optimization question to the maintainers, Fox was working on some optimizations involving reusing objects instead of deleting, but those did not pan out performance wise. I bring this up as its not as simple as fixing bad algorithms or bugs that just need to be worked out, instead new approach to existing functions and code may be required and that will require experimentation. The way I view these trade offs is that on the most basic level, certain features come with certain costs. This is an over simplification but essentially CPU heavy features can be measured against specific player counts in a sense. This was the purpose behind a couple of rounds where backend functions were tweaked to measure the corresponding impact over the course of the round. Right now we are fairly stable at 120 players, if we reverted goon lights we could take that up to 160. 4x'ing LINDA would take us down to 90, however reverting goon lights and 4x'ing Linda would take us up to 130. The LINDA numbers come from a meteor round, and all this is of course subject to very different pressures as to what drives the exact cost, but back of the napkin numbers put the cost of Goonlights = 40 Players 4x LINDA = 30 Players I am not advocating changes to lighting or atmospherics, this is to illustrate the problem paradise faces when looking at any PRs that significantly alter how CPU is used, we are operating in an environment which is far more constrained performance wise due to our popularity. What I hope to instill however, is that we are at the point where, Neat new feature = ## Players. There is some hope, for instance I think that some of the strange behavior within each round CPU wise may be fixed in an upcoming Byond patch. However we lack detailed metrics from before the issue was introduced, so we don't have a great understanding of what that may mean for us. I have not addressed the issues of the how many job slots are available or any of the other factors player count brings, maps/ect. Those are best left to the maintainers and admin staff to address.

A number of potential solutions have been brought up, but I want to address the delister itself as I am its designer. Currently three things are evaluated by the listing system, Total player count Players to Admins as a ratio CPU The elephant in the room is that the hardware the server runs on cannot sustain more then around 120 players before things start to noticeably degrade. This graph is the last 48 hours The blue shaded area is the server playercount, the redline is the moving average the system uses to determine if it should take action based on CPU, the brown line is the CPU for that minute (the sample rate of this data) The blue line that bounces from bottom to top is our listed status, if its on the top, we are listed, at the bottom, delisted. CPU budget is one of the many things that needs to be taken into account when we talk about the servers listed status at any given time. Our player count is the key factor limiting certain CPU intensive game changes everyone would like to see. In the next few days we will be upgrading from an i7-6700k to a i7-7700k. This will get us about 5% more single threaded performance. We will continue to upgrade processors when faster ones come on market, but at the moment short of moving from 14 nano-meters down to 7, things are not looking promising. With all the problems of making a larger map, that is easy compared to rewriting byond to take advantage of more then one CPU core.

It could be simple mob, that is sort of the best that could be easily done.

If the goal is to alter the race so that the players feel like they are playing a different race and behave in a different manner because of it then that is a non-trivial change. Not everything is mechanical, nobody decided mechanically that Vox would be crazy space bird greytide. That just kind of happened naturally in part because they were added and all the early players really only had to go on a few lines from the wiki as far as lore. This little bit of guidance and the annoyances of not being able to use regular clothing or magboots have created the thriving Vox culture we have today. A problem that seems to occur whenever this issue is raised is one of intent. Species diversity means many things to many people entirely separated from then the discussion as to if species differentiation is a goal.