[meyriu]

Hey, sorry if this post sounds stupid, but i really curious about four digit number left under this Hexadecimal guide by staff Neil
http://www.romhacking.net/documents/183/



" 6964 "

i tried to treat 6964 as decimal number and convert it to hexadecimal

6964/16=435 remainder 4
435/16=27 remainder 3
27/16=1 remainder 11
1/16=0 remainder 1

then that gives me 1 11 3 4 = 1 B 3 4
* 11 is B right?

oh where did i go wrong? because 1B34 doesn't make any sense to me?
or was 6964 is author fav number that he puts there to 'mark' his guide?

* i am new here, i just read hexadecimal guide by Neil , but i cant proceed until i know what is this 6964 ~ so curious  *

[BlackDog61]

Calc (in programmer mode) confirms your conversion is correct: decimal 6964 = hexadecimal 1B34.
And 11 decimal is B hexadecimal, indeed.
Don't ask me why that number was chosen, though.

[meyriu]

lol i guess maybe there's no secret message or anything to this number xD

[Revenant]

It's not just that guide, RHDN seems to append numbers to the ends of a bunch of text documents and I don't really understand why

[Nightcrawler]

What basis do you have to make such a claim?

I can tell you this file has not been modified since the last edit upload by Neil in Oct. 2009. The modification date on the server matches precisely. If this site has ever appended anything to a text document (which it never has to my knowledge), it would have been in gross error upon file handling many years ago, and nobody reported such occurrences.

I am certainly interested in what afflicted 'bunch of text documents' you know about and neglected to report.

[Revenant]

Both of the documents on RHDN under my name (uploaded 2012-2013) exhibit it, and if I play around with document IDs I can find some other plaintext documents uploaded around the same period of time that do the same thing:

http://www.romhacking.net/documents/627/
http://www.romhacking.net/documents/639/
http://www.romhacking.net/documents/641/
http://www.romhacking.net/documents/647/
http://www.romhacking.net/documents/659/

Since the document in the OP is from 2009 I assume there are probably a lot more to be found, and I don't remember if I ever stumbled on any others myself at any point (I had completely forgotten it even happened, or else I would have said something already )

[KC]

It looks like it's the file size, excluding the number.

[Jorpho]

Hmm, http://www.romhacking.net/documents/658/ has it too.

I checked http://www.romhacking.net/documents/657/ with a hex editor, and it doesn't look like it has an ASCII number appended after the end of the archive, at least.

[DragonDePlatino]

Maybe this is all some sort of mysterious message coded inside RHDN documents! 

Someone should write a program that takes all these documents, organizes them by date, converts the ending hex numbers to letters and then forms a message out of it!

[Nightcrawler]

Wow... This is one of the strangest things I've ever seen. KC is right, it's the filesize. I don't know how this can be possible. We don't store, calculate, or utilize filesize anywhere in our code for Documents. Our file retrieval is universal to all files on the site too. Readme files, which are also plain text don't seem to be effected and they go through the exact same code. We don't do anything but use PHP's URL wrapper and file_get_contents(), and fwrite() to retrieve and save.

This may still be happening if this entry is any indication:
http://www.romhacking.net/documents/679/

I'm at a loss...

[STARWIN]

Are they all single files that are .txt?

Are documents submitted by uploading them to a third-party site?

Perhaps some third-party site adds that number either when uploaded to, or when this site fetches the file?

I also noticed this long ago, and as probably many others, thought that it was by design somehow.

[Nightcrawler]

I've fixed it!

The problem wasn't with the files at all, but rather the HTTP header/download request sending of the file. We were using 'echo readfile()'.  readfile() writes the file automatically to the output buffer and doesn't return the contents. So by appending it with 'echo' it spits out the file and the return value, which is the bytes written. It's only seemingly visible on text files (browser must ignore it on binary files). I'm sure I had file_get_contents() on the brain, which returns the file as a string.

That's definitely a several year old bug. Thanks for bringing it up so it could be fixed. I wish it has been brought up a few years ago!

[STARWIN]

Scratchpad is still affected.

[Nightcrawler]

Thanks. Similar borrowed code. Fixed.