Standardization will always be an issue regardless, because what some people consider a great standard might be an awful nightmare to others. A great example is that some people love the Git disassemblies, whereas others think they are shit to work with. The only thing that can be standardized with minimal complaints really are the label names and the addressing naming structure for RAM and such. When it comes to macros, splitting data and all that sort of thing, you'll never please everyone and you'll be pissing in the wind. It's the reason my S2 disassembly is sat half completed, because the feedback I was getting back was clashing too much to make informed decisions. In the end, I left it as something I was happy to work with and nothing else.

By sheer coincidence, I had the same idea as Markey where I was splitting all the major data for zones and grouping together in their own folder once split, and I even gave each object it's own folder containing all the code, mappings, art and such relevant to it. If people are interested I'll continue it, but I've got a feeling the reception will be as mixed as it is now with our current ones.

Click to expand...

Funnily enough, one of my prime complaints with the Git disassemblies are that they *don't* have any standard. Shit changes between them like crazy, no standard assembler, no standard macro operations, nothing. It's essentially a headless train, hoping that people hang on. It's not to say the Git disassemblies didn't bring some improvements with them; it's that the intent got muddled down into a mess that ends up alienating both crowds while finding an odd niche at the same time. Yeah, we'll never get 100% agreement on data splitting organization, but we can at least attempt to find a compromise of divide where a general consensus can work.

Honestly, the Git disassemblies have this problem where they try to be as ROM-accurate as possible, to the point that it becomes unfriendly to users. For research, that's all well and good, as the intent is to study and understand and document. To someone whose intent is to get in and modify, though, there's stupid hoops to go through because people pored over bit-for-bit accuracy to the point of assembler hackarounds and other engineering to make it assemble exactly as the original ROM. There's plenty room for disassemblies that try to be consistent in labeling and data division, as well as not being anal and self-defeating with perfect build accuracy. But this is something that requires a lot more proper discussion and hashing out to get in a more solid state, so I'll leave it there for now. I've really thought through the subject, though, and I'm sure others have as well, and there's plenty of space for a happy medium that bridges the divide between the old and new and make things forward-compatible.

I have a suggestion...remove the ability for people to change their usernames on the fly. While having a username history can help to keep track of who's who, it becomes bothersome when people abuse the feature constantly. As a compromise, make it so users can request staff or admins to change their usernames as the higher-ups see fit.

Click to expand...

I've mulled on similar, actually. The current username changing system is abused to crap, and it makes identification of users a total pain in the ass. This is unhelpful and unintuitive, and the feature may be steadily phased out entirely. We'll give word on a final decision regarding that, but your issues are pretty solid with the name-changing.

Well ok, a long time ago, I remember a lot of talk about replacing the old Pro Users group with a few groups, to emphasize on specific knowledge and contribution to the community, to recognize people for their specific talents, and to promote advancing the community and helping other people learn. While I've forgotten the exact details of this discussion (you could probably dig up pars from Discord logs), generally the idea was the create new groups for people good with; ASM, art, music, level design, and maybe something else I've forgotten. At the time I and few others thought it would be a good idea for the future going forwards, but it just never came. I've bugged Lazzie a few times and understandably he is quite busy, especially because of XF2 now.

There were also some other ideas floating around in the early days of XF integration that never came to be a reality, and I dont remember many of them off the top of my head unfortunately. Something that came later, was that XF just destroys tabs in the normal editor, and only in the text-only editor they are correctly preserved, and this is a major bug imo, considering that it is standard for assembly files to use tabs over spaces.

This may be an odd request. But I feel like should have been added. Add some god damn denuvo.

Anyway what I would like to see really is a customizable background for the forums. (Dunno if it's a thing that can be implemented or not.) Or customized themes instead of blue and white. (Not ones that you just get.)

This is minor, but would it be possible to make the time and date formats customisable? I'd really like to use the 24-hour format for the time, just like I'd like to use a sane order (e.g. day/month/year or year/month/day) for the date.