Skull132

To retarget the discussion a bit. I am not a fan of any prompt which directly asks, "Are you willing to be subjugated to Y antag?" On principle, the game's mechanics should reinforce the progression of the round. This is to allow us to actually implement game modes with progression mechanics. And a part of this is forcing players to do things that the antags want them to do: be it literally dying, becoming a cult abomination, a thrall, or so forth. There is an unwritten agreement that by playing on this server, you agree to be subject to such events. From a more balance and "fairness" oriented manner, giving players an opt out on matters like this would end up largely punishing the antags. Even if you stun the player, so the vampire can escape fine, he still has basically betrayed himself. And wasted a large amount of time on a matter which has basically fucked him. The only agreeable way, IMO, to implement this, is by having the victim die if they refuse, much like it works in Cult. This would basically punish the victim for not going along with the game. Now, I will acknowledge one thing about the last sentence: "fairness" goes both ways and for there to be severe enough consequences for ignorance, there should be some level of effort required from the antag as well. So my proposal is to move the mechanics a step closer to how they work in the source material, and make thralling not an explicit ability, but something the vampire can Just Do:tm:. So basically, make vampire blood an item which enthralls. Make it initially start off as an addiction, eg. "I want more of whatever I just drank!" and eventually make it result in full enthrallment. That is, if the subject has consumed enough vampire blood. It would add more roleplay prompts to the matter. Would still allow for forceful conversion (inject or force feed them your blood), while making it perhaps a little less cheap than the ability currently is. And perhaps make it a bit more fleshed out.

Disagreement on principle here, first and foremost. You absolutely need ingame incentives to do things. And ingame justification/reinforcement of actions is a great way to make people go along with them, and to accept them. Yes, we are a roleplaying game, but we're still a game. You are also correct that implementing gameplay elements will lead to powergaming, and the nibbling of players to do things "The Right Way:tm:", as can already be seen if you monitor some remote logs that admins get. But this is an issue that is manageable, and your own argument may well be applied against this: people shouldn't be powergaming, they should be roleplaying. The fact that the system can be powergamed doesn't mean that it should be. Also, your last point is fair but. Well, two buts. First, giving mechanics that are open enough for the character to roleplay out the ideas you mentioned should be the goal. In fact, this kind of roleplay could well be enhanced by mechanics: if you can influence your character's economic status, then you would be able to roleplay out things like not having enough money to visit the canteen, for example. The benefit of having mechanics that enforce roleplay is that this would then also be tangible, even to those who don't lean as heavily on roleplay as some others do. The second but is that with no mechanics, you let people develop their own interpretation of the game. And the analogy of "The Right Way:tm:" is applied yet still, through the creation of social norms that people will not stray from without being punished. With the implementation of mechanics, we can at least influence which way this pendulum swings. By leaving it up to the playerbase, it'd be done through soft means that are less effective quantitatively. So basically. There is a right way to do this mechanically, while leaving open (and actually creating) interesting prompts for roleplay.

The short answer is here, described by Conspire. Our economics ingame aren't consistent, well fleshed out, or convenient. All of these make its use an unfortunate happenstance. There's no real reason to participate in in-game economics outside of a minor degree, and the players can sense this. For chef and cook, because they have no need to charge, the players will feel it's unfair if they do (even if the players also know that the money they're giving away is largely worthless, the act of giving away with no reason is still one to elicit negative emotion). There's also the fact that because there's no need for the chef and cook to do this, the majority don't, and thus, the ones who do are deviating from a social norm. And we all know what deviation from social norms gets you! (It's not cookies.) To fix this. Hoh boy. I'd personally recommend an overhaul and standardization of all prices ingame. Vendors, kitchens, cargo, etcetera. Then giving the chef and bartender a real reason to accept money (paying for the raw materials), and having the rest roll from there. Should also review the amount of money crew get and how they could earn more.

They are whitelisted by time. Buuut the system is somewhat broke. So I need to fix it.

Why do you do this thing. Sand is a resource you need a good amount of, if you want to produce glass. Mining sand is relatively boring; and glass is a very basic resource. As such, the acquisition of it should be relatively painless and mind-numb free. Additionally, if the price of sand in the mining vendor is an issue, then simply lowering that is an exponentially better idea. I also do not see what this has to do with the planned automation update? Unless you mean to nerf manual mining in favour of automated mining, buuut that should arguably done at the same time or after, not before. Since doing it before makes the role very undesirable to play in the mean time.

In general I wouldn't mind if combat was slowed down, made more survivable. It's a wee bit hard to do though, considering the ammunition capacity of average weapons.

Present implementation merged and will be live next round.

Double posting but also re: transparency. Yes there are requirements to PR descriptions and reasoning, all of that falls under the purview of the Head Developers, ultimately. Which means that the Head Developers will inquire about a PR when they see issues and/or have decided that a PR's reasoning or description are lacking.

@Scheveningen Congratulations. That's exactly what I proposed when I said he could remove the links between the two items. PRs do not require project threads unless actually mandated for feedback purposes. Your own handling of a similar situation, though perhaps commendable, does not define what are and are not rules. There have been countless cases where PRs implementing a suggestion have deviated from the original suggestion, have not been large enough to require project threads (again, they are costly to maintain to the creator), and have been linked just fine to the original suggestion. The only differentiating factor here roughly being that people do not necessarily enjoy the proposed changes here. And in general. No policy violation has taken place. "This is not a complaint but a discussion," is grounds to have the complaint closed, which is what I will be doing now. If you want to discuss something, use General Discussion. If you want to propose new policy, use Policy Suggestion. Complaints are for instances of staff violating existent policy. This is due in no small part to the rules surrounding the complaint forum, where opinion-posting by opinionated people is a ban-worthy offense: because opinions are not the point of this forum, "Should have done so to be nice", is not the point of this forum. "Broke policy" is. To reiterate: The current policy is that a PR only requires a Projects thread if dictated by a member of the development staff. No such dictation has yet been made, so no policy has been violated by Arrow. And this decision can only be called into question once a PR has been merged or a Head Developer clearly objects to the idea of requiring a feedback thread for a specific PR. I would lose my mind if we got a staff complaint for every PR which hasn't gotten a feedback thread request after 1 to 3 days of sitting. There is no requirement nor policy to implement a suggestion as posted 1:1, as such, no policy has been violated by Arrow. Since the PR does relate to the suggestion thread, linking it is courteous to indicate that, "Hey, (an iteration of) this idea is being considered for implementation. Go review here. Complaint dismissed. All reasonable actions to undertake with respects to this issue have been outlined in the three paragraphs above.

No. Where is the inaccuracy you're attempting to gnaw at? Where is the lack of transparency you're attempting to gnaw at? The PR's description outlines clear as day what it does. The link is there to let the people involved in the initial suggestion that an interpretation of their idea is being considered for merging. Project threads are not a requirement unless flagged for (generally) major PRs, since they require a retarded amount of work ontop of a decent amount of work already. There is a very sound solution to this complaint, if what is happening now is too complex for people to understand: Arrow removes the link to the suggestion thread, deletes his comment in the suggestion thread linking the PR, and the PR will now be a novel idea to be interpreted on Github. Can you see the issue here?

There is no requirement at all for a PR implementing a suggestion to restrain itself to only implementing the suggestion exactly as outlined in the suggestion. Suggestions are regularly unfeasible as presented, have balance issues, or in extreme cases, are pitched in a fashion that renders them all but unworkable. (Or maybe the coder just disagrees with the details and wishes to implement his own spin on the core idea. Doesn't necessarily have to be a practicality.) This is why the contributor or the developer considering a suggestion has total creative freedom to implement said suggestion as he/she wishes to, with whatever caveats he/she wishes to include. Ultimately, consider the suggestions forum to be a pool of ideas that coders can pick from. For completeness sake, I will outline that posts on the projects forum are meant to represent a PR 1:1. But those threads are to be managed by the PR creator, and are usually created when the PR itself is not sufficient to facilitate feedback.

Let's have a throw back to when I actually played this game :^) My robutticist/RD: My HoS/Captain:

This was proposed to me by the Diona dev some time last year. Or was it right around January. Anyways, I basically said no. Hive chats of any kind are relatively powerful items, and giving them to more and more species would end up posing a relatively difficult problem. I suppose the current balancing factor is that they exist for races that are relatively docile or otherwise difficult to play. This limits their usefulness. But still, it's one of the major issues that exists and giving them out to more and more species is a bit of a butt. Another issue that exists is the originality of the mechanics at play. If you just want to give them a recoloured hive chat, then I would question it from a creative stand point as well. Skrell technically have a global hive chat: they can just enter the tdream realm and talk to each other there. But that's a relatively immersive experience, IMO. One which also compliments their lore and more accurately describes their ability of shared communion. What would you propose as an alternative to the Diona, if we were to rule out the lazy implementation of just, "Here, have a chat that you can talk into and everyone else can listen"? (And don't think about how feasible it is at the moment, a lot of non-coders think themselves into a box by trying to intuitively grasp what is and is not realistically implementable. Leave that determination up to us.)

Acceptable outcome.

> No cat ears -5/10.

It gets tedious, it then becomes an automated action that you do on everyone forever without thinking about it. Making it require active input is meh, IMO. Technologically this is doable, myself and Arrow discussed a few schemes for implementing this years ago. Simply maintain an associative list in the DB, pull relevant names via a 2 index search probably and you'll have what you need.

List of adjustments to be made over the weekend: New name for Eridani if I can be bothered enough. EMPC is a meme, 90% of the other suggestions were memes too. Skrell factions if the lore devs can be bothered enough. Removal of the remaining loadouts I missed if Paradox hasn't gotten around to it yet. Better selection separation because hnrg styling. Solve the Final Question of merchant and reporter. Probably go with what Arrow and others suggested: a special "Freelancer" faction or some such. Though also consider making merchant selectable by other factions as it makes sense. die.

This is now live. Some adjustments to follow but otherwise live.

Per Paradox's request, complaint will be marked as resolved. All of my remarks about the matter made over the course of this complaint are sustained. Hopefully the two can reasonably get along now.

I can so debate this. The idea of a "People's militia" and weekend warriors is much more in line with organizations like the Estonian Defence League and perhaps the US National Guard. Legitimately, the only physical health check required for the EDL is a family phycisian's note and that's it. Regular trainings are held every quarter on the weekends, so that people with regular jobs can attend; exception being large field exercises with the Defence Forces proper, which can run for a few weeks. Even basic training is split up over weekends for about a month and then some. So by that criteria, the TCFL are much more akin to those two organizations, as opposed to the French Foreign Legion. The only real criteria for you to be a foreign legion I suppose is that you are made up of foreigners. It doesn't necessarily mean that you're a professional regular military unit.

You've got the priorities mixed. The description is responsible for providing a good enough overview of the PR (both the technical aspects and the purpose) for the developers reviewing and maintainers merging to know what they're acting on. The title has no such responsibility and largely serves as a discriminator. Which is why the way we've conducted ourselves thus far is that offensive titles get changed by maintainers and lacking descriptions result in a PR being stone walled until updated or declined.

Issues like privacy (example: if suspected of metagaming we will put other ckeys and or they connection information into a note, which leaves us having potentially exposed another person's connection info to the player), meaningless fights over wording (y u so mean, or, "change this word because it's not exactly what I did"), and generally people peering into a semi-work space. All notes that merit it are preceded by the staff member talking to the player. Ergo, the player is usually aware of the root cause. The note is for internal documentation. +1 dismissal and away we go.

Instead of cherry picking, please read the paragraph in full. Or just the final line of the post, which is a summary in and of itself: "If it's an issue [you go talk to them]". As I mentioned, keeping a strictly professional attitude indoors is something you can do if you start legitimately paying staff. Why? Because it requires a decent amount of effort to detach yourself emotionally enough to pull it off. Which is why I do not mind if people nag on each other, as long as everyone involved is okay with it. Like, we have over 50 dudes in chat, all from different cultures and with different world views. There is a lot of grounds for friction and misunderstandings (a good example here is Paradox not being comfortable with Arrow's sense of humour, eg the "Opinions" joke), and we should acknowledge and work to solve this, instead of trying to assimilate everything into a white room with no distinguishing features. A decent example of this is PoZe and I. We both get passionate about code sometimes and some of our disagreements on how to do something can be very fun to watch, I am certain. But at the end of the day, I do not think less of him, I would hope he doesn't think less of me either; I review his code, help him out, merge his code, and life goes on. Psure we've even talked about it a few years ago. And again. No one is actually seething, outright undermining, sabotaging, etcetera. Not that I can see anyways. Arrow is trying to communicate, @ParadoxSpace needs to respond (to Arrow first and foremost). Arrow still merges Paradox's PRs, work gets done, and so forth.

As I explained before to Paradox in private, you will likely not find anyone that matches the desired image of "innocent" within our community. All of us get irate, all of us take jabs at each other, all of us make failed jokes, etcetera. Even Chada will eventually drop down from his zen if you try hard enough to get him annoyed. Countering with, "Well, you said mean things too!" is a bit pointless to that end. Ultimately, we should act like adults and should be able to understand that the expectation to remain cordial 24/7 is reserved for an environment where you're actually paid a salary, and that things will get heated. Either dismiss some stuff in your head, or speak to the person (as Arrow is trying to do and Paradox is responding to, intermittently) about your issues and misgivings. Becrying staff toxicity is not really productive unless there's actual malicious intent or other tomfoolery at play. Eg. attacks that are uncalled for. (And no, referring to a clear mistake as a brain fart does not quality.) Oh and yeah. If you act dismissively towards someone, as Paradox has done in cases, then expect them to act dismissively towards you as well. If this is an issue, you go and talk to them. And expect both of you to have to make changes, not just a point of, "Hey can you cut it out while I continue? Kthx." ONCE that fails, you make a staff complaint.

Hi, complaint's mine to oversee. First, to quickly cover some ground already covered elsewhere. The following assertion is not up for debate in this complaint. The testing of PRs is not the job of a Head Developer nor that of a maintainer. The job of a maintainer is to ensure in the stability and functionality of the codebase. Due to practical concerns (we merged over 70 PRs last month), we rely on the authors to test them and to present relevant information. If a bad PR gets merged, then the maintainers have two options really: to acquire a bugfix for the PR somehow, or to revert it. The latter was done in this instance. Further note, I'd prefer primarily to see dialogue on this matter between @ParadoxSpace and @Arrow768, since this is largely a matter of interpersonal communication. A large deal of evidence submitted to Alb, and by proxy to me, was just banter or a heated discussion. Banter and discussions where both sides can be perceived to be at fault: take the TCFL vs ERT debate. Arrow posted a sarcastic comment disvaluing player opinion, perhaps he should not have. Paradox, in the same discussion, should not have ridiculed the idea of trying to keep ERT relevant (because 'we need ERT!!!!!!!!!!!!!') and should not have personally attacked Arrow's activity (considering i play more). Note that we have about 500 regular players a month, if not more, so insistence that your opinion is somehow more important than the other 499 iiis. An old joke the Head Developers deal with quite regularly. Specially as of late. Ultimately, I would prefer that the staff team actually be able to communicate internally effectively, and either: simply roll with the shit, instead of assuming the worst or taking it to heart; do a double-take and communicate immediately about a matter being taken too far or off-topic. If taken far enough, point two will effectively mean the issuing of strikes and eventual dismissal (or GH bans if relevant), dependent on behaviour.