Banner
Views: 865,428,046
Time:
15 users online: Arcten, Cascade, Drippz85, FrozenHydra, IcyFruit, Infinity, Isikoro, kamekku14, KitikuSa,  Lazy, MasterMario97, NewPointless, Nirv, Siidney, Yagami - Guests: 46 - Bots: 69 Users: 47,950 (2,095 active)
Latest: TheDarkBozzz
Tip: Press F2 on the level editor to see sub-screen boundaries. This will help you avoid glitching Dragon Coins by putting them on the sub-screen boundaries.Not logged in.
SMW ASM Guidelines Update
Forum Index - Important - Announcements - SMW ASM Guidelines Update
Pages: « 1 » Link
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.
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.
Pages: « 1 » Link
Forum Index - Important - Announcements - SMW ASM Guidelines Update

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2020 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy