Current and Future Developments

[Nightinggale]

I wonder if adding demands is such a good idea. 20/turn is a lot in early game and nothing in late game. Such a demand should depend on say combined population of all cities. This way we can have something, which scales up as time passes. Selling goods is a major aspect of the game and changes should be carefully considered as they can both be great and game breaking, possibly both depending on how far you are into the game.

I don't think Civ4EuropeInfos.xml should contain <DiscoverTech>. An XML can only refer to xml files already read when they are read and if I recall correctly Civ4EuropeInfos.xml is read before the inventions. This mean the invention has to tell which "Europe" it unlocks.

 

[Lib.Spi't]

Speaking as a self confessed monkey, I don't really mind how it is done, as long as I have somewhere that shows me how it is done. Also that I don't have to write code to make it happen.

For example, I don't mind if 'discovertech' for a particular trade zone is written as an xml reference, or as a chunk in python that says:

if TECH_SILK_ROAD
TRADE_SCREEN_SILK visible
(Plus all the other words that go in this bit of python)

If I know all I have to do is copy/paste
and change the TECH string Reference and the TRADE_SCREEN Reference, then I am fine with that. (Also if I am shown two or three examples, so I know the right way to write multiple references)

I just need to know what files I need to do copy/pasting in to make the new trade screen work.

That way all it requires of my understanding and skills, is a bit of reading and word processing, rather than understanding the 'Language' and being able to create sentences in that language from scratch.

I need a Code Phrase Book. How many phrases I need to copy doesn't really bother me, as long as I know what and where I need to be copying to make it all work together.

I agree having it all in xml is nice, but it is not essential, as long as I have copy/pastable examples of how you do all the fancy things.

Like:
Revealing Trade Areas with 'trade levels' or techs (Maybe even removing a trade screen too (if possible) so that you can 'obselete' a zone)
Different Zone Prices and Availabilities (like Silk and Spice being different values, or Plate Armour Not being available everywhere)
Accessing a zone from a town or building or land plot or sea plot or both (which I think I have already been shown)
etc.

How many steps it takes doesn't really matter, as long as the steps don't require me to write code from scratch.

It's also better if it doesn't require dll modifications, as this can cause complications (like incompatible project versions) but it is not necessarily the end of the world. (As long as I am shown what needs to change)

As to the demands concept, I personally don't think this is a good idea for a trade screen, but I think it is a good idea for the local market sales system that you have. This way you can make it that selling produce locally gives you the most money per yield unit, but you can only sell X of that yield unit in a town based on the number and/or type of people in that town (e.g. Nobles buy more than serfs) But selling in a Trade Zone is Unlimited because you are selling to a vast distribution network. Trade zone to Trade Zone is then more like a Frieght business than a Product business.

 

[Kailric]

I think adding generic default traderoutes would be bad even if they can be turned off. Everything should be configurable in XML. Default trade routes could then be example code in a tutorial which people can copy paste to get say "Europe" or whatever. We shouldn't consider the case where people don't add trade routes in XML just like we don't consider the case where people makes no units available in XML.

Well, the thing is to get a functional trade route is a complicated procedure, at least for me. So complicated that I couldn't just sit down and make one from scratch and I am the one who designed it. So, the tutorial I plan on writing is for me as well as anyone else and the best way I can do this is to simply create a new moddable working trade route and take notes on every step. So, as of now I plan at add at least one generic trade route to M:C, this will also help me test things to make sure I leave nothing out of the tutorial.

I agree with Nightingale it would be best for modding if instead of a fixed set of M:C-specific trade routes like Spice Route and adding several more default ones, it could be moddable in a totally standard way with XML so modders could make & configure as they want.

This is the plan. When I said generic trade routes I meant I would add a couple trade routes that players could mod to their hearts content. Right now their are basically 3 trade routes, if I added one or two more they will all be completely modifiable and not fixed.

<UnitClassTradables>
			<UnitClassTradable>
				<UnitClass>UNITCLASS_DHOW</UnitClass>
				<iPricePercent>-20</iPricePercent>
				<bCanBuy>1</bCanBuy>
				<bCanSell>1</bCanSell>
			</UnitClassTradable>
		</UnitClassTradables>

The above code is already in the game. It is listed under Civ4UnitInfos.xml. The Coastal Merchant code below is an example. iEuropeCost is still used by the AI as they only use the default Europe Screen atm. If TradeScreenType price is not set then that unit is not sold on that trade route. Also, when I make it moddable the Europe Screen will be accessible through XML changes.

<iEuropeCost>1000</iEuropeCost>
      <TradeScreenTypes>
        <TradeScreenType>
          <TradeScreen>TRADE_SCREEN_SPICE_ROUTE</TradeScreen>
          <iPricePercent>800</iPricePercent>
        </TradeScreenType>
      </TradeScreenTypes>

The existing Civ4EuropeInfos.xml could get a few new tags to allow modding of how Europe plots link to trade screens. E.g.:

<DiscoverTech>TECH_COMPASS</DiscoverTech>
<RouteType>WATER</RouteType>
<TradeScreens>
	<TradeScreen>
		<TradeScreenType>TRADESCREEN_SPICEROUTE</TradeScreenType>
		<bAccess>1</bAccess>
	</TradeScreen>
	<TradeScreen>
		<TradeScreenType>TRADESCREEN_THEORIENT</TradeScreenType>
		<bAccess>1</bAccess>
	</TradeScreen>
</TradeScreens>

Like Nightinggale mentioned because of the xml order New Trade Route Techs will have to be assigned in the Civics.xml. TradeScreens are already in the EuropeInfos, see the below code. Also, land routes are made when you set iMinLandDistance to 0.

<iMinLandDistance>4</iMinLandDistance>
			<iWidthPercent>20</iWidthPercent>
      <TradeScreenTypes>
        <TradeScreenType>
          <TradeScreen>TRADE_SCREEN_SPICE_ROUTE</TradeScreen>
          <bValue>1</bValue>
        </TradeScreenType>
      </TradeScreenTypes>

I don't think Civ4EuropeInfos.xml should contain <DiscoverTech>. An XML can only refer to xml files already read when they are read and if I recall correctly Civ4EuropeInfos.xml is read before the inventions. This mean the invention has to tell which "Europe" it unlocks.

This situation has caused me all kinds of wasted hours and hair, trying to get the code to read XML values that were not assigned yet. Took me great pains to finally figure this out.

Like:
Revealing Trade Areas with 'trade levels' or techs (Maybe even removing a trade screen too (if possible) so that you can 'obselete' a zone)
Different Zone Prices and Availabilities (like Silk and Spice being different values, or Plate Armour Not being available everywhere)
Accessing a zone from a town or building or land plot or sea plot or both (which I think I have already been shown)
etc.

Revealing trade routes is already part of the game just needs to be moddable. Different Zone Prices and Availabilities are already in the mod. The below code is for Mail Armor. iPricePercent modifies the price default price by that much. A -1 here disallows that Yield from being bought there.

<TradeScreenTypes>
        <TradeScreenType>
          <TradeScreen>TRADE_SCREEN_SPICE_ROUTE</TradeScreen>
          <iPricePercent>150</iPricePercent>
        </TradeScreenType>
        <TradeScreenType>
          <TradeScreen>TRADE_SCREEN_SILK_ROAD</TradeScreen>
          <iPricePercent>175</iPricePercent>
        </TradeScreenType>
      </TradeScreenTypes>

Where a Trade Route is accessed will be fully moddable. I'll have options for:

Land
Sea
Any City,
Barbarian City
Foreign City
Owned Cities,
Or Cities with certain buildings

Both land and or sea is a good option also.

It's also better if it doesn't require dll modifications, as this can cause complications (like incompatible project versions) but it is not necessarily the end of the world. (As long as I am shown what needs to change)

As of now I don't see an easy way to do this without dll modifications unless I go ahead and add generic trade routes that are completely modiable. There is just so much code that goes into a trade route. Like new commands and also new automated commands so that units will "travel" to a trade route destination and the only way to add new commands is in the dll. So with my generic trade routes the commands will be there already and all you do is mod them or turn them on or off.

 

[Lib.Spi't]

Yeah I figured dll was unavoidable, but suffice to say I wants, I wants!!!!!

Give me Generic, give me tutorials, gimme, gimme, gimme!!! Now, Now, Now.

 

[Nightinggale]

This situation has caused me all kinds of wasted hours and hair, trying to get the code to read XML values that were not assigned yet. Took me great pains to finally figure this out.

I ran into a deadlock with journeyman (which I put on hold before getting it to work). The problem was that units have a default profession meaning unit is read last. However profession then has to tell which unit it trains for and there is a deadlock you can't solve simply by load order.

The DLL loads XML like this:
-read string
-look up int connected to the string
-store int

I realized this could be done differently and still work
-read string
-store string
-wait for all XML reading to finish
-read string from memory
-look up int connected to the string
-store int
-delete string from memory

This should solve the problem of two files both pointing to each other. However it uses more memory even after deleting the strings and causes a bit of memory fragmentation. Also it uses noteworthy more C++ code. It isn't something we should do just if it can be avoided, but it can be used if we need two files pointing at each other.

As of now I don't see an easy way to do this without dll modifications unless I go ahead and add generic trade routes that are completely modiable. There is just so much code that goes into a trade route. Like new commands and also new automated commands so that units will "travel" to a trade route destination and the only way to add new commands is in the dll. So with my generic trade routes the commands will be there already and all you do is mod them or turn them on or off.

I looked at travel states and the first thing which it me is how the same code is copied for all routes. I think it would be better to kill off the route specific code and instead add a new variable telling giving the index (in the xml file) of the chosen route. This mean travel to Europe and index = 1 would be travel to spice route west while index = 2 would be silk road north. This approach would allow adding or deleting routes in XML without modifying the DLL. I think it would be possible to add this approach to all trade route related code in the DLL. However the code is scattered all over the code and I haven't been able to get an overview of it yet.

 

[Kailric]

I looked at travel states and the first thing which it me is how the same code is copied for all routes. I think it would be better to kill off the route specific code and instead add a new variable telling giving the index (in the xml file) of the chosen route. This mean travel to Europe and index = 1 would be travel to spice route west while index = 2 would be silk road north. This approach would allow adding or deleting routes in XML without modifying the DLL. I think it would be possible to add this approach to all trade route related code in the DLL. However the code is scattered all over the code and I haven't been able to get an overview of it yet.

I woke up this morning after "sleeping on it" and had similar thoughts. I am not sure how your approach would work but my ideas was this...

Currently the game uses "getUnitTravelState()" to tell which route the unit travels on with the three stages of each route such as; TO_SPICE_ROUTE, FROM_SPICE_ROUTE, and _IN_SPICE_ROUTE.

We could remove the specific routes and just keep the original _EUROPE routes.

Then for instance in the CanCrossOcean() function we change to the code..

if (eNewState == UNIT_TRAVEL_STATE_TO_TRADE_ROUTE)
		{
			if (!GET_PLAYER(getOwnerINLINE()).getHasTradeRouteType(eTradeRouteType))
		    {
		        return false;
		    }

		    if (pPlot->isEurope())
            {
                
                if (GC.getEuropeInfo(pPlot->getEurope()).getTradeScreensValid(eTradeRouteType))
                {
                    return true;
                }
            }

            return false;
		}

Then in python we use a new function for units like "getTradeRoute()" to show what trade route the unit is on so that units will appear on the correct Trade Screen. Right now it uses getUnitTravelState().

Is this something like you were saying?

Also, I am sure some coder could figure out how to spawn new Commands and new Automate commands on the fly using Trade Route infos in the XML. Even with the above fix you would still need to mod the DLL in order to add the new commands.

 

[orlanth]

On second thought you're right; it could be easier & play better to just use the supply/demand system for actual cities, and let TradeRoute screens keep their own vanilla-ish system, where prices can drift randomly and will decrease there if you sell heavily. It would be best if they each have their own actual set of prices that can move independently, instead of always being fixed at a certain percent premium over others. This would also be cool for unit prices. Ie if you buy one unit a lot in a single tradescreen, <iEuropeCostIncrease> could make it become costly there, but if you discover a new TradeScreen you could still purchase a few more before sending the price up there.

About going to Trade Screens when entering cities I guess its always good to have options; but I like the existing diplomacy trade system for trading with cities directly, since you can barter and negotiate with some impact on relations, and also have the trade based on supply/demand of that city itself. Another cool option to consider would be to let some TradeScreens be ownable by a civ (such as a King civ or player having its own Europe screen), and you would only get access if having good relationship or Open Borders with that civ.

 

[Nightinggale]

Is this something like you were saying?

Quite possibly. I don't remember the details right now, but I do remember that I read the code and thought I wouldn't have added travel states. Instead I would have added route index.

Also, I am sure some coder could figure out how to spawn new Commands and new Automate commands on the fly using Trade Route infos in the XML. Even with the above fix you would still need to mod the DLL in order to add the new commands.

I don't think it will be that hard to spawn new commands on the fly. It would be something like a loop of all routes. The UNIT will then have a function in the DLL exposed to python telling if the route is available and in the right domain (the latter is the reason why it has to be the unit). Whenever the function replies yes, a new button will be added (something I have yet to find the details on how to do). Once the button is pressed, it will call a function in the DLL and give the route index as argument.

That part actually sounds pretty simple once you figure out how to add buttons. The button graphics will then have to be part of CIV4Europe.xml as we need one for each route. It is quite possible that the DLL will have to have a python exposed function providing the button given the route index as argument. There are a few details we need to investigate, but the overall I think we have the needed idea here.

Something tells me that it can't be more complex than what I did to the domestic advisor. Remember that one spawns new pages on the fly depending on stuff like how many yields the DLL has. If I recall correctly it provides 2 pages for M:C and 3 for col2071 and this is with the very same code.

 

[Kailric]

I don't think it will be that hard to spawn new commands on the fly. It would be something like a loop of all routes. The UNIT will then have a function in the DLL exposed to python telling if the route is available and in the right domain (the latter is the reason why it has to be the unit). Whenever the function replies yes, a new button will be added (something I have yet to find the details on how to do). Once the button is pressed, it will call a function in the DLL and give the route index as argument.

That part actually sounds pretty simple once you figure out how to add buttons. The button graphics will then have to be part of CIV4Europe.xml as we need one for each route. It is quite possible that the DLL will have to have a python exposed function providing the button given the route index as argument. There are a few details we need to investigate, but the overall I think we have the needed idea here.

Something tells me that it can't be more complex than what I did to the domestic advisor. Remember that one spawns new pages on the fly depending on stuff like how many yields the DLL has. If I recall correctly it provides 2 pages for M:C and 3 for col2071 and this is with the very same code.

You are on to something here. I was totally looking at this from the wrong perspective. I was thinking that the "command system" that is the CIV4CommandInfos.xml being hard coded into the DLL was our only option for unit commands but in python you can add a new button and place it any where and have it do anything. With a little bit of investigation this may prove to be doable. At the moment, though, I will save this part till last and just work on getting the other parts of the code more modder friendly.

 

[Kailric]

Hey, Night, when you start to contemplate what to work on next I would love to see the Journeyman mod brought to fruition. There could be Civics that give bonuses or penalties to the Journeyman system is what I am thinking.

 

[Nightinggale]

Hey, Night, when you start to contemplate what to work on next I would love to see the Journeyman mod brought to fruition. There could be Civics that give bonuses or penalties to the Journeyman system is what I am thinking.

Yeah I keep thinking about it and then postpone it

I spotted something else though, which could be interesting as well.

New language text reading code.
Languages are now recognized in the XML by their tag name, not by their position and it is no more necessary to have a translation of everything.
If the chosen language does not have a translation for a specific text, the English one is used instead (or if that is not there either, the first entry after Tag).
There is a new global define named LANGUAGE. If you set it to something other than Default, that tag name is used to identify the translations you want. At Default it uses specific tag names depending on the language chosen in the main Civ4 option. Use that tag if you want to add a new language that is not there in the option dialog.
Note: The tag that defines the name of the texts you add now always has to be named Tag (there were some occurrences of TAG that I corrected).

Looking at the code it looks fairly simple to implement, but it has 11 hardcoded languages. I think I came up with an idea to control number and name of languages from XML. That way we can add more languages from XML alone, which mean somebody would be able to add say Russian without touching the DLL at all.

 

[Kailric]

Yeah I keep thinking about it and then postpone it

I spotted something else though, which could be interesting as well.

Looking at the code it looks fairly simple to implement, but it has 11 hardcoded languages. I think I came up with an idea to control number and name of languages from XML. That way we can add more languages from XML alone, which mean somebody would be able to add say Russian without touching the DLL at all.

Hmm, that would be great. A lot of my Text files only has English filled, especially in InventorText, so this would greatly help that.

 

[Kailric]

I am reinventing my list of things to work on next. I remember talking about several things that needed done but may have forgot some. My list is, not encluding things in first post:

-write a tutorial on adding custom units
-finish tutorial on adding background graphics etc. to Trade Screens
-add back Invention Categories (per orlanth's request)
-play test and define the new Demand system

So, if I have said that I would do something or look into something here recently and it is not on this list please let me know.

 

[Kailric]

I didn't mean a plan with dates on it. It was more meant as task priority. We should decide what to add to the next release and then not focus on tasks not on the list until we have released. We have written so many new features since last release that it would be good to release again. Release early and release often.

Ok, so is there anything that you would like to see in the next release? I have a long lists of things to fix and tweak. They are small things, but I can post that list. I haven't had much time to work on anything lately. I am excited about the next release though with the new Civics Screen and the new Sub professions. People are downloading everyday and missing out on all this new cool stuff

 

[Nightinggale]

Ok, so is there anything that you would like to see in the next release?

Lots of stuff like journeyman and network stability, but we better postpone that for a later release as we shouldn't postpone the release that long. There will always be something, which could be improved.

I have a long lists of things to fix and tweak. They are small things, but I can post that list.

Do post it. I only have afew items for the list.

1. economy balance
   I will playtest to see if I'm happy with how it is now.
2. add art to git before making the actual release
   We shouldn't have such a huge difference between git and what we release. Still not music on git though.
3. Rename types into something more fitting
   Types are stored in a savegame. Renaming before a release could be the thing needed to make 2.1 savegames work in 2.1b or 2.2.
4. Look at the memory manager to ensure that it works as intended
   Maybe we should even disable the MM in a release as technically it is on the alpha stage. Nobody really tested it well enough to clear it for a stable release.

I am excited about the next release though with the new Civics Screen and the new Sub professions. People are downloading everyday and missing out on all this new cool stuff

This is a very valid reason for releasing and more or less an argument for stating we should have released long ago.


We should consider a more organized way or releasing, or rather how to handle the release in git. First of all we should tag the revision we use for the release as it would be very beneficial for later log reading and code diff.

One often used method is to make a branch of the release version. Say we call it release 2.1. We then continue working on master or whatever branches we work on. When somebody finds a bug, which is also present in 2.1, the bug is fixed in master and then that single commit is cherry-picked into "release 2.1". Eventually we can release 2.1b, which has all the 2.1 fixes, but is without the post 2.1 experimental features. When we reach 2.1d or something we will have a really stable release.

We repeat this with a 2.2 branch later on.

One cool thing with this approach is that we can make the release branch BEFORE releasing and then we can test and write stability fixes in the branch while normal development continues (possibly by other people). This branch is then a beta test for the release and if we get people to play it, we can (hopefully) find bugs before making the real release.

EDIT: it would likely be wise to follow public available standards for branches. http://nvie.com/posts/a-successful-git-branching-model/

 

[Kailric]

add art to git before making the actual release
We shouldn't have such a huge difference between git and what we release. Still not music on git though.

Ok, I can do this. We talked about doing this in pak files right?

Look at the memory manager to ensure that it works as intended
Maybe we should even disable the MM in a release as technically it is on the alpha stage. Nobody really tested it well enough to clear it for a stable release.

What exactly is the MM? I must have missed this or over looked any posts about it.

We should consider a more organized way or releasing, or rather how to handle the release in git. First of all we should tag the revision we use for the release as it would be very beneficial for later log reading and code diff.

I'll be sure to tag but what would you suggest as to be organized?

One often used method is to make a branch of the release version. Say we call it release 2.1. We then continue working on master or whatever branches we work on. When somebody finds a bug, which is also present in 2.1, the bug is fixed in master and then that single commit is cherry-picked into "release 2.1". Eventually we can release 2.1b, which has all the 2.1 fixes, but is without the post 2.1 experimental features. When we reach 2.1d or something we will have a really stable release.

Yes, this is brilliant idea, let's do this.

EDIT: it would likely be wise to follow public available standards for branches. http://nvie.com/posts/a-successful-git-branching-model/

I'll look into this.

 

[Kailric]

My current TODO list:

Priority

• -Add consequences for getting behind on Civic Upkeep. Accumulative 10% chance each turn that the Civic Option will revert back to Basic Civic.
• -Play test and adjust the Yield Demands and Overflow sells
• -adjust or remove the Tavern ability to gain Fealty by autoselling Ale
• -Failed Assert in the Multi Yields Consumed code, actual produced does not match up if one of the required yield types are missing
• -Fix research pact as it didn't seem to be working
• -add in game tutorials for new features
• -finish any aspects to the new Luxury Unit/Civic relationship and playtest
• -check Luxury Units and Immigration to make sure it is working as intended
• -Nobles shown in "Conquest Advisor", this should be Nobles/Commanders/Chaplain
• -Is the Viking Age to fast, are the Saracen arriving to quick for the player to handle them?
• -Return trip from the East or West side of map Commands Added in trade screens
• -When units are attacked by Bandits they are taken to "nearest friendly city" not just owned by player. At some point I want to add difficult or player option settings that turns this on and off to make the game more or less hostile
• -Make sure Knights and Knight promotions are working as intended. Knights should only be available under Feudalism. You can choose the Feudalism Civic in times of War as it grants you the Knight Profession.
• -Travel to Fair became instant in my last game. Make sure this at least takes one turn. This also needs to be prevented if a City is under siege as it could trade indefinitely for food and this isn't logical.
• -The Center plot of cities auto builds advanced Roads. My units were building Stone-paved roads on city tiles. This should be done automatically.
• -check into Silk prices as they may be unbalanced. This may be a good time to change the Yields.xml to have actual Trade Screen prices set instead of a percentage. This could also be made a float as to better work for adjusting prices.
• -Could trade the "Native" tech, so check code to make sure "Categories" are not tradeable.
• -There is a discrepancy in the Armor smith's building on what yield is actually being produced. The yield help text does not show what yield is being produced correctly either. We should also consider how we want this to function as there has been talk of changing the functionality.
• -Could select Leather Armor in the Armor Smith's house, this should not be
• -add benefits and adjust Mints and Banks
• -AI maybe starting Conquests way to soon before they are really prepared. I may have fixed this issue when I removed some free AI yields so this needs tested again
• -Nobles can train while fortified, should they already be trained?

None Priotriy

• -add Warning to build trading post that the unit will be consumed. Add Civic changes to this effect.
• -add warning to establish missionary that the unit will be consumed. Add Civic Changes to this effect
• -add Diplomatic measures so that you can ask Barbarian Civs to prevent their attacks by pirates/raiders/Saracen for a specified amount of turns, or per turn. "You pay us 25 gold per turn, we make sure Saracen don't bother your trading ships, aye?"
• -Hire ship command so if you find a lone farmer a million miles away from your cities you can hire a ship at nearby village to escort the unit to nearest city.
• -add Graphical adjustments to Great Generals
• -add unique art or skins for the Sub professions

 

[Nightinggale]

Another thing we should do before releasing is getting new button art. There are 3 identical buttons in domestic advisor.

 

[Kailric]

Ok, I'll do that. I'm not going to worry about pedia buttons just yet, but interface buttons need done so point out any more.

Also, the different screen buttons on the main interface could use some rearranging perhaps so any suggestions would be good.

 

[Nightinggale]

Also, the different screen buttons on the main interface could use some rearranging perhaps so any suggestions would be good.

I'm not sure we need to rearrange them. However it is really simple to do. The buttons are defined near the top of the file and they are displayed in the order they are written. Change the order and you have a new layout. Most of the fine is selfconfiguring meaning you shouldn't have to modify anything else.