C2C SVN Changelog

[Thunderbrd]

We are used to SVN in general so we might want to use some of the more advanced features.

If you want to work on a feature that is incomplete now but should be backed up or you want others to work with you on it, you should consider making a branch.
A branch is cheap copy of the trunk that you can then change without affecting others. After you create a branch, you can switch a local working copy to it and then work with it as you would with the normal SVN. When your feature is complete, you can reintegrate the branch into the trunk and all the changes you have made will be applied. If you regularly merge trunk changes into your branch you can also stay up to date with the changes others make.

Possible uses are:
DHs barbarian diplomacy
Extensive tech tree changes that are not actually filled with content yet
Any experimental project

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html

This is post #3313. If you would, please link to it on the first post so I don't have to go searching for over an hour to find it again


@Koshling: I've made some extensive changes and for numerous potential reasons, what I've done has caused savegame incompatibility. I figured it'd be easiest to ask where I went wrong by simply creating a branch (located in the branches folder under the name: saveincompat) and asking you to take a look at CvUnit, CvPlayer, enums.h, and infos files to see what I did wrong (I have a feeling you'll spot it as soon as you see the changes since the rules as to what we can and can't do are more clear for you.) I suspect its something I didn't do correctly in CvUnit wrappers.

Tomorrow, I'll be testing a few things to see if I can figure out my mistake. Half of my purpose for doing this is that I've been needing to figure out how to work with branches anyhow.

 

[Dancing Hoskuld]

updates

- tweaked bear and rhino riders to fix upgrade paths and force obsolete at the correct tech.
- moved bear knight art into core
- Sea otters can now build fur farms.

 

[Hydromancerx]

Updates
- Added Locksmith, Cider House, Deli, Pizza Parlor, Diner, Cafe and Brick Factory.

 

[strategyonly]

Just pushed to SVN (4332):

• Fixed the city opened by next/prev or insert key when no city selected to be the one closest to the current view center

Nope, not correct yet It needs to open the buildings/units/wonders screen (only the bottom portion) not the whole City Screen, so what you'd see is, the "normal" map but "under" the city you'd be able to construct units/buildings/wonders, change only that portion not the rest of the City Screen area stuff., i hope that makes more sense. . . SO

attached correct look vs wrong look . . . also attached are the OLD sources that still have it set that way, just incase you need them for reference . . . SO

 

[dusckr87]

You DO know you can use the SVN to revert to a previous version if the most recent update(s) are unstable right?

Yes, but my computer isn't connected to the internet 24/7. Downloading is more unreliable than DVDs...That's why I said it was "overkill" and not necessary.

(Plus I need to unpack the fpks to play the game without black tiles, and a zipped version without the fpks is far faster than reverting the SVN and then unpacking again.)

 

[ls612]

Just pushed to SVN (4332):

• Fixed the Great Wall display issues across save & load with viewports
• Fixed the city opened by next/prev or insert key when no city selected to be the one closest to the current view center

Note that the GW fix will not help existing saves that have displaced Great Walls within them (I cannot do anything about those), but they should prevent it happening for new games (or existing games in which the GW is not yet built).

For anyone interested in the gory details here's why it happened, and why I can't fix it for existing saves. First a little background:

• The graphics and tiles that comprise the GW are not handled by the DLL. They are handled directly by the game engine
• The API the game engine provides lets you add or remove a GW belonging to a specified city
• The game engine keeps its own data on the plots the GW runs through, and it adds that to saved game info outside of the control of the DLL
• During a viewport switch, which will change the coordinates (as far as the game engine is concerned) of everything , including the GW, we remove the GW (before the coordinate switch) and re-add it (after the switch) to get it correctly positioned

The problem lies in the fact that the game engine, outside of the control of the DLL, saves the GW positioning information in the save file. That means, that when it reloads the game, if the viewport is positioned differently to when it was saved (and it often will be), the positioning information it has for the GW is incorrect, so it paints it in the wrong place. At that point it is impossible to remove it, since the API forces you to specify a generating city to the game engine (to add or remove), and that generating city (even if it I within the load-time viewport, which it might not be) will generate a different set of coordinates and thus not (cleanly at least) remove the GW that was in the game engine's save data.

At first sight, this can be solved by saving the viewport information in the save and ensuring that the viewport is set on load to what it was on save. However, this is impossible too, since the viewport size (or even enablement) might be different when the game is loaded to when it was saved.

The fix I've adopted is to remove the GW at the start of the save process (so it's not present at all in the save game data), and re-add it after the save completes (and on load, which I already did anyway). This seems to work ok in my testing (though as mentioned it cannot rescue old saves), with the minor downside that the GW disappears and reappears (the animation plays so it's not instant, which again I cannot control) when the game is saved (including auto saves).

This change has made things worse for me, not better. Before, the GW bug only happened on some loads, and it went away after the first Viewport shift. Now it happens on every load, and it's position changes and is incorrect after every viewport shift. I personally would like some way to just disable GW graphics (I assume that's possible right?).

 

[Koshling]

This change has made things worse for me, not better. Before, the GW bug only happened on some loads, and it went away after the first Viewport shift. Now it happens on every load, and it's position changes and is incorrect after every viewport shift. I personally would like some way to just disable GW graphics (I assume that's possible right?).

Are you talking about an existing game (I did say it wouldn't work for existing games)?

Even if I give you an option to turn them off completely they will STILL show up in random positions in any existing save, simply because there is no way to expunge them from the game data for an existing save (since that part of the data is not exposed to the DLL). I can certainly add such an option, but as I say, it still won't rescue your current game's bad graphics.

Edit - if you want to try it just make CvCity:rocessGreatWall() not do anything (or add a BUG option to have that effect)

 

[ls612]

Are you talking about an existing game (I did say it wouldn't work for existing games)?

Even if I give you an option to turn them off completely they will STILL show up in random positions in any existing save, simply because there is no way to expunge them from the game data for an existing save (since that part of the data is not exposed to the DLL). I can certainly add such an option, but as I say, it still won't rescue your current game's bad graphics.

Great. You can't expunge the wonder for one turn or something? Or are the graphics saved independently from the wonder? Because I really don't want to give up on this save.

Edit: I saw your suggestion, but I don't know how to make a BUG option. I'd assume the code would be something like

if (bugoptionison)
{
     return false;
}

in processgreatwall(), right?

 

[Koshling]

Great. You can't expunge the wonder for one turn or something? Or are the graphics saved independently from the wonder? Because I really don't want to give up on this save.

Edit: I saw your suggestion, but I don't know how to make a BUG option. I'd assume the code would be something like

if (bugoptionison)
{
     return false;
}

in processgreatwall(), right?

Just hard code it for now to see the effect - it won't solve your problem. See my description a few posts ago of why - basically the ENGINE saves the graphics data for the GW outside of the DLL and the only way to remove it is to call the method that removes the GW with PRECISELY the same viewport state as it was added in (so that the coordinates all match what the engine saw at the time). In general there is no way to achieve that, which is why the final solution was to prevent it being present in saves in the first place.

 

[ls612]

Just hard code it for now to see the effect - it won't solve your problem. See my description a few posts ago of why - basically the ENGINE saves the graphics data for the GW outside of the DLL and the only way to remove it is to call the method that removes the GW with PRECISELY the same viewport state as it was added in (so that the coordinates all match what the engine saw at the time). In general there is no way to achieve that, which is why the final solution was to prevent it being present in saves in the first place.

Doesn't the new save format save the SVN rev it is on? Because then couldn't you make it so that it uses the old GW code (which worked fine mostly) for old saves and the new one for new saves? Sorry if I'm being annoying, but I really want to save this game without just staying at rev 4330 forever.

 

[Koshling]

Doesn't the new save format save the SVN rev it is on? Because then couldn't you make it so that it uses the old GW code (which worked fine mostly) for old saves and the new one for new saves? Sorry if I'm being annoying, but I really want to save this game without just staying at rev 4330 forever.

The old GW code didn't work either though, it just gave the illusion of doing so if you were not looking at the part of the viewport the engine though the GW was in. Also I didn't change ANY of the actual GW processing APART from taking it out and putting it back across a save, so it should behave identically for any existing save!

 

[ls612]

The old GW code didn't work either though, it just gave the illusion of doing so if you were not looking at the part of the viewport the engine though the GW was in. Also I didn't change ANY of the actual GW processing APART from taking it out and putting it back across a save, so it should behave identically for any existing save!

Well it behaved much better for the old code, 90% of the time it worked perfectly. Now it doesn't work ever.

 

[strategyonly]

Well it behaved much better for the old code, 90% of the time it worked perfectly. Now it doesn't work ever.

Isn't there an old source folder then you could look at ls612 and do a (comparison) such as WinMerge?? I have NO idea, just guessing, i dont know anything about coding, sorry.

 

[ls612]

Isn't there an old source folder then you could look at ls612 and do a (comparison) such as WinMerge?? I have NO idea, just guessing, i dont know anything about coding, sorry.

I could certainly revert the changes for myself, but that wouldn't help, as it would mean I'd need to recompile the DLL EVERY time I update the SVN, not fun.

 

[Koshling]

I could certainly revert the changes for myself, but that wouldn't help, as it would mean I'd need to recompile the DLL EVERY time I update the SVN, not fun.

Well look at the changes I made, and see if you can figure out what aspect caused it to get worse by reverting them selectively - I think only the removal across-a-save bit should be needed, so anything else that got left in is probably accidental and might be influencing things I guess...

 

[Koshling]

Just pushed to SVN (4340):

• Fixed CTDs that occur on most air missions

 

[Thunderbrd]

@Koshling: I've made some extensive changes and for numerous potential reasons, what I've done has caused savegame incompatibility. I figured it'd be easiest to ask where I went wrong by simply creating a branch (located in the branches folder under the name: saveincompat) and asking you to take a look at CvUnit, CvPlayer, enums.h, and infos files to see what I did wrong (I have a feeling you'll spot it as soon as you see the changes since the rules as to what we can and can't do are more clear for you.) I suspect its something I didn't do correctly in CvUnit wrappers.

Tomorrow, I'll be testing a few things to see if I can figure out my mistake. Half of my purpose for doing this is that I've been needing to figure out how to work with branches anyhow.

Well... so far I've been able to figure out CvCity was a bit of a mess. And I've tried a number of approaches regarding CvUnit. I think at this point CvUnit cannot be the problem for me the way I have it now so I'll look into some other issues. Anyhow, just to update you on my progress if you were looking into this for me.

 

[strategyonly]

Added CIVPlayer8 to mod designers list for Civicologist

 

[Hydromancerx]

Added CIVPlayer8 to mod designers list for Civicologist

Where is this list?

 

[strategyonly]

Where is this list?

Look at the BUG options when playing, and go allll the way to the right , under "CREDITS."