Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Community Coder Conveniences
#1
I have two ideas here which i think might help improve QoL for the community coders somewhat

The first one is a community/nonadmin/hobo-coder rank on the discord so that they can get each others attentions easily a la the RPers role

The second idea is to set up a community-patches github where we can aggregate the community patches so people can see, comment, suggest fixes, etc. for other peoples code. I'd be willing to set this one up myself, but i'd need to do a bit of research on how github actually bloody works first and have an admin put it somewhere public once it's set up.

Thoughts?
Reply
#2
Discord rank/role is a good idea, but the community patch thing might be somewhat questionable in utility since we don't actually know how much has changed since the public release and since each patch has been released.

I, for one, know that current implementation of chaplain contracts is significantly different on the back end than my original patch.
Reply
#3
(04-21-2017, 08:51 AM)Noah Buttes Wrote: Discord rank/role is a good idea, but the community patch thing might be somewhat questionable in utility since we don't actually know how much has changed since the public release and since each patch has been released.

I, for one, know that current implementation of chaplain contracts is significantly different on the back end than my original patch.

It's more of a "helping each other think through code and fix bugs" thing, honestly. Just imagine how much better off you'd be right now if there'd been other people who could look at your borg patch and identify bugs while you were making it. That sort of thing, y'know?
Reply
#4
Definite yes on the Discord role. I'd be happy to contribute to a collective hub of patches but I'm not sure how best to set it up.
Reply
#5
Idea: Just have a code/patch discussion subforum in the patches sections for people to talk about this kinda stuff
Reply
#6
(04-21-2017, 08:51 AM)Noah Buttes Wrote: Discord rank/role is a good idea, but the community patch thing might be somewhat questionable in utility since we don't actually know how much has changed since the public release and since each patch has been released.

I, for one, know that current implementation of chaplain contracts is significantly different on the back end than my original patch.

The only way I think a "community" goon would work is if the developers took an minimal effort in maintaining an open source fork. Like a once a year code dump or something.

Although I think Comgoonity has a funny ring to it.

Otherwise I can't see how patches stay too maintainable if someone adds a new game system but nobody can add patches for it.

Patches subforum works because people can create a basic implementation of whatever they want and then the developers can port it into the current version.

Once you get more developments I think it would become much harder to keep contributions current.
Reply
#7
Agreed. It's not really gonna work without a maintained release. You can manage that while keeping some closed source charm, but not all of it. Not to mention it's a giant PITA to manage all'a that.

On a related note, goon getting leaked sapped a good bit of joy out of the server for me. I like secrets. I mean I don't like old chem and it's circlejerky nature, but puzzles I like. I find trial and error fun. I'd be sad to see that go, but I guess it'd be better than everything keeling over. It's not there yet, but a time will come. I've always wondered what would happen when that time came.
Reply
#8
(04-27-2017, 08:54 PM)atomic1fire Wrote:
(04-21-2017, 08:51 AM)Noah Buttes Wrote: Discord rank/role is a good idea, but the community patch thing might be somewhat questionable in utility since we don't actually know how much has changed since the public release and since each patch has been released.

I, for one, know that current implementation of chaplain contracts is significantly different on the back end than my original patch.

The only way I think a "community" goon would work is if the developers took an minimal effort in maintaining an open source fork. Like a once a year code dump or something.

Although I think Comgoonity has a funny ring to it.

Otherwise I can't see how patches stay too maintainable if someone adds a new game system but nobody can add patches for it.

Patches subforum works because people can create a basic implementation of whatever they want and then the developers can port it into the current version.

Once you get more developments I think it would become much harder to keep contributions current.

I'd be super down for yearly code dumps, but somehow i don't really see it happening.

I wonder if there's a way to split a repo into two parts, one containing all the secret stuff and can only be seen by admins, the other containing basic systems etc. so that we could minimise conflicts. Even if there is, it's probably a hell of a lot of work.
Reply
#9
(04-21-2017, 07:56 AM)amaranthineApocalypse Wrote: I wonder if there's a way to split a repo into two parts, one containing all the secret stuff and can only be seen by admins, the other containing basic systems etc. so that we could minimise conflicts. Even if there is, it's probably a hell of a lot of work.

There totally is. One branch with "core" stuff, another branch which is "core + secret". Expose only the core branch. Community developers push to core, actual coders push to either (depending on whether it's a secret or not).

Things get a bit trickier with how BYOND works, though. For example: maps; because of the way those files are generated you can't just merge changes together easily, so any time a coder changes a "secret" part of a map it would take it out of sync with the "core" map, meaning that changes to one would need to be manually done to the other.

Essentially, it's way more work for the actual coders.

We're at the point now where we've deviated from the released code in quite a few key areas (esp. materials), and plenty of map changes. This makes building on top of the existing codebase gradually harder and harder, and become less and less worth it for the coders to do. We're still where content changes or additions can come in, but new systems become less-and-less viable to introduce.

Spriting will almost always always be useful and appreciated by community developers and actual coders alike.
Reply
#10
I really want the community coder role in discord.

Also, I'm pretty sure I remember the coders specifically vetoing the whole 1 core 1 secret codebase idea a while ago, so that will probably not fly.
Reply
#11
[Post was eaten by the Meathook Auditors.]
Reply
#12
(04-28-2017, 07:38 AM)amaranthineApocalypse Wrote: I'd be super down for yearly code dumps, but somehow i don't really see it happening.
I wonder if there's a way to split a repo into two parts, one containing all the secret stuff and can only be seen by admins, the other containing basic systems etc. so that we could minimise conflicts. Even if there is, it's probably a hell of a lot of work.
I too would enjoy regular code dumps.
Instead of a full on split, would it be an option to have have a life cycle for certain secrets? "If you don't figure it out in time for the next release, chance to discover it naturally will be lost."
Reply
#13
(04-30-2017, 01:28 AM)The Grim Sleeper Wrote:
(04-28-2017, 07:38 AM)amaranthineApocalypse Wrote: I'd be super down for yearly code dumps, but somehow i don't really see it happening.
I wonder if there's a way to split a repo into two parts, one containing all the secret stuff and can only be seen by admins, the other containing basic systems etc. so that we could minimise conflicts. Even if there is, it's probably a hell of a lot of work.
I too would enjoy regular code dumps.
Instead of a full on split, would it be an option to have have a life cycle for certain secrets? "If you don't figure it out in time for the next release, chance to discover it naturally will be lost."

problem with that is it basically would kill solarium fun stuff

re: yearly things, don't see it happening
if we were to do something like that it would be open source or nothing

problem with open source is not everyone wants to go open source and thus their code is in our game and blah blah legal blah
other problem as stated before is the secret stuff, basically you could do it so the 'open source' version is just the main Z level and we just maintain the other Z levels on a separate repo (if that's even possible)
Reply
#14
The main problem is that at them moment, the patches subforum is not really sustainable. Eventually, it won't be able to properly modify large chunks of the game, drawing into question the function of the patches subforum.
Reply
#15
Would it work to give out relevant sheets of code to all y'all who want to change the big stuff? Just like get em to pinky swear not to leak the top secret atmos revamp that the illuminadmins don't want you to see.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)