PROJECT: Revision Reports

[Fromafar]

Revision 384 Corrected barbarian tribe name appearance, improved mod compatibility, linux synchronisation

modified ctp2_code/gs/database/profileDB.cpp - linux synchronisation
modified ctp2_code/gs/database/profileDB.h - linux synchronisation, centralised world shape handling
modified ctp2_code/ui/interface/loadsavescreen.cpp - linux synchronisation, tribe index check
modified ctp2_code/ui/interface/loadsavewindow.h - linux synchronisation
modified ctp2_code/ui/interface/spnewgamemapshapescreen.cpp - restored compatibility
modified ctp2_code/ui/interface/spnewgamemapshapescreen.h - linux synchronisation
modified ctp2_code/ui/interface/spnewgameplayersscreen.cpp - improved mod compatibility
modified ctp2_code/ui/interface/spnewgameplayersscreen.h - linux synchronisation
modified ctp2_code/ui/interface/spnewgametribescreen.cpp - Tribe index handling corrected
modified ctp2_code/ui/interface/spnewgametribescreen.h - Tribe index handling corrected
modified ctp2_code/ui/interface/spnewgamescreen.cpp - tribe index check
modified ctp2_code/ui/interface/spnewgamewindow.cpp - Tribe index handling corrected
modified ctp2_code/ui/interface/spnewgamewindow.h - restored compatibility, linux synchronisation
modified ctp2_data/english/gamedata/ldl_str.txt - typo corrected
modified ctp2_data/english/uidata/layouts/spnewgame.ldl - restored compatibility
modified ctp2_data/english/uidata/layouts/spnewgamepopups.ldl - restored compatibility

[Martin Gühmann]

Originally posted by Fromafar
modified ctp2_data/english/uidata/layouts/spnewgame.ldl - restored compatibility
modified ctp2_data/english/uidata/layouts/spnewgamepopups.ldl - restored compatibility

And were are:

ctp2_data/french/uidata/layouts/spnewgame.ldl
ctp2_data/german/uidata/layouts/spnewgame.ldl
ctp2_data/italian/uidata/layouts/spnewgame.ldl
ctp2_data/japanese/uidata/layouts/spnewgame.ldl
ctp2_data/spanish/uidata/layouts/spnewgame.ldl

and:

ctp2_data/french/uidata/layouts/spnewgamepopups.ldl
ctp2_data/german/uidata/layouts/spnewgamepopups.ldl
ctp2_data/italian/uidata/layouts/spnewgamepopups.ldl
ctp2_data/japanese/uidata/layouts/spnewgamepopups.ldl
ctp2_data/spanish/uidata/layouts/spnewgamepopups.ldl

It shouldn't be my task to fix all the other languages for you. It should be the task of the persion who modified these files. Exspeacilly if you consider that we all have these files in the repository and they don't contain anything that requires the need of speaking French, German, Italian, Japanese or Spanish. Actual these two files here in question are identical for all the languages here. So a little bit of copy and paste shouldn't be a lot of work.

-Martin

[ctplinuxfan]

Revision 385
M branches/linux

r1577@linux3: holger | 2005-06-11 10:03:48 +0200
- merge from trunk to branches/linux: r381 - r383

r1581@linux3: holger | 2005-06-12 12:18:55 +0200
- trunk revisions r383 - r384 -> branches/linux

r1582@linux3: holger | 2005-06-12 16:09:40 +0200
- changed _LDADD to unique _LDFLAGS prefix
- added Makefile.common for common compiler/linker options


Sorry for the local revision decrease, i upgraded to subversion 1.2.0 + svk 1.0 and during repository recovery empty revisions were discarded.

[Fromafar]

Originally posted by Martin Gühmann
And were are:
[...]
It shouldn't be my task to fix all the other languages for you. It should be the task of the persion who modified these files.
[...]
Actual these two files here in question are identical for all the languages here. So a little bit of copy and paste shouldn't be a lot of work.

The files are at my harddrive. I will put these at the server when I am able to contact it again. I have some problems connecting at the moment.
But we could argue whether it is your task after all.
It shouldn't be my task to repair - 6 times - the incompatibilities that others have created .

If the layout files are identical anyway, what do you think about putting these in the default section, so we don't have to update 6 versions every time?

And, for something completely different: does anyone know how to merge a branched file into the trunk while keeping the original information? For some files, I just want to put revision 374 (linux branch) on the trunk, without actually modifying anything (revision, author).

[J Bytheway]

Originally posted by Fromafar
And, for something completely different: does anyone know how to merge a branched file into the trunk while keeping the original information? For some files, I just want to put revision 374 (linux branch) on the trunk, without actually modifying anything (revision, author).

I'm not entirely sure what you're wanting to do, but I think svn move might be able to do it.

[Fromafar]

What I want to do, is update the trunk with changes from the linux branch.

In most cases, the last trunk revision is at something like 362, and ctplinuxfan has made some perfectly valid improvements (e.g. guarding #pragma once, inserting comment-// when #endif is followed by text) in revision 374. When I merge this revision into the trunk and commit without making any changes, the file gets assigned a new revision number 380-something and has me as author.

I would like to have the trunk file revision being identified as revision 374 by ctplinuxfan, because it actually is his revision.

[J Bytheway]

Well, if you svn move the file from the linux branch to the trunk, then it will retain its linux modification history, with appropriate credit to ctplinuxfan (although you will be recorded as having been the person to move it). I think that does what you want. Of course, it's a bit tiresome to svn move something when you don't have it checked out, but if you're doing it a lot then I'm sure a script could ease that.

[ctplinuxfan]

Originally posted by J Bytheway
Well, if you svn move the file from the linux branch to the trunk

Please do not move away changes files of a branch, the file is also needed in that branch.

Originally posted by Fromafar
What I want to do, is update the trunk with changes from the linux branch.

The only thing you can do is running svn merge to merge changes.

I would like to have the trunk file revision being identified as revision 374 by ctplinuxfan, because it actually is his revision.

Well, the revision increase is logical: By merging the changes to a specific branch, you modify that branch, so the revision gets increased.
If anybody had commited a change to /trunk/foo.cpp in revision 377, inserting r374 from /branches/bar/foo.cpp before r377 of trunk would break the path of /trunk, so the branches must be independent because that's their purpose (change and test something which shouldn't break /trunk).

I share your opinion that the author gets lost during a conflict-less merge; the subversion book has the assumption that the author who merges the changes is somehow responsable for them to work.
If you resolve conflicts due to merges, it makes sense to keep you as the author, because you must make some modifications for the code to work again.

Somebody authorized could modify the revision property svn:author on merges without conflicts (revision properties may not be changed by default, because you could screw up the log, author, commit-date, etc.), but i don't mind if in a merged revision i'm not mentioned as the author for the changed lines.

During merges i commit source and destination branch and the revisions merged into the destination branch (log, author and changes are stored in repository). If we don't use the revision logs, we could try to agree on a common format for indicating the source of merges.

[J Bytheway]

Originally posted by ctplinuxfan
Please do not move away changes files of a branch, the file is also needed in that branch.

Of course I meant svn copy . Sorry.

[Martin Gühmann]

Originally posted by Fromafar
The files are at my harddrive. I will put these at the server when I am able to contact it again. I have some problems connecting at the moment.

Unfortunately I am having problems connecting to the SVN server. So I can't upload anything or use it.

Originally posted by Fromafar
But we could argue whether it is your task after all.
It shouldn't be my task to repair - 6 times - the incompatibilities that others have created .

Well that's a big problem, most of the stuff are related to the *.ldl files. There aren't a lot of mods that modify them and if a mod modifies them then just a few.

So I don't see any sense in it to do these compatibility issures, just because there might be a mod in the far future that might modify such an file that isn't guarded. It is my opinion as long as a mod is under developement it can fix such things on the level of *ldl files, especially because such things clutter the code unecessarily.

Originally posted by Fromafar
If the layout files are identical anyway, what do you think about putting these in the default section, so we don't have to update 6 versions every time?

I think it isn't a big problem to put them into the default section, but then these files have to be remoded in the language specific position. I suspect it works as it works with the text files. If there is a file in the language folder then this is used otherwise the one in the default folder is used.

Well obviously we have to swap the precedence, so that we can still place there language specific files, but we have to add new ones if necessary.

-Martin

[kaan]

I wasnt aware of any problems connecting to the svn server, ill look into it right away.

[kaan]

hmmm, the process had ended for some unknown reason, it should be up and running again.

[Fromafar]

Thanks Klaus, for making the server work again.

Revision 386 Layout updates

ctp2_data\<language>\uidata\layouts\spnewgame.ldl
ctp2_data\<language>\uidata\layouts\spnewgamepopup s.ldl
ctp2_data\<language>\uidata\layouts\citystatus.ldl

When placing these in the default section, I don't think we should swap the priorities. I would prefer to have any language specific version override the default version - as it is now. Actually, my suggestion would be to move all Apolyton ctp2_data modifications to a new directory (thus not overwriting the original Activision ctp2_data). We can use the RuleSets option (in userprofile.txt, or some new in-game interface) to include the Apolyton data before the original Activision data.

[Fromafar]

Revision 387 Radius computation changes for non-wrapping worlds, linux branch synchronisation

Changed radius computation

Modified: ctp2_code\ai\mapanalysis\settlemap.cpp
Modified: ctp2_code\gfx\tilesys\tiledmap.cpp
Modified: ctp2_code\gs\gameobj\CityInfluenceIterator.cpp
Modified: ctp2_code\gs\gameobj\CityInfluenceIterator.h
Modified: ctp2_code\gs\world\MapPoint.cpp
Modified: ctp2_code\gs\world\MapPoint.h
Modified: ctp2_code\gs\world\wldgen.cpp
Modified: ctp2_code\robot\pathing\unitastar.cpp

linux branch synchronisation

Modified: ctp2_code\ai\mapanalysis\boundingrect.h
Modified: ctp2_code\ai\mapanalysis\mapanalysis.h
Modified: ctp2_code\ai\mapanalysis\mapgrid.h
Modified: ctp2_code\gs\world\Cell.cpp
Modified: ctp2_code\gs\world\Cell.h
Modified: ctp2_code\gs\world\UnseenCell.h
Modified: ctp2_code\gs\world\World.h
Modified: ctp2_code\gs\world\WrlEnv.cpp
Modified: ctp2_code\gs\world\WrlImprove.cpp
Modified: ctp2_code\gs\world\WrldCity.cpp
Modified: ctp2_code\gs\world\WrldPoll.cpp
Modified: ctp2_code\gs\world\worldevent.cpp
Modified: ctp2_code\robot\pathing\Astar.h
Modified: ctp2_code\robot\pathing\BFS.h
Modified: ctp2_code\robot\pathing\CityAstar.h
Modified: ctp2_code\robot\pathing\UnitAstar.h

[Martin Gühmann]

Originally posted by Fromafar
When placing these in the default section, I don't think we should swap the priorities. I would prefer to have any language specific version override the default version - as it is now.

Well for some reason I prefer also the way it is, but I don't know really why.

Originally posted by Fromafar
Actually, my suggestion would be to move all Apolyton ctp2_data modifications to a new directory (thus not overwriting the original Activision ctp2_data). We can use the RuleSets option (in userprofile.txt, or some new in-game interface) to include the Apolyton data before the original Activision data.

One way would be to modify civpath.txt, but that wouldn't work for zip files, because it is different in the various localized versions, so this would require an installer, erasing the original versions isn't a good idea either, as it needs again an installer and maybe someone did it so that he has the original version and our version sharing these files.

So the RuleSet is left. So far I don't know how it exactly works. Therefore I don't know whether we should use this or something else that is similar. Maybe a small readme would be helpful explaining how this feature work. By the way this is a pretty good idea for modders anyway.



Revision 388

Standardized trade route cost calculation to fix number of caravans needed for trade routes, and to make sure that everywhere this is used the same code is used.
modified ctp2_code/gs/gameobj/TradeRouteData.cpp
modified ctp2_code/gs/gameobj/tradeutil.cpp
modified ctp2_code/gs/gameobj/tradeutil.h

Made the code to compile on VC++ 6 to compile again:
modified ctp2_code/gs/gameobj/player.h - Added missing includes
modified ctp2_code/gs/gameobj/PlayerAI.cpp - Removed GetAllTileValue method
modified ctp2_code/gs/gameobj/TradeBids.cpp - Made the Unit argments of AddBit method const
modified ctp2_code/gs/gameobj/TradeBids.h - Made the Unit argments of AddBit method const

Added copy constructor as the default one generated by the compiler caused some problems with my debug version. However this rather looks like a bloody workaround, but now I don't want to go too deep into the details.
modified ctp2_code/ai/CityManagement/governor.cpp
modified ctp2_code/ai/CityManagement/governor.h

Some cosmetic changes since I was modifying these files anyway for some reason. Comments correction, standart casts, spellings, white space.
modified ctp2_code/gs/dbgen/ctpdb.cpp
modified ctp2_code/gs/gameobj/Player.cpp
modified ctp2_code/gs/world/Cell.h
modified bin/Readme.txt