MarkvA
-
Posts
419 -
Joined
-
Last visited
Posts posted by MarkvA
-
-
I don't think it's extremely difficult, no. But I don't know the full extent of the changes either.
-
The main thing holding Lavaland back right now is a turf refactor. Lavaland includes a hefty number of new turfs that are needed to support the map. Porting the turf refactor from /tg/ is a massive undertaking though (it'll probably involve changing like three hundred files) and is terribly boring and tedious. Once that's done porting the remainder of Lavaland (which is mostly the map, ruins and some additional items) is fairly straightforward and probably not very time consuming.
I'd have ported it by now, but I've been rather busy with university-related shenanigans and I have no interest in doing the turf refactor. If the turf refactor does ever happen, I'll probably port the remaining stuff needed for Lavaland.
-
I'm going to quickly give my view on this issue (especially as a former maintainer) and try to keep it short and simple as I don't feel like writing a huge wall of text nor joining in on this discussion.
The issues:
- There are too many pull requests being opened for the current number of maintainers (2) to handle and review.
- The review process of a single large pull request can take hours, and generally one review is not considered enough.
- Too many of these newly opened pull requests are huge and require several hours to review.
- Too many of these pull requests are opened but still require several large scale changes which bogs down the entire review process.
- Reviewing pull requests is terribly boring and time consuming.
- We currently require pull requests to be too perfect - not every pull request should require a file-by-file review that takes hours.
The solutions:
- Find more maintainers. This is pretty much hard/near impossible due to the shit job that it is.
- Make it so not every pull request requires 100% coverage reviews from several different people. We probably have to accept this means slightly more bugs/shitty code, but the current process just takes too long.
- Do not open pull requests that require a lot of changes once it's been opened. I realize this may sound strange, but it really helps to just have your pull request entirely finished before opening it so it doesn't need to be reviewed three times every time major changes have to be made. Probably not feasible.
- If you're not an experienced coder yet, I really suggest you don't try to make huge pull requests. It takes up a ridiculous amount of time because you have to figure so much out, and if the pull request then gets shot down you wasted your time. Start small, once you have more experience and coding doesn't take up as much time you can start working on larger things. The more experienced you are, the less time it takes to code.
- If you're going to make a pull request that's huge and many people probably won't agree with (especially map changes or things like traitor rebalancing) ask around first before you spend hours working on it.
My thoughts:
- Like I said, reviewing pull requests is a terribly boring, shitty and thankless job. Many of the pull requests that don't go through/sit around for forever only cater to a small part of the community or just doesn't interest the maintainers/coders. As a result, they'd much rather spend time reviewing a pull request they find interesting than something that they don't care about or even agree with at all.
- Maintainers would have to spend hours reviewing a pull request which they don't even like. I sure as heck would just leave it lingering in that case. That's just the way it is, and I don't think we can force maintainers to review pull requests they disagree with. It's a flaw of the system.
- It can be hard to tell people that spend hours working on something that their changes just aren't good/detrimental to the server. Oftentimes this means that they won't receive this negative feedback prior to making the pull request after it's already too late. Perhaps we should be more blunt beforehand and in pull requests when the changes are simply not a beneficial change to the server.
-
5
-
Bit late here, but this was an amazing survey. Great job and thank you!
-
Nope...
-1
Very good reasoning, thank you.
-
So a lot of people have been wanting the game to be more deadly/unforgiving and less hugboxy. One of the ways we could achieve this is by making it so you can only open a firelock with a crowbar (or by asking an AI/robot to open it). This means that if you get stuck inside of a room with a raging plasma fire you'll die instead of being able to casually walk out. Most other servers (at least /tg/) have this: attempting to open an airlock with your hands will only have you knock on the airlock.
Just something I was thinking about while working on firelocks, let me know what you think. If there's enough people that like it I'll open a PR.
-
Plasmamen were added to the karma shop two years ago by Ponies (of course) and they weren't finished back then and they still aren't. It was a bad idea back then and it still is. You can get extremely angry at the coders (you should really tone down your post, how many fucks are in there), but in the end no one wants to touch this poorly made race.
-
I'm going to jump in here and say that too many people are basing their opinions solely and purely based on assumptions. This is less prevalent here, but it's especially bad on the Space Station 13 subreddit, where people are blindly repeating claims repeated ad nauseam by a small portion of the community. Claims that haven't actually been properly proven or that are plain false.
I do believe mistakes have been made since Paradise's conception. But I don't find that very surprising considering the size of Paradise's staff team and the incredibly long time (for an SS13 server) it's been around. Pull requests have been unjustly shot down (PJB's comes to mind), certain issues haven't been addressed and communication hasn't always been the greatest. In my opinion, the biggest mistake is the liberal use of permanent bans: that's without a doubt something that needs to be addressed.
But people are looking at Paradise's history with rose-tinted glasses. People think the time when ZomgPonies was the only maintainer was a great time. But many seem to forget that ZomgPonies left us with about a dozen unfinished, half-baked features and the codebase in a terrible shape. Ponies claims he left because of Fox, but in reality on not one but two occasions he simply vanished for reasons which had nothing to do with the code base, but rather with him just getting burned out and abandoning the community (I'm one to speak there, though). If it wasn't for Fox who picked up development and even acted as the sole head admin for a year when no-one else would, there'd be no Paradise.
People complain about cliques, but if we look back about two years you'll find the exact same complaints: it's simply something that naturally happens to a Space Station 13 server due to it's roleplaying nature. What can admins do to break them up? Ban them? That'll kill the server: it's these hardcore players that actually sustain the server, pay for its costs and join it when it's low population. If they meta or are shitlers, ban them. If they prefer playing with friends, how are they breaking the rules? Cliques are an issue, but nowhere near the huge issue people make it up to be.
People are correct that PR's get shot down without sufficient communication sometimes. It's something that needs to be remedied. But the same people that contribute these PR's also refuse to fix any issues: they only take, but do not give. If you truly care about the server, push through some fixes and then create a new feature. It means you actually want to contribute to the codebase, and not just push through features that you happen to like. And too many people try to create new feature PR's despite having very little programming experience. The maintainers aren't there to teach you how to code or clean up your code: having your code up to scratch and extensively tested increases the odds of your PR getting merged by about a million (and oh boy, so many PR's are fully untested, and then the original creators of the PR refused to fix any issues). If you write shitcode and don't contribute in any other way to the codebase, are you really surprised the maintainers can't be arsed to review your PR (leaving it in PR limbo) or even shoot it down?
And really, too many people are blaming Fox. Was adding the Vulpkanin to the server a good idea? Probably not. But he is still doing what he thinks is best for the server, and he ensures that the server is actually balanced. People seem to have a dislike for balance these days, but I remember the times two years ago when races were "unique". It sure was fun chasing down the endless stream of shitler slimes that vent crawled through the station naked cutting themselves. And oh boy, it's certainly very balanced for Vox to leap around the station. Balance may take away some of the "fun", but it is necessary to give every player (including humans) a fun time.
-
My guess is that your school is somehow blocking the outgoing connection to the server, or blocking the server's response for some reason. Not sure why though.
-
I'll look into implementing this once the feature freeze is over.
-
What IP are you trying to connect through?
-
I'd love to add this, but unfortunately enough due to the feature freeze it can't be added. You'll have to post a reminder once it's over.
-
Why is there an argument in the first place. If people want to meta, there's plenty of better ways of doing so.
-
Central Command only has the same stamp as the Nanotrasen Representative because when I implemented proper stamps for admin faxes we didn't have a unique stamp for either party, and I believe WJohnson was kind enough to design a sprite for them. If someone can design a good looking stamp for the NT Rep though I'll gladly implement it.
The photoshop file for stamps is here: https://github.com/ParadiseSS13/Paradis ... stamps.psd.
-
-
Yea, bYOND really needs to get their shit together with regards to associatives/multidimensional arrays, their support for them is just terrible. And I agree that havong am array in for just the commands is overcomplicated.
I should get round to this today.
-
Well well, there's making an overstatement and then there's that post. It really isn't as bad as it's made out to be. Clearly you haven't had the pleasure of working with associative arrays in BYOND before.
I'm not happy about the UI being ripped out in favor of having the new shuttles in as quickly as possible, so I'll re-implement it myself.
-
Heh, that's funny. Turns out that it wasn't quite intentional to not give Dionaea mouth, but a bug. They should be able to eat again next patch.
-
-
Mhm, I thought I got rid of that already. I'll look into it.
-
Sorry, but it's not getting reverted. Also, dionaea are not immune to facehuggers.
-
-
Great work so far!
-
No, pretty sure that was the IPC head color, which was enabled.
Should we organize a Lavaland bounty?
in Public Archives
Posted
There's that too, you'd have to work based on the main PR but then also check the most recent code for changes. This PR is one of the key ones I believe.