Improved WorldBuilder

[Caliom]

I can reproduce it. will look into it.

Edit: uploaded the fix below.

It was related to the alt-tab-fix. I forgot to reset the landmark/reveal mode when leaving the worldbuilder.
Btw. ctrl+w should still work in the messed-up wordlbuilder to close the worldbuilder screen

 

[Wessel V1]

Isn't it easier to use the WB without full screen mode? This way you can switch directly to the forums so you won't need to alt-tab anymore, it also avoids some crashes on older systems like mine.

 

[Michael Vick]

When I try to edit a tile in the provinces, it removes the province label and doesn't change it to the new one, it just leaves it blank. I might be missing a step or something?

 

[Caliom]

Is your cursor black? Then you have no province selected. Pick one either from the dropdown or by right clicking on the province of your choice. The curser should then switch to the color of the province. If you want to remove a province right click on an empty tile and the curser switches to black again.

 

[Caliom]

I looked a bit into the core and normal area editing thing.
There is a function in CyGlobalContext that exposes the normal and core areas to the dll. And it expects the areas in the currently used format (TL, BR and exceptions). Therefore is see no chance to change the format now.
For the core areas i could ignore the rectangle completly and use only the exceptions. For the normal areas however that wouldn't work, bcause here the exceptions get subtracted instead of added.

I wondered for what they are used in the dll at all and did a quick search. Thats what i found:

Spoiler :

CvGame.cpp::safeMotherland
- uses Core- and Normal Areas. Does not use exceptions!
- used in RiseAndFall.py collapseMotherland : collapses ai civs that have no cities in their core area and control less cities in the normal area than the other civs together and is no vassal of anyone.

CvRhyes.cpp::MiroBelongToCore
- uses Core Area
- used in CvGame.cpp calcLastOwned: counts the number of cities in a players core area that are owned by another player and stores it in lOwnedCities. The function and the variable are exposed to python(CyGlobalContext) but not used anymore.
- used in CvGameInterface.cpp updateColoredPlots: visualizes the core area of a player
- used in CvGameTextMgr.cpp setPlotHelp: related to the visulization of core area (see above)
- used in CvPlayer.cpp countExternalCities: counts the number of cities for a player that are not in his core area.
- used in CvPlot.cpp setCulture: prevents that foreign culture covers the core area of a player within the first two turns of their spawn.

CvPlayer.cpp::countExternalCities
- uses MiroBelongToCore (Core Area)
- used in CvPlayerAI.cpp AI_civicValue: AI values civic Imperaialism more if it has many cities outside of core area.
- is also exposed to Python (CyGlobalContext) but not used

CvRhyes.cpp::MiroBelongToNormal
- uses Normal Area
- used in CvGameInterface.cpp updateColoredPlots: visualization
- used in CvGameTextMgr.cpp setPlotHelp: visualization
- used in CvGame.cpp cityStabilityExpansion: seems to be not used in RFCE (provinces are used instead)


Of course the areas are used in python directly as well
RFCUtils.py collapseImmuneCity: Implements UP_Emperor: Civ cannot collaps in their core area as long as it controls its capitol

RiseAndFall.py
- initMinorBetrayal: Core Area
- initBirth: Core Area
- fragmentBarbarians: Normal Area
- findCivToResurect: Normal Area
- convertBackCulture: Normal Area

To summarize it
- Core Areas in the dll are used for:
- - AI evaluation of Imperaialism civic
- - Keeping the spawn area culture free for 2 turns.
- - Collapse AI civs if the do not control their motherland any more.

- Normal Areas in the dll are used for:
- - Collapse AI civs if the do not control their motherland any more.

Proposals
1. leave everything as it is. Core and normal areas have to be edited in the python files manually.
2. leave the format as it is, but move it to RFCEMaps.py. Try to come up with an interface that lets you draw the rectangles in the worldbuilder.
3. leave the format as it is, move it to RFCEMaps.py, but do not use Rectangle for core areas (only exceptions). This would make it easier to edit in WB. For normal areas either do
3.a the same (Then they cannot be used in the dll any more. This would break safeMotherland. That means Cordoba would collapse immediatly after respawn without futher changes) or
3.b do not make them editable in WB
4. change the format. This would make it easier to edit in WB, but would require changes to the dll and the python code.
5. Reconsider what the core and normal areas are used for, if something can be removed and if they are needed in the dll. Then evaluate options 1-4 again.

 

[Michael Vick]

Is your cursor black? Then you have no province selected. Pick one either from the dropdown or by right clicking on the province of your choice. The curser should then switch to the color of the province. If you want to remove a province right click on an empty tile and the curser switches to black again.

Yes, the cursor is black and when I select a province from the list, the cursor remains black. However, right clicking on the tile itself does work for me.

I began to work on the city name maps again and I like all the improvements. The feature where you can look at the names for other civs especially makes editing very efficient. It seems to me though that saving the changes is a bit tricky. I went from city name map to city name map and from one application to another with no problem, but then I think I messed something up when I saved and exited. Upon loading the WB save with the changes, the entire city name map I was working on showed up in landmarks un-associated with the city name map. When I went into the city name map editor, the city name maps were as they were before I started working on them. So the changes were saved... but in the form of landmarks. A possible problem might be that I had saved without exiting the city name map editor? If you can tell what went wrong here it would probably be good to post some explicit instructions on how to make sure edits get saved properly. Then again I might be the only one with all these blunders on this really awesome worldbuilder.

Here is the map of landmarks if it helps anything, is there a way to transfer the names back to the city name map editor?

 

[Caliom]

Yes, the cursor is black and when I select a province from the list, the cursor remains black.

will fix that.

Upon loading the WB save with the changes, the entire city name map I was working on showed up in landmarks un-associated with the city name map. When I went into the city name map editor, the city name maps were as they were before I started working on them.

Did you replace the RFCEMaps.py file with the new one that was saved with your worldbuilder file? City names, as well as war-, settlermaps and provinces are stored in an extra python file. The new file is in the same directory where you saved your worldbuidler file and has the same name. Rename it to RFCEMaps.py and put it under RFCEurope\Assets\Python, replacing the old one.

So the changes were saved... but in the form of landmarks. A possible problem might be that I had saved without exiting the city name map editor?

When you save the map, while city names are visible then they will be saved as landmarks too. I see no way to prevent this at the moment. Sorry.

Here is the map of landmarks if it helps anything, is there a way to transfer the names back to the city name map editor?

If the solution above does not work, you can use the old way to extract the city names from the worldbuilder file.

 

[Michael Vick]

Thank you! It works fine, I just assumed that the improved worldbuilder went in and changed the PY file as I made every change.

This is extremely useful and soon to be bug-free, it looks like. I would upload a vanilla RFC compatible version to the forum if there isn't already something similar.

 

[Caliom]

I thought of a vanilla RFC version too. But i have a few things on my mind that i want to try first. This will make maintaining easier.

 

[3Miro]

I looked a bit into the core and normal area editing thing.
There is a function in CyGlobalContext that exposes the normal and core areas to the dll. And it expects the areas in the currently used format (TL, BR and exceptions). Therefore is see no chance to change the format now.
For the core areas i could ignore the rectangle completly and use only the exceptions. For the normal areas however that wouldn't work, bcause here the exceptions get subtracted instead of added.

I wondered for what they are used in the dll at all and did a quick search. Thats what i found:

Spoiler :

CvGame.cpp::safeMotherland
- uses Core- and Normal Areas. Does not use exceptions!
- used in RiseAndFall.py collapseMotherland : collapses ai civs that have no cities in their core area and control less cities in the normal area than the other civs together and is no vassal of anyone.

CvRhyes.cpp::MiroBelongToCore
- uses Core Area
- used in CvGame.cpp calcLastOwned: counts the number of cities in a players core area that are owned by another player and stores it in lOwnedCities. The function and the variable are exposed to python(CyGlobalContext) but not used anymore.
- used in CvGameInterface.cpp updateColoredPlots: visualizes the core area of a player
- used in CvGameTextMgr.cpp setPlotHelp: related to the visulization of core area (see above)
- used in CvPlayer.cpp countExternalCities: counts the number of cities for a player that are not in his core area.
- used in CvPlot.cpp setCulture: prevents that foreign culture covers the core area of a player within the first two turns of their spawn.

CvPlayer.cpp::countExternalCities
- uses MiroBelongToCore (Core Area)
- used in CvPlayerAI.cpp AI_civicValue: AI values civic Imperaialism more if it has many cities outside of core area.
- is also exposed to Python (CyGlobalContext) but not used

CvRhyes.cpp::MiroBelongToNormal
- uses Normal Area
- used in CvGameInterface.cpp updateColoredPlots: visualization
- used in CvGameTextMgr.cpp setPlotHelp: visualization
- used in CvGame.cpp cityStabilityExpansion: seems to be not used in RFCE (provinces are used instead)


Of course the areas are used in python directly as well
RFCUtils.py collapseImmuneCity: Implements UP_Emperor: Civ cannot collaps in their core area as long as it controls its capitol

RiseAndFall.py
- initMinorBetrayal: Core Area
- initBirth: Core Area
- fragmentBarbarians: Normal Area
- findCivToResurect: Normal Area
- convertBackCulture: Normal Area

To summarize it
- Core Areas in the dll are used for:
- - AI evaluation of Imperaialism civic
- - Keeping the spawn area culture free for 2 turns.
- - Collapse AI civs if the do not control their motherland any more.

- Normal Areas in the dll are used for:
- - Collapse AI civs if the do not control their motherland any more.

Proposals
1. leave everything as it is. Core and normal areas have to be edited in the python files manually.
2. leave the format as it is, but move it to RFCEMaps.py. Try to come up with an interface that lets you draw the rectangles in the worldbuilder.
3. leave the format as it is, move it to RFCEMaps.py, but do not use Rectangle for core areas (only exceptions). This would make it easier to edit in WB. For normal areas either do
3.a the same (Then they cannot be used in the dll any more. This would break safeMotherland. That means Cordoba would collapse immediatly after respawn without futher changes) or
3.b do not make them editable in WB
4. change the format. This would make it easier to edit in WB, but would require changes to the dll and the python code.
5. Reconsider what the core and normal areas are used for, if something can be removed and if they are needed in the dll. Then evaluate options 1-4 again.

Core areas rectangles are done for speedup purposes, they greatly increase the speed of the game. Using only exceptions will both be slower and it will be very tricky to edit since it requires dynamic memory allocation.

Visualization of the Core/Normal areas is relatively easy, we can leave the editing manually. Those get edited only after large changes of the map only.

I can potentially take a look at changing the .dll to allow for dynamic editing, but I will do that only after the 1.0 release.

 

[AbsintheRed]

Hey Caliom!
I was thinking about some improvements for RFCE II
Not yet sure if it's a good idea, but thought about simplifing things by using only one city name map - so no syncronizing issues
Specific civ names would be handled in a separate file - so whenever a civ should have a name that is different from the general name map, they would get a new entry there
What's your thoughts on this?

 

[Caliom]

Sounds reasonably to me. With the bigger map and more civs the city name maps really blow up. I think its no problem to adapt the worldbuilder to a new system.

Have a look a SOI. They have it implemented in a similiar way. Their maps are based on language groups and a priority system in which language group to look first for each civ. The default and most complete map is in latin. Maybe you can port some things over.

 

[AbsintheRed]

Hmm, I didn't check SoI
My idea was simply to have a general city map - with names for every plot in the language that will be used for most civs (usually the civ whose core area it is)
So the tiles will have this most common name as their ID.

Then, all nations have their specific list
They get a new entry on it wherever they have a name on their own language for a plot

For example: The general map has London - this is the tile's ID as well
The Byzantine get an entry: London = Londinium
If they don't have an entry for a name, it means they will use the general name
So all civs list will only contain the civ-specific names

This way it would be extremely easy to edit/update the name maps
And after we have an initial map, everything will be perfectly syncronized

 

[AbsintheRed]

What are the benefits of splitting the civs into language groups?
Would the code be significantly faster?
(btw, I'm really not sure how hard is the city name search code on performance - especially on bigger maps)

 

[merijn_v1]

Hmm, I didn't check SoI
My idea was simply to have a general city map - with names for every plot in the language that will be used for most civs (usually the civ whose core area it is)
So the tiles will have this most common name as their ID.

Then, all nations have their specific list
They get a new entry on it wherever they have a name on their own language for a plot

For example: The general map has London - this is the tile's ID as well
The Byzantine get an entry: London = Londinium
If they don't have an entry for a name, it means they will use the general name
So all civs list will only contain the civ-specific names

This way it would be extremely easy to edit/update the name maps
And after we have an initial map, everything will be perfectly syncronized

IIRC, this is the exact way how SoI works.

 

[srpt]

yes, that is how SoI works.

 

[AbsintheRed]

IIRC, this is the exact way how SoI works.

yes, that is how SoI works.

Cool, it's a good idea then
On a related note, I should really check the latest version of SoI
It seems there are many good things to steal
Spying mode on

PS: If it works the same, what's the exact role of language groups in SoI?

 

[srpt]

language groups are used for groups of civs: Turkish civs can all share a dictionary for example or the Latin/Crusader civs. so civs can use a general language dictionary or a unique one, of they can use the unique one if it has an entry, but default to the 2nd-choice language dictonary if it doesn't. none of the dictionaries need to include the whole map, just the names you need. the way the system is set up in SoI the city will only be renamed on conquest if the conquering civ has a dictionary entry for that city, otherwise there is no re-name, so there needs to be an x=x entry for cities a civ is likely to lose and retake.

so in RFCE you could have a slavic dictionary that a bunch of slavic civs could use as their 2nd choice, with each of them having a smaller dictionary for the names unique to them that they would use as their 1st choice.

so its quite flexible and at the same time quite easy to build and even easier to add to.

 

[civ_king]

language groups are used for groups of civs: Turkish civs can all share a dictionary for example or the Latin/Crusader civs. so civs can use a general language dictionary or a unique one, of they can use the unique one if it has an entry, but default to the 2nd-choice language dictonary if it doesn't. none of the dictionaries need to include the whole map, just the names you need. the way the system is set up in SoI the city will only be renamed on conquest if the conquering civ has a dictionary entry for that city, otherwise there is no re-name, so there needs to be an x=x entry for cities a civ is likely to lose and retake.

so in RFCE you could have a slavic dictionary that a bunch of slavic civs could use as their 2nd choice, with each of them having a smaller dictionary for the names unique to them that they would use as their 1st choice.

so its quite flexible and at the same time quite easy to build and even easier to add to.

Could you have more than two dictionaries? For example civ is Genoa and entry is in Genoese dictionary then use Genoese dictionary, elif use Italian dictionary, else use Latin dictionary?

 

[srpt]

you could have as many dictionaries as you wanted as long as you included them in the re-naming code.