Viewports

[Cyrusfan]

BUG menu, under automations. The option is whether or not to hide the automate button, it may or may not affect the key functionality, but I hadn't noticed units getting automated when I recenter the VP until yesterday's game (could be because I've been using it mainly with workers active who probably wouldn't be affected by it).

The hotkey command is observable from the Automate City Defense button if it hasn't bee hidden.

 

[Nimek]

Do I understant correct. Now thanks to viewports we will be able to build gigantic maps or higher and this will not ause a MAF error?

If I am correct I would love to see Giagantic Earth Map so huge as possible with so much civs as possible to simulate entire world

Just imagine world map so huge tha capture every civ is almost imposible. Map where You can have all of resources only thanks trade.

 

[ls612]

Do I understant correct. Now thanks to viewports we will be able to build gigantic maps or higher and this will not ause a MAF error?

If I am correct I would love to see Giagantic Earth Map so huge as possible with so much civs as possible to simulate entire world

Just imagine world map so huge tha capture every civ is almost imposible. Map where You can have all of resources only thanks trade.

That would definitely have to wait until after Multi-Maps are added and we see how much memory is left over. Currently a Gigantic size map (180x120 tiles) running in a 75x50 tiles Viewport on High graphics uses 2 GB of RAM, meaning that after Multi-Maps and associated content is added that could be much higher. It all depends on what the scaling constant is with non-graphical memory (Maybe Koshling knows?), and how many of these odd graphical errors Koshling can fix with Viewports.

 

[Koshling]

That would definitely have to wait until after Multi-Maps are added and we see how much memory is left over. Currently a Gigantic size map (180x120 tiles) running in a 75x50 tiles Viewport on High graphics uses 2 GB of RAM, meaning that after Multi-Maps and associated content is added that could be much higher. It all depends on what the scaling constant is with non-graphical memory (Maybe Koshling knows?), and how many of these odd graphical errors Koshling can fix with Viewports.

My (long term) goal is a 1 million tile version of GEM (1000 X 1000 in area though thr actual numbers would be different becasue GEM isn't square). Viewports are one ingredient needed to amke this possible, but not the only one. Currently we can't support maps with > 65535 tiles (255 X 256 say is a practical upper limit) due to some encoidnigns used internally. Those are easily addressed, at which point the only (sensible!) limits will be memory usage (which I think will be fine out to 1000X1000 on 4G machines with viewports), and turn times (which increases with map size due to there being more) to process. I'm working on turn times anyway periodically, so the upper limi for map sizes will trend up over time.

 

[ls612]

My (long term) goal is a 1 million tile version of GEM (1000 X 1000 in area though thr actual numbers would be different becasue GEM isn't square). Viewports are one ingredient needed to amke this possible, but not the only one. Currently we can't support maps with > 65535 tiles (255 X 256 say is a practical upper limit) due to some encoidnigns used internally. Those are easily addressed, at which point the only (sensible!) limits will be memory usage (which I think will be fine out to 1000X1000 on 4G machines with viewports), and turn times (which increases with map size due to there being more) to process. I'm working on turn times anyway periodically, so the upper limi for map sizes will trend up over time.

Wow, if we can do that with C2C and have turn times under an hour I will be amazed.

 

[Koshling]

Wow, if we can do that with C2C and have turn times under an hour I will be amazed.

I'm not claiming it will be feasible on all hardware, but some major bottlenecks are in-principal parallelisable, so we can fully exploit multiple cores, and there's at least a doubling in speed to be had still from continuing to improve the single threaded algorithms, so on a good quad core machine I can see up to around a ten fold speed increase being reasonably achievable in time. GEM is around one 40th that area, but until the game gets very developed (and yes ultimately I realise it will) much of the area is wilderness (and 2/3rds is sea and always will be) which has very low processing overhead, so I can see a game at that scale running only maybe twice as slow as a GEM game does today, and a factor of 2 is easily made up in hardware in a couple of years.

 

[ls612]

I'm not claiming it will be feasible on all hardware, but some major bottlenecks are in-principal parallelisable, so we can fully exploit multiple cores, and there's at least a doubling in speed to be had still from continuing to improve the single threaded algorithms, so on a good quad core machine I can see up to around a ten fold speed increase being reasonably achievable in time. GEM is around one 40th that area, but until the game gets very developed (and yes ultimately I realise it will) much of the area is wilderness (and 2/3rds is sea and always will be) which has very low processing overhead, so I can see a game at that scale running only maybe twice as slow as a GEM game does today, and a factor of 2 is easily made up in hardware in a couple of years.

Well, given that I have an 8 threaded processor multi-threading will be very helpful for my machine.

 

[Koshling]

Well, given that I have an 8 threaded processor multi-threading will be very helpful for my machine.

It's not a small project though. I think I will spend one full cycle working on that (that's about the magnitude of it I think). Also I suspect it is not compatible with multiplayer games (apart from hotseat) because too much synchronization between threads would be required to ensure the same random number usage (without which OOS will result), and that would kill the degree of effective paralellism. Havign said that, a multi-threaded implementation will certainly be easy to artifically single-thread when it's a multi-player game, so that doesn;t stop us doing it - it just measn that multiplayer games won't see any (or much) benefit.

 

[Cyrusfan]

Regarding the map size discussion-how difficult would it be to add a bigger map size now? I know one of the scripts can override the size, up to 255x255, but most, I think, can't. Also that override may not (no indication it does from what I recall) make adjustments for research speed or anything else partially determined by mapszie.

A bug: VP 30x50,2,15
View attachment What in the world.rar
So I've got a segment of great wall cutting right through the middle of my view. I tracked down where it came from ( on a later turn)
View attachment no really sos.rar
What apparently happened is around the time when I sentried that stack next to Varna, *something* occurred to make that instance of the wall float. I may have saved (a long time ago-no saves before the artifact appeared) right before that action, otherwise I can't think of how that particular tile got centered for VP view.

Does the wall redrawing code only look at the previous border or is it supposed to remove all instances of the wall graphic? If the latter I don't know how it's even possible for this wall to be hanging around.

 

[Koshling]

Regarding the map size discussion-how difficult would it be to add a bigger map size now? I know one of the scripts can override the size, up to 255x255, but most, I think, can't. Also that override may not (no indication it does from what I recall) make adjustments for research speed or anything else partially determined by mapszie.

A bug: VP 30x50,2,15
View attachment 328641
So I've got a segment of great wall cutting right through the middle of my view. I tracked down where it came from ( on a later turn)
View attachment 328642
What apparently happened is around the time when I sentried that stack next to Varna, *something* occurred to make that instance of the wall float. I may have saved (a long time ago-no saves before the artifact appeared) right before that action, otherwise I can't think of how that particular tile got centered for VP view.

Does the wall redrawing code only look at the previous border or is it supposed to remove all instances of the wall graphic? If the latter I don't know how it's even possible for this wall to be hanging around.

The wall drawing code is sadly all inside the main game engine and not something we can control. We can make exactly two calls to influence the great wall - add one (giving the city its based in) and take one away (again giving the city). This is problematic with a viewport switch since the city it's in may not be within the viewport. So what I do is this:

1) On viewport switch in (a switch is an out of the current and and in of the new, but describing it this way round makes more sense), if the city it's in is within the new viewport I just add it giving the city it's in. If that city is not in the viewport, but one that would be within the GW is, then I add it using THAT city (gives the same logical result). If NO city within the GW is within the viewport I don't add it at all.

2) On viewport switch out, I remove using whatever city I used to add it on the switch in.

This basically seems to work (and I can't think of a better way). The problem case is the load of a saved game. This is because the game engine has its own save data and remembers where it thinks the GW is (which is usually wrong as the viewport has switched under it across the load), so it paints it in some bizarre place that I have no way to actually remove. To solve THAT I remove the GW prior to any save, and that's also why I now remove and re-add it on each turn (which is why the dynamic GW option is requred by viewports and automatically on when you are using them).

The only remaining case I am aware of is saves that were made without viewports being in use (and without dynamic GW turned on), which includes ALL saves that pre-date the addition of viewports (so pre V25 essentially) - loading those can result in bits of GW appearing randomly. HOWEVER, it SHOULD resolve itself if you select a viewport that includes the actual GW and save the game. The resulting save should be free of issues.

It sounds like the case you are reporting might be different however. Does the game concerned predate V25 or was it entirely played with V25? Have you always had viewports (or dynamic GW) enabled at least since the GW was built? If you have then this must be some other bug I'm not aware of (but it may very well not be tractable since we have so little control over the display of the GW).

I could add a BUG option to entirely turn off GW display, so at least any games that are badly affected could choose to no display it at all - is that worthwhile do you think?

 

[Cyrusfan]

The v25 release came out before I hit the classical era, but I've been using the SVN and I'm pretty sure your GW fix had been there before I even started the game. I've always had the VP on since this is a gigantic map. In any case, I think the border the wall was sitting on wouldn't have looked like that until this week when I finished the war with Nabora and the borders in the area firmed up. I need to take another look to be sure, but I think the stack I mentioned for the second save had been sitting in the city as a garrison until I got it to a point it could build its own town watchmen in a reasonable amount of time.

The reason I was trying to locate the border of the wall was I was hoping if I got the artifact lined up with the current border they both might get erased on a VP switch. I thought I had gotten that to work once, but couldn't reproduce it.

As for the BUG option, I'm going to say yes. This artifact wouldn't bother me but for the fact that it goes right by the center tile of my VP, so I always see it. However, if this can happen once, long after the wall was initially built, it might happen more than once, which would be very distracting.

 

[jmmendesp]

If it can't be fixed in order to avoid having it in the wrong place, I would totally appreciate a BUG option to hide the GW.

How about bridges? Are those unfixable too? Cause those would be slightly more problematic if they were graphically removed, compared to the GW (imo).

 

[Cyrusfan]

Oy. So I just tried lining up the artifact with my border (pressing c with the stack by Varna active) and never pressing c again, played a couple of turns so that the VP switches naturally and the artifact has disappeared, which is a success for me. I saved, went to the title screen and reloaded and it seems to be gone.
View attachment sos.rar
When I was failing to reproduce this earlier, I was using c to recenter and the wall came with me. But now c won't work on my old save now for some reason, so I can't reproduce that failure (it works when I load this save, so I have no idea what the issue there is).

c-centering doesn't do anything different from an automatic VP switch, does it?

 

[Koshling]

Oy. So I just tried lining up the artifact with my border (pressing c with the stack by Varna active) and never pressing c again, played a couple of turns so that the VP switches naturally and the artifact has disappeared, which is a success for me. I saved, went to the title screen and reloaded and it seems to be gone.
View attachment 328644
When I was failing to reproduce this earlier, I was using c to recenter and the wall came with me. But now c won't work on my old save now for some reason, so I can't reproduce that failure (it works when I load this save, so I have no idea what the issue there is).

c-centering doesn't do anything different from an automatic VP switch, does it?

No, it's exactly the same code. Both are just calls to recenter the viewport on a particular tile.

I'll add an prion to hide the GW and not worry too much about this for now (I'm trying to stick to AI work for a bit as I have a lot to do there). However, if people continue to see it frequently I'd appreciate more details about when it seesm to happen and if it persists across a save a save game.

 

[Terxpahseyton]

You guys have some crazy ideas. But that is not really the unusual part. I think many Civers had such dreams at some point. What is unusual is that you actually intend to make them come true and seem quit serious about that.. 1kx1k map? I wish the best of luck with it

 

[civfan613]

The feature that I can't await, is of course Multi-Maps - but with some good aid of reducing memory consumption...
Cause I hate 1-minute-long turns...

A side question, kinda:
What EXACTLY IS causing such long end-turns (on big maps with lots of civs)???
Cause using viewports did NOT reduce it at all, or I didn't feel it...
And I have quite a good laptop, so memory per se shouldn't be the cause...
Anything you can think of???

 

[ls612]

The feature that I can't await, is of course Multi-Maps - but with some good aid of reducing memory consumption...
Cause I hate 1-minute-long turns...

A side question, kinda:
What EXACTLY IS causing such long end-turns (on big maps with lots of civs)???
Cause using viewports did NOT reduce it at all, or I didn't feel it...
And I have quite a good laptop, so memory per se shouldn't be the cause...
Anything you can think of???

Mostly Build lists and AI evaluations thereof i think. There are other things, but that is the big consumer.

 

[civfan613]

So, is there a way to reduce it myself???
Or maybe any of you should be working on it..?
Cause this is the most annoying part of the entire mod - which can frustrate to the point of dropping the playing for a while...

 

[Koshling]

So, is there a way to reduce it myself???
Or maybe any of you should be working on it..?
Cause this is the most annoying part of the entire mod - which can frustrate to the point of dropping the playing for a while...

I work on it from time to time. The mod is currently at least 10 times faster than the base BtS code for given size and complexity. The problem is that C2C has a much higher level of complexity so it chews it up.

Main consumers are:

AI unit movement/attack decisions
AI tech and civic choice decisions (which don't happen every turn but most turns a subset of the AIs will be doing them)
AI city build decisions
Python code generally (especially if you have REV on)
Trade region recalculation (doesn't happen every turn, but if a tile flips ownership and changes what is conected a lot of quiote expensive caulcation ensues)
AI city worked tile/specialist placement
AI trade decisions (not all the time but can be expensive on some turns)

Most of the above scale directly or indirectly with map size and/or civ count (bigger maps lead to more cities, more units, etc. is what I mean by the indirectly part)

Viewports don't help with speed (apart from graphical rendering, which is not an issue unless you have a very low end graphics card), just memory.

 

[civfan613]

Koshling
I see.
I thought similarly...
So, this is a problem that can only (MAYBE) be helped by much better computers.
Also, a side question:
I use a W7 x64 i3 4GB laptop - but I've seen people mentioning "turning multi-core and memory on/off".
Does it apply to me - and would it help at all anyways???
Thanks.