Skull132

Background: SS13 uses Internet Explorer to render all text based UIs. I just added these fonts because they were bound to be around without requiring external resources. It is possible to add fonts that are not system default, it would simply require that they be packaged and distributed properly.

Ye the idea would be that it's not an explicit ability, but a side-effect of vampire's blood. Open it up to organic and creative use. (Vampire blood grenades? ?)

Ye I became stranded on a similar thought. It'd basically give folks a softer chance to ignore enthrallment. Even though it would be reasonable to implement mechanics which can result in character insanity if the addiction is not followed through on, it might just prompt the user to cryo. But then again, people can (and actually do) already ghost from things like being soul sharded. Policy exists, but policy is a sub-optimal tool. Unfortunately, there's none better.

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.