Current and Future Developments

Nightinggale said:
Very important
Please do make a new clone to be 100% sure you don't have the revision with wav files hidden somewhere locally where it might resurface at some point. I really don't want to work that hard to get rid of it again.
Click to expand...

Ok, what "exactly" do I need to do? Just pull? Do I need to switch branches or stay in master?

Thanks for fixing that. I need to learn more about Git myself to know what's going on.
 
Kailric said:
Ok, what "exactly" do I need to do? Just pull? Do I need to switch branches or stay in master?
Click to expand...
Remove Medieval_Conquest and then go into smartgit and clone from SF again. That is the only way I'm 100% sure you will not push the audio files again.

After you have made a new clone, you switch to develop branch.
 
Ok, I am back to play testing. I've added a Player Message when you discover the Spice route by moving on to an access plot. Right now this is all hardcoded but I want to make it mod friendly. I have it tied into the "isFeatAccomplished" code but this isn't mod friendly so I am trying to think of the most efficient way to do this.

When a unit moves to the plot is the only place I can really think to add this code. We could:
  1. Cycle through all the TradeScreenTypes and find if it is an access plot.
  2. If it is then check if it is not discovered.
  3. If not check if it can be discovered through exploration, this is set in XML
  4. If so Discover this TradeScreen, display a message, play a movie if applicable.

Would this cause performance issues is the question? We could add a boolean to Players so when they discover all routes this part of the code is skipped.

I am also wanting to add a new XML to TradeSceens called bGoodyRoute, which means this route can be discovered through Goody Huts or Talking to Chiefs. Then add a new Goody that will reveal a TradeScreen Access plot. "The local merchants tell you of wondrous and exotic goods that can be found in far away lands."

These two additions can make it easier to open your first trade screen, while keeping each map random and staying true to beginning the game in the dark, aka the Dark Ages.

Edit: We could also edit a FF to give a free ship earlier. Perhaps one for exploring and another for trading. I think they are already there, just need to move them closer to the front.
 
The AI moves into a whole lot of plots meaning we shouldn't mindlessly add code to execute when entering plots. The question is what to do. Presumably we would need a cache of some sort.

We could do one or more of the following (in no particular order)
  1. cache is there is access from the current plot (currently possible, but the code is broken if more than one screen can be accessed)
  2. cache which screens a player can currently discover by moving into it. BoolArray(JIT_ARRAY_EUROPE) should do the trick
  3. (previous continued) skip checking if BoolArray::isAllocated() is false (can't discover any new routes at the moment)
  4. skip checking if player owns the plot in question
  5. plot vs screen domain check
  6. skip checks for AI units, at least until the AI learns to use non-vanilla Europe
In short: I think just coding a loop could be an issue, but we have plenty of options to make this without causing performance issues. Also most of the options are quite easy to implement. #6 is likely the most efficient compared to coding time. #1 is a bug, which would be good to fix anyway.

If you have a hardcoded version, which works, then I would say that it is good enough for a release. We really need to release soon. There will always be room for improvements. Changing the current modder unfriendly code to a modder friendly version is something, which non M:C mods benefits from. However M:C players will not be able to tell the difference.
 
Yep, it currently works. Just don't change the order of the Spice Route cause it needs to be in the 1st place:) What we can change before this release is like I mentioned with two early possible ways to get a ship through FFs or Trade points even.

That would give us 4 current plans to open a Trade Screen.
1. Through Trade points
2. Through discovery by ship the player builds
3. A ship from a FF Exploration
4. A ship from trade points

Then we can add goody huts later to make it 5 possible ways. Also, I want to be able to trade Trade Screen route information through diplomacy so that would make it 6 ways.

Also, I think we can mod the yield.xlm to allow the player to sell any good to the natives. Ones they do not desire could be sold at no more than half value. Not being able to trade early on was one of your biggest gripes so just looking to address this before next release for the sake of any others who would feel the same way.

What code is broken? More than one screen can be accessed from a plot but each plot has a Boolean for defining access and how far they are from an access plot. Meaning each plot knows if it is a trade screen plot or if a unit can reach an access plot from it and how far they have to travel.
 
Kailric said:
What code is broken?
Click to expand...
In CvPlot, getEurope() and setEurope() both assume the plot to have just a single trade screen access.

Maybe they should be removed and replaced with the apparently working isTradeScreenAccessPlot() and setTradeScreenAccess().

Kailric said:
Also, I think we can mod the yield.xlm to allow the player to sell any good to the natives. Ones they do not desire could be sold at no more than half value. Not being able to trade early on was one of your biggest gripes so just looking to address this before next release for the sake of any others who would feel the same way.
Click to expand...
I plan to look into yields after the next release. I realized that we can make JIT arrays, which are almost as fast as the yield groups. We can then replace hardcoded groups by adding arrays to CvPlayerAI and use those instead.

Good examples of how this would work would be military yields and raw materials. Both can be found by looping allowed professions.
Raw material would be any yield consumed by any profession
military yields would be yield cost for at least one military profession.

With some work we would not only get rid of the setup code, we would also be able to have the AI update behavior according to civics. For instance it will not stockpile yield X before they are allowed to use soldier X, which has yield X as yield cost.

Another bonus would be that if the work ends up as complete as I hope, then we could have one DLL for all mods without recompiling. However I currently lack plans for a decent amount of the yieldgroups and this rather great goal can only be reached if we can get rid of all groups.


It would likely be natural to add "native yield demands" together with this new AI understanding of yields.
 
Nightinggale said:
In CvPlot, getEurope() and setEurope() both assume the plot to have just a single trade screen access.

Maybe they should be removed and replaced with the apparently working isTradeScreenAccessPlot()...
Click to expand...

The AI still uses isEurope, but humans do not. When we teach the AI about the trade screens then we can drop the isEurope.

Nightinggale said:
It would likely be natural to add "native yield demands" together with this new AI understanding of yields.
Click to expand...

It wouldn't take but 30 mins of XML work to add all trade goods sold to Natives. Maybe you was thinking it would be more time consuming?
 
Kailric said:
It wouldn't take but 30 mins of XML work to add all trade goods sold to Natives. Maybe you was thinking it would be more time consuming?
Click to expand...
I would be thinking of cached DLL changes and how the game should use them. I wasn't particularly thinking of how long it would take.

However I really don't think we should add more to the next release as each time we add something, we need to test it well before a stable release. Because of this I will not change anything anymore unless it is both broken in the game right now and somewhat easy to fix. After releasing we can get on with real improvements again.

Actually what are we waiting for? Do we need to add more before releasing? Once we go "this is that we want to release", then we play for a whole (as many people as possible) and once we really think it is stable and that the latest additions didn't break anything, then we release.
 
I am currently working to add "Minor Civ" types to the mod. They will be different than normal natives in that they will construct several buildings, build defensives, etc.

They will have larger towns, currently Natives only have about 1 or 2 sized towns on average.

They will have two new Strategies, build infrastructure and once that is done they will stock pile weapons. They will also be able to produce their own weapons, armor, and horses.

They can Research some of the basic techs and trade them. They will however, be prone to stick to their old ways so advance techs do not really appeal to them.

Other than that they will function like Natives. I am attempting to leave the Native code alone so there can be more primitive Tribes still. For Minor Civs to function correctly they still need to be set as natives as well.

Also, I've add a combat bonus for minor Civs based on difficulty, set in Handicap.xml.

I've added another test code help text to city screens. In vanilla you can press ctrl-z to reveal the map for testing mode. In this mode you can click any city and open it's city screen. If you hold control and hover over a unit you will now see help text on all the professions the unit can have and the AI values for them. This can help you determine what professions the AI unit is preferring. If you add new professions and yields this info can help you determine what settings in the XML you need to make in order for your professions to work correctly.

Any other ideas minor Civs?
 
That sounds cool, it is always good to make the vanilla natives more interesting. How about adding a few Techs and/or Civics that enables you to advance from Native to Minor Civ status, and that enable you to advance from Minor Civ to regular civ status. After all most of the minor or barbarian civs realistically did advance to regular feudal kingdoms within the time frame of the mod. This would also be good for mods like World History in which all civs can undergo a gradual process of enlightenment and industrialization if successful, and aren't arbitrarily blocked from making any attempts at industry, trade, or progress. Games like Victoria 2 are good at this, in that you can start out as an initially backward country like Japan, but can still achieve industrialization and development if you plan well and eventually become a Great Power equal to Western civs (just like happened in real history!):p

There could be certain steps along the way, such as a tech Feudal Land Tenure enabling you to change from native "invisible borders" to having regular borders, and a tech Organized Trade that stops citizens from wandering off to give gifts for free to your neighbors, so you can instead start to trade and earn money from that. At the end of the chain would be a tech allowing you to advance from Minor to regular Civ, and you cannot get access to the most advanced techs until you reach this status.

These kind of social advancement techs should be non-tradable, and maybe also require some advanced yields to achieve. That way the more primitive civs would be demanding your advanced goods and willing to pay a high price, but you'd have to keep in mind the strategic trade-off in profiting from selling advanced goods to them while you may also enable them to gradually advance and become less easy to take advantage of, and eventually potentially become your competitor. :cool::king::viking: Also, in reality Missionaries were important to stimulating backward tribes to advance themselves and transmitted a lot of knowledge; building a Mission in native settlements could give some bonus research points to that civ as a side effect, which are otherwise hard for them to get on their own. That way you're not simply getting an endless free stream of converts, but are gradually helping that civ to advance somewhat as well.

I think most of the native-specific vanilla code seems pretty useless and largely meant to cripple them. Ie many of them make it impossible for them to make anything at all but Braves and Mounted Braves, make them focus only on Food and Horses, and there is a function "native yield destruction" that basically destroys excess yields they produce, where it would be more realistic to have them trade the surplus to neighboring civs. In the old 2071 DLL after some long tinkering I managed to deactivate most of the vanilla native-specific functions and they became more able to build buildings, produce and trade more like regular civs do.
 
I wonder also if you could have some kind of mercenary or auxiliary style contracts with minor civs, so you could buy or rent units from them? These could then give rise to 'minor nation specific units' so some nations could have particularly skillful units of one discipline or another that would be desirable to acquire for you military machine, but of course would require vassalage or good standing with that particular minor nation?
 
I posted a few tickets on sourceforge that can be worked on.


But basically the posts here have most of our ideas and planned features. Some of the Major ones that will require some extended time on but we will save for a Release all to itself are:

  • Medieval Economy Updated: Nightinggale has some planned features for this with the Trade Screens so we are awaiting his additions here.
  • New Military and Battle Tactics: this will be an overhaul of the combat code with lots of new features
  • Spies and Espionage
  • Upkeep Costs and Taxes change
  • New Civilian Promotion system
  • Castles Reworked
  • Religions added

Some Minor features (and more solo-able) are:

  • New art for all the Subprofessions
  • Ability to Hire Mercenaries
  • Events added to event system
  • Xml help text and descriptions filled in
  • New Profession: Wrangler
  • Great Generals improved
  • Animals and Hunting update
 
Adding religion code sounds like interesting task. I guess the different religions and their effects are defined in the XML and C++ takes care of storing religions for units and calculating their effects.You could have religion for every unit and the state religion.

Do you have any thoughts of the matter? Maybe religions could be also defined in Civ4CivicInfos.XML.
 
If you make it flexibly enough, it could also be used for other mods that aren't based around religions (ie units could have an Ideology like Communist/Fascist/Democratic in WW2 mod, or a Race or Species in scifi or Fantasy mods).

The most flexible way to do it would be to let a Promotion in XML designate the category you belong to. That way it can be modded to have the effects you want in any game (or could be modded to have relatively modest or no direct effects if you want.) It might be good to add a new PromotionInfos.xml tag called <PromotionGroup> , where you can only have a max of one Promotion from any category. For example PROMOTION_CATHOLIC, PROMOTION_PAGAN, PROMOTION_MUSLIM would all have <PromotionGroup>RELIGION</PromotionGroup>.

Going with Nightingale's idea where things like Religion or Race can potentially be passed down from parents to offspring, a tag <iInheritsonCityGrowth> to give a chance that Promotion is inherited when a new unit is born in that city . When city growth occurs (which is not often) it can check the current units in that city, and use a weighted average of these chances to determine what the new unit will have.

If you want to allow Civics to have some effects relating to members, you could create a Civ4CivicInfos xml tag <PromotionGroupBonuses> that can be modded to affect certain ones. For example you could choose a Civic which applies bonuses to one type and penalties to others, or choose a Tolerance Civic without big effects, for empires which have a diverse mix of citizens.
 
EDIT: moved the race/religion part of the reply to the other thread and deleted it in this post. Always nice to start writing a reply and while writing, somebody writes that you should post it somewhere else :p


Additions to the list
There are missing tasks on the list, which we already talked about. I'm not really sure they are suited for inexperienced coders, but I think we should try to make a complete list to avoid forgetting something.
  • error detecting savegame format
  • improved AI yield handling (remove yieldgroups)
  • make the AI use feeder service
  • fix network code
  • journeyman

Now that I think about it, journeyman might have become much easier with civilian promotions. All we need to do is to give a profession JIT array to each unit, which counts how many turns it have spent in each profession.
Profession XML then gain variables telling which journeyman promotion it gains and which master it becomes (default none). It then have two ints telling the experience it needs to gain each of them.

Units can then have "master promotion", which they can't learn, like master blacksmith can't learn journeyman blacksmith. However on clear promotion, the unit get journeyman blacksmith promotion.

We may also consider having CvPlayer::doTurn() call CvUnit::doTurn() for all units to make a simple approach to a function, which we know when is called and that it is called once for each turn. That could be useful for upkeep and other stuff as well.
 
I started cleaning up Sourceforge. I made user groups and assign write permissions to those groups:

DLL coder (this includes python)
  • Kailric
  • Nightinggale
  • Fullerene

Modder M:C
  • Kailric
  • Nightinggale
  • Daw
  • Fullerene

Modder Colonization 2071
  • orlanth
  • PatriotNorwood

In addition to this, admins (Kailric and me) have write permission to everything. I decided to ignore this when setting up permissions as the lists then doubles as overview of who works on that.


For the record even though only DLL coders can write to the source code, the mod specific source code (yields, yieldgroups etc) are written in the mods themselves. This mean that somebody who can only write to col2071 can change the col2071 specific aspects of the DLL.

EDIT: added Fullerene.
 
I'm still working on getting a proper implementation of Russian into GameFont.tga.

I have learned that each icon in GameFont has an ID. The functions to get a specific icon is actually functions to get their ID (an int) and then there is a general piece of code to convert an int to graphics.

Fair enough. We can display whatever we want from GameFont as long as we have the ID. I added a new button to the domestic advisor and it will add 1000 columns. Each column then has an ID and it prints the icon, which is linked to that ID. It's a fairly simple approach to get all IDs. The code is written in such a way that you just have to uncomment a single line to enable it. This mean we can keep it in the code and fairly easy enable it whenever we feel like modifying GameFont.

There is one major problem through. The exe controls what ID certain icons has. Even worse, the debugger reveal that there is no clear pattern to how the exe moves around in this file. This mean we should "ask" the exe for permission whenever we want to modify GameFont. That is clearly a bad situation.

I have come up with the idea to cut out the exe. It will still try to assign IDs, but we can make the exe stop listening to what it says. There are also some calls to gDLL->getInterfaceIFace()->getSymbolID(). We can write our own function to replace this function. This will move the entire ID<->icon matching to the DLL.

Next up is how to handle this in the DLL. First we reorder GameFont. We should have one row for each class of icons. It starts with a row for yields, then a row for buildings. We keep those like that.
After that we make a row for bonuses and then one for father points. After that we make one for FontSymbols and we have everything we have now. Russian can then be added after that.

This layout will result in the ID for an icon will be the ID for the first icon in the row + m_eID of the info class. This mean the DLL can handle everything if we just tell it the ID of the first icon in each row. We have the ID from the domestic advisor meaning it will just be a matter of providing the info to the DLL at startup. I figure if we add a new XML containing those ints, then it will be easy to set and each mod can have its own values.

With a platform like this, adding new icons, be it Russian or anything else will be much easier. In fact we may finally be able to get the correct building icons in domestic advisor.

As it appears to be easy to add new rows, I wonder if I should try to add a row for unit icons (scaled down button art). That would make the unit pages in the domestic advisor look better and it was my original goal when I made that page. I just failed to figure out how to access those images, though I gave up for the right reason: they were inaccessible at the time.

If nobody objects I will start this change ASAP.


Also regarding Russian. I have been working on getting a 3rd party tool to convert the text into the right format (I linked to it before). I have realized that we will likely not need external tools for that. All we need to do is to ensure translators set their editors to UTF-8. When the DLL reads a string from XML, it can then read it char by char. We know the IDs for each character in GameFont and we know what the IDs for the same characters in UTF-8. This mean we can make a conversion table. If read char is, then store the char ingame as X.

The result is that the DLL will act like it can read XML files with UTF-8 encoding and the XML files will that way stay human readable.

How to edit the XML files in UTF-8? Simple: Download http://notepad-plus-plus.org/
Then set it to always use UTF-8 encoding in the encoding menu and/or set it to use it by default: http://blog-rat.blogspot.dk/2010/03/how-to-make-utf-8-as-default-encoding.html
 
You must log in or register to reply here.

Similar threads

D
District tiles get bonus -underlying tile
Replies
0
Views
110
DeckerdJames
D
T
Narrowness Of Game Engine Effects Is Becoming Frustrating, I Think It Bodes Ill For Future Modding
2
Replies
21
Views
1K
tman2000
T
PrairieDad
completely confused with current mod situation!
Replies
5
Views
491
Acid.Crash
A
J
[PQ2] World Exploration Progress(in yield panel)
Replies
0
Views
89
Joxin
J
V
Civilization 6 - absolute broken trade
Replies
5
Views
359
Snowygerry
S
Back
Top Bottom