Caveman 2 Cosmos

[JosEPh_II]

I much rather wait into next year than get another V37 launch disaster so just take your time.

Thanks for the vote of confidence.

 

[tmv]

launch disaster

IIRC V37 was one of the "better" releases in that regard, but it is a bit old by now.

Seriously, there is nothing wrong with SVN. The SVN log of the program usually gives you a good idea about what was changed (and whether you need it), and the SVN log of the forum can tell you (often within hours) if there was a bad commit. If there is a particularly bad commit, you use "Update to revision..." (if you use TortoiseSVN) and go to the revision directly before the bad one. Be cautious about updating if you're inexperienced (there should be a very good reason to update), export everything but UserSettings and replace your mod folder (again, keep your UserSettings).

For the paranoid player: Check the pedia for completeness, that is, look for the last entry in every category if it goes to the end. XML errors can be very nasty (and often lead to CTD), but the pedia cuts off at the last correct entry, so if the pedia is complete, you are fine in that regard.

 

[JosEPh_II]

For the paranoid player: Check the pedia for completeness, that is, look for the last entry in every category if it goes to the end. XML errors can be very nasty (and often lead to CTD), but the pedia cuts off at the last correct entry, so if the pedia is complete, you are fine in that regard.

I did not know this! Thanks tmv.

 

[pepper2000]

I should add that there are a number of issues in the space material that need to be corrected. I am still working my way through a test run, and hopefully in the next week or two I should be able to get the fixes made. I will hold off adding any new material until V38.

 

[Thunderbrd]

I should add that there are a number of issues in the space material that need to be corrected. I am still working my way through a test run, and hopefully in the next week or two I should be able to get the fixes made. I will hold off adding any new material until V38.

Cool. I may be more on track here myself than I thought as well. We could have a Christmas release yet. There's always going to be some things I want to get done and some things to address but I"m starting to feel like most of the major items are getting resolved.

We must have a little playtesting time before completion, and I have to have Toffer's UI in place for it too. @Toffer90 Do you think you are close enough to a stable version on that to include it in the core and get enough playtesting from the community to have a release by the 25th? @Dancing Hoskuld I know Toffer wants your green light on that first. Can you please make sure that it's ready or not and make whatever last minute adjustment requests you feel would be necessary? We need a roadmap to completion there!

 

[pepper2000]

I can commit to getting my updates done by December 18, which gives another week to find problems prior to Christmas. Everything I intend to do are XML fixes, so the risk of introducing new bugs should be low. The problems are in the vein of certain buildings and units can be built due to map category mismatches, etc.

 

[Dancing Hoskuld]

Cool. I may be more on track here myself than I thought as well. We could have a Christmas release yet. There's always going to be some things I want to get done and some things to address but I"m starting to feel like most of the major items are getting resolved.

We must have a little playtesting time before completion, and I have to have Toffer's UI in place for it too. @Toffer90 Do you think you are close enough to a stable version on that to include it in the core and get enough playtesting from the community to have a release by the 25th? @Dancing Hoskuld I know Toffer wants your green light on that first. Can you please make sure that it's ready or not and make whatever last minute adjustment requests you feel would be necessary? We need a roadmap to completion there!

I am sill not converted over to my new machine and some things are just not working any more for no reason that I can find.

 

[Sussudio]

One question, the space mod of pepper2000 as installed?

 

[Faustmouse]

It is included, yet you need a scenario for it as mapscripts don't add space terrain.

 

[Toffer90]

We must have a little playtesting time before completion, and I have to have Toffer's UI in place for it too. @Toffer90 Do you think you are close enough to a stable version on that to include it in the core and get enough playtesting from the community to have a release by the 25th? @Dancing Hoskuld I know Toffer wants your green light on that first. Can you please make sure that it's ready or not and make whatever last minute adjustment requests you feel would be necessary? We need a roadmap to completion there!

No, it's not ready for core by the 25th.
I will aim at having a v38 stable version of the modmod that will be available in my modmod thread until v39 is eventually released.
If bugs are reported for the v38 version I will take the time to fix them without breaking v38 compatibility.

There are some points about the modmod that will have to be evaluated by DH, like the centralization work I did in CvEvenManager, a vanilla python file that has never been part of C2C before. I've moved most of the game python event code pieces like onCityRazed, onBuildingBuilt, onGameLoad, onGameStart.. etc. into the CvEventManager where I've made a code engine that makes it easy to add python effects to wonders.

There's a dictionary where you store:
{ "X" : GC.getInfoTypeForString("BUILDING_X") }

Then there's a List where you simply add in
"X" as an element.

And presto, the code engine will track when the wonder is destroyed, goes obsolete by the player that owns it, tracks ownership change and even reactivates the wonder if the old owner had obsoleted it but the new owner still hasn't the tech that obsoletes it.

Then you can add in the effect code you want for that wonder and the code engine will activate and deactivate that effect for you.

I know DH likes to have many small python files, but I felt a proper code engine was necessary for adding in python effects for wonders in a streamlined manner. I saw the same piece of code used in so many different python files that I felt it best to do this code centralization.

 

[raxo2222]

Nice optimization guys - when I enabled memsaver in civ config game takes only 560 MB of memory on launch
I generated random map of Gigantic size - 1220 MB taken.
Opened this map in WB - 1300 MB taken.
And I'm using highest graphics settings.

 

[Dancing Hoskuld]

There are some points about the modmod that will have to be evaluated by DH, like the centralization work I did in CvEvenManager, a vanilla python file that has never been part of C2C before. I've moved most of the game python event code pieces like onCityRazed, onBuildingBuilt, onGameLoad, onGameStart.. etc. into the CvEventManager where I've made a code engine that makes it easy to add python effects to wonders.

There's a dictionary where you store:
{ "X" : GC.getInfoTypeForString("BUILDING_X") }

Then there's a List where you simply add in
"X" as an element.

And presto, the code engine will track when the wonder is destroyed, goes obsolete by the player that owns it, tracks ownership change and even reactivates the wonder if the old owner had obsoleted it but the new owner still hasn't the tech that obsoletes it.

Then you can add in the effect code you want for that wonder and the code engine will activate and deactivate that effect for you.

I know DH likes to have many small python files, but I felt a proper code engine was necessary for adding in python effects for wonders in a streamlined manner. I saw the same piece of code used in so many different python files that I felt it best to do this code centralization.

No No Nooooooooo! The CvEventManager used by C2C is called RoMEventManager Likely to break BUG if you are not extremely careful. I have been working, very slowly, on getting rid of it. The main thing is that it makes it difficult to know when something will be done if order is important.

The reason for small Python files is only so we can have modular Python cod allowing many people to work on the Python instead of only one. At one stage we did have many working on them.

Also you could just have easily done that in a modular way anyway. Just call it C2CWonderMods and include it in the usual way.

 

[Toffer90]

No No Nooooooooo! The CvEventManager used by C2C is called RoMEventManager Likely to break BUG if you are not extremely careful. I have been working, very slowly, on getting rid of it. The main thing is that it makes it difficult to know when something will be done if order is important.

The reason for small Python files is only so we can have modular Python cod allowing many people to work on the Python instead of only one. At one stage we did have many working on them.

Also you could just have easily done that in a modular way anyway. Just call it C2CWonderMods and include it in the usual way.

I got completely rid of the RoMEventManager.py in my modmod. I've also made some changes to the BUGEventManager.py.

The amount of python files that my modmod deletes is 46.
No functionality has been removed, just moved and rewritten a bit.

 

[Thunderbrd]

No, it's not ready for core by the 25th.
I will aim at having a v38 stable version of the modmod that will be available in my modmod thread until v39 is eventually released.
If bugs are reported for the v38 version I will take the time to fix them without breaking v38 compatibility.

There are some points about the modmod that will have to be evaluated by DH, like the centralization work I did in CvEvenManager, a vanilla python file that has never been part of C2C before. I've moved most of the game python event code pieces like onCityRazed, onBuildingBuilt, onGameLoad, onGameStart.. etc. into the CvEventManager where I've made a code engine that makes it easy to add python effects to wonders.

There's a dictionary where you store:
{ "X" : GC.getInfoTypeForString("BUILDING_X") }

Then there's a List where you simply add in
"X" as an element.

And presto, the code engine will track when the wonder is destroyed, goes obsolete by the player that owns it, tracks ownership change and even reactivates the wonder if the old owner had obsoleted it but the new owner still hasn't the tech that obsoletes it.

Then you can add in the effect code you want for that wonder and the code engine will activate and deactivate that effect for you.

I know DH likes to have many small python files, but I felt a proper code engine was necessary for adding in python effects for wonders in a streamlined manner. I saw the same piece of code used in so many different python files that I felt it best to do this code centralization.

I would almost prefer to take it slower then and give you more time. Here's why. The changes you've made there are one of the best ways we can distinguish the release as an official upgrade. That buys me more time to perfect and polish as well.

 

[Tajo]

IIRC V37 was one of the "better" releases in that regard, but it is a bit old by now.

Ai population accumulation in their cities was completely broken in the initial 37. Unplayable.

 

[JosEPh_II]

Ai population accumulation in their cities was completely broken in the initial 37. Unplayable.

Not true until you hit the Modern Era and beyond.

 

[Tajo]

Thanks for the vote of confidence.

Well the 37 was not the first disastrous new version release so my pleasure. Patch thread system is most excellent though.

 

[Tajo]

Not true until you hit the Modern Era and beyond.

Can't remember exactly at what point the game broke down but it did which made it unplayable since the error was easily far too big to accept.

 

[JosEPh_II]

So you are using the Patch version now I take it?

 

[Dancing Hoskuld]

I got completely rid of the RoMEventManager.py in my modmod. I've also made some changes to the BUGEventManager.py.

The amount of python files that my modmod deletes is 46.
No functionality has been removed, just moved and rewritten a bit.

By putting it in a file called CvEventManager you have probably broken BUG modular Python and hence all the mods. They are very explicit in their documentation that you must not have a file by that name.