Download the Super Apolyton Pack 2 Unit Updater - Page 2

Martin Gühmann · January 31, 2003, 10:28

Quote:

Originally posted by Tamerlin
Peter is working on a new version of his updater, you should look higher on this page if you want to see how it works, one of the main differences is you can update your units in the turns following the discoveries through the sleep order.

Obviously I missed something. Although I read (not shure if I really did) Peter's post, but unfortunatly I had to much to do in the last weeks.

But for the updater itself it is questionable to release code that is not properly debugged, if he send it to you and he has later to rewrite something then you could do the converting process again or has to find the changes.

-Martin

Tamerlin · January 31, 2003, 11:22

Quote:

Originally posted by Martin Gühmann
But for the updater itself it is questionable to release code that is not properly debugged, if he send it to you and he has later to rewrite something then you could do the converting process again or has to find the changes.

-Martin

You are right, this why I have sent him a message to ask him if he had found the time to work on his new updater as he was testing it to remove the last bugs.

Peter Triggs · January 31, 2003, 21:40

You're a hard taskmaster, Tamerlin.

But seriously, I would probably have kept putting off getting back to this if you hadn't decided to do a SAP version of the updater.

I haven't actually tested these files, so you get to be a Beta tester. This version is far more robust than the original. But it comes at a price: I tried to set up the original version so that if anyone wanted to use it for a mod, all they had to do was to plug in their own data. This new version doesn't work like that so I've plugged your data in and made the other necessary changes.

Also, I was working from my desktop so extract the three files to your desktop and then copy and paste them to their correct locations (overwriting the original files where necessary). I'm using the powerpoints field in Units.txt to subclassify the Unit Categories, but since neither the executable nor anyone else has used this data it won't conflict with anything.

Pedrunn, you will notice that I've 'borrowed' some of your ideas. But I've credited you in the header.

The reason that I haven't tested these files is that the version of CTP2 that I'm running is my own hybrid: it uses SAP and GOODMOD as a base but is incredibly modified. I'm coming to the conclusion that I could keep tweaking it forever, so maybe it's time to ask for a volunteer to give it a try.

And don't forget to add the line

#include APOL_updater2.slc

to APOL_main.slc

Tamerlin · January 31, 2003, 22:10

Quote:

Originally posted by Peter Triggs
You're a hard taskmaster, Tamerlin.

Quote:

But seriously, I would probably have kept putting off getting back to this if you hadn't decided to do a SAP version of the updater.

The unit updater is just what is needed to make CtP2 the perfect game.

Quote:

I haven't actually tested these files, so you get to be a Beta tester.

It is a pleasure, I will post a feedback as soon as I have the time to test your new updater. I think I will test it at the beginning of the week to come.

Quote:

This version is far more robust than the original. But it comes at a price: I tried to set up the original version so that if anyone wanted to use it for a mod, all they had to do was to plug in their own data. This new version doesn't work like that so I've plugged your data in and made the other necessary changes.

I will have a look at the inner working of your new updater though I doubt I will understand anything at all.

Quote:

The reason that I haven't tested these files is that the version of CTP2 that I'm running is my own hybrid: it uses SAP and GOODMOD as a base but is incredibly modified. I'm coming to the conclusion that I could keep tweaking it forever, so maybe it's time to ask for a volunteer to give it a try.

I volunteer, two hands up.

Quote:

And don't forget to add the line

#include APOL_updater2.slc

to APOL_main.slc

Yes, master!

Pedrunn · February 1, 2003, 00:31

Although the auto update feature is something new.
We have done exacly the same thing. Only changing the order of the 'ifs' and the names of the variables (Actually most have the same name

).

Still nice to see you still care about CTP2 modding. I hope you dont retire after this!

Pedrunn · February 1, 2003, 01:20

Did not work in my PC

What about you tamerlin?

BTW, there are two basic mistakes:

the int_t enadv[] variable is missing

and you cant use as many 'elseif' in the APOL_HasDataBaseAdvance function! There seem to be a max number of 'elseif' in a code. Therefore you must replace all those 'elseif' by 'if's and remove the last 'else' it is not needed at all. Since once a number return it stop the whole function!

Take a look in my zip a couple of posts ago. The correct function is there.

Still after fixing these mistakes the messages doesnt show up!

What about you Tamerlin?

Anyway, I have debugged my code. Seem to be fully working now. But i dont want to post it since the updater is Peter's original creation. I dont want to have him mad at me for messing up a creation he is still working on!

So should i post the debugged version of my code (still there is a minor bug but at most seem really tolerant)!

Tamerlin · February 1, 2003, 05:18

Quote:

Originally posted by Pedrunn
Did not work in my PC

What about you tamerlin?

I will launch a new game tonight but I don't know if I will have the time to play enough to test it, if not I will use the cheat menue to generate the appropriate situation.

Quote:

BTW, there are two basic mistakes:

the int_t enadv[] variable is missing

and you cant use as many 'elseif' in the APOL_HasDataBaseAdvance function! There seem to be a max number of 'elseif' in a code. Therefore you must replace all those 'elseif' by 'if's and remove the last 'else' it is not needed at all. Since once a number return it stop the whole function!

Take a look in my zip a couple of posts ago. The correct function is there.

Still after fixing these mistakes the messages doesnt show up!

What about you Tamerlin?

I post an answer tonight.

Quote:

Anyway, I have debugged my code. Seem to be fully working now. But i dont want to post it since the updater is Peter's original creation. I dont want to have him mad at me for messing up a creation he is still working on!

Quote:

So should i post the debugged version of my code (still there is a minor bug but at most seem really tolerant)!

Of course you should! I would like to test your code again.

Peter Triggs · February 1, 2003, 07:15

It was getting late.

enadv[]got changed from being a local array to a global EN_ADV[] in the new version.

When you have a long sequence of 'if's the computer will start at the top and work it's way down, examining each and every one of them. But if only one of them can be true, then it's better to use 'elseif's because, AFAIK, as soon as it finds the true one it ignores the rest of them and so is slightly faster. I broke the sequence in half to eliminate the stack overflow error. [edit: Actually, after thinking about it, in a function where the 'if' triggers a return, I doubt that it makes any difference.]

Pedrunn, I wouldn't be mad at you. The reason I kept working on this is because I've added a few things like you can only update certain units in certain locations.

Pedrunn · February 1, 2003, 08:39

Quote:

Originally posted by Peter Triggs
Pedrunn, I wouldn't be mad at you. The reason I kept working on this is because I've added a few things like you can only update certain units in certain locations.

Ity is just that our codes look so much like each other. We hould have worked together on this but i believe you are the kind of guy that likes to work alone.

My new version of the updater is here. I did some changes:

1) The broken messages for one unit upgrade are fixed!
In the messages I added what is the name of the unit to be updated and the name of the one that is going to update.

2) I have changed the order from 'Fortify' to 'Sleep' since there seem to be a problem with the first order (eg. when grouping 5 units with one that is fortified all other five units get fortified so the updater was being launched when grouping units what is something i do not want).

3) Some invisible changes to fixes the found bugs.

------------------------------------------------------------------------------------

KNOWN BUG: The first unit of an army to be updated is broken for an unknown reason! You have to say no always in order to upgrade the other units.
Eg. If you have 5 obsolete units in a army. It will scroll over the units. In the first "Do you want to upgrade" if you say "yes" it the messages to update the other units wont show up

If you say "No" the update will continue working as it should.

------------------------------------------------------------------------------------

Anyway here is the improved code. You just need to write the line

Code:

#include "updater.slc"

At the bottom of the /gamedata/default/gamedata/script.slc file and the content of the messages copied inside the /gamedata/english/gamedata/info_str.txt.

It can be used in the the Apolyton Pack (APOL_script, APOL_main_str.txt).

Here is the code:

Tamerlin · February 1, 2003, 18:52

Thanks Peter and Pedrunn for your quick replies and your reactivity.

I have almost finished the translation of Peter's Updater and I will test it tonight or tomorrow.

I will also test Pedrunn's Newupdater as soon as I can.

Tamerlin · February 1, 2003, 21:57

Peter, I have tested the Updater2 with a current game and using the cheat menue to add some units and try different possibilities.

First, the Updater2 is well triggered by an advance enabling Updates and the various options seems to work appropriately (though I am yet to see the "other type of units to update" message...)

But there are a few odd things, it is difficult to say if this is because I have not tested the updater through a whole a new game or not:

1 - After the initial cycle of update (and I am not updating all the units for the sake of the test), if I put a unit to sleep in order to update it, I have a message asking me "Do you want to update this unit?" but the unit is automatically updated before I choose "yes" or "no" and the corresponding gold is removed from my treasury.

Choosing "yes" or "no" does not have any other effect.

2 - When a unit is updated its movement range is "refreshed" and it can move again even if the obsolete units had previously used its maximum movement capacity.

3 - When there are several types of units in a stack, all the units are updated with the sleep order (voir 1) and I am not told there are other types of units waiting to be updated though the second type of units has been added through the cheat menue and might not be registered as a type of unit waiting to be updated.

Peter Triggs · February 2, 2003, 11:07

1) One of those triggers should have been disabled on startup. I had done this in a different file but just copy and paste

Code:

HandleEvent(BeginTurn) 'APOL_DisableTriggers' pre {
    DisableTrigger('AutoUpdateUnit');
    DisableTrigger('APOL_DisableTriggers');
}

right above the handler 'InitUpdateArrays' (line 33).

2) I left it like that on purpose. It would be no problem to zero out their movement if that's what people want. See what kind of feedback we get.

3) See what happens here after you've put the above handler in. BTW, you should only get the 'additional types' warning with ADVANCED_COMPOSITES or PLASMA_WEAPONRY where the advance allows you to update more than one type of unit.

Tamerlin · February 2, 2003, 16:07

Quote:

Originally posted by Peter Triggs
1) One of those triggers should have been disabled on startup. I had done this in a different file but just copy and paste...

It works fine now, thank you very much Peter.

Quote:

2) I left it like that on purpose. It would be no problem to zero out their movement if that's what people want. See what kind of feedback we get.

IMHO, updating a unit should deplete its remaining movement capacity.

Quote:

3) See what happens here after you've put the above handler in. BTW, you should only get the 'additional types' warning with ADVANCED_COMPOSITES or PLASMA_WEAPONRY where the advance allows you to update more than one type of unit.

I had misunderstood the goal of the reminder, I thought it was meant to remind you you had not updated some other older units from a previous update session.

Tamerlin · February 24, 2003, 22:24

Peter, I have spotted a little mistake in the APOL_Units.txt file, the cost of the Destroyer should be 2200 Gold and not 12 Gold.

Peter Triggs · February 25, 2003, 17:33

Oops. 12 should be the value in the PowerPoints field. And I just glanced over the file and noticed that the longship should have a PowerPoints value of 10.

Tamerlin · February 25, 2003, 19:59

Thanks Peter, I have updated my APOL_Units.txt file. Let me know if you find other mistakes.

Tamerlin · February 26, 2003, 23:57

Peter, as far as I know, the AI civs are not spending any gold for upgrading their units. As a rule I don't like the AI to be exempted from applying the general rules. Would it be possible to alter the Updater2 code so that the AI civs would have to pay the upgrades?

Peter Triggs · February 27, 2003, 16:16

It wouldn't be at all difficult to charge the AI for updates; getting it to make sure that it's got enough gold to pay for the updates is another question. I would be quite surprised if this could be consistently done: you would more than likely find that you're often sending your modern units to fight antiquated ones.

Originally, this was my motivation in writing the updater script. I thought that as you progressed through time, there was just too many old units lying around in the game and it wasn't much fun killing them off. It turned out to have a few unexpected side effects: 1) charging the human meant that he had to make added decisions about what to do with his gold, and 2) not charging the AI is like adding another difficulty factor to the game (remember, everybody always used to complain about how easy the game was).

Martin Gühmann · February 27, 2003, 16:30

Quote:

Originally posted by Peter Triggs
(remember, everybody always used to complain about how easy the game was).

Yeah it is a long time ago since I heard this complaint the last time.

-Martin

Pedrunn · February 27, 2003, 21:33

Peter, your code is indeed better than mine. Pretty much bug free. So that should be the official one! And we can forget about mine

I must remind you that like Tamerlin I dont like your cheat of free upgrading. But you could make modification in the following handler in which makes the AI upgrades its units in parts depending of the size of the stack it belong (The bigger the stack the more likely to ugrade) and the distance to the nearest city (The unit can only upgrade if in a radius 4 of the city). The only cheat is that the upgrade cost half the gold and the toleranc on the nearest city distance.

This code can not immediatly be added in you code because there are some different vaariable (Very few ons though). But you may consider thinking about that

Code:

HandleEvent(BeginTurn) 'UpgradeAIUnits' post {
int_t j;
int_t i;
int_t k;
int_t c;
int_t num;
int_t tmpPlayer;
int_t cityCount;
int_t unitNum;
unit_t tmpUnit;
army_t tmpArmy;
city_t tmpCity;
location_t tmpLoc;
	num = 9;
	tmpPlayer = player[0];
	if(!IsHumanPlayer(tmpPlayer)) {
		while(num > 0 && PlayerGold(tmpPlayer) > 300) {
			for(j = 0; j < player[0].armies; j = j + 1) {
				GetArmyByIndex(player[0], j, tmpArmy);
				cityCount = PlayerCityCount(tmpPlayer);
				for(c = 0; c < cityCount; c = c + 1) {
					GetCityByIndex(tmpPlayer, c, tmpCity);
					if(CityIsValid(tmpCity)
					&& distance(tmpCity.location, tmpArmy.location) < 4
					&& tmpArmy.size > num) {
						for(k = 0; k < tmpArmy.size; k = k + 1) {
							GetUnitFromArmy(tmpArmy, k, tmpUnit);
							tmpLoc = tmpArmy.location;
							for (i = 0; i < OLD_UNIT_TYPE.#; i = i + 1){
								if(tmpUnit.type == OLD_UNIT_TYPE[i]
								&& HasDataBaseAdvance(tmpPlayer, enadv[i])
								&& PlayerGold(tmpPlayer) > PER_UNIT_UPDATE_COST[i]) {
									CreateUnit(tmpPlayer, NEW_UNIT_TYPE[i], tmpLoc, 0);
									Event: DisbandUnit(tmpUnit);
									AddGold(tmpPlayer, -PER_UNIT_UPDATE_COST[i]);
								}
							}
						}
					}
				}
			}
			num = num - 3;
		}
	}
}

Tamerlin · February 27, 2003, 22:57

Quote:

Originally posted by Peter Triggs
It wouldn't be at all difficult to charge the AI for updates; getting it to make sure that it's got enough gold to pay for the updates is another question. I would be quite surprised if this could be consistently done: you would more than likely find that you're often sending your modern units to fight antiquated ones.

Why not allowing the AI Civs to update all their units and just set their treasury at 0 when they don't have enough money?

I suppose it would also be difficult to ask the AI civs to move their units to a fortification or a town to upgrade their units.

Quote:

Originally, this was my motivation in writing the updater script. I thought that as you progressed through time, there was just too many old units lying around in the game and it wasn't much fun killing them off. It turned out to have a few unexpected side effects: 1) charging the human meant that he had to make added decisions about what to do with his gold, and 2) not charging the AI is like adding another difficulty factor to the game (remember, everybody always used to complain about how easy the game was).

I agree with you the game is much more interesting now you have to fight against an ennemy that has up to date units. The difficulty is higher but the game really benefit from the Updater2.

Tamerlin · March 11, 2003, 22:32

Peter and Pedrunn,

I am currently finishing the game I intended to use as a full scale test of the Updater2. So far the Updater2.slc code is working fine and it is greatly improving the game. I actually enjoy it so much I think I would be unable to play a CtP2 game without it.

Great work Peter and Pedrunn!

I have only seen one bug, I have been allowed twice or thrice to update a Cavalry unit to a Tank while I had not yet discovered Tank Warfare. I think an AI civs had just discovered it though and that the Updater2 has been somehow confused.

Would it be possible to allow the Aerial Units to be also updated when they are stationed in an Air Base?

I am currently working again on new arrays that would allow you to directly update older units (like Pikemen) to their most modern counterpart (like Marines). I have added the new arrays and I now have to compute and add the Gold cost of each array which will be the cumulative cost of all the updates.

Thanks again for your work Peter and Pedrunn...

itsamic · March 19, 2003, 12:35

I tried the newupdater in a game without modswapper and without mods like APOLPack, cradle etc. and, after minor problems, it seems to work fine. But I get regular messages about global warming??? I tried with a new game so there is no pollution. I have the messages for the updater in a separate file and load this file in strings.txt via import "updater.txt"

Zaphod Beeblebrox · March 22, 2003, 09:52

as i just finished (well it became boring) my cradle game with the modified updater i was curious about one thing:
what did the powerpoints thingy do in the vanilla game?

Peter Triggs · March 22, 2003, 10:36

itsamic,

I doubt that has anything to do with the updater code. IIRC, this has occured before in one of the mods, but I can't remember which one.

Zaphod,

Nothing. They were a freebe data field; that's why I could expropriate it.

itsamic · March 22, 2003, 16:16

I've changed the messages from a separate file to a part of info_str.txt. Now the message appears only once, in the first round after loading the game. I'll ignore it....
But now I have an other question:
I have changed the Update event from the sleep to the move order. Is there an influence to the unit update of the AI? I ask because the AI seems not to update their units.
Or can someone give me a tip how to check this?

Peter Triggs · March 22, 2003, 18:48

That shouldn't make any difference, the AI updates when it gets the advance. But I did change it so that the AI only updates it's units that are not on Human owned land. This is so that you don't instantaneously find yourself fighting a more modern army. You might have to wait a few turns before you see its' more modern units.

itsamic · March 23, 2003, 06:25

I use a cheated game to test different things (tech tree, see how diplomod works etc.) If I change to an other civ I can see they have the whole range from Hoplit to Marine. Most units are on their own territory, some are fortyfied, some moves. I looked into the slic but I can't figure out the problem. For my own units the update works fine and it is a great improve at all.

tlatoani · May 22, 2003, 18:31

I'm in a Good Mood-SAP game but I forgot to add the "include APOL_updater2.slc" to GM1_APOL_script.slc. I f I do this now, can I reload slic and continue with the game or should I start a new one.

Tamerlin · May 22, 2003, 19:07

I am not sure Tlatoani but I think it should work after a reloadslic. If you test it and it doesn't work you will just have to remove the line #include... from your GM1_APOL_script.slc to go on with your current game.