PROJECT: Good Specific Terrain Improvements

[Ekmek]

I see so i the city data one I just need M+citystyle. I'll make the changes...

Bytheway I saw this in citydata.h

#ifdef CTP1_TRADE
	Resources m_resources;
	Resources m_localResources;
#else
	Resources m_collectingResources;
	Resources m_sellingResources;
	Resources m_buyingResources;
#endif

If I read it right, then these identify if a city has a resource(good) so I could do a code for Civ3-like need resource flag for cities only using this (andit'll probably be similar to my code) but I'm getting ahead of myself so I'll post citydata stuff first (cdb is already done)


I think the lecture was great and I guess if you had to add anything it would be all the mistakes or stuff you had to teach me which are probably usual beginner mistakes

[Ekmek]

Citydata.cpp

CityData::CanBuildBuilding

#if !defined(ACTIVISION_ORIGINAL)

	if(irec->GetNumGovernmentType() > 0) {
		sint32 i;
		bool found = false;
		for(i = 0; i < irec->GetNumGovernmentType(); i++) {
			if(irec->GetGovernmentTypeIndex(i) == g_player[m_owner]->m_government_type) {
				found = true;
				break;
			}
		}
		if(!found)
			return FALSE;
	}

	if(irec->GetNumCityStyleOnly() > 0) {
		sint32 s;
		bool found = false;
		for(s = 0; s < irec->GetNumCityStyleOnly(); s++) {
			if(irec->GetCityStyleOnlyIndex(s) == m_citystyle) {
				found = true;
				break;
			}
		}
		if(!found)
			return FALSE;
	}

	if(irec->GetNumCultureOnly() > 0) {
		sint32 s;
		bool found = false;
		for(s = 0; s < irec->GetNumCultureOnly(); s++) {
			if(irec->GetCultureOnlyIndex(s) == g_player[m_owner]->GetCivilisation()->GetCityStyle()) {
				found = true;
				break;
			}
		}
		if(!found)
			return FALSE;
	}
#endif

attached are also the Cdbs, I added the nobarbarian cdb to keep consistent (although if i understand the server right it lets people do modification of individual lines and allows you to sort based on revision, like DOORS, am I right?)

[Martin Gühmann]

Originally posted by E
attached are also the Cdbs, I added the nobarbarian cdb to keep consistent

The cdbs seem to be correct. The only thing that might be reconsidered is the name of this:

Bit(Int) PopCostsToBuild  //added for future use to deduct more than one pop for units

I am not quite confident with it but so far I have no better idea. So we leave it as it is.

Originally posted by E
(although if i understand the server right it lets people do modification of individual lines and allows you to sort based on revision, like DOORS, am I right?)

Maybe I can anwer the question if you can tell me what DOORS is or are.

Appart from that the code fragment you posted above is correct in CityData::CanBuildBuilding. So let's go to the next file.

-Martin

[Ekmek]

Originally posted by Martin Gühmann


The cdbs seem to be correct. The only thing that might be reconsidered is the name of this:

Bit(Int) PopCostsToBuild  //added for future use to deduct more than one pop for units

I am not quite confident with it but so far I have no better idea. So we leave it as it is.

Yeah i basically want to make it optional for modder to have units cost more than 1 pop point to build. I think its a small change in the build code by adding a line where the PopCost subtracts 1.

Maybe I can anwer the question if you can tell me what DOORS is or are.

We use DOORS at work, itlike a spread sheet but you can sort on only certain stuff that applies to what you want. So I assume that you can make builds off of certain revisions and it pastes in between lines of code.

Appart from that the code fragment you posted above is correct in CityData::CanBuildBuilding. So let's go to the next file.

-Martin

Great! I think I can keep almost everything in citydata (wonder, unit) instead of going to the player and the wonder.cpp because it looks like citydata does the same check for government type if a player can build a unit or if a city can build a unit.

[Ekmek]

Martin,

I added the bit of code to the CanBuildUnit and CanBuildWonder in the citydata.cpp. I think that adding the code here wil mean that I don't have to change Unitdata.cpp, Player.Cpp, or Wonderutil.cpp.

If all is well I think I'll have to look how to add the code to the terrain improvement file (including my IsRestrictedTo code). Of course unless tere are other things you've found.

I have a few questions though:

1) inotice that #include citydata.h is in player.cpp. Does this allow the classes of citydata to be accessed in the player.cpp like it would in citydata.cpp?

2) I notice you've guys have done lots of work on the server to the code, including changes to the citydata.cpp. I havent gotten into the server and don't think i could figure it out anytime soon. Could you post the modified citydata.cpp so I can update it with my stuff or are willing to post my changes when you post stuff (I'dh ate to get on the server and screw things up)

thanks.

[Martin Gühmann]

Originally posted by E
I added the bit of code to the CanBuildUnit and CanBuildWonder in the citydata.cpp. I think that adding the code here wil mean that I don't have to change Unitdata.cpp, Player.Cpp, or Wonderutil.cpp.

So far your CityData.cpp seems to be ok, and the note about the other files is correct.

Originally posted by E
If all is well I think I'll have to look how to add the code to the terrain improvement file (including my IsRestrictedTo code). Of course unless tere are other things you've found.

Of course you have to modify terrainutil.cpp.

Originally posted by E
1) inotice that #include citydata.h is in player.cpp. Does this allow the classes of citydata to be accessed in the player.cpp like it would in citydata.cpp?

No, that does not mean it. You can access the members of the class within a function, because this function is a member of the according class itsself.

However it does allow you to create and use opject of class CityData in player.cpp.

Originally posted by E
2) I notice you've guys have done lots of work on the server to the code, including changes to the citydata.cpp. I havent gotten into the server and don't think i could figure it out anytime soon. Could you post the modified citydata.cpp so I can update it with my stuff or are willing to post my changes when you post stuff (I'dh ate to get on the server and screw things up)

So you mean I should submit your modifications as my own to the resperitory and get the honor, the glory, the fame ... and the blame for it?

Come on this isn't so difficult. The first thing you do with Tortoise is to check out the respiratory. Then you download the files (as default it copies the files into an empty folder) and then you have a work copy. Then you do your modifications on the work copy. When you are done you check the update option, to see whether there are any new versions of files. Once you have updated your work copy you can commit your files. And if there was a change of your file in the respiratory and there are no conflict the files are easily merged. Otherwise you have to resolve the conflict by hand.

-Martin

[Ekmek]

I also found this bit in advances:

g_player[m_owner] && g_theCivilisationPool->IsValid(*g_player[m_owner]->m_civilisation

I think I can use it to compare a CivOnly attribute to the m_civilisation? Should I plug it in there?

Originally posted by Martin Gühmann
No, that does not mean it. You can access the members of the class within a function, because this function is a member of the according class itsself.

However it does allow you to create and use opject of class CityData in player.cpp.

If understand my C++ for dummies right, then by objects you mean it lets me use m_citystyle without having to do -> and get. right?

If so, can I just add #include citydata.h to terrutil.cpp so I don't have to make any changes to my code?

So you mean I should submit your modifications as my own to the resperitory and get the honor, the glory, the fame ... and the blame for it?

Come on this isn't so difficult. The first thing you do with Tortoise is to check out the respiratory. Then you download the files (as default it copies the files into an empty folder) and then you have a work copy. Then you do your modifications on the work copy. When you are done you check the update option, to see whether there are any new versions of files. Once you have updated your work copy you can commit your files. And if there was a change of your file in the respiratory and there are no conflict the files are easily merged. Otherwise you have to resolve the conflict by hand.

Ok you've been warned I'm going to give it a shot but expect annoying questions

[Martin Gühmann]

Originally posted by E
I also found this bit in advances:

g_player[m_owner] && g_theCivilisationPool->IsValid(*g_player[m_owner]->m_civilisation

I think I can use it to compare a CivOnly attribute to the m_civilisation? Should I plug it in there?

If you can tell me were you ripped off this piece of code and where you want to insert it. And why.

Originally posted by E
If understand my C++ for dummies right, then by objects you mean it lets me use m_citystyle without having to do -> and get. right?

If m_citystyle is member of the same class like the function in that you indent to use it then you are right.

Originally posted by E
If so, can I just add #include citydata.h to terrutil.cpp so I don't have to make any changes to my code?

No, in terrainutil.cpp there aren't any member functions of CityData or do you see any functions with CityData:: there. And even if you have such a function there, it doesn't need to be a member function of an object of type CityData, as it can be static as well.

Originally posted by E
Ok you've been warned I'm going to give it a shot but expect annoying questions

Better ask before before you break anything.

-Martin

[Ekmek]

Originally posted by Martin Gühmann
No, in terrainutil.cpp there aren't any member functions of CityData or do you see any functions with CityData:: there. And even if you have such a function there, it doesn't need to be a member function of an object of type CityData, as it can be static as well.
-Martin

Ok I added the code to terr_util, and I rememered that I don't need to check citystyle because the game doesn't check citydata at all and since I call g_player than I think my code will be alright. Its in CanPlayerBuild and I kept the IsRestrictedToGood at CanPlayerBuildAt.

If it looks good then I'll make my attempt at putting into the svn

[Martin Gühmann]

Originally posted by E
Ok I added the code to terr_util, and I rememered that I don't need to check citystyle because the game doesn't check citydata at all and since I call g_player than I think my code will be alright. Its in CanPlayerBuild and I kept the IsRestrictedToGood at CanPlayerBuildAt.

Well first you should get the whitespace usage in the terrainutil_CanPlayerBuildAt description. You added also a brief description in the "Modifications from the original Activision code:" section in this file, fine. But IIRC in the last version of CityData that piece of information was missing.

Now let's come to the stuff that keeps the file from compiling. m_owner is a member of CityData and inaccessable from a global function like terrainutil_CanPlayerBuild. But the answer on the question how you can replace it should be located inside this function.

Oh and by the way the function returns a bool and not a BOOL.

Originally posted by E
If it looks good then I'll make my attempt at putting into the svn

I think the best is you get a work copy from the server and merge in your changes manually, otherwise you have to deal with the Toirtoise merger and with the amount of changes in the file on the server that will be a hazzle.

And I think if you just overwrite the file in your work copy with the file attached here, it won't merge but will overwrite the file on the server.

And as we have removed the ACTIVISION_ORIGINAL stuff you have now to do the preprocessor task. So replacing the old code with the new code.

-Martin

[Ekmek]

Originally posted by Martin Gühmann


Well first you should get the whitespace usage in the terrainutil_CanPlayerBuildAt description. You added also a brief description in the "Modifications from the original Activision code:" section in this file, fine. But IIRC in the last version of CityData that piece of information was missing.

Now let's come to the stuff that keeps the file from compiling. m_owner is a member of CityData and inaccessable from a global function like terrainutil_CanPlayerBuild. But the answer on the question how you can replace it should be located inside this function.

Oh and by the way the function returns a bool and not a BOOL.

-Martin

g_player[pl]

I think I got it!

but your whitespace comment was confusing did you mean to get rid of the whitespace?

[Martin Gühmann]

Originally posted by E
I think I got it!

I agree.

Originally posted by E
but your whitespace comment was confusing did you mean to get rid of the whitespace?

How much sense does this make. Getting rid of all white space together. Leaving the whole code in a single line. Of course not.

I was after this:

//----------------------------------------------------------------------------
//
// Name       :  terrainutil_CanPlayerBuildAt
//
// Description:  Checks terrain improvement properties to see if it can build 
//               on a tile only if it has a good
//
// Parameters :  sint32 pl		: Variable for player
//		const MapPoint &pos	: Variable for tile on map
//		const TerrainImprovementRecord *rec	:Varriable for improvement flag
// Globals    :   g_theWorld		: The game world properties
//		      g_player   		: Player properties 
//
// Returns    :   bool			: Returns true if an improvement can be built 
//                                    on a tile
//						  false if the improvement cannot 
//
// Remark(s)  :   A new improvement attribute IsRestrictedToGood was 
//                added by E. Modders will define this in tileimp.txt as 
//                IsRestrictedToGood: X. The flag adds an additional option 
//                in order to restrict ceratin improvements to goods, adding 
//                new options and bonuses. 
//              
//
//----------------------------------------------------------------------------

It is a mixture of spaces and tabs. But everything inside this block should be spaces.

And at the end of this function is a closing brace without the right indent.

-Martin

[Ekmek]

ok, yeah I saw that too after I went in, strange it didn't look that way before...I guess I had it on a wordwrap or something...

[Ekmek]

fixed the whitespace and the }

[Martin Gühmann]

Well I think we can test it on a compiler. So that means that you have to get it onto the server. I guess you have now all the files form the server. Then go to the trunk directory. You should be familiar with the subdirectory structure.

Go to the according files and insert your changes there. Possibly that can be done more confortable with a merge tool, but we don't want to make it too complicated for the start.

The files you have to merge manually are terrainutil.cpp, CityData.cpp and terrimprove.cdb. I think you can overwrite the rest of the *.cdb with yours without any problem. Maybe you like to add also to the *.cdb files such a nice description on the top like Fromafar did it with the terrimprove.cdb.

And of course let me have a final look before you commit the files. And of course you have now to strip the ACTIVISION_ORIGINAL stuff manually.

OK and finally some remarks to the descriptions, you don't need to mention this word 'variable' I know that this knd of stuff is variable. And a sint32 pl is not a player's attribute it is the players index, the thing that I need to acces the player in the list of players.

-Martin