Current and Future Developments

[Lib.Spi't]

Yeah, global effects doesn't quite feel right because these are more 'player' (as in each player including AI) effects as they are impacted by each players specific situation/choices/orders, globaleffects is more like the handicap options or map setup and such, it's the things that sort of effect all players equally and at the same time.

SocialEffects or CivEffects both fit quite well.

 

[Nightinggale]

Perhaps PlayerEffects as they all affect a single player. That or CivEffects would be my choice.

If it is not much work to give it a seperate folder, it would be good.

I think it is just a matter of moving the files to a new location and set the path in the DLL (it has hardcoded paths for each XML files). The real work is splitting the schema file, but since it is that massive, it would be good to split anyway and the workload from splitting the XML file into multiple files after that is minimal. Also the workload from splitting into 2 or 6 files is roughly the same.

 

[Lib.Spi't]

Yeah I always find it better to have more folders and fewer files (In each) rather than a few folders with loads of files.

For some odd reason I find it easy to 'read through' folder names than files names. Probably because the files have so many extra letter/word combinations.

 

[Kailric]

I've added the ability to give captured cities to your Vassals. If you have enough cities, or the city in question isn't worth all that much you can give it to your Vassal and collect taxes with a tax collector.

 

[Kailric]

I'm getting closer to another test version. At least from my end, not sure how much Night has left. I have a few things todo on the punch list at the start of this thread but in my current game I am down to 60 turns left. I have 27% Fealty and I am going to shoot for at least 50% by the time the 60 turns are up. I wonder if I could calculate and display what my Fealty will be in 60 turns, based on my current production, will have to check that out. That would be helpful for the below idea.

I'm thinking we could have the Fealty at 50% as a victory condition requirement that you can choose as well. This would test your managing skills that way. Lib would love this.

Besides the minor fixes and testing, the most major thing on the list would be to diversify the Teachclasses of Natives. Like I mentioned in this game I had 4 Natives all in close proximity teaching me Expert Shepard, which was no fun. I want to add a few of the other more medieval like Professions, perhaps Lumberjack, Horse Heardsman, Blacksmith, and Butcher perhaps.

 

[Nightinggale]

not sure how much Night has left.

That would be something like implementing the cache for the remaining 1/3 of the tags, then the civic file into also having a tech file, add the trait file and make the DLL use those 3 files.

I have no idea how long that will take. Sometimes I can do tasks in 5 minutes and sometimes it just takes longer. Worst is unexpected problems, which can take hours to solve.

Also since such a major part of the game have been rewritten, it should be playtested a lot before releasing anything.

One thing, which should be fixed before releasing is that I butchered the display of civic tags. It should get a nice display where it tells about all tags. I noticed that the popup in FTTW pedia groups bonuses like I want M:C to do. I will look at the code later to figure out if it can be borrowed.

 

[Kailric]

Tell me if my math would be wrong or how I can improve it. I wanted to add a help text where you could estimate where your Fealty Percent would be at the End Game before Conquest starts.

First I created a function that estimated the Cities RebelSentiment to the Conquest Turn. The part in red simply multiplies the current Bell rate by the remaining turns and is the only code that is not in the vanilla calculations each turn.

int CvCity::getEndTurnRebelSentiment() const
{
	int iTurnFactor = std::max(1, GC.getXMLval(XML_REBEL_SENTIMENT_TURN_WEIGHT) * GC.getGameSpeedInfo(GC.getGameINLINE().getGameSpeedType()).getGrowthPercent() / 100);

	int iPast = (iTurnFactor - 1) * getRebelSentiment();
	int iNew = 0;

	if (!GET_PLAYER(getOwnerINLINE()).isEurope())
	{
		iNew = calculateNetYield(YIELD_BELLS) * GC.getXMLval(XML_REBEL_SENTIMENT_BELLS_FACTOR);
	}

	if (!isHuman())
	{
		iNew *= 100 + GC.getHandicapInfo(GC.getGameINLINE().getHandicapType()).getAIRebelModifier();
		iNew /= 100;
	}
	[COLOR="Red"]iNew *= (GC.getGameINLINE().getMaxTurns() - GC.getGameINLINE().getElapsedGameTurns());[/COLOR]
	return (iNew + iPast) / iTurnFactor;
}

I then take that value and use it in the below function, which the part in red normally just gets the Current RebelSentiment, but I calculated what it would be at End Game as above...

int CvTeam::getEndGameRebelPercent() const
{
	PROFILE_FUNC();

	int iRebelSentiment = 0;

	for (int iPlayer = 0; iPlayer < MAX_PLAYERS; ++iPlayer)
	{
		CvPlayer& kPlayer = GET_PLAYER((PlayerTypes) iPlayer);
		if (kPlayer.isAlive() && kPlayer.getTeam() == getID() && kPlayer.getParent() != NO_PLAYER && GET_PLAYER(kPlayer.getParent()).isAlive())
		{
			int iLoop;
			for (CvCity* pCity = kPlayer.firstCity(&iLoop); pCity != NULL; pCity = kPlayer.nextCity(&iLoop))
			{
				iRebelSentiment += pCity->[COLOR="Red"]getEndTurnRebelSentiment();[/COLOR]
			}
		}
	}
	return std::max(0, std::min(100, (iRebelSentiment / std::max(1, getTotalPopulation()))));
}

Of course, the value is just an estimate based on the getTotalPopulation() not changing. getTotalPopulation() is only units inside your Cities, it doesn't count units on the out side.

I have 60 turns left in my game and I am at 27% Fealty. I added this new calculation to the Conquest Screen, you can hover over the Fealty Bar and it will tell you your current Fealty percent and well as your end game Fealty percent. So, it tells me that after 60 more turns, I'll be at 100%. Does this look right, or can I make it better?

 

[Nightinggale]

I would add a bool argument to the existing functions. CvTeam::getEndGameRebelPercent() would do nothing but pass it on to CvCity::getEndTurnRebelSentiment(). Let's call it bEndGame.

if (bEndGame)
{
    iNew *= (GC.getGameINLINE().getMaxTurns() - GC.getGameINLINE().getElapsedGameTurns());
}

Then make the default bEndGame = false and the existing code should work without modifications.

Other than that I would say that it looks fine.

 

[Kailric]

So, what you are saying is I should remove the int CvCity::getEndTurnRebelSentiment() const and just use a modified getRebelSentiment() with the bool you mentioned?

Well, I'll see how close the calculations are as I reach end game I should be at 100% fealty.

But, once again my game is stalled because of a bugged Delayed Response. My debugging text paid off as I know exactly what Diplomacy it was and with who. I did some testing so time for an updated bug report...

 

[Nightinggale]

Taken from the CivEffect thread.

Anyway I'm not wanting to block development of new interesting features that would be cool to implement, but if we don't have some goal for a final codebase we would easily succumb to the all too common inevitable phenomenon of Feature Creep meaning that no playable modmods can develop until its 2021 and no one is playing Colonization anymore .

This is a very valid point. We have a bunch of half finished features nobody works on and a really poor plan to aim for a release. I mentioned it earlier, but seeing that it didn't really help at all, I will bring up the topic again.

We need a plan for how to get to the next release and this time we should stick to the plan. I will finish CivEffects ASAP. Kailric is doing some foreign trade stuff, which I assume can be done by the time CivEffects is done. We really shouldn't add any other features before next release, but naturally we should test and fix bugs or it wouldn't be a stable release.

At the next release, the DLL is intended to be used for other mods as well.

After next release:

• More tags should be added to CivEffects (we talked about a number of them elsewhere). Addons only, not design changes.
• AI improvements
• more generic yield code
• Improved automated transports (the current system is way better than vanilla, but doesn't scale well)
• Update XML to make use of the new options. Plenty of DLL features have been added, but not really activated in XML.
• Fix network games (low priority)
• Add a city XML file instead of hardcoding in the DLL

As you can see I didn't really add anything major after next release. Instead we could concentrate on improving what we have because we need to aim more for quality of features instead of quantity.

 

[Kailric]

There are two main issues I want to address in response to orlanth's posts about "goal for final codebase" and those are:

1. An Economy model we can all mod to fit our own wants or desires
2. Fitting and complete Victory conditions for the current Civ types


For the Economy model, the one feature I would really like to test out is every city having its own TradeScreen model, with rising and falling prices, demands, and perhaps quantity as well. We've talked about it somewhat in a few threads and I need to get all those thoughts together for this.

For Victory Conditions, we want to preserve the Current King type independence, which I believe is done already by setting your Civ's VictoryType to 0 or default and adding a Parent Civ. Also, for none independence victory types we have added new features, like Nation States such as the Pope's cities being on the map. And your relationship with the Pope effects your relationship with other Civs but the Pope doesn't control the REF. The REF is simply an outside threat that you must deal with in order to Proclaim yourself Emperor and to preserve the Final Battle of independence type games. We lack any other proper victory condition at the moment so we go with this. Also, you'll need to convince other Civs to support your cause or you could be fighting a war on multiple fronts when you decide you are the ruler or the world. Much of this is coded already and just needs tested.

 

[Lib.Spi't]

One more 'default' type might simply be a conquest victory, that is just defeating all other players on the map.

This would be useful looking forward to WHM, where there is (probably) no nation state or REF victory.

(I would still like to repurpose the REF as the forces of discontent within your empire.)

 

[Nightinggale]

There are two main issues I want to address in response to orlanth's posts about "goal for final codebase" and those are:

I'm not sure I like the term "final codebase". It sounds like we will not work on the DLL after the next release. Instead we should add whatever we want, but additions should be controlled by XML. This mean if they aren't added in XML, then nothing changed and we will not break the mods not using the feature in question.

What I want to do before next release is to make a "final" version of XML and savegame setups.

1. CivEffects
2. No arrays in savegames. Replace all with JIT arrays as this will make savegames less likely to break
3. Make JIT arrays save even less data (I have a nice idea on how to reduce savegame file size)

That's it. Those changes could cause issues for other mods if added later, which is why I want it now. Everything else that I want to add can be added to multiple mods with few or no issues.

One more 'default' type might simply be a conquest victory, that is just defeating all other players on the map.

A sole survivor victory is a must. Also RaR has a victory where you win if you control more than 70% of the land plots (or whatever the number is). We could add a few victory conditions, but something like a victory condition can always be added later. It needs to be added to the DLL and XML and if XML isn't updated, then nothing will change. This mean if one mod adds a victory condition, then it will not affect other mods unless they intentionally modify XML files to include the addition.

 

[Lib.Spi't]

You know me, anything xml based is a big thumbs up from me.

So I guess in this goal oriented conversation we need to understand what modifications will/will not or may/may not break the core .dll.

For the purposes of this conversation in my mind I am making two definitions. Core Dll and Xml Dll.

Now I know they are one and the same but for this conversation they need a simple differentiation for 'Breakable Code base' and 'non-breakable code base'.

So Core Dll is the stuff like you just mentioned, stuff that will break 'cross mod compatibility'.

Xml Dll is the stuff that will automatically read a default (probably 'off' in most cases) for every mod, unless it has the appropriate xml entry to make it do something, and so will not affect cross compatibility, but will automatically allow any mod to use the new xml effects if it so chooses when it updates it's .dll.

So the final question from me as a duhbrain, what other modifications/concepts would/might be Core Dll, not Xml Dll? (also saying 'xml dll' is really fun )

 

[Nightinggale]

So the final question from me as a duhbrain, what other modifications/concepts would/might be Core Dll, not Xml Dll?

Good question. Hopefully nothing after the next release. I made that list because I can't think of anything else offhand, which I would like to add and would break stuff. There are a number of core features (like AI), which can be improved without breaking anything.

If we need a new setting, which has to be set, one solution could be to assert on the default setting. That way we will know which setting to adjust to fix the problem, which is more or less the same as not breaking the game.

Now that I think about it, I wrote about route movement cost. It is currently set to how many 1/60 of movement points it cost. I want to change it into how many plots one movement point can travel as this is a whole lot more friendly towards CivEffect, which can then give +1. In fact it can make a road, which cost 1 movement point and then have two CivEffects giving +1 and they stack as intended, something which isn't possible right now.

(also saying 'xml dll' is really fun )

Too bad you are writing it and not saying it

I like name core and XML parts of the DLL, though I wonder if we can make the names a bit more inspiring.

 

[Lib.Spi't]

Pfff stuff in the .dll is never inspiring, it is when you say 'this allows you to do this!' that everything gets inspiring.

For names we want Ronseal "It does exactly what it says on the tin!".

We could call it the Bang! or Explosion Dll and Xml Dll... that would make things exciting!

 

[Lib.Spi't]

Link to new thread around this issue:

Core DLL and XML DLL Thread

 

[Nightinggale]

I highly recommend everybody to follow the link in the previous post. I added post 4+5 regarding issues and possible solutions to performance vs coder friendly vs XML friendly. As this is a fundamental issue, which greatly affects all of us, we should all join the debate to find the design strategy we agree on and will follow in the future.

 

[Kailric]

I highly recommend everybody to follow the link in the previous post. I added post 4+5 regarding issues and possible solutions to performance vs coder friendly vs XML friendly. As this is a fundamental issue, which greatly affects all of us, we should all join the debate to find the design strategy we agree on and will follow in the future.

Nice, I take a break a few days and now I have a mountain of text to catch up on The WH mod thread is full of new text as well that I've missed. Yeah, I've been busy with some "real life" things (as they say) but I'll have some time to start catching up hopefully over the next few days.

I'm in the testing phase again with my work and should be basically ready to merge with CivEffects when ever that is ready.

 

[Lib.Spi't]

Most of the stuff in WHM was moved in distilled form to the new Core Vs XML thread.

It was discussing how long it would be before Xml work could begin on other mods that use the combined .dll.

The new thread was setup to discuss this, and also to discuss thoughts about how to make the combined .dll, and how to avoid future problems again like when we had 2071 break and we still don't really know why.

Oh the other part was a debate on using FF points and Research points in tech research. I think you might have already read most that though.. I think I saw you replied at one point.