Skull132

Iirc it's linked through the web interface This is true.

Double post but hey. The effects of the election results are amazing. So much hilarity.

Dis gon b gud. Where's my popcorn.

Had a chat with him about ECF/EE lore a few days ago. Understands that dry wiki stuff is just that -- dry. Considers slice-of-life important. Though, I'm curious. With the fact that lore developers are not granted automagical event manager position (ergo, their ability to influence gameplay remains through constant movement/changes in code, and through other means), how would you do better on bringing the slice-of-life stuff you were referring to back then?

Lore Developer feedback for Skrell: Sprint speed to be raised so they're faster than a hunam. Stamina to be kept somewhere between a Taj and a hunam.

My scheme of being too lazy to swap out my avatar is about to pay off. Just you watch.

Ban should actually be Alberyk's, because it looks like he was the trial that actually handled the case, and Tish just applied the permanent ban for him. I'll let him know to check this.

There are! CCIAA system currently refers to character IDs. Though this only applies if you get a report and such against your char. Retroactively, we'd just lock the name modifications effective whenever the update for it is pushed. Anything before that is up to CCIAA to sort out if they see it necessary.

It resolved itself, aye. If you have connection issues, send me a PM or email me at skull132@aurorastation.org, and I'll see what can be done about it!

Will have a chat with the coders, but it may be easier to remove the radiation event from circulation in there, due to how the system is built up. We'll see.

Won't affect it, one way or another.

Solely the name. Other mechanics, such as the economy, will push for characters having a lot of things preset in stone/hard to reset. Such as a character's economic status, for example, or all of their transaction and other records. But user input will include the name. All freeform data for IRs, CCIAA records, character emails (I actually forgot about my plan to code those in the coming near future), will include the character's name in the data field. If the user is given ability to change it, the end result will be a large bulk of data pointing to a character which may as well have been outright deleted at that point. It'll create a lot of confusion if staff are, for whatever reason, required to look into logs on that matter. Also, it's not about using names as primary keys, it's about making sure that you don't end up with a whole lot of content referencing a Dave McGee (emails, IRs, brig notices, transaction logs: the freeform, user generated content for them), while the character slot's new identity is a Cheshire McGoo.

Okay, so. A few features which have been planned, such as, the economy, persistent (though fully player controllable) brig records, and even the already-established CCIAA mechanics would benefit from one thing: character name be made more difficult to edit. First, a little elaboration from a technical standpoint. A character has exactly one marker that we mechanically keep track of: a character ID. Each character has their own, the player never sees or interacts with it. This is what, presently, ties CCIAA reports and actions on the WI to specific characters. Later on, it would tie your character's economic status, brig incidents, and whatever else (apartment status?) back to the character and you. However, it's a number. Never seen in anywhere but the code. What is seen, is the character name that's written in the freeform content of such data. A very basic problematic scenario that can already happen today is: your character gets a CCIAA note against them, you rename and re-purpose the character slot, and that note will still be there. Its contents will refer to the wrong name, but still the same character slot. Multiply this a little as we keep stacking things. The solution to this is to make the character name require a quick form and Admin/CCIAA approval to change after a grace period of, say, 3 days. Github issue here. (And no, this would not be a measure to make dodging CCIAA or shit like that harder. It would ensure that records don't get messed up, and horrible things don't happen in the backend. In fact, it would encourage proper dodging: the making of a new character. So please, don't assume this.) Sounds simple? Well. As I was discussing it with the dev team, I came up with a good list of edge cases which would suffer from this. First, know that this does not restrict you from deleting and making a new character all together, in any way, shape or form. An old character can easily be nuked, and a new one made up, no matter how similar. However, things which this would outright stop: Usage of a persistently random name all together (no more, "I'm going to join as a char with the same look/FT, but a different name, every round"). Regularly name hopping, for, for example, undercover RP or shenanigans like that. (TECHNICALLY hindered, but it's hindered to the point where it's almost inconsiderable, unless you get CCIAA to help you out on a daily basis.) Here's the list of things it would hinder: Simple name edits for whatever reason (marriage, retcons, divorce, whatever), past the 3 day grace period -- need to get some form of back-end approval, from admins or CCIAA. A streamlined pipeline can be set up for the process that would take no more than 72 hours -- specifically, fill out a form on the WI, wait a bit, someone presses "APPROVE", and the change goes through. Any major retcons of a character would require contact with the CCIAA to also remove attached CCIAA records. Shouldn't be a major issue in most cases, but simply takes time and adds to burden. At first glance, some of these things may seem relatively arbitrary and useless. But, I've personally made use of 3 out of the 4 features noted above. So, give it a thought, a second one, and a third one. Now, what would we gain? Simple: development of pseudo-persistent features, the ones outlined in the opening paragraph, would be made easier by ten nautical miles. As it would remove a elephant from the coder's room. What am I asking from all of you regarding this matter? Opinions and thoughts. Concerns and comments. Questions.

Archived.

I am okay with some animoos.

Reminds me of Yithani. [Know and learn the SS13 meta lore.] I find it odd how close those names are.

Realize what this proposal made clear just now: You pretty much stated that your suggestion isn't actually to deal with a specific mechanic that's abuseble or a mechanical issue in general, but rather to deal with a specific individual or playstyle. Because: the mechanical change from mouse to cockroach on its own would leave the same gaps in policy and enforcement that people are attempting to expand upon right now. It would only resolve the present concern, as it were, while taking no proactive measures to ensure that such shenanigans do not happen again in the future. No thank you. The issue you're getting at is one to be solved at the administrative level, not at the developmental and code one.

I have a principle of not removing things for reasons like this. Generally because these issues will eventually get resolved at the administrative level, so we'll be short an issue in the near future. If we also remove the mechanic tied to the issue, we'd be short an issue and a mechanic. Addendum: The only things to look at from the mechanical perspective are outright possibilities for abuse. Such as squeek-spamming, which was resolved by a patch; and maybe respawn timers. But at the moment, this seems like a singular case being blown infinitely out of proportion. Doubly so when the administration is fully capable of dealing with the matter at hand, and will deal with it.

Fun fact! This stuff exists for donations in any form! Or, at least, has the chance of existing, depending on your country of residence. The main reason I've not set up a PayPal for it all yet is because I'm currently seeking legal council to see if I'm required to do anything, by Estonian law, whence I start managing the donations.

There's a long list of staff and players who would simply quit working for Aurora if any part of it was monetized. That list includes myself. It is a fantastic way to ruin a hobby and an enjoyable activity. We in no way, shape or form, require funds this fast. If we were in financial trouble, you'd see me act about ten times faster with regards to setting up donations. Right now, I'm slowburning it because we have the ability to: the donations are there to distance the server's dependence on me as an individual, but I'm not dropping out without a word over the next 6 months at least. And even if I was to pull out, we should be able to manage just fine. I would also suggest reading community feedback on this issue in the actual announcement thread. 99% of people who replied were against any monetization. And this sentiment has been shared by every outstanding member of the community that I've discussed the matter of donations with over the past year -- it is not simply me being stubborn. A hobby should remain a hobby, and money should be kept as far from the actual running of the community as possible. And I don't plan on giving up this principle for shit, same goes for all higher level staff. We'll have an ability to donate. It will be completely voluntary, there will be no rewards or services offered in compensation. We have no need for anything more. Any questions?

Yes, but power is a challenge a borg/AI team has to face to a greater degree if they want to move to anyplace other than TComms. That's my point: using TComms is made easier by the presence of a meta-hack. Had this complaint been about using the engineering sat, for example, or the asteroid (both of which have been done by other AIs in the past), I'd have walked along past this issue. But I want to know what the madmins think about the infinite power thing.

Well, there are roughly two points here. First, is the AI permitted to be moved off station? Second, is it alright to use the TComms satellite (and its magical SMES) for activities that clearly benefit from the energy security they provide? The first question will shape the way enforcement of AI specific shenanigans is handled, while the second will shape the way the magical SMES and their utilization is looked upon. It is specifically the latter question that has never been answered by a higher authority, as far as I'm aware. Hence my raising that for review. Why does it matter? Why do any of these questions matter? Why are these questions even asked? In the case of the first question, it was asked because a member of the community was displeased with the currently established rules of enforcement. The latter, because, again, it's not need answered properly yet ever.

It's only worse off when it's spotted moving there. For the third sodding time: you're relying on power from magical SMES that never run out. This makes the spot very easy prepare and move to, in comparison to any other spot off the station. On principle, this is questionable to me. The specific scenario is almost irrelevant here to the actual issue of, is this a legitimate play, or should we force malfs to take more time by going through the actual steps to setting up a new safe haven for themselves?

Nono, you're fine. Generally, whenever I see "Adminbot" (our first and relatively bad attempt at an automated ban mirror attempt) as the banning admin, I go looking for a web of bans which the admins can't navigate as easily as I can, due to me having direct database access. My post was just a note for whatever member of staff looks into this, that all of your data is centralized under your ckey, and not strewn about over 10 other ckeys and adminbot bans.

Original ban by tablespoon, applied at 06MAY2015. Admins should be able to find everything if they search silverus from notes.