One of the options for alternate maps is worldbuilder saves, so yes, you can load premade maps. What do you mean by different rules?
Parallel Maps
- Thread starter LyTning94
- Start date
One of the options for alternate maps is worldbuilder saves, so yes, you can load premade maps. What do you mean by different rules?
raystuttgart
Civ4Col Modder
Congratulations to this. 
It really is the most astonishing ModComp I have seen in the last years.
Lots of potential.
Already got some ideas how this could be used in our project ...
(Although these ideas would require massive amounts of effort.)
It really is the most astonishing ModComp I have seen in the last years.
Lots of potential.
Already got some ideas how this could be used in our project ...
(Although these ideas would require massive amounts of effort.)
The Capo
godless Heathen
This does have a lot of potential. It could be used for the obvious "two or more planet" scenarios, but could also be used for things like the age of exploration/imperialism (where you could have Europe and then maps for the Americas, Africa, Asia etc.) or a world war (like a European and Pacific theater for WWII), or as mentioned before just a change in terrain. This is a fantastic idea, I wish you luck in expanding upon it.
Looks interesting. On largish map sizes what is the map-switch lag time like? (and what happens visually during the switch - blank screen or old map displays until new is basically ready)?
I'm guessing the switch time is likely to be somewhere in the 2-10 seconds range for large+ maps, and that it basically blanks in that period...?
I'm guessing the switch time is likely to be somewhere in the 2-10 seconds range for large+ maps, and that it basically blanks in that period...?
On my PC it takes ~15 seconds to switch between huge maps, and ~30 seconds for the first switch to a map (since it has to generate the map). Standard sized maps take ~5 seconds to switch with ~11 seconds for the initial switch.
When switching maps, the screen displays the old map during the waiting time, and then switches to the new map.
Ok, that's not so bad at all.
Another question for you:
Suppose IO have cities on two different maps, and in a particular turn both complete a production and thus need new orders. Normally at the start of a tun you get popups for each such city and the map centers on them. Obviously, with them being on separate maps this cannot happen, so what does? Are popups queued by map somehow?
Because there are so many different scenarios to use this mod, I haven't implemented anything yet to handle possibilities such as this. If you are switching between maps every turn, I think the best way to handle this (I haven't tested it yet, but it should work) would be to put a loop into one of the doTurn() functions so that it handles all of the player's data shared between maps, such as technologies, at the beginning of the turn, but handles things like city production when it switches to each subsequent map.
I just started working on a new version that adds some functionality like this, and will hopefully make the mod a little easier to use.
Since this is still code, I can't test it.
You'll need to make sure end-turn doesn't skip a map if the user doesn't explicitly select it (so either end-turn on one map implicitly ends turn on all, or implicitly switches the user to the next map).
One thing that would be nice, and which I expect we'll need to do later in C2C anyway, if not in the base, would be to keep the concepts of maps as display spaces (i.e. - what the Civ4 engine is aware of as the set of graphical entities and externally visible CvMap instance) and play-spaces (i.e. - what the AI and turn processing sees) distinct. See this thread for one reason why this would be nice: http://forums.civfanatics.com/showthread.php?t=460484.
It's not for me to say what you should do in your mod, but since the eventual need (my need, not neccessarily yours, so take this only as opinion) would require such a split, it would be better if aspects that entangle the two concepts were avoided rather than increased. Handling UI interaction that is initiated by the game, rather than the user (popups and map-centering mostly), is one major such area. If you address it by changing processing order in things like doTurn() you tend to entangle the things better kept separate. Looking at filtering the message queues by map, so that only those relevant to the current map get delivered, and the rest stay queued, might be an alternate approach without this downside. End-turn would still need to implicitly map-switch if another map had queued up interactions, but that's true either way I think.
I've never messed with the UI, so I was planning (at least for the time being) to use the end-turn button as a method to switch between maps, and end the actual turn when all maps have been played.
Interesting ideas. Splitting a larger map into smaller ones could be useful in all kinds of scenarios, which would mean the AI would have to have access to the other maps, like you said. I'm not sure how to go about that... I'll have to take a look at the code.
I should be in a position to start playing with it also in a couple of weeks I hope.
I came up with a few ideas, based on Koshling's idea of multiple maps within one larger one, that would not only add this feature, but also make the mod a lot easier to use. At the moment this is all purely speculative; I haven't even confirmed that this will work, thought I see no reason why it shouldn't.
I could add two new XML systems: MapGroupInfos and MapSwitchInfos. A map group would contain one or more maps that occur on the same "planet" and are connected to each other. For maps one different planets, you would create multiple map groups. MapGroupInfos would hold information such as how techs are shared between this and other groups, the year/event in which the map group is made available, and the map switch type the group uses.
MapSwitchInfos would hold which map group is being switched to and the event or number of turns which causes it to switch.
While map groups requre a map switch event to switch between, maps within a group can be switched to at will. I could also add a new advisor screen that contains a 2D strategic overview of the entire map group, not just the map visible at the time. It would be similar to the map in the military advisor screen.
Making these changes would mean that the mod could be used with purely XML modding, which would be a huge benefit. I'm not sure how much it will take to teach the AI to use other maps in the same map group or to make the necessary UI changes, but aside from that it should be pretty straightforward.
I could add two new XML systems: MapGroupInfos and MapSwitchInfos. A map group would contain one or more maps that occur on the same "planet" and are connected to each other. For maps one different planets, you would create multiple map groups. MapGroupInfos would hold information such as how techs are shared between this and other groups, the year/event in which the map group is made available, and the map switch type the group uses.
MapSwitchInfos would hold which map group is being switched to and the event or number of turns which causes it to switch.
While map groups requre a map switch event to switch between, maps within a group can be switched to at will. I could also add a new advisor screen that contains a 2D strategic overview of the entire map group, not just the map visible at the time. It would be similar to the map in the military advisor screen.
Making these changes would mean that the mod could be used with purely XML modding, which would be a huge benefit. I'm not sure how much it will take to teach the AI to use other maps in the same map group or to make the necessary UI changes, but aside from that it should be pretty straightforward.
Adding XML modding would be awesome. Especially since I can't do SDK
I agree completely. A lot more people will be able to use it, and it will be a lot easier to use in general, which is one of the main reasons I'm doing it.
Sounds like a good plan at theXML level.
Internally I think this requires two classes that implement the interface of CvMap. One is internally facing and is pretty much what CvMap is now - this is what most of the DLL sees (and in particular the AI). It corresponds to a map group in the XML tagging level (i.e. - one large 'play surface'). The other is externally facing (what we present to the Civ IV engine for graphical purposes). It needs to be an indirection to an appropriate subset of the internally facing instance, so that (for example) plot() returns a pointer to the plot allocated by the internal class (so where the internal class has a true array of allocated plots, the external just has indirections to them). Only the externally facing instance manages graphics entities.
I very much like the idea of a new advisor-like screen to provide the 2D overview map. In my original suggestion I was planning to use another pseudo-CvMap in this role, but your suggestion is better I think. IMO the 'maps' (I prefer 'viewports' just so we're clear what we're talking about) within a map group should not be rigidly defined by the XML (though it can instantiate a default set optionally, or possibkly lock down a fixed set, again optionally at the modder's discretion). Instead the 2D overview should allow the user to define new viewports dynamically according to need (to center them over areas of interest). Just showing them as shaded areas on the overview 'map' and allowing them to be manipulated there (created, switched between, etc.) would be ideal.
Edit - the CvPlot instances we pass to the Civ IV engine probably need to be subclasses actually (well, the underlying ones will hav tio eb the subclasses because we can't chnage the naming which fixes linker names for non-virtual methods). The reason is that CvPlot::GetX() and CvPlot::getY() need to map coordinates between the 'real' coordinates in the larger map group, and those within the viewport that the engine will expect to see.
Sounds good. I think a subclass should serve the purpose if we derive it from CvPlot and make functions like getX() and getY() virtual, so we can redefine them in the subclass.
Do you have any suggestions to handle calls like getMap().numPlots()? How will getMap() know to return either the visible map or the entire group?
I was originally thinking we would allocate each individual map as one object, but if we instead made the whole map group one map object it shouldn't be too difficult to change the viewports in-game. I think this is probably the better solution anyway.
EDIT: If we did treat the map group as one map there would be no need for a seperate XML class. The map group would be the map, and the viewports could be user-defined, like you said. The viewports themselves should probably be a seperate class derived from CvMap, though there's still the problem of how getMap() will know which object to return.
Agree with almost all of this. However, You cannot subclass CvPlot (or CvMap) and provide the subclasses to the game engine I dont think. Reason is that it is compiled against these class names and many of the methods are non-virtual, so the linker will have baked them into the Civ4 engine (i.e. - the name of the class that gets provided to the external game engine cannot change). That means one of the following:
1) The subclass would have to be the internally facing vesrion, which would require renaming of all internal uses to the subclass name (yuck); or
2) Don't subclass at all, just have an instantiation mode on the instances that is passed into the constructor - one mode provides 'true' coordinates, and has all the real data. The other mode maps coordinates and indirects (for all its underlying data) to another insance which is operating in the first mode. The underlying map (group) object is populated with CvPlot instances in the first mode, the overlying (viewport) CvMap is populated with CvPlots operating in the second mode and redirecting for real data
Option (1) will just be downright painful to do to the code (and especially when porting from this mod to another) since it will require naming changes prety much everywhere. Option (2) is slightly icky from a purist O-O standpoint, but practically it isolates the changes to the classes themselves (CvMap, CvPlot). We might need to break the actual data storage (of CvPlot) out into a third class (CvPlotData say) so that the size of the 'dummy mode' instances isn't uneccessarily large (i.e. - there are a lot of these objects and stroign everything in their members that CvPlot does now, but only using it from the ones operating in one of the two modes would be very wasteful).
I would definately go for option (2)
Good point. I didn't think of that.
Option 2 sounds like a good idea, and definitely the better choice. One question, though: How will getMap() know whether to return the CvMap with plots operating in the first mode (most of the time), or the CvMap with plots in the second mode (for calls from the game engine)?
Similar threads
