 |
| |
|
| |
|
| |
|
| |
|
| |
|
|
Dale
|
 |
Sir! Why do you keep clicking on me?
Dec 2000
time: 15:31
|
|
Wanna know how to read/write "shoruded" files? Take a look in the ctp2files/CTP/fingerprint folder and open shroud.c.......
quote:
/*--------------------------------------------------------------------------
Shroud module.
These functions are used to read from and write to "shrouded" files. A
shrouded file is an encoded version of some other file. A shrouded file and
its corresponding unencoded file are related in the following way: Each byte
in the unencoded file is transformed in value depending on its location in the
file. Hence, a shrouded file is identical in size to its corresponding
non-shrouded file.
A shrouded file is unreadable to any non-superhuman. One can use a shrouded
file in place of a file in which information must be hidden (and unalterable
in a controlled sort of manner) from an average user. For example, a
shrouded localized strings file will be unreadable and so the strings will
not be vulnerable to alteration. As another example, a shrouded image file
will be unreadable to any standard image viewing/manipulation program.
Since shrouding a file alters each byte rather than rearranging bytes, one
can use the functions in this file to read/write shrouded files and decode
them one byte at a time. For example, if you only want to read in the
BITMAPINFOHEADER from a shrouded BMP file, you need only to use shroud_seek()
to seek past the BITMAPFILEHEADER and shroud_read() to read and decode the
next sizeof(BITMAPINFOHEADER) bytes of the shrouded BMP file. Similarly,
shroud_write() will encode bytes as they are written to a shrouded file.
Futhurmore, these functions correspond to commonly used stdio.h functions.
So, when dealing with a shrouded file, one can make intuitive substitutions
in their code:
FILE *file ---> shroud_t *sfile
fopen( filename, "rb" ) ---> shroud_readopen( filename )
fopen( filename, "wb" ) ---> shroud_writeopen( filename )
fopen( filename, "ab" ) ---> shroud_appendopen( filename )
fopen( filename, "r+b" ) ---> shroud_updateopen( filename )
fread( buffer, 1, length, file ) ---> shroud_read( sfile, buffer, length )
fwrite( buffer, 1, length, file ) ---> shroud_write( sfile, buffer, length )
fseek( file, offset, origin ) ---> shroud_seek( sfile, offset, origin )
fclose( file ) ---> shroud_close( sfile )
So we can deal with shrouded files in nearly exactly the same way in which
we deal with any other file. The encoding and decoding is handled internally.
See the .h file for function declarations and descriptions of data types.
--------------------------------------------------------------------------*/ |
Looks like Ogre missed a few. 
|
|
| |
|
|
|
Dale
|
|
Sir! Why do you keep clicking on me?
Dec 2000
time: 15:31
|
|
More interesting stuff........ unencoding the data files.....
quote:
/*--------------------------------------------------------------------------
Encode 'length' elements of 'bytes' using 'operand' as the encoding key.
When used with shrouded files, 'operand' represents the offset of the the
first character of 'bytes' in the file. However, it is not mandatory that
'operand' be used this way outside of shrouded files...
In general, one can deduce the proper usage of encode() by accepting as an
axiom that the following two snippets produce equivalent results:
// this line of code...
shroud_encode( ptr , len1 + len2 , opr );
// is equivalent to these two lines...
shroud_encode( ptr , len1 , opr );
shroud_encode( ptr + len1 , len2 , opr + len1 );
--------------------------------------------------------------------------*/
void shroud_encode( unsigned char *bytes, size_t length, size_t operand )
{
unsigned char uc_operand = (unsigned char)(41*operand);
unsigned char uc_offset = (unsigned char)(operand/70 + 53);
unsigned char uc_count = (unsigned char)(operand%70);
while ( length-- )
{
/* If 'byte' is odd in value, adjust its value but still keep it odd
so that the operation is invertible.*/
if ( *bytes & 0x01 ) *bytes += 108;
/* Bitwise-exclusive-or 'byte' with 41 times 'operand.' 'operand' is
scaled so that identical adjacent bytes will be shrouded better. */
*bytes ^= uc_operand;
/* Every 70 characters will get a different value added to it. This way,
repeating strings in a given file will be endcoded differently depending on
their location in the file. Add 53 so that the leading characters of a file
will be altered. */
*bytes += uc_offset;
/* Get ready for next pass. */
bytes++;
uc_operand += 41;
if ( ++uc_count == 70 )
{
uc_count = 0;
uc_offset++;
}
}
}
/*--------------------------------------------------------------------------
Decode 'length' elements of 'bytes' using 'operand' as the decoding key.
When used with shrouded files, 'operand' represents the offset of the the
first character of 'bytes' in the file. However, it is not mandatory that
'operand' be used this way outside of shrouded files...
In general, one can deduce the proper usage of decode() by accepting as an
axiom that the following two snippets produce equivalent results:
// this line of code...
shroud_decode( ptr , len1 + len2 , opr );
// is equivalent to these two lines...
shroud_decode( ptr , len1 , opr );
shroud_decode( ptr + len1 , len2 , opr + len1 );
--------------------------------------------------------------------------*/
void shroud_decode( unsigned char *bytes, size_t length, size_t operand )
{
unsigned char uc_operand = (unsigned char)(41*operand);
unsigned char uc_offset = (unsigned char)(operand/70 + 53);
unsigned char uc_count = (unsigned char)(operand%70);
while ( length-- )
{
/* These operations undo what the operations in encode() did.
See shroud_encode() for comments. */
*bytes -= uc_offset;
*bytes ^= uc_operand;
if ( *bytes & 0x01 ) *bytes -= 108;
/* Get ready for next pass. */
bytes++;
uc_operand += 41;
if ( ++uc_count == 70 )
{
uc_count = 0;
uc_offset++;
}
}
}
|
|
|
| |
|
|
|
Peter Triggs
|
|
Gone Fishin, Canada
Jan 2000
time: 05:31
|
|
Because, IIRC, st_swithin said the operative pacman code had been commented out. And now all the comments have been removed. Otherwise it could have been uncommented and we'd see what it did.
|
|
| |
|
|
|
ahenobarb
|
|
Returning to the "getting our bearings" theme. Once we have a core group of people who can compile the code (about 5-6 public admissions at this point), the community can turn to the To Do list we developed a while back in this thread. Item 1, IIRC, is to lift the build in mod limits, which Immortal Wombat located.
So, if someone makes the necessary changes, lifts the 200 sprite limit and compiles a working version of the game. How do they get a copy out to everyone?
Last edited by ahenobarb on 31-10-2003 at 23:57
|
|
| |
|
|
|
Locutus
|
|
ACS CTP1/2 Manager & Civ4 Co-Manager
|
 |
Hengelo, The Netherlands
Nov 1999
time: 06:31
|
|
As far as lifting limits goes, someone will also have to look into lifting the 64 limit for buildings and wonders (probably similar to the sprite limit).
As for getting a copy out to everyone, I think it would be useful to fix more than 1 bug at a time, so we don't get new releases every hour or so As most software companies, we'll probably want to put out patches which fix a whole bunch of issues simultaneously.
A patch would presumably simply be a zip file with a new ctp2.exe (plus maybe other DLLs and files that have changed) and a readme explaining what the patch fixes (and containing the warning that it's not an Activision product, blah, blah -- as the EULA requires). So not much different from a mod really...
Edit: oh, since the patches will probably be pretty big (ctp2.exe alone is about 6 MB large, IIRC), the final release version of the patches will probably have to be built by me, so I can upload them directly to the Apolyton server (too big to attach in the forums, and probably soon gets too big for the upload feature as well).
|
|
| |
|
| |
|
|
|
Fromafar
|
|
I think the 'final' version (called ctp2.exe) is the actual release. It is almost as large as the original in the ctp_program directory. The difference must be caused by our removal of some sound library calls.
|
|
| |
All times are GMT. The time now is 05:31.
Apolyton Time is 00:31. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
29-10-2003 01:35
|