Geo Realism: Discussion on a new SDK based map generator

Ok. Then perhaps a button isn't what we need so much as a set of hotkeys to change the plot graphics to a different setting. If most players don't need to be more concerned with it than what a hoverover could express, then a combination of hotkeys to switch the map view would work. Later on that could be adapted to a button but I THINK AIAndy is the only one I've known to work out how to add a button to the UI in that manner.

In all honesty, none of the Globeview buttons (activated when the "Globe View" is pressed or you back out far enough) are of that much use for game play. The only buttons I regularly use are the grid button and the resource button. But those are all on the main view. So I still think that a globe view (or some kind of) button is preferable.

In the meantime, players could still access the different mapview and be told how to do so via a quick bottom line in the hoverover plot help popup.

This much is true. We could use hotkeys until a way is found to implement the buttons.

You know... there are existing buttons there too for map view changes. Perhaps the code that reacts to each button press could be isolated and an additional option in the cycle could be tied in.

Yes... the globe view buttons. However, I have already checked both python and the DLL and unfortunately ALL this code is in the main executable. Not even the XML for the buttons gives any hint on a callback function to be executed. The only code I could find for these globe view buttons is where they are created on the main screen from python and (I think) where they are changed from the regular view to the globe view.

I believe the trick to this is a matter of changing the reference skin on the terrains themselves so that it switches from the usual skin of the terrain to the colors the representing the geo-definition on that plot (assuming I'm understanding everything you're saying here...) That would take some identifying of where the game asks for the terrain's graphic skin and adjusting the return to redirect to the plot data and the geo-definitions instead if the gamestate has changed to showing the geo data thanks to the use of that button.

I have already figured out how to handle the coloring of the plots; thanks to modifications already made to the original code... The colored "circular" patterns that appear around cities on occasion and the ones that appear for settlers of different players were a big clue as to how the plots could be recolored. I found that you don't have to draw just circles. There are a number of different plot fills/overlays to use that are defined in the XML/enums. So the actual drawing of the map view from the DLL will not be a problem.

I'm pretty sure a button already exists that could have another 'phase' added to it harmlessly.

I have already tried doing this to the globe view buttons with no success.

First, the callback routines are not defined for the different "phases" so there doesn't appear to be a mechanism within python, the DLL, or the XML that allows a callback to be defined. I can't find any callback anywhere. I suspect that the button id for globe view buttons is differentiated within the main executable and that determines what is done.

Second, for some reason I cannot seem to replace the skin that is on the Globe view buttons. Maybe I am just going about it wrong but I have not been able to change it no matter what I have tried.

Specifically, I will need at least as many buttons as there are for the globe view so using another set of buttons seems pointless. So eventually we need to add another set, or find some way to manipulate the globe view buttons.
 
@primem0ver

I was thinking over your idea of rainforests having poor soil today. And while I am not going to argue against that fact I am going to argue about what :food: represents on a tile. First of all a Jungle (-1 :food:) if built on a Muddy (+1 :food: and +1 :hammers:) tile gets a total of +1 :hammers:. Plus of of course the benefits of anti-pollution.

This seems quite adequate to me since one could use a Jungle Camp to get the benefits of hunting whatever animals in the jungle or picking whatever flora. The :hammers: I assume are from the potential of mud being a building material.

Thus I don't see why you would need a special terrain for the Jungle (aka rainforest). Note that one could also find Jungle on Grassland (+2 :food:) or Lush (+3 :food:). Which comes out to 1 or 2 food with the rainforest. I look at it not as the soil quality but the quality of the Jungle. Thus a Grassland + Jungle would be a jungle that has some food and a Lush Jungle would be a thriving jungle with lots of food potential. And not necessarily the soil.

If anything its an indicator of the moisture in the soil such as ...

<- Wet -- Dry ->
<- Marsh - Muddy - Lush - Grassland - Plains - Barren - Rocky - Scrub - Desert - Dunes - Salt Flats ->
 
@prime: Ok, well that helps me understand more of where you're actually 'stuck' then. I get to points like that and get pretty frustrated too. The most recent time I did I realized on a second look that I was only two steps away from actually completing what it was I was looking to do so it may be possible something was missed in there.

But although I can't help much with buttons in general, I can say that AIAndy recently added the extra build queue generator screen (the Hammer button in the upper right corner of the main interface.) Perhaps its possible to follow that example, if you can get a bead on where/how he went about that, to create a control panel that could then be utilized to toggle the map view accordingly.

Given the problems you face with the direction you were going with the globe view buttons, which are completely understandable, I think we simply need to start considering alternative ways to accomplish the same results.

I'm very impressed with how far you HAVE solved the problem so far though ;) That's not the easiest area to go manipulating things!


@Hydro: I'm not really in argument with you on this BUT I'd like to point out that its not a matter, so much, of how the plot should be when the jungle is there, so much as what happens when the jungle is removed. Anywhere jungle has been deforested, we see complete and utter wasteland good for little more than scant grass patches and some ranching. This is because as soon as deforestation takes place, the topsoil, being very thin, rushes off in the next monsoon... never to be fertile land again (not in our lifetimes anyhow) and I think Prime is looking to replicate this effect.
 
Great to hear about the progress!

Since the climate engine is apparently nearly finished, I assume that all the points we talked about in private messages are resolved?

I read your descriptions of them, but am still not quite clear on what the exact differences between "climate", "biome" and "vegetation" are. Do we really need all of these three layers?

About the ocean issue: I am looking forward to seeing that in action as well. Getting the ocean currents accurate enough is going to be an issue of major important, since a cold or warm current can totally change the climate of a coastal zone (such as Norway or the Namib desert in our world). So this is going to be interesting!

Once the engine is ready to be tested by others, I can hopefully make a good contribution to that, being familiar with climate zones and with the underlying calculations of the climate engine.

If there is anything I can help out with, let me know!
 
@Hydro: I'm not really in argument with you on this BUT I'd like to point out that its not a matter, so much, of how the plot should be when the jungle is there, so much as what happens when the jungle is removed. Anywhere jungle has been deforested, we see complete and utter wasteland good for little more than scant grass patches and some ranching. This is because as soon as deforestation takes place, the topsoil, being very thin, rushes off in the next monsoon... never to be fertile land again (not in our lifetimes anyhow) and I think Prime is looking to replicate this effect.

Perhaps there should be a "Terrain Feature" for deforested tiles rather than a new tile? You chop the forest and then you get a deforested terrain feature with like -:food:.

EDIT: Here are some graphics from the "Any Fun" Mod.

attachment.php


Perhaps the "Burnt Forest" could be used as deforested terrain. However I would much rather have "Burnt Forest" as a new type of forest along with "New Forest" and "Ancient Forest"
 
Well... deforestation of FOREST works a lot differently than it does for JUNGLE. Jungle terrain is almost always the same general type of soil... there's a very limited type of soil that supports the Jungle and the Jungle changes the soil drastically over time so that nearly all jungle has similar underfeatures. Forest, on the other hand, does have a wide variety of underlying terrains and doesn't suffer quite as badly when deforestation takes place... most of North American farmland is deforested territory. It just kinda sucks to be Brazil is all...

Forests do have a natural cycle of forest fires and natural deforestation and regrowth so those phases you noted in the graphics do seem pretty cool to incorporate somehow!
 
Well when a Forest fire event happens it would be nice to get a "Burnt Forest" appear.

And then when you have a "Forest has Grown" event it would be nice to have a "new Forest" appear. Likewise having it grow into a normal forest and if it last long enough an Ancient Forest. All of which give a bigger chopping bonus the longer you let a forest grow.

Note these could work in tandem with the Volcano eruptions and have nearby forests become Burnt Forest if they adjacent to the Volcano when it erupts.
 
The Globe view functionality is handled by the .exe and not directly adjustable.

The buttons, however, are added via Python. Adding more buttons, or different buttons, is purely a Python matter. If you add your own buttons in addition to, or instead of, the regular Globe view buttons you can control what they look like and what they do.

An example of putting new things on the map is the dot mapping functionality. That puts shaded areas on the map and is done purely in Python (well, with the help of the existing functions for drawing on the map, of course).
 
There are two ways to handle button callbacks. One is to use a special widget type that you add to the DLL and which defines the callback in the DLL (see CvDLLWidgetData.cpp). The other is to use the handleInput method of the screen (you can use BUG to bind a special widget type with a mouseover help text for that).
 
GE said:
The buttons, however, are added via Python. Adding more buttons, or different buttons, is purely a Python matter. If you add your own buttons in addition to, or instead of, the regular Globe view buttons you can control what they look like and what they do.
So what python files must be manipulated to add an additional button/set of buttons where he's looking to add them? Does it show any example code blocks there that sets up the initial buttons on the screen? Or are those initial buttons in the main interface and global view interface generated and handled entirely in the exe?

AIAndy said:
There are two ways to handle button callbacks. One is to use a special widget type that you add to the DLL and which defines the callback in the DLL (see CvDLLWidgetData.cpp). The other is to use the handleInput method of the screen (you can use BUG to bind a special widget type with a mouseover help text for that).
Once you've created the widget, something I've done for my current project successfully so I'm following you here pretty well, how do you tie it to a new button on the screen? Does the button need to be setup in python, then the button push processing programmed from the dll? (There's also a way to set selection buttons to popup a help text on mouseover there too but I'm not sure if that's purely a tool that can be used for selection list buttons or not...)
 
@Hydro New Forest is already in the game - but it does not seem to be working properly. You plant a Tree Nursery which grows into a Young Forrest which then grows into a normal Forest. There are three problems with this as far as I can tell
1) the AI (and automatic workers) prefer to chop down existing forest to plant Tree Nurseries and there is no way to limit the build to not forest.

2) the Mew Forest graphic is not working well - may just be that I have not programmed properly

3) the New Forest does not seem to grow into normal Forest.​
This is all part of ModifiedA4's mod. I think I have the terraform to forest now working so that the resultant forest can be worked.
 
So what python files must be manipulated to add an additional button/set of buttons where he's looking to add them? Does it show any example code blocks there that sets up the initial buttons on the screen? Or are those initial buttons in the main interface and global view interface generated and handled entirely in the exe?

The buttons for this are set up in CvMainInterface.py.

The globe view buttons are set up in the createGlobeviewButtons function using information supplied by the .exe via the CyGlobeLayerManager and CyGlobeLayer classes (which are handled by the .exe). There is no particular reason that you have to use that data for any new buttons. I have no idea where the data comes from - it may be hardcoded in the .exe. There are some definitions in CIV4ArtDefines_Interface.xml that point to .dds file (I have no idea what these icons are used for - they are not used by the actual buttons).

The widget type the current Globe view buttons use is handled by the .exe is "WIDGET_GLOBELAYER" (I haven't checked, but it may not appear in the DLL).

The image for the button is done via the style, as with many thigns in the UI. For example, the strategy overlay should be using "Button_HUDGlobeStrategy_Style" which corresponds to the Civ4Theme_HUD.thm theme file's "SF_CtrlTheme_Civ4_Control_Button_HUDGlobeStrategy_Style" which pulls the graphics for the various button stated out of the HUD_icons.tga file. (I don't know where it is actually setting up the style names. They are gotten via the CyGlobeLayerManager's getButtonStyle method. They may be hardcoded in the .exe.)
 
WIDGET_GLOBELAYER does appear in the dll in the widget types enums (enums.h file) but its only further reference there is in cyenumsinterface.cpp(449): .value("WIDGET_GLOBELAYER", WIDGET_GLOBELAYER) which is simply meaning its being reported to Python.

I'm not understanding everything here but I'm hoping this conversation can help primemOver. It has been some interesting information for sure. I'm quite certain a more full understanding of CvMainInterface.py would provide an easy solution to the problem here...
 
@Hydro New Forest is already in the game - but it does not seem to be working properly. You plant a Tree Nursery which grows into a Young Forrest which then grows into a normal Forest. There are three problems with this as far as I can tell
1) the AI (and automatic workers) prefer to chop down existing forest to plant Tree Nurseries and there is no way to limit the build to not forest.

2) the Mew Forest graphic is not working well - may just be that I have not programmed properly

3) the New Forest does not seem to grow into normal Forest.​
This is all part of ModifiedA4's mod. I think I have the terraform to forest now working so that the resultant forest can be worked.

Oh. And what about the Ancient Forest?
 
@Hydro and Tbird

I feel the same way about the forest/terrain/soil issue as I feel about other issues in C2C. I am not going to make an artificial (contrived) system for something that can be done realistically and naturally. If that requires some XML changes then fine; some XML has to change. I will change it myself if no-one else wants to do it. That is the nature of adding new features to a game.

The system and terrains/values that exists are inadequate for the high level of doable realism I am trying to achieve (though they are MUCH better than BtS vanilla). If you want to use the logic you are using then by that logic we should remove all the dry terrains you have added except rocky since there are (in reality) far more wet terrains than dry terrains. The system that I have created making terrains soil terrains is more realistic, logical and it will work, mimicking reality very well. Period. There is no debate here. If you want realism I will add the soil terrains that are necessary to make it that way. If you don't want realism then I will stop working on this project and save it for my own purposes.

@everyone else
THANK YOU for the tips in getting the graphics going. The questions about "where" would still help (some of you have asked for me and thank you). I may wait for AIAndy to be available before I embark on this journey (provided people still want me to finish this project) since he is the UI guru but I appreciate the heads up.
 
If you really want me to break down the entire model I plan on using, I will do that. I will post a chart with the terrains, their statistics, and their rationale. (I should probably do this eventually anyway before modifying the terrains... that has not yet been done). But you will need to give me some time to create it. In the meantime just look at past posts in this and/or the Biomes files discussion. I have listed the ones I was thinking of off the top of my head at least twice.
 
I think climate and weather is going to be as big a deal as subdued animals, not necessarily better, but almost as cool. After all they affect the progress of civilizations and battles very much. Great to see you guys working all together on this. :)
 
If you really want me to break down the entire model I plan on using, I will do that. I will post a chart with the terrains, their statistics, and their rationale. (I should probably do this eventually anyway before modifying the terrains... that has not yet been done). But you will need to give me some time to create it. In the meantime just look at past posts in this and/or the Biomes files discussion. I have listed the ones I was thinking of off the top of my head at least twice.

That would be wonderful! Please do! :goodjob:
 
@Hydro and Tbird
If you want realism I will add the soil terrains that are necessary to make it that way. If you don't want realism then I will stop working on this project and save it for my own purposes.

Well, we have had this discussion before. I think what it all comes down to is that you and I on the one hand and Hydro on the other hand just have very different design philosophies when it comes to the terrains. Ours is pretty "scientific" and strives for as much realism as is doable, while Hydro's is more artificial and "game-like". Personally, I prefer the former, but it really comes down to a matter of personal taste - there are players who would prefer the latter, and that is alright!

Just as a thought, would it be possible to build the GeoRealism engine in such a way that it works with different mods and different terrain sets? To program more of a general planet generating engine which can then be plugged into different terrain sets, similar to some of the map editors people have made? Or would the additional work be prohibitive?

In any case, posting an up-to-date terrain chart would be a good idea, I think, since some things have changed since we started working on this. This might also help answer my question from my previous comment, about what, exactly, we mean by "climate", "biome" and "vegetation" (I assume I understand the difference between "climate" and the others, but I am not clear what the distinction between "biome" and "vegetation" is).
 
Back
Top Bottom