Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nightcrawler

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 80
Site Talk / Re: Little feature request
« on: October 03, 2016, 07:41:14 pm »
Nothing has changed on this. It shouldn't matter because the site accepts BOTH three character or full month names. I don't know what form you're talking about, but I don't see any problems with this on any pages I have seen at present. There is indeed automatic fixing on fields that accept full dates when previewing. Partial date fields don't do this.

Calander support is unlikely in the near future due to poor support. There is no current way to do this without javascript. HTML5 tried to address this with a new date input type, but made calendar support for it browser optional. As such, Firefox, Safari, and IE do not support this at present. Perhaps this will change going forward.

Site Talk / Re: Hacks Guidelines Revision
« on: September 30, 2016, 09:40:32 pm »
I've taken a final pass at rounding these out to accommodate comments in this topic. I've gone back to the Addendum moniker and patch rule for M-Tee to avoid the foretold end of the community as we know it, but added the same reasonable exceptions and rules as the Translation section for consistency and sanity. I also kept the minor refinements in the other categories. Lastly, I've eliminated the subjective sprite only/low effort clause. I don't think it is the most appropriate way to achieve the desired results for some of the reasons vivify mentioned. The desired outcome can can be tackled from a different direction.

And with that, I quit working on this. I just tried to help and wanted some consistency. I never wrote these rules to begin with! I think these were Dragonsbrethren's (Yeah, I'm calling YOU out. Where have you been the past years? :P)

I think we assign a committee of Spinner, M-Tee, and STARWIN for any further changes. If they could all agree on something, it's bound to be something good! :laugh:

OK, last attempt to appease everyone after M-Tee practically ran me over for fundamentally altering the course of the site to throw us into an eternal spiral of darkness. A dark future where everyone's rights were gone, addendum patches could be applied in a single step, and that evil 'improvement' terminology wreaked havoc everywhere. Oh how it has haunted me since!

This basically puts everything back to the way it was, yet still retains reasonable exceptions and exemptions necessary to solve the immediate problems. We can still keep spinner's conversion hacks, we can still throw Danger X's patches in the Hacks section, every FF5 patch ever does not have to go in the Translation section, and we still retain M-Tee's general community ethics on Addendums. Whew!

This is effective immediately, and with that, I quit working on this! :P

RHDN accepts translations that fall into four categories.

Fully Playable: This is for completed projects where the patch is fully playable in the target language.
Unfinished: This is for incomplete projects where the patch is not fully playable in the target language.
Announced: This is for announced projects with no released patches yet.
Addendum: This is for cases where new person/s improve or fix old patches released from other people while promoting good community ethics. Archives should contain a patch that patches an originally patched work. This is for translation projects that fix bugs, or improve upon an existing translation project released from another author/s. The resulting patch is intended to also be a translation. Patches should contain addendum work only unless it is not possible due to the technical requirements of the patch (such as patches targeting a different ROM). Significant improvements that convert an unfinished translation to a fully playable translation are exempt and may be submitted under the Fully Playable category.

Special Note Addition:
General game hacks that may incorporate a translation, but are not intended to be translation hacks themselves, belong in the Hacks section.

The proposed guideline changes don't change anything in regards to user protection, user rights, or any such related items in my opinion. Submission reviewers have never been involved in policing people using other people's work or checking for individual submission permissions. Any involvement is limited solely to  file removal/distribution policy for being hosted here, which is user enforced anyway (compared to the early days when staff handled due to lack of public mechanism).

If you're implying this protection exists solely due to the previous requirement of cascading patches for Addendums, submission reviewers could not ascertain if the patch adhered to this anyway. It was non-enforceable. I think it is a bit silly to have non-enforceable rules that many weren't adhering to anyway. I really don't see anything being forfeit. I don't think there was anything there to begin with. :P

Site Talk / Re: Hacks Guidelines Revision
« on: September 09, 2016, 06:31:31 pm »
Hopefully Spinner will back soon to address some of these items as I feel like I'm fighting his battle. In the meantime, I can say you're right back to start M-Tee with all of the same problems everyone complains about that you haven't addressed well. It's just not practical to have all derivative patches as Addendums. In fact, it's generally NOT followed because of it, which is why you think there are only 34. There are actually hundreds of patches utilizing other patches with any type of permission unknown. Again, rehashing previous discussion...

  • What about most non-English translations? The vast majority are typically built from the English translation base. Nearly all of them are standalone patches. Under your rule, they'd all be removed from the site as they would have to be Addendums and need to be patches on top of the English translation.
  • What about hacks like Danger X's Bananna Prince hack that use an English translation as a base, but is not even a Translation. Again, under your rule, it should be an Addendum and patched on top of the translation. It's an addendum to a translation, but it is a hack. Does it go in the Translation section where nobody will look for hacks? Or does it go in the Hacks section where now you have cross sectional patching necessary. Danger X has taken great offense to it simply not being allowed in the Hacks section as a 'Complete' patch, which most people would agree on.
  • What about existing Improvement or Bug Fix patches? Would any hack EVER that uses any of these small patches be an Addendum to it? Or, what about if it uses multiples ones? What is it an addendum to? That's just crazy. There's 127 FF3/6 SNES hacks for example, many of which use a multitude of small improvement or bug fix patches without expressed permission.
  • As stated by Spinner, any FF5 hack ever would probably be an Addendum to the English translation patch.
  • No submission reviewers can enforce the cascading patch rule. There's no way to know short of patching every single submission yourself, which nobody is going to do for thousands of submissions. Making rules you can't enforce in any way doesn't seem like a good idea.

The proposed changes for both sections addressed every one of these in a way that makes no real changes. Instead of conforming people to the guidelines, it conforms the guidelines to the ways people are already trying to and want to use those sections and categories!  :thumbsup:

Site Talk / Re: Hacks Guidelines Revision
« on: August 29, 2016, 05:40:38 pm »
Text-only hacks that require minimal effort... I consider that extremely broad, to be honest. Being frank here, it sounds to me like text hacks could be rejected no matter what, depending on how a moderator feels about you or your work. Putting text in proper case is something I consider pretty important for readability's sake, but under the new rule, I'm pretty sure they'd be considered "low effort." Would my text cleanups, then, that remove various typos also be considered "low effort"? Or what about complete text re-invigorations?
That's a valid concern. There is no intention of excluding something like a proper case hacks, typo corrections, or complete text re-invigoration. That clause was intended for submitted hacks that only change a few words, or replace a character's name throughout the game with 'vivify93', or changing Mario to blue for no reason, or replacing Mario with a one frame glitched rectangle sprite, etc. There must be a clause that prevents such hacks. People try and submit all kinds of junk daily. Sadly, the noise ratio is high enough already.

The idea is such hacks simply need to substantiate themselves in the description. That can be done by noting reasonable necessity for having the trivial hack, or explanation of any non-trivial nature of the hack. It's not intended to widen the scope of exclusion, rather rephrasing existing exclusion. Do you have a better way of expressing that idea through the guidelines?

I linked to that topic because these very issues were already recently discussed, and the consensus was the current addendum system did not make sense for various good reasons presented there. I don't know why you did not take part in that discussion if you so strongly disagreed with Spinner8, MathUser2929, Zynk, jink640's expressed sentiments against the addendum cascading patch rule. This topic simply incorporates the result of that topic for guideline consistency. Also, the Improvement category has already been around for many years. Why is this a new issue? I don't see any of those types of objectionable improvements in the 'Improvement' section OR the 'Addendum' section. Such examples aren't in the spirit of the original work and wouldn't even be allowed. If we don't have that problem now, why would it start?

I really don't know what you want. It seems like you want full-on back peddling now from what the others wanted. You don't have to convince me of anything. I don't really care what it's called, or how it's patched. I'd concede to any consensus reached on those items. What I care about is the guidelines being 1.) consistent between the two sections 2.) simpler to understand for patrons, 3.) simpler to enforce for reviewers (enforcing cascading patch rule is very difficult by the way), and 4.) consensus by the lot of people complaining about it from both sides! We don't want to do this again for the FOURTH time next year! There needs to be a majority consensus, and it needs to be upheld and followed. What do you suggest be done to achieve that?

The goal was making Hacks guidelines consistent with the Translation section's recent guidelines changes (including rulings on hacks of hacks). I'm not really sure what you're suggesting the guidelines be changed to beyond abolishing all categories and extending the modification check boxes, or restructuring the whole section and database. We're just adjusting the guidelines for what we have, not drafting a new interface and database structure. This is a text based project. :P

General Discussion / Re: Password problems
« on: August 29, 2016, 04:59:19 pm »
I think it's a cookie issue. If you can't, or are unwilling to enable cookies in your browser, you will have to create an account here and log in. Being logged in would eliminate the password requirement.

Site Talk / Re: Hacks Guidelines Revision
« on: August 28, 2016, 11:04:12 am »
Yes, contributing members are altering the content of others, but at least by requiring the patch, we're sending the message, "only redistribute what you've created." (Even though relocated data and the copying of data from other games, etc. prevents that from being the actuality.) The addendum patch rules, in theory, extends the "don't distribute the work of others without their permission" message to other members, not just game companies large enough to afford legal action.

It was established in this topic with the translation guideline revision that people don't want those addendum patch rules anymore. Spinner pointed out for example that some 'Addendum' type hacks may alter hacks in a way that makes them applicable to a different ROM than the original! In such cases, the cascading patching requirement really doesn't make sense.  Such items are to be extended to the Hacks section for consistency and easier classification across both sections. The Improvement terminology originated from STARWIN's posts in that topic as well. The term implies all hacks in the section were intended to be improvements (in the spirit of the original work) by the creator.

Site Talk / Hacks Guidelines Revision
« on: August 27, 2016, 12:36:48 pm »
In accordance to the recent revisions of the Translation section guidelines, a similar treatment should be made to the Hacks guidelines as far as eliminating the 'Addendum' category and making reasonable exceptions where needed. I also took this opportunity to make a few other edits to better reflect the guideline intentions. (HTML such as the Example links are omitted here).

RHDN accepts hacks that fall into five categories. If your hack falls into more than one category, choose the one you think best represents the purpose of your hack.
    • Complete: A hack that completely changes one or more aspect(s) throughout the entire game (levels, graphics, text, etc.). A Complete hack has its own identity and an established premise of change applied throughout the entire game (levels, graphics, text, etc.). It should not appear as a minor variation of the original game, nor contain partially implemented ideas. For instance, a complete graphics and level hack would consist of most or all graphics and levels changed. (Example)
    • Spoof: Complete Hacks that specialize in humor, usually being parodies of the original game. They also frequently contain adult content. The same rules apply to them as do Complete hacks. (Example)
    • Improvement: These hacks improve on some aspect of the original game, while leaving the majority of the original content intact. Game Improvement hacks must be in the spirit of an extension or enhancement to the original game. An example would be a hack that adds a new powerup to a platformer, or a new magic spell in an RPG. Improvement hacks are often ones intended to be used as a base for other hacks. While hacks that re-balance difficulty or modify game mechanics may be considered improvement hacks, those that apply simple cheats (infinite lives, invincibility, game genie or pro action relay codes) are considered out of scope for RHDN. (Example)
    • Bugfix: A subcategory of Improvement for easy filtering; these are Improvement hacks that only fix bugs in the original game. This covers code, data and/or graphical fixes. (Example)
    • Addendum: A hack of a another person’s hack to completely revamp it, improve the hack, or fix a bug. This should not be submitted as a patch for the original game so proper credit and community ethics are observed. A hack that fixes bugs, improves upon, or revamps another author's released hack. The resulting patch is intended to be a non-translation hack. Patches should contain addendum work only unless it is not possible due to the technical requirements of the patch (such as patches targeting a different ROM). Significant improvements that cause the hack to take on a new identity are exempt and may be submitted under the Complete category. (Example)

The following types of hacks are not accepted:

    • Demos/Alphas/Betas: Any incomplete version of a hack, usually given out well before the final version is ready, for feedback or other purposes is not accepted. You may post such hacks on the forum.
    • Texture Packs: Commonly made for Nintendo 64 games, and consisting of new textures which will be loaded in place of the originals. Actual texture hacks are acceptable ( as long as they are complete ), however these packs are not.
    • Sprite-Only Hacks: Typically single or few sprite only hacks are considered incomplete and/or non-improvements, and will not be accepted (Think Naked Mario hacks). Extensively difficult or artistic sprite hacks however may be considered.
    • Emulator Specific Hacks: Any hacks that are known to only run properly on a single emulator such as ZSNES or Nesticle only hacks.

The proposed guideline changes have now been adopted and implemented. :)

Items pointed out in this topic can now be corrected accordingly. I submit corrections for a few that did not need to change sections. As stated, there is no way to convert between hacks and translations. So, for those cases, you would have to submit the new section's entry, then flag the old one as non-compliant with link to the new one in the reason.

Programming / Re: Snes division
« on: August 21, 2016, 11:35:20 am »
I think Yoshi's docs are some of the oldest on the Internet, so they may not be the best reference. :)

Definitely not the best reference today. I think I mentioned that to you before, jonk.

You guys should be using the following. The information on the division registers and their use is correct in both.

1. Anomie's docs (Anomie’s Register Doc specifically for this case)
2. nocash's documentation (Original source in case there has been any unreported updates).

You can of course poke around in the BSNES/higan source code, but that's only of any value to those well versed in C++ and structure presented.

Rereading, you didn't say that putting the games in the improvement category was a policy, just listed those as examples. In which case I think Banana Prince 2 should be a Complete category, and a Source Translation field could still be useful.

Correct. The revised translation guidelines merely makes sure such hacks don't belong in the Translation section. In the hacks section, they would go in whichever category is most appropriate there. Bananna Prince 2 indeed probably does better belong in the 'Complete' category.

It's clear few people are interested in any detailed solution discussion, so I'm not going to spend much time on this. I want to keep bug fixes and improvements to translations, intended to be translations, in the translation section. It makes no sense to me to go looking in the hacks section for updates to translations.

I propose the following translation guideline amendments. I think this will address the main concerns brought up here.

RHDN accepts translations that fall into four categories.

Fully Playable: This is for completed projects where the patch is fully playable in the target language.
Unfinished: This is for incomplete projects where the patch is not fully playable in the target language.
Announced: This is for announced projects with no released patches yet.
AddendumImprovement: This is for cases where new person/s improve or fix old patches released from other people while promoting good community ethics. Archives should contain a patch that patches an originally patched work. This is for translation projects that fix bugs, or improve upon an existing translation project released from another author/s. The resulting patch is intended to also be a translation. Significant improvements that convert an unfinished translation to a fully playable translation are exempt and may be submitted under the 'Fully Playable' category.

Special Note Addition:
General game hacks that may incorporate a translation, but are not intended to be translation hacks themselves, belong in the Hacks section.

With these changes, the following classification would occur for those items mentioned in this thread:

These would be categorized in the 'Improvement' category of the Translations section.
These hacks fix bugs or improve upon an existing translation project and are intended to be translations.


This would be categorized in the 'Fully Playable' category of the Translations section.
This hack improves upon an existing translation project and are intended to be translations. However, this one has the significant improvements that convert an unfinished translation to a fully playable translation exemption.


These would be categorized in the 'Improvement' category of the Hacks section.
These hacks, while incorporating a translation, do not intend to be translations themselves. Per the special note, they should go in the Hacks section.


How's that? If you disagree (other than minor point), please propose the new guidelines, new resulting classifications, and reasoning.

Site Talk / Re: 3DS Utilities
« on: July 30, 2016, 11:23:08 am »
OK, thanks. We've added 3DS with:

Original DS resolutions:

Single Screen images:

Dual screen images:

Perhaps we should get rid of the original DS resolutions. Are they accessible in any way by 3DS software? My understanding is DS games are either scaled to the native resolution, or displayed with black bars in their original DS resolution. It doesn't seem like the 3DS actually has support for the DS resolutions and it's just a matter of how it is scaled to native 3DS. Comments?

Programming / Re: VRAM question...
« on: July 30, 2016, 10:57:30 am »
You've found the location of the graphics in VRAM. There is no direct correlation to where those graphics came from in the ROM. All graphics are loaded into VRAM through the VRAM registers $2118/9. These registers could be written to via DMA (most likely), or manual copy routines. The source data may not have even come from the ROM at all if the data was decompressed or buffered. In those cases, they would have come from RAM (and you'd have game code you would need to reverse engineer).

In summary, if you can't find the graphics in the ROM by looking in a tile editor, you're going to have to spend much time learning about the hardware registers on the SNES, and how to use a debugger to back trace how the data you're interested in got there. That's well beyond what I can explain to you in this post. It's simply not quick and easy.

Site Talk / Re: 3DS Utilities
« on: July 28, 2016, 06:07:14 pm »
We need to know all of the valid resolutions of the 3DS before we can add it. I assume to start it has the DS resolutions which are '256x384', '384x256', '256x192', '384x128'.

1. What does "G source" mean?

2. You didn't provide what category they would go under for the section you call out for them. I really don't understand what categories they'd all be going in.

3. Earlier, it was advocated that there would be no requirement for the patch. If a patch is not required to be cumulative or not-cumulative, and that is critical for determining which section is belongs in, that is not information that is going to be able to be quickly surmised by a submission reviewer.
4. It seems you want any translation addendum patch that fixed repacked, or updated any previous patch appear equal in status as the originating patch as 'Fully Playable' or 'Unfinished'? For example, if I fix an Aeon Genesis patch like Orden did, then my patch should simply in equal standing to the original patch and appear as another 'Fully Playable' translation for Shin Megami Tensei? I'm not sure Gideon or other authors would like something like that to occur. They should chime in if they read this.

This does not seem very clear and simple categorization to me. Do you understand what's going on Zynk?

Could the option to ADD CREDITS be included within the Submission Form?
I find it quite odd that we have to add the Credits AFTER the submission has been aproved.

This could help out greatly for the overall submission form.

See this topic. Unfortunately, we can't do that any time in the near future.


Let me get this clear.  We'd still keep the 'Addendum' categories in both the Hacks and Translations sections, right? Then, the only real change is making it so that all hacks that modify a fan translation (that are not themselves intended to be translations) should be added to the Hacks section under the  'Improvement' category? Can you just run down the list of hacks brought up in this thread below and quickly categorize them?

These should be changed to the 'Improvement' category of the Hacks section?

These are in the 'Addendum' category for translations?

These are in the 'Addendum' category for hacks?

Personal Projects / Re: Oracle of Ages VWF Edition
« on: July 14, 2016, 05:53:54 pm »
The system only cares if the screenshot's link ends in a .jpg extension. It doesn't check the resolution.

Complete fabrication. Don't take any advice from this guy. He has no idea what he's talking about. He's so far off base, he's not even playing in the same ballpark. ::)

The REAL Answer

The system checks for all known valid resolutions for all consoles in the database. Turns out there was bug introduced the last time the console lists was re-organized to official names. Some consoles weren't being processed correctly. It should be fixed now. And of course 'JPEG is not recommended as it reduces the image quality'.

I don't like the rule that addendum patches can only work on a pre-patched ROM. Why make the end-user jump through hoops to get a game they want to play? As long as proper credit is given, who cares? Has anybody complained? It's ridiculous. Besides, some of the addenda I've made recently don't apply to this rule, because they're intended for different ROMs than the original translation (Famicom Wars, Tales of Phantasia).

I'm fine with that. I think people did complain back in the day, and it was thought of as better ethics at the time. However, we didn't have the credit system that we do now back then. So, that's probably an obsolete point now. Also, there is the case for having addendums not being tied to a particular version of the base hack. That was brought up somewhat recently actually (can't recall where).

We can probably make new topic and take a vote on this. No objection from me.

And I'm sure there will always be edge cases, but I think a distinction should be made between "a hack of a game translation" and "a hack of a game that happens to be translated".

Sure. What are your proposed revised guidelines? Make them black and white enough for Zynk or he'll explode and quit after all the headaches this classification has given him! :laugh: This may be a more difficult task than it first appears. There has been numerous discussions and disagreements on this topic.

Really, if we take this rule through its natural course, any ROM hack of a translated game, ever, would be considered a "translation". Are we never going to have any FF5 hacks, unless they can be applied to the Japanese ROM? I'm really not sure why this rule change was made in the first place.

I think it was made because it was equally ridiculous to look in the Hacks section for third-party updates to older translation patches. Then there were the retranslation patches submitted in the Hacks section. Then there were translations of hacks trying to be put in the translation section. There was a whole cart load of stuff in the Hacks section that belonged in the Translation section. Zynk can probably add more here. So, it ended up at something that was pretty cut and dry on where something goes with Addendum's in both sections. It's just not necessarily as ideal or logical as we'd like.

I'd say be very careful about trying to put that cart load BACK in the Hacks section. Some scrutiny and care on any exceptions made is definitely needed. There is no direct conversion between hacks and translation either because nobody wanted me to combine the Hacks and Translations section to best fix these problems. I always thought translations were just a specialized category for Hacks...

I don't know why every entry doesn't have a list of addendum hacks below it (if applicable), making it really easy to tell what's out there. As it is, people don't know about these addenda unless they're specifically looking for them. Plus, on each addendum page, you could have a big section that reads "Requires [such and such hack]" that links back to the original.

I'd like that too, but that information doesn't exist. One time I was going to add some more fields for this, but then I found people added Addendums to the site for base hacks that weren't even on the site! Then, some refused to add it when asked. People are so lazy... I know there were also some Addendum entries where you don't even know what it's for because it's not even linked in the description (have no idea how such stuff got approved...).

I had no way to even get the data to link many of them together so I quit on that! As it stands it's sadly not possible to do what you suggest. :'(

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 80