C2C SVN Changelog

[Koshling]

Just pushed to SVN (4892):

• Allowed the DLL to run with assets that define fewer game options than the DLL knows about (older assets)
• Numerous performance optimizations

The performance optimizations should be fairly significant for more mature games, though they won't have such a dramatic effect on earlier stage games.

 

[Thunderbrd]

Allowed the DLL to run with assets that define fewer game options than the DLL knows about (older assets)

I suppose this would enable us to put a game option in a module - presumably. But what if the load sequence makes it load in later than others added subsequently in the core and thus throws it out of sequence with the enum definition?

 

[AIAndy]

I suppose this would enable us to put a game option in a module - presumably. But what if the load sequence makes it load in later than others added subsequently in the core and thus throws it out of sequence with the enum definition?

Loading order matters in regards to keeping it synced with the enum.

 

[Thunderbrd]

I figured. Just wanted to be clear on that. So this does NOT mean that we should feel free to put game option definitions in modules and not in the core.

 

[Koshling]

I figured. Just wanted to be clear on that. So this does NOT mean that we should feel free to put game option definitions in modules and not in the core.

No, it was just so I could continue to run with my existing assets for continuity of performance measurements really.

 

[dexter_inside]

Disabled how? Can you clarify exactly what you mean please.

The revolutions button in the top right corner just vanished after SVN update.
Also the revolution bars from the city screen.

 

[strategyonly]

I suppose this would enable us to put a game option in a module - presumably. But what if the load sequence makes it load in later than others added subsequently in the core and thus throws it out of sequence with the enum definition?

Loading order matters in regards to keeping it synced with the enum.

I figured. Just wanted to be clear on that. So this does NOT mean that we should feel free to put game option definitions in modules and not in the core.

No, it was just so I could continue to run with my existing assets for continuity of performance measurements really.

I am really on the fence on this GameOption/Modular stuff, i really DONT like it, it takes away from the concept of the modular, IMPO

 

[Koshling]

The revolutions button in the top right corner just vanished after SVN update.
Also the revolution bars from the city screen.

Ah - that must be due to the error in Revolusions.py then - I think DH has fixed that already

 

[dexter_inside]

Ah - that must be due to the error in Revolusions.py then - I think DH has fixed that already

That would be great, no Revolutions takes the fun out of Deity Should I try the HEAD revision again?

Edit: Thanks for the 4892 commit, it saved my game

 

[strategyonly]

Found more ArtStylye duplicates:

Japan:
2 Pikeman
2-Longbowman
2-Heavy Pikeman

 

[Koshling]

Just pushed to SVN (4894):

• Fixed AI skipping attacks incorrectly (reported as animals not attacking)

 

[Vendayn]

Has there been tweaks or something to gold amount from religion/civics or something? I was making 10-15, then I updated yesterday and it went down to 3-4 (that was before I made a couple new cities). So new cities did take me down a lot (this is in ancient era btw, but think I was in prehistoric yesterday morning)...but then last night I was making 3-4 gold a turn after doing a bunch of stuff.

Updated late last night, and now it is minus 3-4 gold. Though, I haven't updated yet today...been taking a break.

Guess balance changes or something? Just was strange to be making 10-15, and suddenly drop to 3-4 and then drop again after a while, to minus 3-4. Not a big deal right now since I have a lot of supply and can just build gold buildings, but was just curious.

 

[Koshling]

@TB - bug in the code merged from TheLadiesOgre:

Couldn't say whether this is a merge bug, or a bug in the original code, but I think you need to look at it. In this code (in CvUnitAI.cpp):

bool CvUnitAI::AI_paradrop(int iRange)
{
	PROFILE_FUNC();

	if (getGroup()->getNumUnits() > 1)
	{
		return false;
	}
	int iParatrooperCount = plot()->plotCount(PUF_isUnitAIType, UNITAI_PARADROP, -1, getOwnerINLINE());
	FAssert(iParatrooperCount > 0);

the assertion is going off, because of the extra calls now present to this method due to the merged code, such as this in Ai_attackMove():

/*****************************************************************************************************/
/**  Author: TheLadiesOgre                                                                          **/
/**  Date: 16.09.2009                                                                               **/
/**  ModComp: TLOTags                                                                               **/
/**  Reason Added: Implement AI_paradrop for other UNITAI's now that it is potentially available    **/
/**  Notes: 14.10.2009-- Moved higher and added bCity check                                         **/
/*****************************************************************************************************/
	bool bCity = plot()->isCity();
	if (bCity)
	{
		if (AI_paradrop(getDropRange()))
		{
			return;
		}
	}

/*****************************************************************************************************/
/**  TheLadiesOgre; 16.09.2009; TLOTags                                                             **/
/*****************************************************************************************************/

The code is now called for arbitrary units, because they may gain paradrop ability as a promotion. However the counting of paradrop capable units in the line:

	int iParatrooperCount = plot()->plotCount(PUF_isUnitAIType, UNITAI_PARADROP, -1, getOwnerINLINE());

does not take this into account. It needs to be changed to actually count units that have the ability, not just count PARADROP unitAIs.

Since the value is used later in the routine to scale things, it is not just a cosmetic assertion failure.

 

[Dancing Hoskuld]

Update

- Add resources Turquoise and Parrots. Note I will need to go through and lower the chance of all gem types somewhat, I have not done this since we split gems which is why there are so many of them.

I tried to add the building art (ie buttons from Hydro) to the Trade Goods- vintage wine buildings but get a bdependancy... tag missing. None of the other files have it on so I am not sure what is happening.

Edit Update

- Activate OV's Immigration mod (Only needed the MLF turned on after I finished the tests)

 

[rightfuture]

I am really on the fence on this GameOption/Modular stuff, i really DONT like it, it takes away from the concept of the modular, IMPO

I think it is important to concretely define what is part of the core C2C experience vs what is important to the core programming.

Modular programming separates the experiments, both individual and group, as well as the alternative (more unstable) options/choices from gameplay to work out their necessity, bugs, speed, and balance to improve core gameplay.
To have the best worlds, to have a streamlined and stable core, and including improving and varying ideas, options, opinions, and ongoing vision, means organizing things effectively.

A stable core that slowly includes proven improvements from the modules.
AND flexible/selectable modular group and individual experiments to test ideas until they are ready to be included as default. You want regular and ongoing ideas/work flow from
core<modules<mod-mods<idea projects<threads<ideas
in threads from
exterior sources>players(new>old)>C2C community>new/existing modders>ModTeam>best established hierarchy
of good judgement and area of most desire/expertise.

This organizes the pursuit of these modules and path of inclusion better.
Ideas which show new potential to be improved upon, can also be shifted back from the core (add selectable triggers and isolated to move to modular function) so that function can be toggled between working basic and modular (improving/experimental) to give maximum accessibility. Areas which require regular tweaking, AI, gold balance, research, turn/game time/difficulty/era timing adjustments, etc. can be localized (as much as possible) and accessed from the core by linking them and organizing them into regular modules which encompass them. Making a category module that links to the gold affects of all buildings may be easier said that done, but it would make regular adjustment easier and rollbacks/variations more accessible.


Mod-Mods themselves should be external explorations or deviations which explore large changes, or philosophies which deviate from the vision of the mod, and regular explorations/experimentation until they are proven ready/popular to be included as modular in the SVN modules. They are more proof of concept, individual explorations, add on (modular) themes, controversial variations, etc. than ready to be included modules.

For clarification and example:
-Subdued animals is now more of a core C2C experience,
-Revolutions more of a group module which should be more of an experimental one to be reworked,
-Multi-maps and Viewports more of a group than individual experimental module now,
-Leader traits more of a individual module until made a group one,
-the Combat Mod is more of a mod-mod until made a individual or group module,
-Advanced Civics was a mod-mod which became core (perhaps a little quickly)

At the appropriate point of discussion, these things should be shifted between these areas for development.
Core, modules, and mods-mods should stay compatible within a version.
A changing core should line up with the changing modules as things are shifted.

For Example: when features are moved between core and modules a new .1 version is added for both core folder and module that lines up.
Let's say you moved a new lightsaber unit from ls612's folder to the core.
If it is significant enough or risky change. You would make 2 versions of each folder. 1 before and after the move- so you can revert. LS612 V28.0 Core V28.0 versus LS612 V28.1, Core V28.1. All compatible folder changes can have maintain the same .1 version number. (The .1 thing is just an idea for reversion. Still haven't mucked around enough with the SVN to be familiar with how it works. Good reason to be motivated.)

The point is organization of both worlds. I think going either way too much is a mistake.
Modular exterior, streamlined core interior. Make modules of all key features as makes sense, make group and ind modules as make sense. Move them around as wise. Let mod-mods be projects, let modules be accepted working experiments.
Better Organization = Ease of Use/Improvement (worth the time to have ongoing group discussions on improving this)
Just my 2 cents on the subject.

 

[Dancing Hoskuld]

You are forgetting that some of the core C2C concepts are written by others and we keep them in modules to emphasise their contribution. This is the case for Orion Veteran and The_J.

 

[rightfuture]

I completely agree with this, especially the individual folders, but my point was to organize things (beyond that) more effectively. Modularity in different places affects speed and stability so profoundly, I wanted to chime in on why modules and core function should be separate to some degree.

Please forgive my lack of understanding beyond that, because I have chosen to not dive deeper, yet! (yet another argument to get around to learning the specifics and participating immediately)
I am assuming we want to encourage more of their development? I am all about emphasizing and encouraging people's personal and group contributions. (if code could just be colored.and contributions grouped and sorted on the fly to identify changes and contribution...

 

[Hydromancerx]

Updates
- Applied Turquoise and Parrot resources to buildings.

 

[Thunderbrd]

@TB - bug in the code merged from TheLadiesOgre:

Couldn't say whether this is a merge bug, or a bug in the original code, but I think you need to look at it. In this code (in CvUnitAI.cpp):

bool CvUnitAI::AI_paradrop(int iRange)
{
	PROFILE_FUNC();

	if (getGroup()->getNumUnits() > 1)
	{
		return false;
	}
	int iParatrooperCount = plot()->plotCount(PUF_isUnitAIType, UNITAI_PARADROP, -1, getOwnerINLINE());
	FAssert(iParatrooperCount > 0);

the assertion is going off, because of the extra calls now present to this method due to the merged code, such as this in Ai_attackMove():

/*****************************************************************************************************/
/**  Author: TheLadiesOgre                                                                          **/
/**  Date: 16.09.2009                                                                               **/
/**  ModComp: TLOTags                                                                               **/
/**  Reason Added: Implement AI_paradrop for other UNITAI's now that it is potentially available    **/
/**  Notes: 14.10.2009-- Moved higher and added bCity check                                         **/
/*****************************************************************************************************/
	bool bCity = plot()->isCity();
	if (bCity)
	{
		if (AI_paradrop(getDropRange()))
		{
			return;
		}
	}

/*****************************************************************************************************/
/**  TheLadiesOgre; 16.09.2009; TLOTags                                                             **/
/*****************************************************************************************************/

The code is now called for arbitrary units, because they may gain paradrop ability as a promotion. However the counting of paradrop capable units in the line:

	int iParatrooperCount = plot()->plotCount(PUF_isUnitAIType, UNITAI_PARADROP, -1, getOwnerINLINE());

does not take this into account. It needs to be changed to actually count units that have the ability, not just count PARADROP unitAIs.

Since the value is used later in the routine to scale things, it is not just a cosmetic assertion failure.

So you're saying I actually have to think about this? lol.

I'm a little unclear as to what he did there... I wasn't sure if he was making it so that units could be MADE paradrop capable or simply increase paradrop capability if they had it. I'm wondering... about the best way to go about it... would that PUF take into account secondary AI settings or only primary? One thing that would aid the AI here would be if taking a promo that provides paradrop capability would add UNITAI_PARADROP to the unit's AI sub-selections. Would that resolve the problem AND give the ai something to work with there at the same time?

 

[Koshling]

So you're saying I actually have to think about this? lol.

I'm a little unclear as to what he did there... I wasn't sure if he was making it so that units could be MADE paradrop capable or simply increase paradrop capability if they had it. I'm wondering... about the best way to go about it... would that PUF take into account secondary AI settings or only primary? One thing that would aid the AI here would be if taking a promo that provides paradrop capability would add UNITAI_PARADROP to the unit's AI sub-selections. Would that resolve the problem AND give the ai something to work with there at the same time?

AFAIK (go look at the PUF) it only checks the unit's current operating AI type. Also changing that PUF to do anything wider would probably break other uses, so you almost certainly will need a new PUFCanParadrop or something and use that instead.