GENERAL: lets get are Bearings

The Big Mc · October 28, 2003, 16:35

i just logged into apolyton five minuets ago we now have the source code and a new forum

we have to thank locutos no doubt for 1/2 if not all of the forum work and a hole lot of people for the code so i decided to set the tread of so we could thank people

chock choke not the activision layers choke choke

Solver · October 28, 2003, 16:41

Hehe... of course, we have to thank Activision. They decided to release the code, even though they get no profit for it, for a game that they officially ceased to support.

And, the big thanks go to everyone who was in contact with Activision, and to all of ex-Activisioners for posting on the forums!

Maquiladora · October 28, 2003, 16:44

Big Mc your typing cracks me up

Aside from the people thanked in the CTP2 news item it was mentioned that Big Mc should get some thanks for pestering Activision

The Big Mc · October 28, 2003, 16:52

yes but I still want what I started out for my beta walker

centrifuge · October 28, 2003, 16:53

Quote:

Originally posted by Maquiladora
Big Mc your typing cracks me up

Aside from the people thanked in the CTP2 news item it was mentioned that Big Mc should get some thanks for pestering Activision

Absolutely, I think that his original thread, may actually have give the bal that little bit of a nudge..

Edit: that makes absolutely zero sense

"given the ball" ... in order to get it rolling... umm huh, oh never mind

Tamerlin · October 28, 2003, 17:47

Many thanks to The Big Mc who in a way initiated all this and to all the modders without whom there would not be any CtP and CtP2 communities on Apolyton, these games are living because you are modding and improving them.

I think we can also thank the creators and administrators of the Apolyton CS who are supporting turn based games since many years with the seriousness and dedication we all know. I am sure that the fact the call to release the Source Code came from Apolyton has heavily weighted the balance in our favor.

Ekmek · October 28, 2003, 17:49

here here

centrifuge · October 28, 2003, 18:01

Quote:

Originally posted by Tamerlin
... to all the modders without whom there would not be any CtP and CtP2 communities on Apolyton, these games are living because you are modding and improving them.

Although it always has been

We can now, without the slightest bit of hesitation, state that CtP2 is the most easilly moddable civ game in existance

So keep up the good work guys...

The Big Mc · October 28, 2003, 19:23

any body seen this yet

BOOL ChatWindow::CheckForEasterEggs(MBCHAR *s)
{
if (!strcmp(s, "pacman")) {
return TRUE;

Peter Triggs · October 28, 2003, 19:51

Shucks. Now we'll never know what would have happened if that line hadn't been there and we'd typed "pacman" into the chat window.

The Big Mc · October 28, 2003, 20:16

void PacCommand::Execute(sint32 argc, char **argv)
{
PLAYER_INDEX player = g_selected_item->GetVisiblePlayer();

MapPoint pos;
g_tiledMap->GetMouseTilePos(pos);

Unit newu = g_player[player]->CreateUnit(g_theUnitDB->NumRecords() - 1,
pos, Unit(0),
FALSE, CAUSE_NEW_ARMY_INITIAL);
newu.AccessData()->SetPacMan();
}

the pac command

Dale · October 29, 2003, 00:34

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 · October 29, 2003, 00:44

Wanna play CTP2 while running an audio CD through WinAmp?

No problems.......

Quote:

BOOL c3files_HasLegalCD()
{
BOOL success = FALSE;

if (g_soundManager) {
g_soundManager->CleanupRedbook();
}

while (!success) {

success = c3files_FindCDByName(k_CTP_CD_VOLUME_NAME, TRUE);

Dale · October 29, 2003, 00:46

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++;
}
}
}

Dale · October 29, 2003, 00:59

I found why AI stacks won't move around it's own 12-stacks. We'll need to put in a new Astar entry type so it doesn't return as ASTAR_BLOCKED, and then change Astar.cpp so it processes it to look for a different direction.

Code:

BOOL UnitAstar::CheckUnits(const MapPoint &prev, const MapPoint &pos,                           
    Cell* the_prev_cell, Cell* the_pos_cell, 
    float &cost, BOOL &is_zoc, BOOL &can_be_zoc, ASTAR_ENTRY_TYPE &entry, 
	BOOL &can_enter)
{     
..
..
..
				if (m_check_dest && (k_MAX_ARMY_SIZE - dest_army->Num()) < m_nUnits) {   
					cost = k_ASTAR_BIG; 
					can_enter = FALSE;
					entry = ASTAR_BLOCKED; 
                    return TRUE; 
				}
..
..
..

Dale · October 29, 2003, 01:05

And the location to add in our ASTAR_JOINUNIT_ENTER (or whatever we call it)......

Code:

void Astar::PropagatePathCost(AstarPoint *node, AstarPoint *parent, 
   const MapPoint &start, const MapPoint &dest, AstarPoint **cost_tree)
                              
{  
..
..
..
    if (node->GetEntry() != ASTAR_CAN_ENTER) { 
		return; 
	} 
..
..
..

Dale · October 29, 2003, 01:48

If we change this to true, wonder what happens.....

bool g_e3Demo = false;

Solver · October 29, 2003, 08:58

Quote:

Originally posted by Dale
If we change this to true, wonder what happens.....

bool g_e3Demo = false;

It seems to me from the source that it does then start the game right away, without main menu or other stuff.

Edit: and after the game ends, it goes straight out too, no menus or stuff.

mishad2 · October 31, 2003, 04:44

Quote:

Originally posted by The Big Mc
any body seen this yet

BOOL ChatWindow::CheckForEasterEggs(MBCHAR *s)
{
if (!strcmp(s, "pacman")) {
return TRUE;

Quote:

Originally posted by Peter Triggs
Shucks. Now we'll never know what would have happened if that line hadn't been there and we'd typed "pacman" into the chat window.

Why? strcmp(s, "pacman") returns 0 if s == "pacman", so the decision, translated to English, is:

if the string s is "pacman" then return TRUE

I'd search for calls to CheckForEasterEggs() and see what the caller does when the return value is TRUE...

Misha

Peter Triggs · October 31, 2003, 07:16

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 · October 31, 2003, 14:51

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?

Locutus · October 31, 2003, 15:33

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

ahenobarb · October 31, 2003, 16:35

Quote:

Originally posted by Locutus
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).

I located the limit on the numbers of civilizations as well.

Quote:

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

That's the answer I was looking for! However, what will happen when there is the Official Apolyton patch 2.0 (or whatever) and then several independent patches that are bifurcations of other patches? I guess what I am getting at is that distribution of different patches and versions in the future my become a real problem. How much storage space will Apolyton allow us to use? The number of patches worth sharing will quickly grow after the first one we produce. Without trying to get ahead of ourselves, in a year or so, the CTP/CTP2 community may need its own server and domain.

Just some rhetorical questions to think about.

Locutus · October 31, 2003, 17:42

Quote:

How much storage space will Apolyton allow us to use?

Some of the current mods also take up 20 MB or more (think MedMod, Cradle) and we have quite a few of those (not just for CtP but for other games as well).

The Apolyton Staff always has a few open positions but worrying about diskspace and other technical issues is one position that's already taken

We'll let you know if there are any openings in the future

Solver · October 31, 2003, 17:44

BTW, the debug exefile of CtP2 that I built is over 14 MB in size.

Locutus · October 31, 2003, 17:48

Yes, but the release version is only about 9 MB (quite a big difference, actually). Which is odd as the in theory exactly identical ctp2.exe file on the game CD is only 6 MB

Either way, nothing Apolyton won't be able to handle.

Fromafar · October 31, 2003, 17:57

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.

Locutus · October 31, 2003, 18:04

Ah yes, now I see. That explains it....

J Bytheway · October 31, 2003, 18:06

Yep, Final comes out at about 6MB. It's probably smaller than Release due to additional optimisations.

J Bytheway · October 31, 2003, 18:24

Does anyone think we should look into the making of binary patches, rather than uploading whole copies of the executable - that would take rather less space.