PROJECT: Altered source files

[Fromafar]

Bug fix: make sure that the human player will get the selected civilisation.

gs\utility\gameinit.cpp

Notes:Tested for most SP start possibilities. Not tested for MP. The code for an editor start has not been changed (still using player 1). I could not fully test it for the Alexander scenario, because it crashes (in a DPRINTF statement ) in InitSStateEvent upon game start. Could you have a look at that one, Martin? I suspect the crash is caused by the 2004.08.15 personality changes.

[Edit: file link removed. Included in the 2004.09.13 source collection.]

[Martin Gühmann]

Originally posted by Fromafar
I could not fully test it for the Alexander scenario, because it crashes (in a DPRINTF statement ) in InitSStateEvent upon game start. Could you have a look at that one, Martin? I suspect the crash is caused by the 2004.08.15 personality changes.

Well looks like every scenario exept the NuclearDetente scenario has its own personalities.txt, so we need to update them all. Actual I don't like the idea of backward compatibility in this case, because as it is now, every startegy except the one for the Barbarians can be removed, and that increases the modability and flexibility and otherwise we would force the strategies.txt to the old layout.

-Martin

[Fromafar]

I am not sure I completely understand your last sentence.

I like the idea of backward compatibility - in the sense of being able to accept unchanged Mod and Scenario files. This will save us the hassle of having to update the scenarios, and will most likely result in a larger number of people that are willing to help with playtesting.

OTOH, I like the flexible format. However, it is not that flexible yet. You can not really leave out any strategy line from personalities.txt. You will not get an error when parsing the file, but the handling in the code makes it crash without any message. All statements in SStateEvent.cpp of the form

diplomat.GetPersonality()->GetSomeStrategyPtr()->DoSomething()

will crash, because GetSomeStrategyPtr() returns NULL when the SomeStrategy line is missing in personalities.txt.

[Martin Gühmann]

Originally posted by Fromafar
I like the idea of backward compatibility - in the sense of being able to accept unchanged Mod and Scenario files.

In that case I don't like the idea of accepting unchanged mod or scenario files, it doesn't make sure that everyone can benefit of the new features and it would leave a lot of unnecesary code back in the *.exe I don't like either. And finally noone can let's say remove STRATEGY_SETTLE_COMPACT for instance and replace it a strategy of another name, because it would be still in. However the problem is indeed that I have no idea how to make sure that the program sends a message when a necessary struct is missing from the text files.

However here are the updated personalities.txt's for the scenarios:

2004.08.20
..\Scenarios\AlexanderTheGreat\scen0000\default\ai data\personalities.txt
..\Scenarios\MagnificentSamurai\scen0000\default\a idata\personalities.txt

Changed by Martin Gühmann to make the Alexander the Great and the Magnicant Samurai scenarios compatiple with the lastest personalities.txt modifications.

-Martin

[Fromafar]

Now I am getting even more confused.

Accepting unchanged Mod files will make sure that everyone can benefit of the improved stability of the playtest executable, while giving the Mod maker the option of using the new features - when he feels these are beneficial to his particular Mod and has time available to do so.

Not accepting the unchanged Mod files will result in the Mod maker being forced to make changes without any noticable effect, as long as he has no use for the new features. Something like having to insert a MAX_MATCH_LIST_CYCLES 6 line somewhere in the middle of some file , just to make it run. I think it is more likely that this will force Mod players into not using the playtest release.

I thought that the idea of not requiring the lines in the strategies.txt was a deliberate design by you. In this way you make it easier for Mod makers if they only need a few strategies. When a line is missing, I had expected the default strategy - if available in the file - or the original Activision hardcoded strategy to be used. Of course, this will make the executable larger, but I think it is worth it. Don't let my nitpicking confuse you . I think the new features will be useful.

Oh, and just to nitpick some more: what is the meaning of the # line at the top of the text files?

[Martin Gühmann]

Originally posted by Fromafar
Not accepting the unchanged Mod files will result in the Mod maker being forced to make changes without any noticable effect, as long as he has no use for the new features. Something like having to insert a MAX_MATCH_LIST_CYCLES 6 line somewhere in the middle of some file , just to make it run. I think it is more likely that this will force Mod players into not using the playtest release.

There is a difference between just making it run and making it use of all the benefits, without updating you have very high costs for trade routes (well so far I didn't look into it how the final solution should look like), you might miss a lot of strings like in GoodMod, and that forces players to not use the playtest build as well.

Originally posted by Fromafar
I thought that the idea of not requiring the lines in the strategies.txt was a deliberate design by you. In this way you make it easier for Mod makers if they only need a few strategies. When a line is missing, I had expected the default strategy - if available in the file - or the original Activision hardcoded strategy to be used. Of course, this will make the executable larger, but I think it is worth it. Don't let my nitpicking confuse you . I think the new features will be useful.

I was happy once I saw the new code much shorter then the old one, and I considered how to make the backward compatibility. The problem is if you have just have set half of the strategies and change the priorities, then these priorities doesn't match with the hard encoded ones. Maybe I could make it like this. If no DefaultStrategy is set then the game falls back to STRATEGY_DEFAULT, and if the other strategy structures are missing, nothing happens.

Another approach would be to make the game to use the original code if a struct is missing. But in this case I would only offer the defence and the nuclear startegies as blocks respective. And what should I do with the NuclearStrikeStrategy, currently this is the only struct you can leave out, if it is there you have the same behaviour like with (Discovery: Military || Discovery: Scientist) &&
Trustworthiness: Chaotic && Alignment: Evil. But if it is missing there is no nuclear launch startegies.

Originally posted by Fromafar
Oh, and just to nitpick some more: what is the meaning of the # line at the top of the text files?

It means the same like // line.

-Martin

[Martin Gühmann]

I wanted to fix the age selection screen of multiplayer but with all the latest files I can't reach it for testing purposes. Always when I want to enter the lobby the game crashes, and the content of all the list boxes is screwed up.

-Martin

[Fromafar]

Bug fix: repaired the garbled text display from the previous post.

ui\netshell\ns_listbox.h
ui\netshell\ns_customlistbox.cpp

Updated the list box data handling to match the .NET compatibility changes.

[Edit: file link removed. Included in the 2004.09.13 source collection.]

[Martin Gühmann]

CityMod3

2004.08.28
Graphics part:

..\ctp2_data\default\pictures\CM2_*.tga
Update the age membership of the buildings and advances in the Great Libary.

..\ctp2_data\default\pictures\Classic.tga
..\ctp2_data\default\pictures\Future.tga
..\ctp2_data\default\pictures\Industri.tga
..\ctp2_data\default\pictures\Info.tga
..\ctp2_data\default\pictures\Renaiss.tga
Blank age backgrounds.

..\ctp2_data\default\pictures\RomanStyle.tga
..\ctp2_data\default\pictures\ArabianStyle.tga
..\ctp2_data\default\pictures\AsianStyle.tga
..\ctp2_data\default\pictures\AmericanStyle.tga
..\ctp2_data\default\pictures\CastleStyle.tga
..\ctp2_data\default\pictures\EgyptainStyle.tga
..\ctp2_data\default\pictures\PalaceStyle.tga
New city style icons for the scenario editor.

..\ctp2_data\default\gamedata\sprites\gc*.spr
From sprite 000-020: New sprites to complete the set of new modern sprites of CityMod2 to a set of 8 sprites per city style.
From sprite 097-187: Sprites by Harlan Thompson (American and Castle style and Industrial Age), PinkFriend (Palace style) and Martin Gühmann (Egyptain style and new Modern style).
From sprite 188-219: Sprites from CTP1 (Genetic style, Diamond style, Underwater style and space style)

Text file part:
..\ctp2_data\default\gamedata\Advance.txt
..\ctp2_data\default\gamedata\age.txt
..\ctp2_data\default\gamedata\agecitystyle.txt
..\ctp2_data\default\gamedata\citystyle.txt
..\ctp2_data\default\gamedata\civilisation.txt
..\ctp2_data\default\gamedata\uniticon.txt
..\ctp2_data\default\gamedata\script.slc

New city styles, ages and civilisation have been added to these files. Now there are 45 civs in the game. The following civs have been added:

Arabian
Austrian
Nubian
Byzantine
Celtic
Babylonian
Carthaginian
Swedish
Aztec

The following civs have been removed:

Korean
Nigerian
Welsh
Cuban
Nicaraguan
Irish

However the according strings are still in the civ_str.txts maybe with an interface update we can readd them.

Language text file part:
..\ctp2_data\XXXXXX\gamedata\GreatLibary.txt
..\ctp2_data\XXXXXX\gamedata\gl_str.txt
..\ctp2_data\XXXXXX\gamedata\civ_str.txt
..\ctp2_data\XXXXXX\gamedata\info_str.txt
..\ctp2_data\XXXXXX\gamedata\str_loc.txt
Where XXXXXX stands for English, French, German, Italian or Spanish. However there is no str_loc.txt in the English version, therefore this file is not included in the English folder, for French and Spanish version I have only the Great_Libary.txt and the info_str.txt the other files are missing and are also needed in modified form to run the game.

New age concept descriptions were added to the Great_Libary.txt, age concept, age and city style names were added to the gl_str.txt. New age entering messages were added to info_str.txt. New localized grammar was added to the German str_loc.txt, placeholders for localized grammar were added to the Italian version of that file.

In addition all the other localized text files except sceen.txt for English, German and Italian were added for later use. However French and Spanish files are missing.

Source files

..\ctp2_code\gs\newdb\*.stamp
Updated stamps for database record files.
..\ctp2_code\gs\newdb\citystyle.cdb
..\ctp2_code\gs\newdb\AgeCityStyleRecord.h
..\ctp2_code\gs\newdb\AgeCityStyleRecord.cpp
..\ctp2_code\gs\newdb\CityStyleRecord.h
..\ctp2_code\gs\newdb\CityStyleRecord.cpp
Updated file for new flags in the AgeCityStyleDB to expose city walls and force field tile set indices to the text files.

..\ctp2_code\gs\dbgen\MemberClass.cpp
..\ctp2_code\gs\newdb\RecourceRecord.cpp
..\ctp2_code\gs\newdb\TerrainRecord.cpp

Updated dbgen to allow flags of substructures to have default values. The record files are updated due to this change.

..\ctp2_code\gfx\spritesys\SpriteGroupList.h
..\ctp2_code\gfx\spritesys\SpriteList.h

Increased the sprite limit from 200 to 500 per sprite type.

..\ctp2_code\gfx\spritesys\UnitActor.cpp

Exposed city walls and force field graphics to the AgeCityStyleDB, fixed the sea city sprite bug concerning force fields, however city walls and force field graphics aren't positioned correctly on the screen, if for each graphic an idifidual correction factor is needed then this should be exposed to AgeCityStyeleDB as well, in form of x and y coordinates.

..\ctp2_code\ui\interface\greatlibary.cpp
Doubled the maximum entry size. To remove game entry assert in German version.

..\ctp2_code\ui\interface\scenarioeditor.cpp
Added icons and tooltips to the city style buttons on the city tab of the scenario editor.

..\ctp2_code\ui\interface\agesscreen.cpp
Start and end ages names are now taken from the gl_str.txt instead of the *.ldl files. This makes the game more flexible when ages are added or removed.

..\ctp2_code\ui\netshell\gameselectwindow.cpp
When a new multiplayer game is started, default values are now taken from the profile. These values are for world size, shape, world type wet/dry, warm/cold, ocean/land, island/continent, homo/deverse and goodcout. The end age is now set to the last age in the database instead to the age with the DB index 4.


Edit: Link removed, this is now part of the latest all pack.

-Martin

[Maquiladora]

The following civs have been removed:

Did we have a poll on this?

[Locutus]

Re: CityMod3

Originally posted by Martin Gühmann
The following civs have been removed:

Korean
Nigerian
Welsh
Cuban
Nicaraguan
Irish

However the according strings are still in the civ_str.txts maybe with an interface update we can readd them.

If you kept all the strings were they were, these civs weren't removed, they're just not selectable anymore by the human player. It's still possible for the AI to become one of these civs (either at the start of the game or when a city revolts). So yes, with an updated user interface it should indeed be possible to choose between all 63 allowed civilizations.

[Martin Gühmann]

Originally posted by Maquiladora
Did we have a poll on this?

What should I ask? For instance: Should we add all the features of Apolyton Pack by text file or source code modification to the game?

In fact removing these civs was Dale's or Harlan's idea, I just used the civilisation.txt from Apolyton Pack as a base. But maybe I should reconsider the choice, for compatibility concerning the world map. However in that case the removed civs would only have 30 city names instead of 50.

Originally posted by Locutus
If you kept all the strings were they were, these civs weren't removed, they're just not selectable anymore by the human player. It's still possible for the AI to become one of these civs (either at the start of the game or when a city revolts). So yes, with an updated user interface it should indeed be possible to choose between all 63 allowed civilizations.

Strings are strings and not civs. You add strings to the string database and you add civs to the civ database. The string file is called civ_str.txt and the civilisation database file is called civilisation.txt. I can add tons of strings to civ_str.txt but if no civ uses them it doesn't matter.

So in fact the civs are not in the game. If I (or Dale) left them in the civilisation.txt, then they would be indeed selectable in the game. Freely for the AI but restricted by the UI for the human player, but in fact even without an updated UI the human player could select them via the userprofile.txt. However the civs on the civ selection screen are in alphabetical order respective their local singular names, so in the end I don't have control which civ appears on that screen.

-Martin

[Maquiladora]

What should I ask? For instance: Should we add all the features of Apolyton Pack by text file or source code modification to the game?

I dont know. I just wanted to avoid another color.txt type situation

[Locutus]

Originally posted by Martin Gühmann
However the civs on the civ selection screen are in alphabetical order respective their local singular names, so in the end I don't have control which civ appears on that screen.

At least in CtP1 it was true the sorting was done based on civilization.txt. So by using the names like ZZZ_NIGERIAN instead of NIGERIAN in civilization.txt, you could control which civs are selectable and which aren't. I think this is true for CtP2 as well, but it's been a while so I'm not 100% certain.

Either way, someone should look into the UI thing, can't be hard to fix (and then it doesn't matter anymore which civs are included/selectable)...

[calvitix]

Source Modifications to improve AI army movement (specially Grouping)

ctp2_code\gs\gameobj\ArmyData.cpp
ctp2_code\gs\gameobj\ArmyData.h
Added a method to check if the army can transport troops (used for the escort transport)


ctp2_code\ai\ctpai.cpp
ctp2_code\ai\ctpai.h
Added a method to move out of the city the transports
Changed the frequence for road and tile improvement building (every turn instead of every 5 turns)
Changed the explore goal resolution (2 tiles instead of 5 tiles)
new explore goals are generated every turns (instead of when all the previous goals are accomplished)


ctp2_code\ai\goals\goal.cpp
Add a condition to IsSatisfied method : when army size for the goal is equal to k_max_army_size


ctp2_code\ai\strategy\goals\ctpgoal.cpp
ctp2_code\ai\strategy\goals\ctpgoal.h
Added an Ungroup condition that can be associated to goals (as it exists RallyFirst)
and Ungroup methods
Changed the task forces for goals (based on objectif's threat)
Added a Debug Log (activated with k_dbg_scheduler_all) to see the goal priority computing
(raw priority, plus value of each modifier)
Added an SUB_TASK_TYPE attribute (used for armytext display)


--updated : only one file is needed : Goal.cdb (other two are automatically generated)
ctp2_code\gs\newdb\Goal.cdb
ctp2_code\gs\newdb\GoalRecord.cpp
ctp2_code\gs\newdb\GoalRecord.h
Added Ungroup token to interpret the goal.txt file



ctp2_data\default\aidata\goals.txt
Added UngroupFirst token to several Goals (Explore, Defend, ...)



ctp2_data\default\aidata\strategies.txt
Changed ratio forces to promote group formations
Lower army garrison to avoid full cities


ctp2_code\ai\strategy\scheduler\plan.cpp
ctp2_code\ai\strategy\scheduler\plan.h
ctp2_code\ai\strategy\scheduler\scheduler.cpp
Changed the > and < operator (to change the Sort method see Sort_Matches)
Added a method that will determine if the plan can be reevaluated (ie the agent can be rollbacked
and eventually be used for another goal)


ctp2_code\ai\strategy\squads\squad_strength.cpp
Changed the > operator (used by Goal::IsSatisfied method)
the Original method only test attack or defense param.
New methode take the sum of all strength (attack, defense, ranged,...)