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.