PROJECT: AE and AOM compatibility

[Ekmek]

whoops, typo. it is layouts

[Fromafar]

Did you try renaming UI to uidata?

[Ekmek]

Sorry Fromafar I might have been screwing you up. I copied the AOM files exactly as provided so the drive path is:

english\uidata\layouts

but I'll double check tonight to make sure


EDIT:

Fromafar I confirmed it, its:

Scenarios\AoM3\scen0000\english\uidata\layouts

[Ekmek]

Protra,
Here's an upload to test out a sceario version of AoM3

http://apolyton.net/upload/view.php?file=2610_AOM3-AE.rar

To install you should unrar this into your scenarios folder (this is to set up the scenario folders)

then copy all the AoM2 and AoM3 update stuff.

then rar this again.

if you are comfortable building scenario folders make and AoM folder then a scen0000 subfolder, copy all AoM in that scen0000 folder then put the rar's default and english folders over it.

then taken the ui/layout file controlpanel.ldl from the AoM and put in your main one.

THEN the game should start, let us know how it goes. Any problems post them here. Thanks!

[Pave]

I got AOM to start up as a scenario. But, of course, not without quirks. I got the following error messages while creating the game:

• ...script.slc:1098:ADVANCE_FROM_CAPTURING_CITY_VIC TIM not found in string database
• In object AOM_StartMessages, function _DisableTrigger: Wrong type of argument
• ...AOM_frenzy9.slc:1063:Array index 1 out of bounds
• AOM_WatchTower5.slc:1308:Array index 0 out of bounds
• AOM_misc.slc:1681:Array index 0 out of bounds

The lower two messages both appear dozens of times. After that the game starts, with starting messages and all. However, there were some problems:

• Some of the colours are mixed up. The black in the minimap appears in dark red, healthbars and other usually in green are now pinkish grey, and city names are in yellow, when they should be white.
• I got other civ than the one I chose in the beginning. I had the same problem wit Civ3 mod too, and I remember this is a frequent problem with scenarios both in CtP1 and CtP2.
• In almost every AI turn, there comes an error: In object AOM_warOnHuman, fuction _Random_ Value out of bounds

Other than that, AOM was very playable The last error is propably the only critical bug, if gameplay is to be considered, along with the "other civ chosen" bug.

[Ekmek]

Thanks Pave!

I think the first four might be remedied if you have the debugSlic line in userprofile.txt set to NO.

the other three, I think can be fixed too
1) change AoM (and Civ3mod) colors.txt to match the base game.

2) same with civs, change the civs to match the base game

3) this one might also be fixed by setting userprofile.txt's debugslic to NO.

Thanks for testing. I'll do what I can to fix it!

[BureauBert]

Hi, Pave!

Regarding the "index out of bounds" errors: Switching DebugSlic off does help, but the better solution would be to "initialize" all arrays in the scripts -- like in the following example:

void_f SetupSettling() {
	int_t stlInitCount;
	army_t stlInitArmy;

	for(stlInitCount = 0; stlInitCount <= MOD_MAXPLAYERS; stlInitCount = stlInitCount + 1) {
		STL_SETCON[stlInitCount] = 0;
		STL_FRUSTRATION[stlInitCount] = 0;

		STL_FirstSettler[stlInitCount] = stlInitArmy;
		STL_SecondSettler[stlInitCount] = stlInitArmy;
		STL_ThirdSettler[stlInitCount] = stlInitArmy;

		STL_FirstSettLoc[stlInitCount] = stlInitArmy.location;
		STL_SecondSettLoc[stlInitCount] = stlInitArmy.location;
		STL_ThirdSettLoc[stlInitCount] = stlInitArmy.location;

		STL_FirstPrevLoc[stlInitCount] = stlInitArmy.location;
		STL_SecondPrevLoc[stlInitCount] = stlInitArmy.location;
		STL_ThirdPrevLoc[stlInitCount] = stlInitArmy.location;

		STL_FirstSettScore[stlInitCount] = -1;
		STL_SecondSettScore[stlInitCount] = -1;
		STL_ThirdSettScore[stlInitCount] = -1;
	}
}

I would guess that AoM's scripts are using arrays to store data for each player like in the above example -- in this case the function could easily be adapted (and you can use g.max_players instead of MOD_MAXPLAYERS). The purpose of this setup-function is making sure that the arrays are set up with the needed number of "slots"/members that will be filled with the actual data later.

I don't remember the background story but for some reason I chose to set up arrays this way in order to avoid those "index out of bounds" errors even with DebugSlic turned on.

[Ekmek]

Stan has been doing some work over at his forums to get AoM and AE integrated, the first problem was the excessive revolting of AI cities. He posted this:

Firstly, as far as I know that was never a problem in ctp2 in practice. In Cradle, every AI empire fractured. It really wrecked a lot of games and had to be fixed. In AOM I coded it so that all empty AI cities got a militia and gave the AI a small happiness bonus. That fixed it really well. The human can still get revolts if he gets a combination of happiness hits (such as miltiple rebellions).

Secondly there are no slic codes that give NEGATIVE happiness to the AI.

I went into government texts and made all sliders for Dynasty and Tyranny 2. (In AE they are 1). 1 point of happiness difference should not cause an empire to fracture. The revolt level is 67, standard happiness is about 75-76 till you get over your cap. So I cannot understand why the problem.

I conducted an experiment and now have AOM working nearly as fast as the original game by modifying city expansion code. That was the single biggest cause of slowdown. It goes so fast now by comparison that I mucked up my last game as I did not have the usualy think time during turns.

later post...

This is obviously the problem.

The first image is an AI empire manager from my AOM/AE test. Something like turn 25. It seems as soon as the ai change government first time, they max out the sliders off the scale and destroy themselves.



This is an AI empire manager from my current AOM only game. Very nice and sedate, no revolt problems.

Stan has requested that we disable the current slider calculation. Not sure you want to do this Martin, but is there a way to get around this.

[Martin Gühmann]

Originally posted by E
Stan has requested that we disable the current slider calculation. Not sure you want to do this Martin, but is there a way to get around this.

Of course I don't do this. If it does not work as advertized than we have to find the problem and fix. Instead of returning to the old crappy slider non-optimization code.

Well I don't remember what the minimum happiness criterion is right now without the code in front of me.

There could be two possibilities I used as criterion. On the one hand the minimum city content level, this is in the Standart game 73 and by the way not 75 as you introduced it in your ApolytonPack const.txt.

The other possibility is the that I took the value from the strategies.txt. And this is more probably. Since I can allow the AI to go one notch below the minimum. In this case the targeted happiness level is 72. If Stan has a value there of 60 for instance then he shouldn't wonder why the AI cities revolt. Actually having a target happiness level far below riot level isn't a good idea in Activision version either. But without the code and AOM in front of me this is all speculation.

The second problem I have with the empire managers is that they don't show the same empire. For instance the AOM image wasn't created from a 1.1 savegame by pressing the optimize slider button. A before and after image of the slider optimization algorithm is missing.

And the third problem is that I don't know whether the values there aare optimal: The savings of -18 do not seem to be right.

-Martin

[Ekmek]

Martin, if this is the code you are talking about (but it maybe old around rev622)

bool Governor::ComputeBestSliders(SlidersSetting & sliders_setting) const
{
	const StrategyRecord & strategy = 
		Diplomat::GetDiplomat(m_playerId).GetCurrentStrategy();

	bool config_found = false;
	bool found;
	SlidersSetting last_sliders_setting = sliders_setting;

	for(sint32 i = 0; i < strategy.GetNumSliderElement(); i++)
	{
		// Slider elements not very usefull, too rigid.
		// Better preferences, in which order to optimize sliders.
		const StrategyRecord::SliderElement *elem = strategy.GetSliderElement(i);

		if (elem->GetProduction())
		{
			sliders_setting.m_optimizeProduction = true;
			sliders_setting.m_deltaProduction = elem->GetDelta();

			if(sliders_setting.m_deltaGold <= 0)
			{
				sliders_setting.m_deltaGold = -1 * elem->GetDelta();
			}
			if(sliders_setting.m_deltaFood <= 0)
			{
				sliders_setting.m_deltaFood = -1 * elem->GetDelta();
			}

			found = FitSlidersToCities( sliders_setting );

			sliders_setting.m_optimizeProduction = false;
		}
		else if (elem->GetGold())
		{
			sliders_setting.m_optimizeGold = true;
			sliders_setting.m_deltaGold = elem->GetDelta();

			if(sliders_setting.m_deltaProduction <= 0)
			{
				sliders_setting.m_deltaProduction = -1 * elem->GetDelta();
			}
			if(sliders_setting.m_deltaFood <= 0)
			{
				sliders_setting.m_deltaFood = -1 * elem->GetDelta();
			}
		
			found = FitSlidersToCities( sliders_setting );

			sliders_setting.m_optimizeGold = false;
		}
		else if (elem->GetFood())
		{
			sliders_setting.m_optimizeFood = true;
			sliders_setting.m_deltaFood = elem->GetDelta();

			if(sliders_setting.m_deltaProduction <= 0)
			{
				sliders_setting.m_deltaProduction = -1 * elem->GetDelta();
			}
			if(sliders_setting.m_deltaGold <= 0)
			{
				sliders_setting.m_deltaGold = -1 * elem->GetDelta();
			}

			found = FitSlidersToCities( sliders_setting );

			sliders_setting.m_optimizeFood = false;
		}
		else
		{
			Assert(false);
			return false;
		}

		config_found |= found;
		if(found)
		{
			last_sliders_setting = sliders_setting;
		}
		else
		{
			sliders_setting = last_sliders_setting;
			break;
		}
	} 

	return config_found;
}

then it looks like const.txt was never taken into consideration for the AI. But i dont think either of us want s the ai tied only to the const.txt because some AI are happier than others

Maybe it should be some thing that compares the strategy value to the const value and picks the best one????

[stankarp]

These are some base settings from AOM, in use since I started with Hexegonian 2 years ago.

From Diffb.txt

BASE_CONTENTMENT 75# starting happiness

From const.txt

REVOLUTION_LEVEL 67
REVOLT_INFLUENCE_DISTANCE 6# city's revolt influence radius

This image is from a pure AE test game. Hexegonian recommended that the slider adjustments be made big enough to prevent the human from maximising them too easily. It is an issue in AOM as there is potentially, more happiness in the game.

[stankarp]

Stan has requested that we disable the current slider calculation. Not sure you want to do this Martin, but is there a way to get around this.

Just to clarify. I am not asking that AE be changed to accomodate AOM. I wondered how much work it would be to produce a version of AE with the slider option disabled, or even the original file the game came with, so I can test the other changes with AOM.

Many people have asked to have an AOM version compatible with the source code build.

With AOM, an enormous effort has gone into trying to get the game balance right. David (Hex) made a big issue out of making it difficult for the human to max out his sliders to exploit extra happiness in the game. That is how the current settings were arrived at.

The base happiness is probably not the issue. If I simply adjusted the slider penalties, then the human can very easily max out everything once he has a few outposts on happiness goods and built a few happiness wonders. The human will then have too big an advantage IMHO.

[Martin Gühmann]

Originally posted by E
Martin, if this is the code you are talking about (but it maybe old around rev622)

No E this is dead code.

Originally posted by stankarp
These are some base settings from AOM, in use since I started with Hexegonian 2 years ago.

Those values look alright, but the really important value concerning AI slider optimization are missing, namely MinimumHappiness from startegy.txt. So far we haven't ruled out that there is something wrong with the strategies.txt. Of course the can be something wrong with the code, but before the weekend I don't have the time to look into it.

Originally posted by stankarp
Just to clarify. I am not asking that AE be changed to accomodate AOM. I wondered how much work it would be to produce a version of AE with the slider option disabled, or even the original file the game came with, so I can test the other changes with AOM.

Of course something like this can be done, but this is the easy way and the way proposed too often. The ssimple way if this doesn't work let's ripp it. So if the AI does not work let's rip it off, MP is the future. If MP does not work, let's rip it off, but then there is no game left that can be played. So there can only be a No to the easy way. Instead going the easy way we have to fix it. And to fix it we have to find the problem. In theory the AI should be able to optimize the sliders even if there is a higher happiness penalty. That is the design.

-Martin

[Ekmek]

Originally posted by Martin Gühmann
Those values look alright, but the really important value concerning AI slider optimization are missing, namely MinimumHappiness from startegy.txt. So far we haven't ruled out that there is something wrong with the strategies.txt. Of course the can be something wrong with the code, but before the weekend I don't have the time to look into it.

Martin, are you saying that the strategy.txt that stan is copying over from AoM is missing fields. Therefoore that may be the problem? If that the case it may just require strategy.txt tweaking. Atleast I hope.

[Martin Gühmann]

Originally posted by E
Martin, are you saying that the strategy.txt that stan is copying over from AoM is missing fields. Therefoore that may be the problem? If that the case it may just require strategy.txt tweaking. Atleast I hope.

As long as I have no chance to look on Stan's strategies.txt, I cannot say anything, I just can speculate. And I don't have it here in university, it is at home. And I doubt that I feel like to switch on my home computer, today.

If MinimumHappiness is missing in Stan's strategies.txt than he has a problem, since in this case the AI trys to reach at least a happiness level of 0 and that means the AI ignores happiness altogether.

By the way this is also the expected behaviour in Activision's version, but due to something I don't recall the AI ignored this to some extend.

-Martin