Mining, trapping, prospecting, and depleting resources

So when a tiles is depleted of ore, you can reprospect it?

Is that like prospecting level 2 or repospecting level 1?

Also is the reprospecting another 'random chance' or is it guaranteed to produce more available ore?

There are no guarantees in life, son. Well, it should be that order to prospect again the plot must be lesser than the Player's Prospecting Level. Player's start at level 0, then move up. When you prospect a plot it move up a level, so from 0 to 1, then the Player needs to be that level before you can prospect again. And it is another random chance that you find anything, but there is a smaller chance now that you will find nothing.
 
Game option as a bool in CvGame. It is picked when the game starts, just like victory conditions and other stuff like that. Once you get to turn 1, the setting becomes hardcoded and if you want to change it, you start a new game on a new map.

Uggh, I don't ever ever use Custom Game, I always use the Play Now option which just uses the default settings. I would like to have an XML option if that is the case so that the XML takes precedence. Shouldn't be a big deal as it is only checked during map build.
 
So you cannot reprospect a depleted site until you have unlocked the next prspect level from technology?

So it is just the level up prospecting, not a reprospecting of a depleted site?

Technology allows you to dig deeper or use better techniques to get to the ore, if there is any there. Once you have depleted a site and you lack the technology to get more you have to wait until you get better tech. So yes, it is the level "of" (took me a bit to figure out what you meant) Player's Prospecting. You can't prospect a site over and over with the same tech and expect different results, isn't this what they call insanity? :twitch::crazyeye::aargh:
 
New Techs not always mean new yields. I am living in Texas and oil well Fracking is a big deal here. But, it is a gamble, you could spend several thousand dollars fracking an old well just to pop a dud. This would be a cool Tech for WHM, Fracking, of course it has the draw back of creating earthquakes, but who cares when you got plenty of money to rebuild anyway!!

I like the Idea of Prospecting and it is kinda fun to see what you get.
 
Uggh, I don't ever ever use Custom Game, I always use the Play Now option which just uses the default settings. I would like to have an XML option if that is the case so that the XML takes precedence. Shouldn't be a big deal as it is only checked during map build.
Some mods have a display of game settings if you click play now. I have been planning to figure out how they do that for a while.

New Techs not always mean new yields. I am living in Texas and oil well Fracking is a big deal here. But, it is a gamble, you could spend several thousand dollars fracking an old well just to pop a dud. This would be a cool Tech for WHM, Fracking, of course it has the draw back of creating earthquakes, but who cares when you got plenty of money to rebuild anyway!!
All you talk about is eqrthquakes? The rest of the world talks about how it contaminates the drinking water, making it really toxic. You can rebuild broken buildings if you have the money, but even with money you can't repair toxic drinking water.

Besides person A earns a lot of money on fracking, person B lost his house to an earthquake and person C gets ill due to a toxic spill. If that happens, person A is suddenly on Bahamas and nobody helps B or C.
 
That is why THIS game is based around being person A!

Bahamas here we come!

lol:lol:

I haven't actually researched the side effects, I only read one article the other day about all these earthquakes around the Dallas area and some think they are tied to fracking.

Anyway, I am actually good friends with some of the leaders of the Fracking industry and I dare not talk smack around them. Poison water?? I hate terrorist!!!:mad:
 
I just pulled the new center plot changes and it fixed my issues with no Barley being produced, but it also revealed an issue in the Prospecting code. If you found a city on a plot that has ore the plot can never be prospected. So, I need to make it auto prospected, but there is a chance that you may not find anything, thus your center plot will only produce food. And or make the code allow for Prospecting city plots. The auto prospect would be just like Founding ability to Clear a Forest in an instant. Currently I have two cities built on Marsh that only produce food because they where never prospected.

Which also gives the ideas that terrain type could hinder or help city building placements.

I did some research on Marsh and Hides/Fur would actually be a good third yield for Marshes, as Beaver often make their homes there and also Deer and the like frequent these areas for water and grub.

Tundra only had food I think in vanilla.

Hills is an issue also, we could change the default of -3 to Grapes, Barley, and Cotton, to only -1 so that Hills can produce crops at some point and see how that goes.

If/when we add more yields it could also solve this issue of only Food in center plot.
 
I managed to implement an on/off switch for depletable yields. Nothing listens to the setting yet, but it's there, which is a start.
Code:
<GameOptionInfo>
	<Type>GAMEOPTION_DEPLETABLE_YIELDS</Type>
	<Description>TXT_KEY_GAME_OPTION_DEPLETABLE_YIELDS</Description>
	<Help>TXT_KEY_GAME_OPTION_DEPLETABLE_YIELDS_HELP</Help>
	<bDefault>0</bDefault>
	<bVisible>1</bVisible>
</GameOptionInfo>
bDefault tells what the setting will be if you click "play now" as well as starting value in custom games
bVisible tells if the player is able to use the non-default setting.

Looks like we have the XML setup, which allows us to easily ban the feature from a stable release as well as easily use it by default for development.

For the record, it is actually not that hard to add game options. All you have to do is to add it to CIV4GameOptionInfos.xml, enum GameOptionTypes and CyEnumInferface.cpp. It is then accessed by CvGame::isOption(enum value) and is accessible to python. Now all we need to figure out is how to give the option to change the options if you click play now and we are free to make the game configurable.

Btw all game options are automatically included in savegames. It's not a JIT array through and it takes custom code not to break savegames. Rather than trying to save old savegames, I will instead intentionally break them and clean up savegame code now that they break anyway. Because I will break savegames over and over, I will make a dedicated branch just for this task.


EDIT: we need a single name for prospecting/depletable yields. It would appear that there are at least 3 names for it so far and that was even before I came up with the "depletable yields" name. While the names are not downright misleading, it would be way better if we could have a standard name for each feature as finding all the code for that feature largely depends on searching for "/// name".
 
I was about to write a post about changing the arguments to setBonusType() even though the function has DllExport written in the declaration. The exe will not be able to figure out new arguments, meaning it can be a cause of weird bugs :gripe:

However I decided to search through the exe with a hex editor. The functions it will call are written in plain text and it turns out that setBonusType is not present in the exe. Danger avoided, but vanilla is flawed in the sense that it adds unneeded DllExports, which impose unneeded restrictions to modders.

I wonder if I can write a perl script to look through the source code as well as the exe (read as an ASCII file) and delete all unneeded DllExports. I once considered this compared to the vanilla files, but since vanilla suffers from the same problem, looking into the exe itself seems to be the only real option.
 
Code:
<BuildInfo>
	<bProspect>1</bProspect>
	<ProspectYieldType>YIELD_ORE</ProspectYieldType>
Wouldn't it be better to have ProspectYieldType to be default NO_YIELD instead of the current YIELD_FOOD. That will allow us to remove bProspect. Instead bool isProspect() will return ProspectYieldType != NO_YIELD.

It's not a big deal, but essentially we have two variables, which more or less tell the same thing.

Also we may consider prospecting for multiple yields at once. If I dig a hole in the ground to look for mining opportunities, I will use that hole for all minerals, not one for iron, one for copper, one for silver, one for gold etc.

EDIT: we may also consider rewriting the code to loop all cargo yields instead of all yields. That is, unless somebody plans to prospect for crosses or something like that. If that is the case, then the yield drawing code should be changed because that one is hardcoded to only handle cargo yields.
 
Yeah, the Prospecting code is in its infancy stages. I didn't really write out a plan and just started coding (like you love it when I do that:love:) so the code does need cleaned up for things as you say.

I only started with Ore as a testing Yield for Prospecting. Adding Silver and Stone is planned as well, once we work out the kinks in Ore. Its all a work in progress, and was a good idea to have it disable-able ;)
 
I know in 2071 you could get things like 'crosses' off of the land, alien sites and such. So it may be a point to consider, as prospecting may become archaeology in that situation...
Good point.

I came up with a different idea though. Let's assume the vast majority of yields will not use prospecting. After loading XML, we can calculate which yields are possible to prospect. We can then store the IDs of those in a vector and loop that vector whenever we need to loop all prospectable yields. Right now that is just one yield and according to the plan, it will be 3. In other words that is checking 31 non-prospectable yields whenever we loop the prospectable ones.

I'm not sure where it would be best to store such a vector though (possibly CvGlobals), but I think we should make it at some point.

Speaking of performance, I do not simply disable prospecting based on the game setting bool. Instead I add asserts in the read/write functions for prospecting and whenever one of those functions assert, I go backwards to disable the call itself. Usually the call is looping all yields meaning that way we avoid entering unneeded loops. I haven't found indications that the prospecting code should be dead slow, but I still prefer not to enter unneeded loops. Also I plan on changing all prospecting arrays in CvPlot to JIT arrays. The majority of the plots will not need those and none will need them if prospecting is disabled. We might as well save some memory, not to mention using JIT arrays can later be used to make savegames survive adding/removing yields.

I decided the name for prospecting in the DLL.
Code:
/// Prospecting
It's pretty descriptive and I'm attempting to add it to all the prospecting code I encounter.
 
After loading XML, we can calculate which yields are possible to prospect. We can then store the IDs of those in a vector and loop that vector whenever we need to loop all prospectable yields. Right now that is just one yield and according to the plan, it will be 3. In other words that is checking 31 non-prospectable yields whenever we loop the prospectable ones.

Yeah, I thought about doing this as well. Also, there are tons of places that could use this kind of code improvement that cycles through unneeded yields and such. Perhaps your performance checker could find where this could help.

I'm not sure where it would be best to store such a vector though (possibly CvGlobals), but I think we should make it at some point.

Perhaps in CvGame, so that each Game will keep up with it.

I decided the name for prospecting in the DLL.
Code:
/// Prospecting
It's pretty descriptive and I'm attempting to add it to all the prospecting code I encounter.

Roger that:goodjob:
 
Top Bottom