Announcement

**Locutus** · October 21, 2004, 10:58

The use of temporary variables was recommend by Activision as some of the built-in variables tended to have some quirky and very subtle bugs sometimes. Not sure if that's still the case (never really noticed it myself, beyond the late alpha builds), but there's no real harm in having temporary variables so I'm not going through 10,000+ lines of code to remove them all

The CityIsValid bug will indeed need to be fixed eventually, but it's not at the top of my priority list. With one or two possible exceptions, I don't see any cities event-tied cities being disbanded or destroyed...

**Ekmek** · July 18, 2006, 15:44

Bumping this thread after talking to Locutus.

I'll look at the scenario tonight and see how it fairs.

Look at the problems though I'm inclined to remove the SLIC that tells the AI to use transports. IF thats the source of the problem. I'm thinking SLIC the AI to use transports is no longer necessary mainly since stuff I've seen recently HERE

EDIT: Whoops. I think actually it may be your code about ships to far from cities that do damage that means each turn they need to calculate ALL the ships distance. I have yet to test of course but just a look through the slic and thats my guess. anyways as I note below we can do without that code and add hostileterrain value or use the sinking ship code now.

Also a couple of other points:

* A long time ago I made Civ3 style units for this mod. I'm thinking of adding my E tiles, those units, and my many citystyles to add flavor.

* A lot has been added to the AE code since this was introduced. Some of the ne stuff by me and in my Civ3mod.

*No longer need to Slic for elephants since we can use NeedsCityGood

*All of AG_mod.slc is no longer necessary since we now have cultureonly, civilizationonly, and citystyle only units. And we can set the advances to need Subneural ads. cutting down slic should help.

*Add Civilization bonuses (prod, food, science, gold, hp, sea movement)

*citystyle bonuses (like greek cities have more science)

*sinking ships (maybe an alt to hp decrease, or just use hostile terrain?)

*hostile terrain (definetely for deserts like gedrosians)

*visiblewonders (sort of)

*gifting units

*unit upgrading (we could do something like experience by either advances or NeedsfeatToBuild)

*city razing, liberating, etc is now in thanks to slic and code work

* Anything else we need we code code as well, I think pregnancy should be left to slic but maybe new great leaderbonuses would be easy to add just by editing unitdata.cpp to add a variable when attacking etc.

EDIT2: Can uses AddFeat Slic code to trigger some of the bonuses (like +3 happy when certain city captured) as described in the outcomments

**Locutus** · July 18, 2006, 16:13

Originally posted by E
I'll look at the scenario tonight and see how it fairs.

Thanks, much appreciated. I messed with changing rivers around in the past, didn't seem to make much of a difference. I really don't have much time to invest in this now, but if you can track down the bug I'd be very happy indeed to do what it takes to get this finished.

EDIT: Whoops. I think actually it may be your code about ships to far from cities that do damage that means each turn they need to calculate ALL the ships distance. I have yet to test of course but just a look through the slic and thats my guess. anyways as I note below we can do without that code and add hostileterrain value or use the sinking ship code now.

That was one of the first things we added and it had zero effect on performance on the regular non-Apolyton Edition game. But by all means test it.

Also a couple of other points:

This is Harlan's project and we're already releasing it without his permission as it is, I'm very hesitant to make any changes without his consent. If it's just 'under the hood' stuff of moving stuff from SLIC to TXT/EXE that's fine, but I'd rather not change anything about the gameplay if it's not something Harlan was already planning. By all means improve on this as much as you like, but release it as a seperate scenario (it can still be part of the AE of course, but copy the files to a new folder and call it "Alexander the Great -- E's Revision" or something like that).

And we can set the advances to need Subneural ads. cutting down slic should help.

That will show up in the tech tree in the GL won't it? That's ugly. Those mod files were created for a reason, they're quite elegant to work with, and it hasn't had any impact on performance in the past.

**Locutus** · July 18, 2006, 16:46

Okay, I tried it myself again with the latest playtest (had some problems getting the game to run, but worked it out on my own in the end, didn't even need your advice in the other thread but thanks anyway) and the problem still exists for me. The game is now also very buggy now, if moving units doesn't crash the game it doesn't send them where they should go either, and the wrong SLIC code seems to be triggered. I tried removing all the SLIC code, see what that did, but that just crashes the game basically as soon as you give any order or end the turn.

This is over my head, I hope you can make something of it...

**Maquiladora** · January 4, 2009, 00:15

I just started playing this scenario again now, I had a couple of problems to get it running without errors though.

1. I got a invalid argument error in this function:

Code:

HandleEvent(ArmySelected) 'AGCenterOnAlexander_F' post {
    if (IsHumanPlayer(g.player))
    {
        if (g.player == 1) 
        {
	      [b]SelectUnit(alexUnit);[/b]
	      AddCenter(alexUnit);
	      DisableTrigger('AGCenterOnAlexander_F');
        }
    }
}

As it only runs once I just left it and carried on playing.

2. When I tried to send a proposal to any of the AI's I get an error that it can find the picture for the leader. For example in the case of the Persian's it was looking for upd023.tga but this has been changed in the AE for some reason, so all the old diplomacy pictures have another "p" in, so it should be like this: updp023.tga.

I just added the extra "p" to all the photos in civ_str.txt in the Alex language directory to look like this:

GREEK_DIPLOMAT_PHOTO "updp023.tga"
AMERICAN_DIPLOMAT_PHOTO "updp010.tga"
SCOTTISH_DIPLOMAT_PHOTO "updp044.tga"
IRISH_DIPLOMAT_PHOTO "updp028.tga"
ENGLISH_DIPLOMAT_PHOTO "updp019.tga"
NATIVE_AMERICAN_DIPLOMAT_PHOTO "updp035.tga"
GERMAN_DIPLOMAT_PHOTO "updp022.tga"
FRENCH_DIPLOMAT_PHOTO "updp021.tga"
JAPANESE_DIPLOMAT_PHOTO "updp030.tga"
CHINESE_DIPLOMAT_PHOTO "updp015.tga"
RUSSIAN_DIPLOMAT_PHOTO "updp043.tga"
SPANISH_DIPLOMAT_PHOTO "updp045.tga"
PORTUGUESE_DIPLOMAT_PHOTO "updp041.tga"
DUTCH_DIPLOMAT_PHOTO "updp017.tga"
VIKING_DIPLOMAT_PHOTO "updp048.tga"
ROMAN_DIPLOMAT_PHOTO "updp042.tga"
EGYPTIAN_DIPLOMAT_PHOTO "updp018.tga"
PERSIAN_DIPLOMAT_PHOTO "updp038.tga"
TURKISH_DIPLOMAT_PHOTO "updp047.tga"
PHOENICIAN_DIPLOMAT_PHOTO "updp039.tga"
WELSH_DIPLOMAT_PHOTO "updp049.tga"
CUBAN_DIPLOMAT_PHOTO "updp016.tga"
ZULU_DIPLOMAT_PHOTO "updp050.tga"
HEBREW_DIPLOMAT_PHOTO "updp024.tga"
ASSYRIAN_DIPLOMAT_PHOTO "updp011.tga"
INDIAN_DIPLOMAT_PHOTO "updp026.tga"
THAI_DIPLOMAT_PHOTO "updp046.tga"
POLYNESIAN_DIPLOMAT_PHOTO "updp040.tga"
INDONESIAN_DIPLOMAT_PHOTO "updp027.tga"
JAMAICAN_DIPLOMAT_PHOTO "updp029.tga"
INCAN_DIPLOMAT_PHOTO "updp025.tga"
MAYAN_DIPLOMAT_PHOTO "updp032.tga"
CANADIAN_DIPLOMAT_PHOTO "updp014.tga"
NIGERIAN_DIPLOMAT_PHOTO "updp037.tga"
KOREAN_DIPLOMAT_PHOTO "updp031.tga"
BRAZILIAN_DIPLOMAT_PHOTO "updp013.tga"
AUSTRALIAN_DIPLOMAT_PHOTO "updp012.tga"
MEXICAN_DIPLOMAT_PHOTO "updp033.tga"
ETHIOPIAN_DIPLOMAT_PHOTO "updp020.tga"
MONGOLIAN_DIPLOMAT_PHOTO "updp034.tga"
NICARAGUAN_DIPLOMAT_PHOTO "updp036.tga"

AFRICAN_MAN_PHOTO "updp050.tga"

I haven't encountered anymore bugs yet, although I'm only 5 turns in. Also because of the latest AI improvements this scenario is a lot harder now, hopefully it will play well still.

Here's after only 5 turns, seiging with catapults seems essential now:

Attached Files

**Maquiladora** · January 4, 2009, 01:31

Well unfortunately it seems like a lot of code is not firing. I killed Darius on turn 12 (the Persian's are REALLY aggressive with the new AI), and I didn't get any message, gold, and Bessus wasn't created either. I'll probably look at this another time.

**Maquiladora** · January 4, 2009, 18:35

A couple of other problems.

I had to add the upgrade order line to uniticon.txt:

ICON_ORDER_UPGRADE { FirstFrame "upgradeunit_GLpicture.tga" Movie "NULL" Gameplay "ORDER_UPGRADE_GAMEPLAY" Historical "NULL" Prereq "ORDER_UPGRADE_PREREQ" Vari "ORDER_UPGRADE_STATISTICS" Icon "upgradeunit_buttonactive.tga" LargeIcon "NULL" SmallIcon "NULL" StatText "NULL" }

Also some general scenario loading problems. I'm still getting graphical problems with the UI when loading scenarios. Sometimes the frame corners on message windows is messy or missing. Also buttons like the rush-buy button is messy, like wrong format or something.

Even worse sometimes the background of the National Manager (and other list windows) is bright pink, very weird. I'll get a screen shot if it happens again.

**EPW** · July 6, 2009, 23:48

Originally posted by Maquiladora View Post

I just started playing this scenario again now, I had a couple of problems to get it running without errors though.

1. I got a invalid argument error in this function:

Code:

HandleEvent(ArmySelected) 'AGCenterOnAlexander_F' post {
    if (IsHumanPlayer(g.player))
    {
        if (g.player == 1) 
        {
          [B]SelectUnit(alexUnit);[/B]
          AddCenter(alexUnit);
          DisableTrigger('AGCenterOnAlexander_F');
        }
    }
}

As it only runs once I just left it and carried on playing.

alexUnit hasn't been set yet at this point apparently. The ArmySelected triggers too early for some reason. Besides, it won't work anyways since SelectUnit and AddCenter only trigger in context of a message.

**BureauBert** · July 9, 2009, 17:05

Originally posted by EPW View Post

alexUnit hasn't been set yet at this point apparently. The ArmySelected triggers too early for some reason. Besides, it won't work anyways since SelectUnit and AddCenter only trigger in context of a message.

Hi!

Both functions should and do work outside messages, but AddCenter needs a location as an argument

.

Code:

AddCenter(alexUnit.location);

should fix it. IIRC this bug has always been in the Alex scenario.

**EPW** · July 9, 2009, 17:32

You are right, but both functions refuse to work on the first turn.

**BureauBert** · July 10, 2009, 03:42

Well, just another idea: looking at the FindSpecialUnit function in AG_func.slc I notice that the name of the first argument to this function is identical with the name of a SLIC-function, which could cause a problem in this line:

Code:

tmpNum2 = [URL="http://www.ctp2.info/database/slic/functions/units/information/UnitType.shtml"]unitType[/URL];

This way I believe tmpNum2 will always become something invalid, FindSpecialUnit will never return 1, and specUnit will always be the player's last unit, additionally the return value oft this function isn't evaluated before using the specUnit variable, so alexUnit will always become the player's last unit, too:

Code:

// Initialize Special Unit locators
	FindSpecialUnit (UnitDB(UNIT_ALEXANDER), 1);
	alexUnit = specUnit;

Martin Gühmann also tought me to use the built-in int-functions in the proper manner, like:

Code:

if(GetUnitByIndex(tmpPlayer2, i, specUnit)) {
		tmpNum = specUnit.type;
}

I think this lesson was Martin's answer to some problem I had with one of the early AE playtest versions. I am not sure if it resolved the particular problem, but at some point I had the impression that a couple of problems were gone after I had re-worked my entire code in this sense

It could possibly also be a good idea not to use player[0] for a player other than the current one, and to use player[3] instead - just to avoid unnecessary conflicts

.

I'd suggest to try the following:

in AG_func.slc:

Code:

int_f FindSpecialUnit (int_t tmpUnitType, int_t tmpPlayer) 
{
int_t	i;
int_t	numUnits;
int_t	tmpPlayer2;
int_t	tmpNum;
int_t	tmpNum2;

	player[3] = tmpPlayer;
	numUnits = player[3].units;
	tmpPlayer2 = tmpPlayer;
	tmpNum2 = tmpUnitType;
	for(i = 0; i < numUnits; i = i + 1) {
		if(GetUnitByIndex(tmpPlayer2, i, specUnit)) {
			tmpNum = specUnit.type;
			if(tmpNum == tmpNum2) {
				return 1;
			}
		}
	}
	return 0;
}

and in scenario.slc:

Code:

HandleEvent(BeginTurn) 'AGStart_F' pre {
.
.
.
	// Initialize Special Unit locators
	if(FindSpecialUnit (UnitDB(UNIT_ALEXANDER), 1)) {
		alexUnit = specUnit;
		alexHP = alexUnit.hp;
	}
	if(FindSpecialUnit (UnitDB(UNIT_PARMENION), 1)) {
		parmenUnit = specUnit;
	}
	if(FindSpecialUnit (UnitDB(UNIT_ANTIPATER), 1)) {
		antipUnit = specUnit;
	}
	if(FindSpecialUnit (UnitDB(UNIT_CRATERUS), 1)) {
		cratUnit = specUnit;
	}
	if(FindSpecialUnit (UnitDB(UNIT_DARIUS), 4)) {
		dariusUnit = specUnit;
	}
	if(FindSpecialUnit (UnitDB(UNIT_MEMNON), 4)) {
		memnonUnit = specUnit;
	}
.
.
.
}

**Fromafar** · July 16, 2009, 18:14

Originally posted by BureauBert View Post

Hi!

Both functions should and do work outside messages, but AddCenter needs a location as an argument

.

Code:

AddCenter(alexUnit.location);

should fix it. IIRC this bug has always been in the Alex scenario.

I am sorry BureauBert, but this is not entirely correct. The argument of the AddCenter function has to be something that has a location, but is not restricted to a location_t. Using a unit_t (or city_t) variable as argument works just as well.

The original Activision scenario actually had alexUnit.location as argument. This didn't work, because there was something fishy about using an expression as argument. Introducing a variable of type location_t (and assigning alexUnit.location to it) might have worked as well, but was unnecessary, because alexUnit is a unit_t and has a location. I have updated the scenario.slc of the original Alexander scenario, and centering on Alexander did work after the modification.

There was one problem left: a save file contains a pre-parsed version of the Slic code that was active when saving it. When you load the (Activision) scenario file, you will get a warning about the invalid (expression) argument in the pre-parsed code. But when you start a new scenario, the Slic files are reparsed, so you may safely ignore this warning. You should get centered on Alexander when starting the game.

I think using player[3] is also a bad idea, but I can not remember exactly why anymore.

**BureauBert** · July 16, 2009, 19:24

The argument of the AddCenter function has to be something that has a location, but is not restricted to a location_t. Using a unit_t (or city_t) variable as argument works just as well.

I would never have guessed ... This is the kind of infomation I am instantly updating the reference with. Thank you!

But when you start a new scenario, the Slic files are reparsed, so you may safely ignore this warning.

So starting the scenario and immediately saving it again should solve it? Seems to be a better solution for a final release than just to ignore the warning ... specially for an unadverted end user/newbie

I think using player[3] is also a bad idea, but I can not remember exactly why anymore.

Well, I am using player[3] (in my "specific" functions) as well as player[9] (in my "common", basic functions -- to avoid conflicts/accidential overwriting) and in general it seems to work

. I only noticed that it is important to use "member variables" like player[3].cities immediately after having assigned a value to player[3], because SLIC tends to "forget" the value of player[3] quickly, which leads to these "index out of bounds" errors/warnings.

Usually, I try to avoid using player[x] for my own purposes, e.g. player[3].cities can be replaced by Cities(myPlayer) -- but it's the only way to e.g. figure out the government of a player other than the current one:

Code:

player[3] = myPlayer;
myPlayersGovernment = player[3].government;

I didn't notice problems with this, but with something like this:

Code:

[B]player[3][/B] = myPlayer;
for(some condition) {
     do lots of stuff
     if(some other condition) {
          possibly add an event
          do something else
          myPlayersGovernment = [B]player[3][/B].government;     <- SLIC possibly doesn't remember what player[3] was: "index out of bounds"
          and so on
     }
}

**Fromafar** · July 18, 2009, 15:50

In the reference you have the code: the "args->GetPos" line decides whether a location can be returned (BTW: army_t will work as well).

I think resaving the scenario will work, but you may lose compatibility with the original Activision game. The end user/newbie will probably have the debug Slic option disabled.

What you tell about the player[3] does ring a bell. In AOM, Stan had the same problem: any call may reset it. Too bad Activision didn't make a player_t variable type.

**Martin Gühmann** · July 19, 2009, 15:30

Originally posted by Fromafar View Post

What you tell about the player[3] does ring a bell. In AOM, Stan had the same problem: any call may reset it. Too bad Activision didn't make a player_t variable type.

If I remember correctly it wasn't supposed to work it all, it was just some usage of some invalid memory. So you fixed that it first, so that it didn't work at all, then I told you that all the slic files are littered with that, and you fixed it, at least that was it what I understood.

-Martin

Announcement

Alexander the Great v1.5

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment