logo
 drop

Main

Community

Submissions

Help

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 ... 76
1
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

2
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:

3
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?

M-Tee:
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?

STARWIN:
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

4
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.

5
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.

6
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).

Quote
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)
    • ImprovementGame 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 rebalance 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)
    • AddendumHack Improvement: 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. Significant improvements that cause the hack to take on a new identity are exempt and may be submitted under the Complete category. Hack improvements intended to be game translations belong in the translation section.  (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.
    • Low Effort Hacks: Minor sprite changes, palette edits, text changes, or other seemingly low effort hacks may be viewed as incomplete and/or non-improvements. Descriptions should clearly demonstrate the necessity of, or non-trivial nature of such hacks to avoid unnecessary rejection.
    • Emulator Specific Hacks: Any hacks that are known to only run properly on a single emulator such as ZSNES or Nesticle only hacks.

 

7
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.

8
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.

9
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.


10
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.

Quote
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.

http://www.romhacking.net/translations/2590/
http://www.romhacking.net/translations/2335/
http://www.romhacking.net/translations/2612/
http://www.romhacking.net/translations/2656/
http://www.romhacking.net/translations/2604/
http://www.romhacking.net/translations/2518/

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.

http://www.romhacking.net/translations/2558/

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.

http://www.romhacking.net/translations/2671/
http://www.romhacking.net/translations/2607/
http://www.romhacking.net/translations/2617/
http://www.romhacking.net/translations/2618/

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

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

Original DS resolutions:
256x384
384x256
256x192
384x128

Single Screen images:
400x240
320x240

Dual screen images:
400x480


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?

12
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.

13
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'.

14
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?

15
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.

STARWIN

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?
http://www.romhacking.net/translations/2590/
http://www.romhacking.net/translations/2335/
http://www.romhacking.net/translations/2671/
http://www.romhacking.net/translations/2607/
http://www.romhacking.net/translations/2617/
http://www.romhacking.net/translations/2618/

These are in the 'Addendum' category for translations?
http://www.romhacking.net/translations/2558/
http://www.romhacking.net/translations/2656/
http://www.romhacking.net/translations/2671/
http://www.romhacking.net/translations/2612/

These are in the 'Addendum' category for hacks?
http://www.romhacking.net/hacks/542/

16
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'.

17
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.

Quote
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.

Quote
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...

Quote
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. :'(

18
Site Talk / Re: What's up with all the noncompliants right now?
« on: July 11, 2016, 06:23:43 pm »
Why couldn't you just let them all be on the site?

I was perfectly fine with them being here. I don't actively seek to remove anything. It was popehentai who explicitly removed them. I was just explaining the historical context of the guidelines when they were originally written, and how based on them, there wasn't much ground to reject popehentai's non-compliant submissions.

Quote
It was never anyone's intention to encourage you to remove as many hacks as possible, this was about illustrating an unreasonable rule that was not being enforced fairly.

popehentai's submissions have just shown that they are fairly enforced. Anything flagged as non-compliant with reasonable reasoning would be upheld. Again, I don't remove any hacks. All non-compliant flagging comes from the community. The only ones I ever submitted were duplicates or other such strictly maintenance based items. It's all public record.

That. I dont want anyone to get the wrong idea here. I was not intending for removal, i was trying to make a point for reinstatement.

You explicitly flagged and requested removal of all of those hacks. There's no other reason to flag non-compliant material. It seems your 'point' was entirely misdirected. Reinstatement certainly would never be the outcome of using the non-compliant submission maintenance tools. I hope you will rethink how to approach such things in the future that won't affect your peers in the manner this topic has. Perhaps raising a discussion on guideline clarification or proposed changes might be a more productive and peer friendly avenue.  :thumbsup:

Remember Zophars Domains hack section? All those hacks that were never completed and just were teasers.

ZD was definitely in mind when the guidelines were written. There are countless incomplete, bugged, or broken hacks out there far outnumbering completed ones. You definitely want to exclude becoming an archive for those in my opinion. Even with the restrictions at RHDN, I've been told a number of times that the bar is set too low here, and there are too many junk hacks already.

19
Site Talk / Re: What's up with all the noncompliants right now?
« on: July 10, 2016, 06:43:52 pm »
also there are several .01% complete translation patches from the 90s archived here  -- including some of my own.  it's kind of a different argument but IN GENERAL shows how arbitrary "complete" and "compliant" are.

The translation section has its own set of guidelines entirely and has no 'complete' component whatsoever...  :huh:

The guidelines are, in all seriousness, a little vague, but seem to be geared towards discouraging the submission of low-value and/or incomplete ROM hacks.  They can unfortunately be a little subjective, and the definition of "complete" can vary widely across different types of hacks, as well.  The hack of mine you reported for noncompliance, for example, cannot get much more complete than it already is; the purpose of the hack is to correct text errors in the NES version of the game based on the text of the versions from which it was derived, and there are not many of these.  (I actually have found a few more since submitting it, and will at some point update it once I'm confident I've caught everything; however, I have very limited time for ROM editing these days.)  Some of the FF6 bugfix hacks we have on the site literally change exactly one byte in the ROM, but this does not make them incomplete hacks; they accomplish exactly what they are designed to do, without any feature creep. 

You got it. :cookie: That was exactly the intention. It's deliberately vague for the reasons you've described. Unfortunately, the ratio of poor or unfinished hacks is extremely high and we do not want every hack ever made. You've also got it right with the established scope of the project. 'Bug Fixes' by definition have no minimum. They are completely functional even at the smallest level. 'Improvements' also generally also have no minimum. However 'Improvement' hacks MUST be in the spirit of an extension or enhancement to the original game. A new power-up, a new set of enemies, additional feature etc. Again, fully functional at the smallest level. If it's not in the spirit of an extension or enhancement the original game, it must be in the 'Complete' category and that is where subjectivity is most needed. You can start by using scope again as a judging factor. Does the hack's premise of change accomplish everything it set out to do throughout the entire game? If it does, that's great, but you still have to evaluate if the scope itself is enough to warrant adding. A 'Complete' hack really should have its own identity and shouldn't be a simple sprite hack, a 5 word text hack, or a gender neutral knock-off of the original game. It shouldn't be something that you did in 15 minutes. Those types of things are a dime a dozen and really increase the noise ratio.

I hope that clears up the intentions of the original guidelines. It's not an exact science and nobody is going to rule lawyer out every little thing, but I think what I've described above is fairly coherent baseline! :)

If the removal of my hack was in "good faith" so are these submissions. these hacks, the ones i and others listed (out of nowhere honestly, i know at least one of those guys i CERTAINLY didnt expect to be agreeing here) are not "in compliance". They are even less that the work i did that was removed. A precedent was set, for the amount of work required and those hacks do not meet that level of work. Replacing five instances of a pronoun, or swapping a palette, I am fully willing to take my lump. My hack was not "in compliance". Thats fine. All i'm asking for, in the "noncompliance" submissions, is that everyone else be held to the same standard i am being held to on this site.

You're correct, but don't confuse the different categories. See my response to Reiska above. Bug Fixes, Improvements, and Complete categories really aren't on the same judgement plane. The bigger problem for me with the gender neutral hacks are that they were submitted as 'Improvements'. However, they are not an enhancement or extension to the original game, and rather they go against what has been established already by the game with characterization of the main character. They should have been categorized as 'Complete' type hacks instead. However, then they are judged by scope and effort. Simply put, the scope is very low in effort along the lines of the sprite-only hacks. In the end, I don't think they, nor the helicopter hack belong here.

Nonetheless, I think both the helicopter and gender neutral hacks are sound base ideas to use for a larger hack and building something that establishes its own identity. Something like that would surely have a home here. :thumbsup:

20
Site Talk / Re: New/updated threads not marked as unread
« on: June 27, 2016, 06:18:24 pm »
Looks like Chrome's having a hard time finding one of the CSS files for the theme. Here's a screenshot of Chrome's debugger. I can confirm that the 404 on webkit.css shows up on pretty much every forum page.

Interesting find. I'm not sure why the forum is looking there for that. We didn't modify that file for any themes, and typically the forum falls back to the default SMF base theme files located elsewhere.

Nonetheless, I added what it is looking for. Any difference?

Pages: [1] 2 3 4 5 6 ... 76