• Civilization 7 has been announced. For more info please check the forum here .

Multiple Maps and Mapscripts

In regards to your question in the viewports thread, unit and city position is referenced with X and Y coordinates all over the place. Pretty much any code part that accesses those coordinates will need a review in regards to that one of the units might actually be on another map.
 
In regards to your question in the viewports thread, unit and city position is referenced with X and Y coordinates all over the place. Pretty much any code part that accesses those coordinates will need a review in regards to that one of the units might actually be on another map.

OK, that doesn't sound fun. I somehow suspect it will be more complicated than adding an "int iZ" argument to every plot related function.
 
In regards to your question in the viewports thread, unit and city position is referenced with X and Y coordinates all over the place. Pretty much any code part that accesses those coordinates will need a review in regards to that one of the units might actually be on another map.

Nah. Jut change the iterators to make only a current map visible to most code (the iterators wouldn't iterate through units on other maps), then iterate through maps at a higher level to context-set. That way mot code can operate as now, and only code that has to be explicitly aware of inter-map movement need change. Won't work everywhere, but would for most of the AI for example.
 
Nah. Jut change the iterators to make only a current map visible to most code (the iterators wouldn't iterate through units on other maps), then iterate through maps at a higher level to context-set. That way mot code can operate as now, and only code that has to be explicitly aware of inter-map movement need change. Won't work everywhere, but would for most of the AI for example.
Hmm, yes, that will probably end up considerably less painful.
So all old methods refer to the coordinates on the current map except for a new set of methods that also take the map ID.
 
Can't multi-maps wait until other, more basic issues (such as nomadic start), get implemented?
 
We did a poll as to what should be taking priority focus for the team overall and Multi-maps won out over nomadic start (search the forum for the thread on that 12padams...).

I have it in mind to really work on Nomadic Start someday soon but I've got a lot to get through first. Its one of my favorite ideas and we haven't, as a team, been able to get enough consensus on how it should play out to really develop it further. Besides that, we all have so much we're working on ourselves at the moment.

Multi-Maps would be a huge hurdle to have overcome once we have it so I'm all for seeing it getting implemented. Still, I'm patient as I'm not a good enough programmer to think I can even assist much in that project.
 
Can't multi-maps wait until other, more basic issues (such as nomadic start), get implemented?

The Long Freeze is supposed to be for addressing basic balance issues with the current game through the Transhuman Era as well as for stability purposes. That was one of the main reasons I advocated for this time, was so that we would have a rock solid base for Multi-Maps before year's end.

Nomadic Start is rather controversial among the team, especially considering the resources that would be necessary to implement it. I personally would vote for setting up the Galactic Era after the long Freeze.
 
When will the Freeze start, anyway? When v27 is released?
 
When will the Freeze start, anyway? When v27 is released?
Judging by the recently extremely frequent bug fix updates on the svn I thought it had already started...
 
Judging by the recently extremely frequent bug fix updates on the svn I thought it had already started...

Yes, the freeze started today technically, although it has been on for a week in fact. I'll probably release V27 the first weekend in November assuming the major bugs have all been addressed.
 
@Koshling:

I was wondering, given what we already have in the DLL and the Parallel Maps codebase (however incomplete) that is still extant, what specifically would be necessary to add the ability to support Multiple Maps? I know that the iterators would need to be adjusted and that map object classes would need to be added, but what else am I missing, and how long would that take theoretically? I hate to be a constant nag about this, but I would really like to be able to see multi-maps by year's end. That new feature alone will I suspect double our user base and popularity, due both to the novelty and to the new vistas it opens up for modding Civ 4.
 
@Koshling:

I was wondering, given what we already have in the DLL and the Parallel Maps codebase (however incomplete) that is still extant, what specifically would be necessary to add the ability to support Multiple Maps? I know that the iterators would need to be adjusted and that map object classes would need to be added, but what else am I missing, and how long would that take theoretically? I hate to be a constant nag about this, but I would really like to be able to see multi-maps by year's end. That new feature alone will I suspect double our user base and popularity, due both to the novelty and to the new vistas it opens up for modding Civ 4.

The map object is already there. What is needed is to add the extra coordinate (map Id) to units and cities, fix the iterators, and provide some way to actually access different maps in UI terms. As and when travel between maps becomes possible that will presumably need new AI also.

Btw - I had an idea for a totally different way to do multi maps (and viewports) in terms of the underlying mechanism, which (if I can make it work) may well have far less graphical artifact issues, and also allow viewports or maps to be of different sizes. I have not done the necessary experiments yet though to see if it's possible.
 
Top Bottom