Skull132

AKA: Democracy. The Nuclear Option. AKA: Skull has 1 week break from school and pretty much all responsibilities and so he's decided to start coding again. Assorted PR: https://github.com/Aurorastation/Aurora.3/pull/11008 Okay so, let's take stock. Our current voting system is "Winner takes all", which means that there is very little point in voting anything other than extended and secret, unless you manage to get on a voting spree. This is not great, and many, many suggestion threads have been made, attempting to propose a fix. Though staff have resolutely not touched any of these, as trying to over complicate game mode selection is a bad idea and we'd just have a thread asking for another voting implementation next time around (see: how the transfer vote limit got jerked around a lot). Instead, let's remove game modes. Aurora's backend allows us to compose game modes on the fly. So let's do that instead. Thus, the players will now vote for 2 things, back to back. Intensity. This will determine just how "Intense" of a round the players want. Do they want a lot of action, or a lot of action. The scale is from 0 to 3, with the lowest being "Extended" -- guaranteed no antagonists. We did originally discuss how to get by without this, but figured that the playerbase would be in quite the uproar if we didn't include a clear cut option. I also couldn't figure out a good way to make the antagonist selection not maximize the intensity output, so it works out. The other options, 1 - 3, dictate what antagonist types (not game modes) are up for grabs. Each antagonist type also has their own intensity level: 1 - 3, and so for every round, the antagonist types selected will have a summary intensity equal to or less than (in case of no other choices) to the round's intensity. For example, a round with intensity 2 can have: 2x antag types with 1 intensity, or 1x antag type with 2 intensity. This system is a bit simple for now, and I'm not fully happy with it, but it works. Antag voting. Once intensity has been decided, players will be allowed to vote for an antag. This is not winner takes all. Instead, the antags that get selected will be randomized. The list is weighted, so that the antag that was voted for more will have a higher chance of being used, but that antag's presence is not guaranteed. Though, I think how the function will play out numerics wise, there will be some relative threshold past which it's impossible to not get picked? We'll see. This should demolish most "voting strategies", while also making your vote more useful. Every vote given to your favourite antag will increase the likelihood of their presence in the round: you no longer have to pick between two evils. Did I say that the "game mode" will be dynamically composed? You could in theory have shit like ninjas and traitors and wizards. And it'll be very interesting. If not horribly broken. We'll see!

The PR will be modified to only affect the round winners. While my qualms about this approach remain, I suppose it's better than nothing.

Mmmmooossstly so we could test it. I also kind of want to see what kind of reaction such modes would gather from the general audience. Whether it stays in secret or not, or if it'll even be votable, will be discussed Soon:tm:.

But the thing is, you do have a third option here. Don't vote. Again, let those who are willing to play a round regardless of voting outcome to vote. And then determine whether you want to play after that. There are people whose prime time SS13 is what you consider late in the evening. And if they get swamped with passing out people from your timezone voting for extended, then they might be very miffed.

That's just the thing. There are two ways to present this change: As punishment. As attempting to create a more sportsmanship environment in general. If I vote for the winning round, without any malicious intent, why do I specifically deserve to have my freedom of choice limited, while everyone else gets a free pass? If I see 10 players hobble a gamemode I know I won't like, and I join in on voting for the second largest gamemode as a counter vote, why does one of those sides deserve to have their choices limited, while the other does not? Surely they both influenced one another. So again. The idea is not to punish anyone. But instead, to see if it is possible to foster an environment where only those who are willing to commit to the opening of a round vote.

I was more trying to illustrate that your example of malicious vote bombing isn't the only case: ergo, the act of vote locking shouldn't be viewed as punishment/karmic justice. Upon further consideration, the idea that a vote for a round that didn't win is not necessarily true. Often enough you see people voting in reaction to one mode getting initially dog piled. We're running "Winner takes all", a voting system known for creating 2 majority outcomes: the winner, and the runner up. With proponents of less popular choices hopping onto the "Least bad" option. This means that the system is also subject to reaction voting: "I would rather let this win than let that group get merc." Are the people who initially voted for a mode, even if it was the runner up, not responsible for causing the reactionary votes? Another way to look at it is, if you're not 100% sure whether you can sink 30 - 60 minutes into the round, perhaps don't vote? Let those who are certain they want to stick around for that time place their bets and determine what they want to do.

That is unfortunately not the only problem we are dealing with. The staff have observed, over a long period of time, that people also tend to silently vote for things like extended, and then observe for the remainder of the round. This is very typical in deadhour. There is no OOC drive attached to those either. The outright malicious mode of conduct you present is not the only thing I am attempting to get at, and is actually pointing out something that I wanted to avoid by making it apply to every voter: finger pointing and general "othering".

If this wasn't done the way it is, then your classification of vote memer would be anyone who votes for the winning mode. Which sounds sort of off: again, no singular person has control over what ends up winning, so why should only those whose choice won be required to participate, if everyone else who voted had just as much effect on the outcome?

https://github.com/Aurorastation/Aurora.3/pull/11005 PR is up, with some alternations to the original idea. Everyone who voted is going to be locked. Why? Because the ultimate goal here is to develop good sportsmanship in the player base, everyone who tries to alter which game mode gets played (by voting), should be willing to participate in the round. Limiting this only to winners could be seen as punishment for something that's not directly within their control -- which game mode ultimately wins. Those who disconnect after the fact and remain DC-d until the round begins, effectively dodging this mechanic, get logged for admins to deal with as they spot a pattern. Even if this is "easy" to do, a regular pattern is easy to spot and can be culled by staff.

test

Can someone explain something for me, real quick. When reading feedback, I see that some of it is positive and falls straight into the spot we want to hit: I can summarize this as follows: Security now has to pay more attention to even unarmored combatants (provided that security themselves aren't armed with high alert level gear). This is arguably a positive change, as a good deal of antagonists, specially in the beginning of a round, are themselves unarmored. Also, making way for lesser crimes to be viable again without a 100% "You're fucked" rate upon being sighted by security might actually encourage antagonists to not arm up immediately. Security is now, in general, more considerate towards combat. Which should make engagements with antagonists in general be more interesting, as security should be looking out for their own lives as well. Both of these sound like great, positive points from an overall gameplay perspective. But them we follow it up with this: So we can agree that the nerfs are pointing us in the right direction (sans tackle-hugging*). But then we swing to either an extreme of "Bring back the .45s" or "Just remove everything"? Why exactly is this? Generally speaking, considering the overall protection security has on the station, them not being able to solo actively resistant people without being careful might be a good thing? You typically have one of the better staffed departments, along with the AI and the rest of the crew to help you locate and snoop out the guy who's causing trouble. Making intended confrontations more tactically interesting seems like an overall plus. * If one balance change reveals another mechanic in need of balancing, then such is life. It ain't always a valid argument against the original change.

I don't really see this as an obvious downside. Having antag gamemodes be more complex than "Antag vs station" is a good thing.

Mazda.

I mean. Removal was a legitimate option that was discussed for a few solid months. I am not sure what about being open about such discussions counts as "Fearmongering".

I probably should have made this post whenever we originally did those changes, but I was having a bit of trouble IRL and couldn't really focus. But here goes. SKULL! WHY DOES MY GOONCHAT TAKE FOREVER TO LOAD?! Short answer: You're A*stralian. I'm sorry, it's a terminal issue. There's nothing we can do about it. Long answer: Okay, so first, let's take stock as to how resource management worked before our changes. In ye olden days, if you remember, you would regularly encounter the long black loading screen when loading onto the server. The one that would be anywhere from 50 MB to 120 MB. This is BYOND preloading resources to your machine from our server. There was one major issue with this system: It was horribly slow. The issue is that it used the BYOND server process, which alongside sending you your 100 megabytes of resources, still had to deal with actually running the server. Because BYOND is coded in a really old fashion, this did not scale. The resource download times would be unreasonable slow -- trust me, our server(s) are capable of way more throughput, the bottle neck in the download speeds was BYOND itself. This started perking up on our radar as our resource size kept rising and rising due to new sprites, sound effects, etcetera being implemented. It was simply not reasonable to continue with this process, as it would result in longer and longer download times for everyone. So what did we do? We did two things. First, we moved the resource downloading over to another process. We basically set up a small webserver on our main box (I thiiink?) which would now hold the newest resources. This meant that the download speed was no longer capped by the horribly ancient BYOND limitations, but instead, by how fast our webserver can distribute shit. And that is way faster than BYOND ever could. And this includes in parallel download scenario also. So this is a clear download speed gain for most people. The aforementioned A*stralians likely won't see that much of a performance boost, but it should be there. But there's another thing we did. And this is the likely thing that was causing a whole bunch of "issues" for people. We removed the preloading of resources. I forget but I think this is necessary for the other resource distribution method to actually work. So what happens now is, even if you don't have all of the resources downloaded, you can join the server and the server will let you join. So you get the impression that you're all good to go. But this is not the case: in the background, your game is still frantically trying to download everything. Depending on how fast it manages, and in what order, certain things (like goonchat and UIs) may "not work", as their files still haven't arrived yet. Unfortunately, there is not much we can do about it. You'll just have to sit it out and "hope" that the resources get finished. In the worst case, it should only take as long as it would have taken you to sit behind the 120 megabyte black screen. Though in the average case, it'll definitely be faster. As time goes on and we remove NanoUI, we should be able to remove some stuff from being downloaded. Which will make life a bit easier. There's an improvement in BYOND 514 planned which should also make certain things download faster. This specifically ties to how the UIs are delivered. So hopefully that'll bring a performance boost int he future as well. But ye. That's it. So basically: goonchat isn't any slower than life would be using the old download system. And in the average case, it's likely way faster to download everything. Questions welcome.

Appeal accepted and ban lifted. If you have trouble joining the server, PM me on the forums.

This might happen sooner. ?

If my memory serves, this might have been due to you and your comrades from old Apollo doing some grifforing back in ye day, under an alt key?

Someone has to post "Shrek" first, tho.

poll machine broke in the mean time, apparently. So, ye we're working on fixing that first.

Passing comment, the on-wrist sprites look exceedingly bulky and weird. The only really acceptable way to sprite them, IMO, would be to just have them overlay the sleeve area. Maybe extend it a bit but not as much as they are now. Also I would be up for some holographic-display like sprites for these. ? at Kyres and Wezzy.

Yes but no. They're had a long test merging period and vairous fixes/adjustments over the course of that time.

A topic of great debate. Of great achievement by Myazaki. Of great strife within the community. Of great disappointment by the elitist old. Of ultimately inconsequential significance. We have decided to give vision cones a fair shake. They will be merged for a period of 1 month. After which we'll hold a voterino to see whether we should keep them or not. The 1 month playtime is to let everyone get used to the fee-fee's of the new game. Enjoy! And do report bugs on Github!

This. Events is one of those systems that I would not remove without a better option being PR-d, due to the effect they have on gameplay.

lmao. Their huge-ass weakness to lasers is another symptom of them not having any pain/stamina/paralysis mechanics. The reason why IPCs are so horribly fragile is that they exist outside of the normal combat tools, ergo, to not make them into huge ass powering trains, we've made them horribly fragile when confronted with the right tools. If and when we can add some analogy to pain to the IPCs, only then can we consider making them less horribly fragile. Otherwise they just end up being super fucking strong.