Language…
9 users online:  dacin, DimeR, Isikoro, KaidenThelens, mason, Odyssey K., RetroJunky.T, Rykon-V73,  Segment1Zone2 - Guests: 91 - Bots: 209
Users: 65,846 (2,175 active)
Latest user: HugsNotDrugs

SMW ASM Guidelines Update

As a response to the feedback sent regarding the ASM sections and due to the fact the old rules were dated, the ASM team has decided to restructure the guidelines of every SMW ASM section.
Major changes include:
  • General: due to the fact that most sections' rules were similar, we grouped a bunch of guidelines into a "general" section that will display when attempting to submit to any section.
  • Blocks: simple blocks will begin to be accepted. We are also going to enforce a standard for the Acts Like field.
  • Sprites: PIXI is now specified as the only tool for which we'll accept sprites; temporarily we'll stop accepting overworld sprites due to it not having support yet.
  • Patches: we put recommendations on when to make a resource UberASM code instead of having it as a patch.
  • UberASM: when submitting patches which have hijacks, a clean patch will be obligatory. This so the user can safely remove the resource from their ROM.
Expect small tag updates over the next few days.

If you want to check the guidelines:









There’s a problem with #1 on “General SMW ASM Section Submission Guidelines”, what happens if the author is inactive and there’s a bug in it found by someone else?
Give thanks to RPG hacker for working on Asar.
Originally posted by GreenHammerBro
what happens if the author is inactive and there’s a bug in it found by someone else?

I'll look into amending it that updates to a user who has been inactive for a long time are allowed regardless of permission.


As I mentioned in the OP regarding new tags. We have added the lorom tag to submissions, with the purpose of actually being able to catalog SA-1 only or Super FX only submissions in a better way. For now, all submissions have it, but be sure to report if any submission which isn't compatible with a normal ROM has it.
Originally posted by Erik
Originally posted by GreenHammerBro
what happens if the author is inactive and there’s a bug in it found by someone else?

I'll look into amending it that updates to a user who has been inactive for a long time are allowed regardless of permission.

Thanks, also not just bugs, but improvements, sometimes the readme is poorly written. The update for the overworld borders plus, for example have its readme contents more easy to understand. Not to mention, it requires an n number of bytes + 2 for handling the frames to update the tiles and knowing when it shouldn’t write when the other byte is nonzero. This information wasn’t mentioned until I updated it.
Give thanks to RPG hacker for working on Asar.
I'd also like to note that, as for Blocks, having simple submissions in the other sections wouldn't hurt too. Probably applicable to the UberASM section mostly, where simple codes can be very useful for people who doesn't know how to ASM. I'm sure simple codes are already a thing in the UberASM section, but also seems to be missing as a guideline by itself.
Layout made by MaxodeX
2021 TRENO vibe check thread
Originally posted by Shiny Ninetales
I'd also like to note that, as for Blocks, having simple submissions in the other sections wouldn't hurt too. Probably applicable to the UberASM section mostly, where simple codes can be very useful for people who doesn't know how to ASM. I'm sure simple codes are already a thing in the UberASM section, but also seems to be missing as a guideline by itself.

There isn't really guidelines that enforce the removal of simple code; it's more of an unwritten rule. That being said, from now on resources which consist of simple code (say, two or three lines) in any section will begin to be accepted as long as they're not niche/overly specific usecases.
As for the patches section and hex edits, expect something regarding them soon.
Originally posted by Erik
As for the patches section and hex edits, expect something regarding them soon.

You misspelled [Soon™]. So! Patch Submission Guideline #2 had stated:

Originally posted by Old Patch Submission Guideline #2
  1. Your patch may not consist exclusively of simple hex edits.
    Patches that solely apply one or more hex edits are better posted here or submitted to the ROM Map.

This rule was prematurely put into effect in anticipation of a more refined means of hosting hex edits. This feature still being a ways off, we're shifting this rule back around to actually make some sense given what we have right now:

Originally posted by New Patch Submission Guideline #2
  1. Patches that consist exclusively of simple hex edits must be of sufficient functional depth and must be marked with the
    hex
    edits
    tag.

    Generic singular edits such as "modify Banzai Bill's X speed" are better posted in the ROM Map.

Very generic hex edits such as "change tiles used by Ninji" or "change L/R scroll SFX" are still better suited to the ROM Map for the time being, but a coordinated series of hex edits such as this or this may now be submitted to the Patches section (so much so that I've gone ahead and submitted them). If submitting a patch that consists only of hex edits, please assign your patch the hex edits tag; if submitting a patch from the Hex Edit Repository, we would appreciate it if you would also make note of this fact in the submission notes. Hex edit patches will not be documented in the Hijack Map. Thanks go out to Tattletale for questioning the oddity of our former no-hex-edits-allowed policy.

While we're at it, the Block Submission Guidelines are also gaining a new rule:

Originally posted by New Block Submission Guideline #4
  1. The value of RAM address $0F must be preserved and restored if used under the SpriteV or SpriteH labels, unless modified deliberately.
    This scratch RAM address is used by the sprite/object interaction routine that runs after GPS runs its code; failure to preserve $0F can cause interaction bugs.

Thanks go out to Hammer Brother for pointing this one out. If anyone happens upon any blocks that alter $0F under the SpriteH or SpriteV labels without restoring it afterwards, please notify an ASM Moderator. Note that GPS itself has no issues in this regard - as of GPS 1.4.1, the only subroutine that alters $0F is %change_map16, and it does in fact preserve $0F.

These and other section guidelines are now viewable outside of submission pages in the Moderation Questions forum should you care to peruse them:

General / Blocks / Sprites / Patches / UberASM / ROM Map / RAM Map / Hijack Map / Tools / Documents

That's all for now! If anyone has any questions, feel free to respond here, or to reach out to the ASM staff.
A few ASM guideline additions and alterations are going into effect. Nothing wild, just some clarifications and common sense stuff.

First off, I apparently never posted about the "new" General SMW ASM Submission Guideline #9 (now #10) that was added quite a while ago:

Originally posted by New General SMW ASM Submission Guideline
  • Your resource may be gently modified during moderation.
    A moderator may make very small technical changes to a submission, generally to fix small errors that lead to a bug or crash as discovered during moderation (for example, a missing SA-1 conversion). This is done as a courtesy to spare the author the effort of resubmitting after making a trivial fix. Any changes made are documented by the moderator in a comment on the resource and may be freely challenged by the author(s) if desired. Stylistic changes or changes that alter the core function of a resource will not be made in this way.

Next up, General SMW ASM Submission Guideline #1 - which addresses author permission for updates - has been revised to better clarify the general acceptability of technical updates. This guideline has led to some confusion in the past, so we're hopeful this update makes our stance clearer:

Originally posted by Current General SMW ASM Submission Guideline #1
  • If you are not the author of a resource, do not submit it without permission.
    Updates to another user's work will be refused without explicit permission (outside of special remoderation projects). Submitting a resource on behalf of a banned user is forbidden.
Originally posted by Updated Guideline
  • If you are not the author of a resource, do not submit it without permission.
    Explicit permission is required to submit a resource on behalf of another person, user or not. Submitting a resource on behalf of a banned user is forbidden. Technical updates to fix bugs or improve the usability of an already-hosted resource may generally be submitted without author permission; changes that alter a resource's style or core function(s) require permission from all active authors. See Site Rule C1 for further details.

General SMW ASM Submission Guideline #6 (now #7) has been expanded to require that all of a submission's included files are relevant and set up for convenient use by the end user. The new terms are, or at least should be, pretty obvious in practice:

Originally posted by Current General SMW ASM Submission Guideline #6
  • If your submission includes a palette file to be inserted with Lunar Magic, ensure it is of the .palmask format.
    .palmask files are used as to only replace the needed colors in the palette.
Originally posted by Updated Guideline
  • Ensure that all files included with your submission are ready to use as provided.
    Palette files should be of the .palmask format. GFX files shouldn't contain any unrelated graphics, and your resource should by default reference all included graphics as submitted. If your resource includes a sample level, it should reference any ExGFX or other files as named.

Finally, a new General SMW ASM Submission Guideline has been added, placed between current guidelines #4 and #5 (now #4 and #6). This new guideline sets forth a common-sense request to include simple, demonstrative .gifs or screenshots when submitting a resource. The main takeaway is to avoid submitting images that contain irrelevant stuff - if you're showing off a modified coin block, for example, don't do so using a custom player in an elaborately decorated custom level. Not only does this distract from the demonstration, but it can also heavily bloat .gif size, which can be a meaningful detriment to users with slower internet connections or metered data usage.

Originally posted by New General SMW ASM Submission Guideline
  • Please include a simple screenshot or (preferably) .gif with your submission demonstrating your resource in action, if applicable.
    Demo images should ideally offer an easily understood depiction of how the resource behaves, and should exclude extraneous elements such as elaborately decorated levels, unrelated sprites or abilities, etc. Submitting more than one .gif/image to demonstrate the complete function of your resource is highly encouraged (sprite extra bit differences, fix patch before/after behavior, etc.). Images are unnecessary for resources with no visual component.

That's all for now! Feel free to ask any questions in this thread, or reach out to the ASM Team directly if you wish.
On submitting .gif screenshots, I think it would be of the general interest to recommend some tools that can record them, since a lot of people don't know how to do that. I personally use LICEcap.
I also have to mention Mesen for this which has an in-built GIF recorder (same place where you can record a proper video) while sacrificing none of the quality.