Jump to content

Bmon

Mentors
  • Posts

    75
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by Bmon

  1. *TOOLBOX TEAM NAME PENDING EDITION* Once a year TG Station hosts a charity tournament where different servers come together to bash each other skulls in with toolboxes for a good cause. This year's charity of choice is Doctors Without Borders. I am currently looking for two other players from Paradise to join me in kicking some ass and putting on the best show we can in the name of charity. Last year we managed third place out of thirty-plus other teams! The tournament is currently scheduled for Dec 16th from 3:00 PM to 7:00 PM EST. Also, I haven't settled on a name for the team yet since I was bullied by both Paradise and TG last time for picking a boring name :( . I'll probably pick something suggested from this thread so brainstorm away below! More details about the tournament and charity can be found on the TG Station Discord. SIGN UP NOW!
  2. I don't think many people aim this way? Personally, I hole my cursor somewhere in the middle of my viewport and lead my shots. This wouldn't do much because you're not clicking the other person's sprite so no way to block the shot. Take a look at the Steam hardware survey if you want a general idea of what monitors most people are using. Keep in mind account for aspect ratio not resolution. Resolution is just pixel density which means nothing to SS13(pixel game lul). A quick google search will tell you what aspect ratio a certain resolution is.
  3. This is a fantastic feature that I've seen successfully implemented on two great servers (Goon, TG) and has been implemented on countless others. The only reason SS13 and most older byond games are 15x15 is because monitors 20+ years ago most monitors were big blocky 4:3 CRTs. In that context 15x15 makes perfect sense, but in today's world where I can almost guarantee you no one here is using a 4:3 monitor, a 19x15 viewport is the way to go. Some servers even use a 21x15 viewport like goon, cit and skyrat which is roughly what 19x15 viewport looks like on a 16:10 aspect screen. Also, briefly touching combat advantages. Two extra tiles on the side of the screen in the grand scheme of things isn't that big of a concern. You can compare SS13 with any topdown game released in the past decade to see that they all give an advantage to the sides of the screen far greater than two tiles in most cases. Regardless, we should not be so strung up on the combat advantage of two tiles, our focus should be on the overall gameplay and feel and this does wonders in improving it.
  4. Woah there, I don't think anyone is out to get me nor do I think there is a conspiracy against me, that would be silly. I am usually upfront and blunt with people so I am sorry if you feel as if I was being argumentive, it was not my intentions edit: Probably best to leave it here. I am going to shut up now.
  5. Saying they prefer another PR but not stating why is not an explanation. I don't think a single day really changes my point much. I picked those examples based on the day they got judged by the design teams. Also, why are we trying to fit these into an arbitrary timeframe?
  6. I can only speak from my own experience so these are my PRs. https://github.com/ParadiseSS13/Paradise/pull/19836 https://github.com/ParadiseSS13/Paradise/pull/20096 https://github.com/ParadiseSS13/Paradise/pull/20115 All these never got a why. PRs being closed by the author are irrelevant. Don't know why Miraviel decided to list them.
  7. It's a perspective thing. If you compared the development cycle from uhh idk around 2017 when I first started playing, of course, things are better now. I am just noticing things slipping back, it's hard to see that happen considering the strides in progress that have been made lately on the development side of things. I am always going to be a pro-transparency purest, that's just who I am and what I believe in. Some wise old man would probably tell you and me that the solution lies somewhere in the middle.
  8. I am sure it has happened, I am not at all dismissing that. I just believe that it is more detrimental for us to be closed off than it is to be open with our development decisions.
  9. I understand how the Paradise development team works so I am just going to skip over that part. I don't know why you're cherry-picking examples, I could do the same with more recent PRs to try to prove a point, there will always be outliers. I made this thread because I noticed it was happening more now than it was before. And I am not even touching on the fact that a lot of the times there are only one or two people are voting. In your own example, only one person voted on that PR out of a team of five. The least the design teams could do is to take five or ten minutes to look at a PR and say yes, no or abstain. Before at least the whole team was getting together to vote on PRs which lead to discussion, this has all but stopped in recent times and has led to an overall decline in communication. Moving on I really do hope whoever is making death threats over 2d spaceman game gets swiftly banned. I do understand where you're coming from though, especially with that example, I think special circumstances could lead to a PR being voted on privately but I do not believe it should be the norm. Regardless it is not good practice to be closing PRs with no explanation, it pushes contributors away from wanting to contribute to this codebase. And yeah, sometimes we do get explanations but again it is my own opinion that this has been in decline. Your bullet points do prove that some things should stay private but I am still of the opinion that the greater development channel should be visible. Most of these things could be moved into separate private channels. I don't think many people will be down your neck for merging X PR. Again, it is my experience that the contributor usually gets most of the flak for an unpopular PR being merged.
  10. I agree that something like that constantly happening could lead to burnout but I just don't think many people would go out of their way to harass the maintainer team for voting on PRs. In my own personal experience, it's the PR creator who gets most of the heat for an unpopular PR that gets merged. I guess what I am getting at here is wanting to understand why maintainers voted the way they did and how that could be useful for understanding what should be changed in the future. An explanation could do this but most of them are rather brief and usually don't give the full picture
  11. If someone is going out of their way to harass a maintainer for voting a certain way then they should be banned, simple as that. Being able to see why the X design team voted the way they did and their thought process behind that would lead to a greater understanding of what went wrong. Right now we get nothing but a blank yes or no which in the case of the latter is nothing more than an absolute insult to said contributor as you are talking about potentially hours of someone's free time being flushed down the drain with no explanation. I don't see any downsides to making the channels visible, most counterarguments honestly feel like a strawman of 'somebody' 'potentially' harassing the maintainers when the obvious answer to that is to just ban people who do that. Also, this adds zero extra strain on the development team, they don't need to come out with a statement every time a PR is closed or merged, you could just look at the respective design channel and figure it out yourself. Many other servers already have their development channels visible and I think we would clear up a lot of frustrations by following in their footsteps.
  12. I have noticed a massive decrease in communication and transparency on the github ever since PR voting has been split into different design teams. It's to a point where I myself no longer want to contribute to this server as it is a massive morale zap to see your PR closed with little to no communication from the different teams. I think it'd be productive to see exactly why and how the different teams are voting on PRs the way they are. There's no reason for our PR review process to be private, we are an open-source codebase. Do note the differences between visible and public. I am calling for all development channels to be made visible meaning that anyone can read them but not talk in them.
  13. We got third! I want to thank everyone who watched and our team memebers@Eric6426and @ItsMarmitewho had to fill in for Corn and Hal. We did amazing considering all odds were stacked agaisnt us, couldn't have made me any more proud. Thank you! p.s. fuck cancer. parasweep 2023
  14. For those of you that aren't on TGs discord Date and time has been announced along with sign ups being opened. @CornMyCob& @CharliminatorAre you both free at this time?
  15. On TG a 357. round will deal 60 DMG no matter where you hit them, it's just that if you shoot someone in their leg it caps out and disables it or decapitates that limb(if the weapon is sharp). You're not able to kill someone by shooting their leg unless you inflict a wound and cause them to bleed out. Aiming for the head or chest on TG allows you to stack someone with enough damage to kill them, the downside being that's where you're most likely to be wearing armour. None of this matters on Paradise because our limbs have no damage cap so you're free to shoot someone in their pinky toe 100 times to kill them.
  16. Then just target the chest/head and don't go for the limbs. That's exactly it works on TG.
  17. There are obvious counters to each type of armour, a slow down or any other type of drawback would be unnecessary. Honestly, normal armour is pretty useless right now since you can target any limb to negate almost all of it. What we should do is a damage cap on each limb to force people to actually aim for the head/chest.
  18. Sounds like you're describing urn voting which was voted against by our design team in this PR https://github.com/ParadiseSS13/Paradise/pull/18489 Two Headmins saying no to this happening means it just won't happen, ever. I would have loved to have a vote to decide on what to do with the current map rotation system, unrealistic as it is for me to want that on Para.
  19. But then you have to account for special round ending conditions like a wizard dying or a blob taking over the station. I think it would be best to extend the round end duration from one minute to two minute and force a pop-up instead.
  20. Message of the day (MOTD). It's what you see when you first connect to the server. Yes a discord ping would work, me saying to use the MOTD is me being a boomer again
  21. Currently the only thing that can be done is begging in OOC for people to vote a map other than Box, something that can get you banned on other servers. We already have a sound iirc and forcing the vote menu to pop-up would only happen if there was a way to permanently disable it as an option, thus in my eyes defeating the purpose. If we really want the most fairest thing here wouldn't a community wide vote to have this config option on or off be it? I get that community wide votes on issues that effect the whole server isn't something that's been tried on Paradise, at least to my recollection, but you really can't get much fairer than using direct democracy. I believe enough people want this to at the very least warrant a vote.
  22. If you want the choice of the players to be respected I suggest running a community wide vote on whether to enable this config option or not. I don't think it'd be too hard to add a forum thread with a poll in the MOTD. Or at the very get the staff team to vote on this. A community vote would show what everyone wants, not just what 10% of a server voted for in 60 seconds.
  23. None of our other maps are being played, and that's really due to our community being locked to only Box for the vast majority of its life. It might seem unfair at first but it genuinely is for the best and is standard practice on the vast majority of servers with a map vote to prevent what is currently happening on Para, having the community gravitate to one map. No one will play the other maps if they're not encouraged to and then we get stuff like this: Doesn't help that our voter turn out is usually pretty abysmal and other maps are only picked when someone is actively begging in OOC for other players to vote said map.
  24. Changing the config option "non_repeating_maps" from false to true will prevent players from voting on the currently played map during the map vote. Paradise has an unhealthy attachment to Box which stems it being the only playable map for the vast majority of this communities life. Our other maps will never updated, made better, or otherwise fixed if no one ever plays them. And when someone does try to fix one of our maps that isn't Box it can be highly demoralizing when those countless hours spent mapping are essentially wasted as it goes completely unused. For me at least I think the most frustrating part is that our other maps Delta and Meta aren't even bad or broken, it's just everyone is stuck in their ways with Box and refuse to vote for anything else. To be honest, this is going to force peoples hands a bit, and there will probably be people complain about having to play other maps, but we've been playing Box for the past nine years, so I think it's about time we give other maps a shot. This monotonous cycle of Box Box Box Box Box needs to be broken and this is one very easy way to do it, it's as simple as changing a config option from false to true.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Terms of Use