Multiple Maps and Mapscripts

[strategyonly]

FYI - version with working viewports up on the parallel maps SVN, if anyone wants to take a look. See http://forums.civfanatics.com/showpost.php?p=11595369&postcount=59

C2C port next week.

OK i looked at some of the python, you are using CvEventManager.py, but doesn't that have to be converted to a BUG type before going into C2C, no offense, but i tried using CvEventManager on other stuff and it doesn't work in C2C, am i just confused or like usual, not knowing what the "heck" i am talking about, again??

 

[Dancing Hoskuld]

StrategyOnly is correct. You can't use CvEventManager in C2C because it uses BUG based modular python which basically ignores (iirc) any file of that name. Anything that you want in a python event handler needs to be in its own module. There are many ways of achieving that.

 

[Koshling]

StrategyOnly is correct. You can't use CvEventManager in C2C because it uses BUG based modular python which basically ignores (iirc) any file of that name. Anything that you want in a python event handler needs to be in its own module. There are many ways of achieving that.

I don't use it in the viewports. Lytning uses it in the multimap switching. Since I'm only porting the multimap groundwork (which doesn't need this) and the viewports currently that aspect won't be in the port anyway. It's only use is so that the <MapInfo> can specify an event that triggers auto-transition to another map (Lytning has it set up so that end-turn transitions to a second map for demo purposes atm). In practise in C2C we'll be auto-transitioning WITHIN turns when you have units to move, and by explicit UI (which is TBD obviously, via the existing API (which is what this Python calls), so we won't need it anyway.

 

[strategyonly]

I don't use it in the viewports. Lytning uses it in the multimap switching. Since I'm only porting the multimap groundwork (which doesn't need this) and the viewports currently that aspect won't be in the port anyway. It's only use is so that the <MapInfo> can specify an event that triggers auto-transition to another map (Lytning has it set up so that end-turn transitions to a second map for demo purposes atm). In practise in C2C we'll be auto-transitioning WITHIN turns when you have units to move, and by explicit UI (which is TBD obviously, via the existing API (which is what this Python calls), so we won't need it anyway.

Its too bad it cant work in C2C, if it did, i would have around 25-35 more things i could do with C2C, that would enhance it tremendously.

 

[AIAndy]

Its too bad it cant work in C2C, if it did, i would have around 25-35 more things i could do with C2C, that would enhance it tremendously.

The conversion from CvEventManager to the BUG equivalent is simple and very mechanic.

 

[ls612]

Well Koshling, I want to congratulate you for making me load a mod other than C2C for the first time in ten months! Great work, I can't wait until this gets ported to C2C.

I have one issue though. In the modcomp, the viewport size is detetermined by a new Globaldefines file. Could that please be made a BUG option in C2C? That way it is much easier for the individual user to adjust to their preference.

 

[Koshling]

Well Koshling, I want to congratulate you for making me load a mod other than C2C for the first time in ten months! Great work, I can't wait until this gets ported to C2C.

I have one issue though. In the modcomp, the viewport size is detetermined by a new Globaldefines file. Could that please be made a BUG option in C2C? That way it is much easier for the individual user to adjust to their preference.

Yes, though changing it will require a reload for the change to take effect. How long did the transitions take for you?

 

[ls612]

Yes, though changing it will require a reload for the change to take effect. How long did the transitions take for you?

~3 seconds using the standard Viewport size. Changing it to a 40 by 40 reduced the time to about 2 seconds.

 

[Koshling]

~3 seconds using the standard Viewport size. Changing it to a 40 by 40 reduced the time to about 2 seconds.

..and that sems acceptable right? Transitions shouldn't need to be too common hopefully anyway (small number per turn in a moderatly advanced game maybe).

Incidentally, the adoption of viewports removes the restriction on all maps having to be the same size. The rule now is that viewport size cannot change (within a session), but there is now no need to pad the size of things like lunar maps and so on.

 

[strategyonly]

but there is now no need to pad the size of things like lunar maps and so on.

What does "pad the size" mean?

 

[Koshling]

What does "pad the size" mean?

Before viewports all maps in a multimap setup had to eb the same size, so a map lunar) for example would have to be a big as the earth. With viewports that restraint goes away.

 

[strategyonly]

Before viewports all maps in a multimap setup had to eb the same size, so a map lunar) for example would have to be a big as the earth. With viewports that restraint goes away.

ahhh, nice touch then, makes way more sense that way, way to go guys. . . .

 

[ls612]

..and that sems acceptable right? Transitions shouldn't need to be too common hopefully anyway (small number per turn in a moderatly advanced game maybe).

Incidentally, the adoption of viewports removes the restriction on all maps having to be the same size. The rule now is that viewport size cannot change (within a session), but there is now no need to pad the size of things like lunar maps and so on.

I posted a bug (at least I think it's a bug) on the Parallel Maps thread.

 

[Dancing Hoskuld]

The conversion from CvEventManager to the BUG equivalent is simple and very mechanic.

That is what I keep telling people but the just ignore me and say it is too hard

 

[ls612]

@Koshling:

Sorry to keep bothering you, but do you have an ETA on the conversion of the Viewports to C2C?

 

[Koshling]

@Koshling:

Sorry to keep bothering you, but do you have an ETA on the conversion of the Viewports to C2C?

This week

 

[ls612]

This week

Great! I can't wait to see how much this improves my machine's memory situation, currently it can almost run out of RAM on a giant map. (my system only has 3 gigs, so things can be touch and go)

 

[Acularius]

This week

That is excellent news.

 

[Koshling]

Preliminary result of viewport usage in terms of Civ memory usage. Please note that this is one data point from the port to C2C, and I'm still debugging so the code is not yet finalized. However...

....I loaded an industrial age GEM game I happened to have lying around, and after game load the memory usage without viewports enabled was 1.4G. With viewports enabled (using a 50 X 50 viewport) it's 900M. Since the base before any map laoding is around 600M this means the map-related contribution dropped from around 800M to about 300M. Furthermore it should be fairly stable at that sort of level for ANY map size.

 

[ls612]

Preliminary result of viewport usage in terms of Civ memory usage. Please note that this is one data point from the port to C2C, and I'm still debugging so the code is not yet finalized. However...

....I loaded an industrial age GEM game I happened to have lying around, and after game load the memory usage without viewports enabled was 1.4G. With viewports enabled (using a 50 X 50 viewport) it's 900M. Since the base before any map laoding is around 600M this means the map-related contribution dropped from around 800M to about 300M. Furthermore it should be fairly stable at that sort of level for ANY map size.

Nice! How does the non-graphics memory usage scale though? Is it by map size, number of cities, or a combination of the two?