I inserted a custom sprite into my smw rom but the game is no longer running on the emulator (neither znes nor snes9x) what do I do?
This is not the kind of question that user feedback should be used for. I'd recommend taking your question to the SMW Hacking Help subforum, and giving a little more details about what sprite you inserted and what tool you used to insert it.
I wanted to express my disappointment with the actions the staff has chosen to take in this matter.
I understand there isn't a course of action that is going to satisfy everyone, but to strip an excellent admin from her position for something that had no negative impact at all whatsoever to anyone else on the site is ridiculous. It would be one thing if she leaked IP addresses or private messages between users, but what she leaked only involved one user (who just requested their own User Discussion thread), and nobody else.
Now, I'm not saying Staff should be allowed to sell non-Public information for money. Even if people try to brush this off as a trivial matter because this is "a silly Mario website". If a site wants any sort of serious staff, then that obviously shouldn't be allowed and the seriousness of it should not be minimized. But to demote an exemplary admin over something that happened over a year ago, at a time when they weren't even admin yet, is an overstep.
Had none of this come to light, nothing would have even happened. Nobody was hurt by her actions. Nobody felt the effects of her mistake at all except for the two people involved. Yet she decided to air it all out to the broader userbase for transparency, and to let everyone know she did something wrong and receive criticism for it. In my opinion, this is exactly what an administrator in this position should have done. If this was a repeated, recent pattern of abuse of position, then yeah, I'd probably agree with the actions taken, but as far as we know, this was the only incident like this involving her. With that taken into account, I earnestly believe she does not deserve to be demoted as she was.
What should have been done instead then, if anything? Unfortunately, I don't know. I know it's not exactly productive to point out something you don't agree with without providing a better or alternate course of action, but all I can offer is my opinion that this definitely was not the right course of action, even if it probably was a compromise between not doing anything at all and a complete demotion and/or ban. I know this decision probably was not carried out without serious consideration and deliberation among the staff, but I feel it should absolutely be reconsidered yet again.
i want to begin addressing this by noting that had we chosen to keep nameless as administrator, we would've gotten a very similar staff feedback about not handling this properly - and, had we fully fired her from staff, we would've also gotten a very similar staff feedback.
while you do note that nobody was hurt by her actions, it did compromise the staff guidelines of which all staff are expected to abide by, and admin or not we expect those rules to be followed. and, while you do note she was an exemplary administrator, an extreme action such as exchanging private staff info (which did not just include ladida and nameless, but also the other staff who weighed in or were part of discussions) will have a disproportionate reaction. this might be a hobby site, but we cannot condone the leaking of staff information with little consequence, and we do not want to give off the impression that the higher staff you are, the more immune to the rules you are.
there are currently no plans to reconsider this demotion.
After an update to the in-browser SPC player a month or so ago, you need to click on the play button twice for the submission to play, and it doesn't seem intentional (the player shows up, but only plays if I click play a second time). Using Firefox 72.0.2
This isn't really the purpose of the User Feedback form. If you encounter future bugs on the site I'd suggest making a thread in the Issue Tracker subforum or a post in the Minor Bug Reports thread.
That said, I'll let Telinc know about it and see if he can replicate the issue.
In a late response to Nameless' leakage occurence which I just happened to stumble about again, why don't you make it so IP addresses aren't just so blatantly around everywhere for staff members? This probably takes some effort to do, but you could replace the IP address fields in posts, profiles etc. by "Show IP address" links, and make a log, accessible to administrators, of the usage of said links by staff members. That way, you can make sure no actually sensitive information is being misused by being able to keep track of suspicious IP-gathering activity.
As I said in the thread somewhat, staff members are not this group of people elected mature and trustworthy. Maybe they were in the past, back when being staff was such a big thing. Now promotions happen left and right and the teams are much more specialised. That's something I can say I like, as it makes everything work so much faster, but it doesn't fit with this old format where everyone has free access to everything. You can't keep track of everyone with such a big team; back then everyone knew eachother well in it, I'm confident that's no longer the case.
i just noticed this box at the bottom of the form. have you actually anonymised this thing for real?? i doubt it. oh come on, you know who this is. no one else writes dumb like that, except maybe like snn but i am pretty much him lol
Sorry, I don't actually know who you are. Staff feedback is truly anonymous and we cannot see who you are in any way, shape, or form without you explicitly telling us or using the checkbox at the bottom of the form to make yourself visible.
IP Addresses are only logged in profiles, not on posts. Histories are only visible after clicking a link in the profile, but you're right that all Staff have access to see those histories due to their potentially helpful nature when carrying out userbase matters. In general, we don't go out of our way to track IP addresses, and when there's an issue with IPs it's usually because of IP matches or duplicate accounts, and the site will inform us of those instances.
As for making accessing the history logged internally and accessible by admins, we can consider it further.
Can something be done about the birthday thread? It's getting pretty obvious that people use it to just make daily "happy birthday [user]" posts with no other content, even if the person they're wishing a happy birthday to is someone who's inactive or probably doesn't even know the user wishing them the happy birthday. One of the users who's guilty of this actually has the majority of their posts being "happy birthday" one-liners.
Personally, of all the ways to postcount+++, wishing someone a happy birthday is the least egregious way. We don't have an issue keeping up the thread, nor an issue with people using it to consistently wish others a happy birthday.
Originally posted by A big problem with your staff's attitude
Yikes, just when I thought you couldn't get pettier, you surprise me yet again, SMWC Staff!
What is it about you thinking you are (or that you should be) the center of the universe?? First it was the Lunar Magic 3.0 situation, when you got so freaking upset Fusoya and Vitor weren't working with you (lol) that you went out and made that incredibly stupid "We The Staff™" post. [redacted] What the hell?
Now today? Oh boy. You rejected graphics made for a patch just because it isn't hosted in SMWC. And again with your ego problem, thinking you should be the center of everything SMW hacking related. If something isn't on your site, it's irrelevant and shouldn't be discussed or considered at all. Seriously, stop thinking you're goddamn gods or something. What happened to the place I fell in love with in my youth that dedicated itself to promote a hobby, whether resources or tools were hosted on the site or not?? Why are you acting like this now??
So what will happen if someone like Vitor doesn't upload more SA-1 versions to your site? Will all the resources that use that new version be instantly rejected because it's using a version that isn't owned by you (according to your new policies)? What if someone were to create an improved Addmusic tool that gives porters a lot of tools and freedom that AMK lacks, and they want to make the resources widely available in your site? Will those be rejected as well because your staff wasn't part of the development??
Jesus Christ people, this ego of yours isn't doing anything that will help SMW hacking more forward; it's literally doing the opposite. You know why people are "leaving you in the dark" in the development of new stuff or are choosing not to host their big and revolutionary resources in your site? Because of this stupid attitude you're taking. Doing this only alienates your talented creators.
Seriously, get out of that stupid bubble you're living in. You're an important site, yes, that can't be denied, but that doesn't mean you should be consulted with everything before releasing stuff, or that you should have the ownership of a tool/patch/whatever to be able to accept resources that could be useful for people. You're no authority over SMW hacking, even if you delude yourself into thinking that.
Well, there's some stuff to dissect here. I redacted a part in the first paragraph that referred to a staff only discussion, but I have addressed it within the staff forums. Here we go:
First it was the Lunar Magic 3.0 situation, when you got so freaking upset Fusoya and Vitor weren't working with you (lol) that you went out and made that incredibly stupid "We The Staff™" post.
Lunar Magic 3.0 was a pretty big surprise. Since Lunar Magic is a separate project from the management of SMW Central, we cannot anticipate when there are updates that may cause resource incompatibilities. While in retrospect Lunar Magic 3.0 had less incompatibilities than we were worried about at first, the staff team had to act fast to ensure that our resource sections would be up to par with the most recent version of Lunar Magic. We still run into resources in our section that are incompatible with LM3.0's big level settings every once and a while.
Now today? Oh boy. You rejected graphics made for a patch just because it isn't hosted in SMWC... If something isn't on your site, it's irrelevant and shouldn't be discussed or considered at all.
SMW Central is both a resource hub and a community for SMW Hacking. People have the freedom to submit their resources if they so wish to, but our current policies is our resource section only supports resources also found in our section. This is mostly to ensure about resource stability - for example, if we hosted graphics for a sprite not found on SMW Central, anything could happen to that sprites availability that would then nullify the graphics we hosted.
I disagree that "we" don't support user projects, though. Staff's jobs are to support the resource sections and the site itself, but plenty of hackers use external resources not hosted here and discuss them through our forums or our Discord. lx5's powerups patch has its own area in the hands of lx5, and he even plans to host a wiki that'll link to player graphics for his own patch. We encourage users to handle their own resources and share them on their own terms if they wish, and SMW Central doesn't intend to give off the idea that things hosted here cannot be discussed or given attention to. It's just our sections are currently as self-contained as they can be. We can consider revisiting our section policies in the future, but it's currently low priority.
So what will happen if someone like Vitor doesn't upload more SA-1 versions to your site? Will all the resources that use that new version be instantly rejected because it's using a version that isn't owned by you (according to your new policies)?
I assume this hypothetical also implies that Vitor would not permit another user to submit new versions of SA-1 on his behalf, either. In this case, current policies would require submissions be compatible with non-SA-1 and the most recently supported version of SA-1 available on SMW Central. We do hope SMW Central can be a fulfilling resource hub for most people to feel okay with submitting their resources to, and we hope to remain that for the users who feel comfortable utilizing the site for those purposes.
What if someone were to create an improved Addmusic tool that gives porters a lot of tools and freedom that AMK lacks, and they want to make the resources widely available in your site? Will those be rejected as well because your staff wasn't part of the development??
Staff are not involved in the development of PIXI and it's the best sprite tool we have currently. Staff involvement in resources is irrelevant. If a user is developing a tool that they know will break compatibility with stuff hosted here - we do encourage them to talk to staff in advance because we can help make the transition easier, such as setting up remoderations in advance and whatnot. It's not necessary of course, but we can only roll with the punches we're given.
Something that resources need is that each resource refers to their dependencies, for example a patch can require another patch to work (i don't like to use as example my resources, but for example you can create a patch or a uberasm code that uses Dynamic Z features to work, it is just an example but a lot of patches require others to work), then a resource that requires another resource can have a field with all the dependencies and another button of "Download with dependencies" that would download the resource along with its dependencies.
If a resource uses two or more resources to work (for example i know that we use amk, but if a port uses amm, amk also works), the page recommends the latest or the best of the options as dependencies (amk in this case).
For external dependencies like "LX5's power ups", the resource can have a Warning saying "Hey this resource requires this external resource" and put a link of the resource, also those resources can have a special tag for example "lx5 powerup" to remove them easier if on the future that dependency is not available anymore or if the dependency was added to smwc and need to change the description of the file without a remoderation (this can be made with only a SQL Query).
I write this thread as a response to this moderation log also because i read this feedback and i think that resources that require external dependencies shouldn't be instantly rejected, i think that rejecting resources of people for those reasons just hurts the hacking community, smwc should support hackers to create new resources and these kinds of arbitrary restrictions just discourage people from creating resources, so i was thinking of a solution to that.
The first part of this feedback would probably be better suited to the Issue Tracker subforum, but I have to say that I do like the idea of more clearing and directly linking dependent resources when making submissions. It could be done manually by the submitter or moderators by having them provide direct links to other resources in their submission descriptions, but adopting this as policy would first require staff discussion. As for a system that automatically downloaded the resource and its dependencies, I do not know how feasible that would be offhand. Once again I'd encourage you to make a thread in Issue Tracker with the idea as a feature suggestion, so it could get a technical response from one of our developers.
As for the second part about external dependencies, as has been mentioned before, and even referenced within this feedback itself, our current policy is to not accept any resources that require an external resource that we do not host. But I will admit that this rule is one that was conceived when the site was first founded. 14 years is a long time, and the culture surrounding the site and submissions has no doubt changed in some ways since then. Myself and the other admins have discussed the rule in light of the feedback we received recently, and have been split on whether we feel it should remain as it is. It seems that it could be deserving of further discussion among staff, and perhaps the wider community as well. Like mentioned in idol's previous post, however, such a discussion would be lower priority at the moment. When we find an appropriate time to have an honest talk about it, we will.
Originally posted by A Staff Feedback about Staff Feedback
(SF = Staff Feedback)
Dear staff, your staff feedback system is not working. People don't use it because people don't trust it is anonymous (myself included), and people who uses it uses it in a wrong way (see all those posts about feedbacks that should be in the forums instead).
There's at least one reason why SF can't be fully anonymous: spam. If somebody spam SFs, you wouldn't have any form to know who is behind the spam, then anyone would have freewill to spam SF, and I don't think you aren't that cautious to not consider spam under your options. Therefore, it's actually impossible that SF can be fully anonymous, it's a common sense thing.
But yes, people isn't trusting SF's anonymity (and that's why I think it isn't used), probably due to better reasons as the one I said, but still. I know you know who I am, and who the person of the previous SF is. It's obvious, you don't need to try to convince us. I'm sorry idol, but your endless petitions to use SF everytime Staff is being questioned isn't working.
Staff Feedback/User Feedback is truly anonymous (I will likely use both of those terms interchangeably throughout this reply). To prove it, we admins have agreed to show a screenshot of the ten most recent threads in the User Feedback subforum, the place only accessible to admins where user feedback reports are, as well as a screenshot of how the inside of a feedback thread looks. The two thread titles I blacked out are feedbacks we have not responded to publicly in this thread because they concern matters that do not fit the criteria for sharing their contents in this thread.
As everyone can see, there are no hidden identifiers in thread titles, or in post bodies, or outside the post body in some other location. The only way a person's ID becomes known to us is if they click the box to Share their Identity. At that point, their current username and user ID get placed in the thread title instead of "[Anonymous]", as you can see with the feedbacks sent by Truxton and Infinity. We do not track information about who sends us User Feedback.
You do bring up a fair assumption in spam prevention measures. However, we believe that although the risk is there, it is more important to the site and to the community that anonymous user feedback is truly anonymous. Additionally, in the five years since staff feedback was created, there have been no serious attempts to spam the system. Spam in user feedback is not a particularly large concern to us.
As for the last part about trust in the system, we've actually seen a fair bit of use of the system in recent months. Whether you consider that a good or a bad thing if up to individual interpretation, because, admittedly, there have been a couple of turbulent moments this year that have resulted in people sharing their opinions via Staff Feedback. Aside from that, I don't really think there's a way anyone can quantify "trust" in the system here. This feedback suggests people are afraid to use the system, but aside from this brief glimpse into the user feedback forum that I've shared today, no one other than admins has any statistic to work for how many people are using the system. It makes a claim that cannot truly be backed up.
I do not know who you are. None of us do. We may have our suspicions because that's just natural curiosity, but that curiosity is not pertinent to the feedback. Who you are doesn't really matter in the end. If, after all this, you still don't believe us, then I encourage you to reach out and speak with us directly. Clearly there's been a misunderstanding, and we'd like to try and resolve it. We will not be retributive.
And lastly, a quick statement to everybody. In general, do not expect this kind of behind-the-scenes look at staff and administrative areas to become commonplace. It was done here simply to provide clear evidence to back up my points.
I just read the latest feedback that someone posted and it did get me thinking of a possible preventative measure against spamming the feedback forum. However, it does (in theory) make it possibly less anonymous; only if someone reads the database (which only leaves two who are able).
Couldn't there be like an `ip_counter` DB table of sorts when someone uses the form? If the count exceeds the limit over a period of time, they are given an error message/banned (some amount inhuman). Now again, this does in a way give a way to find who did the feedback for those with DB access.
However, ideally it'd expire after like 5-10 minutes or something like that (the ip row would be deleted). You'd be able to throttle potential spam and also keep the window minimal that in theory could reveal who is submitting if you searched the IP (heck the IP could be hashed, which is a way better idea!).
Not that Telinc nor Noivern would try to read but this could be something to consider down the road if someone reads that reply and decides to test us. The main thing would be probably banning them after X amount submitted. There's lots to consider, I do hope this helps!
Thank you very much for all your wonderful work! <3
Originally posted by Spam on Staff Feedback
Anonymous feedback should have captcha and each user should do only one per day to avoid spam.
I highly appreciate the suggestions given, but I do not want to compromise the anonymity of the system unless there is a compelling reason to do so. As far as I'm aware, there have been no attempts to abuse the feedback system. If keeping track of the sender becomes a necessity in the future, we will be transparent about it and the logs will be as obfuscated as possible and kept for a minimal amount of time.
Regarding the Captcha suggested in the second feedback, I don't currently see a need to hurt the user friendliness of the system. Once again, this decision may be reversed in the future. Should the need for stricter control over feedback arise, I would be more open to trying a Captcha first before resorting to logs.
Originally posted by Re; the staff feedback about user trust
I'm not the same person who submitted that other message, I'm a different guy.
When the staff feedback system was first opened, SNN specifically said on IRC that, although the system is for all intents and purposes "anonymous", it is still possible for someone with database access to check the source of the message and find out who sent it that way.
Yes, I'm aware that this would imply that most regular staff members and even some admins still have no way of knowing who it is, yes, I understand that such drastic measures likely won't be taken unless there is a case of spam and/or threatening messages, and yes, it probably wouldn't be very easy for someone even with database access to find out precisely who sent a message, but I feel as though you're being a bit disingenuous by making it sound like it's completely impossible for the identity of an anonymous sender to be discovered. And it's even more fishy when you make a detailed post trying to prove the anonymity of the messages without so much as mentioning or acknowledging said "extreme" cases.
Moving on to a slightly different point, I'm curious: If you staff members can't find out who sent a particular anonymous user feedback, are you at least able to recognize if two different anonymous messages were sent by the same person? In other words, even if you have no idea who sent a particular message, is there at least a way for you to know if the person who sent it is the same as the person who sent another "anonymous"-marked message?
This feedback came in last week but I waited to post a response until I'd confirmed certain things with Telinc first.
You bring up a good point, one I hadn't necessarily considered because I don't have access to database matters. My previous response was written without that in mind. So I spoke with Telinc about how the site handles feedback and if anything gets kept in the database. I hope you don't mind me getting a bit wordy.
In short, the site truly does not store any details or user IDs related to staff feedback. Telinc looked through the database and through the code for how feedback works now and could not find any instances of identification being stored there. In fact, the site actually has at least one system in place to intentionally obscure anyone who might be in the middle of sending a feedback.
The first is an obfuscation of the Online Users page staff members have access to. Normally, the Online Users page shows a list of where everyone currently browsing the site, both logged in members and guests, has navigated to. For example, as I'm writing this feedback, the page would show my current location as "replying to thread 93969", a.k.a this thread ID. If someone is in the middle of using the staff feedback page, the site will essentially "fake" that the user is at their last known location that wasn't site feedback. I didn't even know we had this preventative feature at first, so it was a real pleasant surprise to hear about, because shortly before learning about it I had also had the thought that there was the possibility we could accidentally and unintentionally see who was sending a feedback through the Online Users page.
Another preventative measure in place was the discontinuation of System sending PMs to people who submitted feedback. I'm not sure when exactly this was changed, but it appears to have been a while ago. Basically, at one point System used to send confirmation PMs to people who submitted feedbacks. Administrators are the only ones who have access to System's PM inbox. It used to be technically possible for an admin to look at System's PM Outbox to see if she'd sent feedback confirmations to users. I have nothing to suggest anyone ever did this, and if they did it would have been long before my tenure as Admin. Regardless, this is no longer an extreme possibility, as System does not reply with feedback confirmations any longer.
Another now-closed "extreme" possibility was through certain access logs in the old site server, but our current server does not log anything related to the staff feedback page. Even then, those kinds of logs are not even visible to someone like me. I think only Noivern and Telinc can see them.
Now, there is one final way that I'll bring up that could be argued as a way we could still track users sending feedback. However, I do not consider this a legitimate way for us to keep track of who's sending feedback and therefore not something I would concern myself with. If that sounds dismissive of such a serious topic, let me explain further: If a user encounters some kind of error while attempting to send a feedback, the feedback will not send and an internal error would be logged on the site. In this very specific case, that person's username would be logged in our error reporting system, along with some details about where they were on the site when it happened. Please understand though, that this possibility is extremely unlikely, and not something we could intentionally abuse. I would consider this possibility a truly extreme edge case, where any user identification would be entirely unintentional, and would instead be an accidental result of our error reporting systems working as intended. Lastly, even if this error happened and a username was attached to it, the feedback would not be sent at the same time, meaning that there would not be conclusive proof that the person who eventually sends the feedback was the same person who encountered the internal error.
Finally, to speak to the part mentioning a comment from SNN on IRC at the time the system was implemented, that would have been around five years ago, long before any of the current administrators were promoted to their current positions. It could very well be true that there was some period of time in the past where staff feedback was not 100% anonymous and identifying data could be found through the database. I obviously can't speak to that possibility since I wasn't even a staff member back then. Either way, it is certainly not the case now.
From everything I looked into and was told about, I'd truly consider staff feedback to be anonymous, even at the deepest levels of the database. Telinc also mentioned to me that he'd be willing to share the entirety of the code that makes up the Staff Feedback page if anyone has any further doubts about its anonymity. I hope this explanation helps allay any doubts you and others may have still had.
Telinc also mentioned to me that he'd be willing to share the entirety of the code that makes up the Staff Feedback page if anyone has any further doubts about its anonymity. I hope this explanation helps allay any doubts you and others may have still had.
I think showing this actually would be a good thing! It would disprove to all the naysayers once and for all and satisfy anyone curious about the process.
Here is the complete code used for /?p=staff_comment. The Gist contains three files - staff_comment.php, which is the backend code, staff_comment.phtml, which contains the HTML view, and staff_comment_lang.php (actually called staff_comment.php, but Gist requires unique filenames), which contains the strings shown in the page.
Feel free to leave comments on the Gist if you have questions directly related to the code. Similarly to the screenshots of the User Feedback form, keep in mind that sharing something like this is highly irregular. Do not expect it to become commonplace.
Quick note that abuse of the staff feedback page will lead to a ban, especially if you create five feedbacks consisting of nothing but your username and then choose to make those feedbacks not anonymous.
[this is in reference to the current countdown banner having a link in it]
Originally posted by "Click here to read how to cast your votes."
Whoever came up with that idea is a genius
Thanks, I took a guess about whether or not [url] tags worked in site's countdown banners and it turns out they do. I'll probably make use of this fact more in the future to direct people towards events.