Question: Bug fixes

[Gilgamensch]

I don't know if it had been mentioned before (or even being fixed):

But yesterday I played the original again and I stumbled across some stuff which we ( D: ) might want to fix:

1.) Changing specialists will not update the city window (bottom right of the screen) till closed. This can be annoying when you are trying to max out everything and you have to keep going forward and backward between F3 and the map to get the data updated.

2.) Possible improvement: Double clicking on a city in the F2-manager (Inland-manager) doesn't open up anything, just centers on the city (you still have to press F3, CTRL-b to open the according windows). Might be better if in the overview (gold/production/....) to open the city-manager and in the overview of production to open up the build-manager (CTRL-b). Sometimes I am to lazy to use the keyboard

3.) Again, don't know if it has been addressed (maybe even in a mod): When reloading a game the trade is screwed. Values are changing.

4.) Closing the save-window: Why if you press Return/Enter is it processing the turn? Can it not take it as OK (as every other application)?

5.) I had a few more, but I can't remember them in the moment

[MrBaggins]

Re: Question: Bug fixes

Originally posted by Gilgamensch
I don't know if it had been mentioned before (or even being fixed):

But yesterday I played the original again and I stumbled across some stuff which we ( D: ) might want to fix:

1.) Changing specialists will not update the city window (bottom right of the screen) till closed. This can be annoying when you are trying to max out everything and you have to keep going forward and backward between F3 and the map to get the data updated.

Should be possible... but then some small things can be difficult to implement in practice...

However, I believe there is a plan to do an entirely new city screen thats much more complete and shows all the necessary information at once, including specialists and their effects.

2.) Possible improvement: Double clicking on a city in the F2-manager (Inland-manager) doesn't open up anything, just centers on the city (you still have to press F3, CTRL-b to open the according windows). Might be better if in the overview (gold/production/....) to open the city-manager and in the overview of production to open up the build-manager (CTRL-b). Sometimes I am to lazy to use the keyboard
*SNIP*

Completely agree. This is sensible. If we can give the row a double click action effect, then we'll implement this.

[Gilgamensch]

One more thing:

Might mean a 'big' change. I know we have some problems with mods and great library. Would it not be possible instead of having extra files for the GL to use the relevant files and just have a txt-file for the description in the GL? Couple of times mods have the wrong information in the GL

[Gilgamensch]

One more thing to complain

Can't the game remember the last save-game path?

This is kind of default for any other game :doitnow:

[MrBaggins]

Originally posted by Gilgamensch
One more thing:

Might mean a 'big' change. I know we have some problems with mods and great library. Would it not be possible instead of having extra files for the GL to use the relevant files and just have a txt-file for the description in the GL? Couple of times mods have the wrong information in the GL

You still have to have a data file linking entries to the gl symbols... since data is stored and referenced with numbers, effectively.

As for having them as separate text files, you could do that, but then we'd have A) a much slower start up, and B) a few hundred gl text files to change/search instead of one.

Theres no real reason why the great library can't be correct for Mods... it IS a text file already... it just could be easier to change, I think.

That could be achieved by creating an editor utility for the existing file. You'd STILL have to ensure that the game changes you made were properly reflected in the GL that you distribute with your Mod, however... its really just a matter of being detail oriented.

[Gilgamensch]

I haven't thought it completly through yet.

But my idea was, that CTP2 would read the data (values like price/HP/AP/whatever) out of the 'normal' txt-files (being used by the game itself) and then having just one txt file with the description of it, just plain text.

[Peter Triggs]

B) a few hundred gl text files to change/search instead of one.

Mr Baggins remembers what CTP1 was like. It was because people complained about what a pain it was to deal with all those GL files that they changed to the current system.

[MrBaggins]

Originally posted by Gilgamensch
I haven't thought it completly through yet.

But my idea was, that CTP2 would read the data (values like price/HP/AP/whatever) out of the 'normal' txt-files (being used by the game itself) and then having just one txt file with the description of it, just plain text.

Thats nice... but a bit of a nightmare to program... particularly with some of the changes coming up.

[Martin Gühmann]

Originally posted by Gilgamensch
One more thing:

Might mean a 'big' change. I know we have some problems with mods and great library. Would it not be possible instead of having extra files for the GL to use the relevant files and just have a txt-file for the description in the GL? Couple of times mods have the wrong information in the GL

First there is no need to readd this seperate file system again, you can already use the same GreatLibrary.txt for more than one mod even if they don't share the information entirly.

Which GreatLibary entry is used is determined in the uniticon.txt.

Second, that the information of GreatLibary is wrong is not a problem of the system itsself, but the problem lies at the modmakers end. For instance if I do an addon for the ApolytonPack and or provide a German GreatLibary and Dale does not document the changes he did, then I never have a chance to do a correct GreatLibary. For my mods or for a translation of the GreatLibary. (Mainly to Dale: )

And another point if I don't have time to update my mod or the source code was released, then the last thing I am doing is to correct some stuff in the GreatLibary.

The real way to deal with altered statisics of terrain and tileimps and goods is to use slic code in the GreatLibary like: {terrain[0].BaseEnv.Gold} unfortunatly so far slic does not allow to access such substructures.

-Martin

[Gilgamensch]

that was kind of my idea: making it easier for moders.

So you would have the normal units.txt file which is what really determines the values. But instead of having 'double' entries in the GreatLibrary.txt CTP2 shall read the values from units.txt and take the text for it, out of GreatLibrary.txt.

So if somebody changes something you could at least trust the values in CTP2 when you access the Library. The text (meaning explanation) might not be correct, but at least the rest.

[MrBaggins]

Originally posted by Gilgamensch
that was kind of my idea: making it easier for moders.

So you would have the normal units.txt file which is what really determines the values. But instead of having 'double' entries in the GreatLibrary.txt CTP2 shall read the values from units.txt and take the text for it, out of GreatLibrary.txt.

So if somebody changes something you could at least trust the values in CTP2 when you access the Library. The text (meaning explanation) might not be correct, but at least the rest.

I'll say it again... thats nice... but a bit of a nightmare to program... particularly with some of the changes coming up.

It might be possible, but I don't see it being given a lot of time any time soon... particularly since any Great Library can be done perfectly, and fixed already...

[Maquiladora]

So you would have the normal units.txt file which is what really determines the values. But instead of having 'double' entries in the GreatLibrary.txt CTP2 shall read the values from units.txt and take the text for it, out of GreatLibrary.txt.

Doesnt it work like that already? I know the GL takes some things from units.txt.

[Martin Gühmann]

Originally posted by MrBaggins
I'll say it again... thats nice... but a bit of a nightmare to program... particularly with some of the changes coming up.

It might be possible, but I don't see it being given a lot of time any time soon... particularly since any Great Library can be done perfectly, and fixed already...

It would be a nightmare if we have to do it from scratch, in fact for units the statics are already correct, here is an example:

[UNIT_LONGSHIP_STATISTICS]
Attack: {UnitDB(UnitRecord[0]).Attack / 100}
Ranged: {UnitDB(UnitRecord[0]).ZBRangeAttack}
Defense: {UnitDB(UnitRecord[0]).Defense / 100}
Armor: {UnitDB(UnitRecord[0]).Armor / 100}
Damage: {UnitDB(UnitRecord[0]).Firepower}
Vision: {UnitDB(UnitRecord[0]).VisionRange}
Movement: {UnitDB(UnitRecord[0]).MaxMovePoints / 10000}
Max HP: {UnitDB(UnitRecord[0]).MaxHP}

Costs: {UnitDB(UnitRecord[0]).ShieldCost}
Upkeep: {UnitDB(UnitRecord[0]).ShieldHunger} Shields
Food Hunger: {UnitDB(UnitRecord[0]).FoodHunger}
[END]

You see for units none of the values are hard encoded into the Great Libary they are all taken from the unit.txt.

You see this is the example for the Longship, but this same entry can also be used for other units you just have to alter the uniticon.txt:

ICON_UNIT_LEVIATHON { FirstFrame "UPUP077L.TGA" Movie "NULL" Gameplay "UNIT_LEVIATHON_GAMEPLAY" Historical "UNIT_LEVIATHON_HISTORICAL" Prereq "UNIT_LEVIATHON_PREREQ" Vari "UNIT_LEVIATHON_STATISTICS" Icon "UPUP077A.TGA" LargeIcon "UPUP077L.TGA" SmallIcon "UPUP077B.TGA" StatText "UNIT_LEVIATHON_SUMMARY" }

ICON_UNIT_LONGSHIP { FirstFrame "UPUP016L.TGA" Movie "NULL" Gameplay "UNIT_LONGSHIP_GAMEPLAY" Historical "UNIT_LONGSHIP_HISTORICAL" Prereq "UNIT_LONGSHIP_PREREQ" Vari "UNIT_LONGSHIP_STATISTICS" Icon "UPUP016A.TGA" LargeIcon "UPUP016L.TGA" SmallIcon "UPUP016B.TGA" StatText "UNIT_LONGSHIP_SUMMARY" }

Replace 'Vari "UNIT_LEVIATHON_STATISTICS"' by 'Vari "UNIT_LONGSHIP_STATISTICS"' and text under UNIT_LONGSHIP_STATISTICS is used for the Leviathon, too. Exept that the variables are replaced by other values.

The only problem is that we don't have it for substructures. Something like this is invalid:

{TerrainDB(terrain[0]).BaseEnv.Gold}

But this can be summed under slic database access, and we want this for slic, too. When we have it for slic or for the Great Libary then, it is not a big deal to implement into the other language.

-Martin

[MrBaggins]

Don't forget that GovernmentModified alters unit (and other object) data too... would you use the base or the current Government of the player value... or?

[Martin Gühmann]

Originally posted by MrBaggins
Don't forget that GovernmentModified alters unit (and other object) data too... would you use the base or the current Government of the player value... or?

That's indeed a big problem, but so far the Great Libary only reflect the unmodified versions.

How would I access them is the syntax you implemented treated as a name as an additional database index? If yes then this would not be a big deal first unmodified values and then government specific values.

-Martin