C2C SVN Changelog

I'm hoping to be ready to merge a BIG set of multi-threading changes later this weekend, but I've been developing and testing it with an SVN that is now about 2 weeks or so out of date. Obviously I'll merge and retest before I push anything, but I'm wondering if I should hold off for a few days anyway, as I'm seeing a lot of won't-load and crash reports in the past couple of days, that indicate the current SVN might not be in the ideal state to merge with! This leads me to think I should maybe hold off a bit until whatever bugs are plaguing the current SVN have been sorted out.

Anyone care to venture an opinion...
 
Anything that is not part of schema checking (the schema also defines some data types that are checked) should not be lost with the new parser.

@TB: You can make a DLL with the old parser by commenting out a single line in the code. Open CvDLLUtilityIFaceBase.h and look for this line:
#define USE_RAPID_XML

Ok, cool! Very easy. I thought with those switches there was something you had to change with the compiler. So the way that works is just to define it then use it to 'bracket' code anywhere. If defined, the bracketing takes effect to eliminate the code within and if not then it ignores the brackets? (I use the term bracket to indicate the way I see the # utilized, not actual brackets as in } )


@The Team:
What I'll do then is include a debug dll in our assets folder. It will be named CvGameCoreDLL.dll.debug and all you'd have to do to use it (which will also give us other assert messages that xml programmers on the team may find useful) would be to rename the original dll file to CvGameCoreDLL.dll.core (or whatever you want to put after the second dot) and rename the debug dll to the 'in use status' of CvGameCoreDLL.dll
.

Use this file after any changes so as to check your work, but remember to switch back to using the core file by reversing those naming changes before pushing changes to the SVN.


@Koshling: I did run across one crash spot last night but it was in multi-player (which works surprisingly well with minimal OOSs as long as we're not running with Revolutions) but it'll take a bit to find the fix. Otherwise, the dll itself seems to be fairly stable. Just the usual amount of bugs. I wouldn't be too worried about merging.
 
I'm hoping to be ready to merge a BIG set of multi-threading changes later this weekend, but I've been developing and testing it with an SVN that is now about 2 weeks or so out of date. Obviously I'll merge and retest before I push anything, but I'm wondering if I should hold off for a few days anyway, as I'm seeing a lot of won't-load and crash reports in the past couple of days, that indicate the current SVN might not be in the ideal state to merge with! This leads me to think I should maybe hold off a bit until whatever bugs are plaguing the current SVN have been sorted out.

Anyone care to venture an opinion...

Great news, the only file that is causing a problem now is the UB_one in Hydro's folders, it has a loading failure, Hydro see bug reporting thread, thx.
EDIT: See below, thx TB
 
Great news, the only file that is causing a problem now is the UB_one in Hydro's folders, it has a loading failure, i mentioned it a day ago already??

Pushing a fix now. Along with the debug dll inclusion I mentioned two posts ago and another fix I found in the promotionlines file thanks to running the debug dll. This will be useful enough for us to maintain a copy of at all times. Just make sure to not update the svn while still using the debug dll rather than the core ;)
 
Pushing a fix now. Along with the debug dll inclusion I mentioned two posts ago and another fix I found in the promotionlines file thanks to running the debug dll. This will be useful enough for us to maintain a copy of at all times. Just make sure to not update the svn while still using the debug dll rather than the core ;)

Thanks. I would have fixed it last night but my internet went down. Its been that type of week for me. :rolleyes:
 
Pushing a fix now. Along with the debug dll inclusion I mentioned two posts ago and another fix I found in the promotionlines file thanks to running the debug dll. This will be useful enough for us to maintain a copy of at all times. Just make sure to not update the svn while still using the debug dll rather than the core ;)

So is the DEBUG DLL using he older XML parser, or did I misunderstand what you were asking previously?
 
suggestions for next update

-make diety difficulty actually harder, not easier, than immortal difficulty. Also make it so that AI doesnt lose their starting settler by sending it alone or smth (half of civs tend to lose their second tribe somehow at games start on diety difficulty). Also, you could go even further and just make each difficulty much harder than it is currently. As it is, I see no difference between, say emperor and diety. If you choose to play on higher difficulty, your supposed to face a challenge, not "win" a game with 50 civs by 20000 BC!!!!!!!!!
-make civs more prone to settle new cities when they have a settler
-release a modified version of the current GEM map with only the old world. Just cut it out and thats it.
This is a really good mod, but iam still curious as to how people can play it. Its so imbalanced: way too easy for human player, and I get tired of using the WB to buff AI all the time.
How do you stay entertained playing this mod past the rennaisance age? I usually quit in prehistoric because the game is basically won, how are you supposed to stay until later ages, doesnt it get boring?

the game has like 10 different difficulties, utilize them all. Make prince difficulty like a standard difficulty and the later difficulties actually difficult. If a person wants a challenge, he should be able to choose the difficulty and make it challenging.

Iam tired of:
- playing worst civs (arabias, byzantiums, etc) just to make it challenging
- picking obviously overpowered game options (barbarian generals, great commanders, etc)
-using WB to save civs from early revolutions by adding happy buildings, or helping them expand at later stages
-roleplaying... like instead of kicking everyones ass, just sit back and relax. I think many ppl do this

My suggestion on deity difficulty which would make me happy: Diety difficulty gives additional 3 happy faces for all AI cities, and AI is much less likely to revolt at beginning of the game(prehistoric age), AI recieves 2 more fighting units which he would use to defend the second starting settler, AI does not build commerce or research, AI places defensive units in cities which have enemy armies nearby, AI city defensive bonus doubled


/rant
 
thats because the SVN has now changed, it always requires a password now, at least for us modders, and the address has changed also, look at 1st post, thx.:p

what first post ? this
1)Download and install Tortoise SVN if you don't already have it (http://tortoisesvn.net/downloads.html)

2) Prepare a folder to contain your copy of the project
Create an empty directory that will hold your working copy (i.e. - local directory on your machine which will be your 'image' of the central repository - this is where you will make your changes when you want to contribute them and where other people's changes will sync down to). I strongly recommend that this is NOT your 'live' copy in 'program files/firaxis/...'. Mine is in \development\C2C, but the location doesn't matter - just put it somewhere convenient where you have space.
3) Checkout from the repository to the folder you created in (2). This will get the current revision and make a permanent connection between your working folder and the repository. Assuming you have installed SVN as in (1) you can do this by right-clicking the directory in Windows Explorer and selecting 'Tortoise SVN/Checkout...'. When it asks you for the repository URL enter 'svn://svn.code.sf.net/p/caveman2cosmos/code/trunk'. It's 3.4G (uncompressed transfer I'm afraid), so obviously this will take a while (might want to do it overnight - the upload took me about 8 hours!). Future refreshes or uploads (aka Commits) only get changed files, so they will be much, much faster, especially since the really big things like art assets
and movies don't tend to change much.
it has the same code
 
i try to conect to svn://svn.code.sf.net/p/caveman2cosmos/code/trunk but i cant
thats because the SVN has now changed, it always requires a password now, at least for us modders, and the address has changed also, look at 1st post, thx.:p
That is plain wrong.
Untill yesterday this was the corect new adress.
I'm with Stromwind, problems at sourceforge.
 
That is plain wrong.
Untill yesterday this was the corect new adress.
I'm with Stromwind, problems at sourceforge.

Try https: rather than svn:. I am connected that way and not having issues
 
Pushing a fix now. Along with the debug dll inclusion I mentioned two posts ago and another fix I found in the promotionlines file thanks to running the debug dll. This will be useful enough for us to maintain a copy of at all times. Just make sure to not update the svn while still using the debug dll rather than the core ;)

Thanks for this. It is slower but it makes writing new stuff much easier.
 
Back
Top Bottom