Multiple Maps and Mapscripts
- Thread starter ls612
- Start date
Too soon to be absolutely certain, but to a reasonable level of confidence it doesn't look like it.
@Koshling: You said that LyTning is working on the core Multi-Map implementation and that the main issue outstanding is how end-turns are handled. My question is, how will the Viewports handle end-turns when you are exploring in the Prehistoric Era and have the 'auto-end turns' option on? I can't see that being an issue in the Modern era, but in earlier eras that may run into snags.
No, I think it's non-issue. It won't auto-end unless you have no actiosn to take ANYWHERE on the current map (whether in the current viewport or not).
But, if you have a scout set to explore in another viewport, will it move without switching viewports?
Yes, anything automated will move without requiring a viewport switch (same for map switch if you have a map that is entirely automated). At least that's the intention.
strategyonly
C2C Supreme Commander
I wonder how the Original Zelda did a so called top and below map, WAY back in the late 90's then? That was the main reason i stated playing (PC/Playstion/Nintendo) stuff in the first place, because of the 2 map situation, but haven't seen alot of them besides the Heroes series before?? But i haven't played any new games since 2006 other than Civ or even bought another game.
MaXimillionZero
Warlord
- Joined
- Sep 26, 2010
- Messages
- 205
With an engine designed for it, and with far less objects stored than even the smallest Civ IV map.
We abuse the Civ4 graphics engine in ways it was never meant to be used. That is why we get the limitations.
@Anyone with enough technical knowledge to help:
I'm currently stumped on an issue I never even saw coming, which while not a complete stopper is extremely irritating. If anyone has suggestions I'd welcome them.
Background:
I have viewports essentially functionally working but have no UI to control them. My intention was that I'd use a screen like the military advior which would display the entire underlying map, and allow you to set the viewport position by interacting with that (ideally it would display outlines of the viewports and so on, but that's a detail). For now I'm trying to just modify the military advisor slightly to achieve a crude version of this that simply re-centres the viewport wherever you click on the minimap displayed in the advisor screen.
The following aspects (which I had expected to be the hard part) all work:
The one issue I simply cannot find a solution to is figuring out where the user has clicked on the minimap! The military advisor Python gets an event OnMinimapClicked, which it responds to by simply closing. This event has no arguments and does not tell you anything about where on the minimap was clicked (just that it was). Without the multimap work, basic BTS treats such a click by centering the main map on the point you clicked. Since there is a map switch (well strictly a viewport switch but it amounts to the same thing) on advisor exit, this behaviour doesn't occur (the switch obliterates all map context and recreates it). Here are the things I've tried:
I can continue to test with no decent UI for the viewports, and just have key combos (ctrl-shift-cursor arrow or something) to slide the viewport in a desired direction. That kind of works for basic demo purposes, but it won't realistically be a useable UI I don't think.
Open to any suggestions...
I'm currently stumped on an issue I never even saw coming, which while not a complete stopper is extremely irritating. If anyone has suggestions I'd welcome them.
Background:
I have viewports essentially functionally working but have no UI to control them. My intention was that I'd use a screen like the military advior which would display the entire underlying map, and allow you to set the viewport position by interacting with that (ideally it would display outlines of the viewports and so on, but that's a detail). For now I'm trying to just modify the military advisor slightly to achieve a crude version of this that simply re-centres the viewport wherever you click on the minimap displayed in the advisor screen.
The following aspects (which I had expected to be the hard part) all work:
- Forcing the advisor minmap to display the entire map regardless of your military unit disposition
- Scaling the entire map into a pseudo viewport that the minimap sees as the 'map' (because the 'map' size must be constant to the game engine and that includes all minimap instances)
- Switching effective viewport on entry to, and exit from the advisor screen (so that the advisor screen sees the scaled 'full' map)
The one issue I simply cannot find a solution to is figuring out where the user has clicked on the minimap! The military advisor Python gets an event OnMinimapClicked, which it responds to by simply closing. This event has no arguments and does not tell you anything about where on the minimap was clicked (just that it was). Without the multimap work, basic BTS treats such a click by centering the main map on the point you clicked. Since there is a map switch (well strictly a viewport switch but it amounts to the same thing) on advisor exit, this behaviour doesn't occur (the switch obliterates all map context and recreates it). Here are the things I've tried:
- Retrive the 'lookAt plot' on exit from the advisior (before any map switching) using gDLL->getInterfaceIFace()->getLookAtPlot(), and calling gDLL->getInterfaceIFace()->LookAt() with the appropriately transformed coordinates after the map switch. This isn't a total failure but the results are highly erratic - basically the correlation between where you click and what a call to getLookatPlot() returns shortly afterwards is best described no more strongly than 'positive'! 2 times out of 3 you get somewhere near the llocation you actually clicked, the remaining times seem to be a total lottery - I cannot identify any pattern either.
- Looking for mouse events in interactions with the minimap (you don't get any)
- Trying to find some way to query the mouse location when the event fires (I can't find a way to do this) [I can probably get the absolute mouse location from Windows, as well as the top left of the current Window, but I'm not sure how reliably I could map that to a minimap location given the rendering of the Python screens and how that reacts to things like resolution]
- On the assumption that the default BtS behaviour effectively calls lookAt(), entirely internally to the game engine (i.e. - interaction between the minimap and the main map happens directly all inside the engine), I hacked the vTable for the class instance (presumably a singleton) of CvDLLInterfaceIFaceBase you get from gDLL->getInterfaceIFace(). This works (in the sense that my patch gets called ok when the DLL makes calls through this instance), but is not called by whatever the engine itself does (so I guess it goes directly to a concrete class or something)
I can continue to test with no decent UI for the viewports, and just have key combos (ctrl-shift-cursor arrow or something) to slide the viewport in a desired direction. That kind of works for basic demo purposes, but it won't realistically be a useable UI I don't think.
Open to any suggestions...
@Koshling:
I like what I'm seeing so far on the workings of the new Viewport system. I have a few questions about it though. The first one is, what is the net RAM gain from this. I would assume it is quite substantial, but I'd like to know for sure.
Also, you said that you have been working on the Viewports side of things, and LyTning has been working on the actual Multi-Maps. How will the mechanics of the Multiple Maps in C2C work. Specifically, how will
work in practice, assuming those have been hashed out between you and Lytning? I like to understand how things work on a technical level, even if not all of it makes sense to me.
I like what I'm seeing so far on the workings of the new Viewport system. I have a few questions about it though. The first one is, what is the net RAM gain from this. I would assume it is quite substantial, but I'd like to know for sure.
Also, you said that you have been working on the Viewports side of things, and LyTning has been working on the actual Multi-Maps. How will the mechanics of the Multiple Maps in C2C work. Specifically, how will
- Movement of units between different maps (not viewports)
- Transmission of yields/commerces and trade
- AI understanding of working with multiple maps
work in practice, assuming those have been hashed out between you and Lytning? I like to understand how things work on a technical level, even if not all of it makes sense to me.
Unknown at this point, as it's not something I've even considered measuring (will need a mature game, which I cannot load since all the work is currently in the parallel maps mod which has no body of saves to use). However, I would expect significant (100s MBytes) savings for games with maps that are significantly larger than the viewport size you choose (which I'll probably default to around 75 X 75 or so)
Also, you said that you have been working on the Viewports side of things, and LyTning has been working on the actual Multi-Maps. How will the mechanics of the Multiple Maps in C2C work. Specifically, how will
- Movement of units between different maps (not viewports)
- Transmission of yields/commerces and trade
- AI understanding of working with multiple maps
work in practice, assuming those have been hashed out between you and Lytning? I like to understand how things work on a technical level, even if not all of it makes sense to me.
The groundwork will provide APIs to allow units to be moved between maps. It's up to the mod that uses it to decide how to employ that. One example might be a 'wormhole terminus' building you can build in a city maybe. Since the APIs will all be exposed to Python it would then be possible to add a unit action ('go through wormhole' or whatever) to move it to another map.
The model for commerce/yield is likely to have two options, which comes down to how turn ends are handled on different maps:
1) Turn ends are synchronized (i.e. - all maps have time running at the same rate, so on each turn every map processes any necessary movement etc.). In this case (which I think is what we'll want for C2C) then player-level stuff is pooled across maps. Just think of the map id as being a third spatial plot coordinate (so instead of a unit or city being at (x,y) it's at (x,y,M) wheer M is a map id). As now, where something is doesn't impact whether its net commerce output flows to the player or not, and so that won't change. As for resource availability, that depends how we want to define trade route connectivity between maps, which hasn' been decided (or even thought about really)
2) Maps have independent turn sequences, so 10 turns (say) could go by on one map, while a single one ellapses on another. This is a much more problematic model for player-level pooled things (like total gold etc.). Because of that it's possible that there will only be limitted support for this model. Lytning needs something like this for his 'tactical maps' which basically provide localized battle-level simulations or tactical encounters. Most likely time will be totally frozen at the global level while actions occur on this map (however many turn they take there), so during play on that map you'll have no income at all (and probably no ability to spend gold for consistency).
The AI will understand the maps essentially as independent entities (much like widely separated continents). Until we decide how the multiple maps are to be used (including the mechanics of moving between them and so on) there's not much more it can do. When we do decide on those mechanics then AI work will certainloy be required to drive its decision making in terms of those mechanics
@Koshling:
A couple more questions. First, would it be possible to define a time it takes for something to get between two maps? For instance, it would probably take six months using modern technology to send a person from Earth to Mars, and that is several turns by the Modern Era. Could it be possible to, once you have given the unit an order to go between maps, put that unit in a 'storage' map, which just holds them out of sight of everything else, for a specified number of turns, so to simulate the time issues involved in early space travel? Or, is there some other more elagent solution that I don't see.
Second, will old saves generated and played with pre-viewport C2C be compatable with the viewports? I'd assume so, as from what I understand it is mostly a graphical issue, but I thought I'd ask. Also, is the definition for Viewport size going to be a BUG option or a globaldefine? (BUG is my vote, assuming it's possible)
A couple more questions. First, would it be possible to define a time it takes for something to get between two maps? For instance, it would probably take six months using modern technology to send a person from Earth to Mars, and that is several turns by the Modern Era. Could it be possible to, once you have given the unit an order to go between maps, put that unit in a 'storage' map, which just holds them out of sight of everything else, for a specified number of turns, so to simulate the time issues involved in early space travel? Or, is there some other more elagent solution that I don't see.
Second, will old saves generated and played with pre-viewport C2C be compatable with the viewports? I'd assume so, as from what I understand it is mostly a graphical issue, but I thought I'd ask. Also, is the definition for Viewport size going to be a BUG option or a globaldefine? (BUG is my vote, assuming it's possible)
strategyonly
C2C Supreme Commander
Ok, I've resolved the minimap clicking thing. It's pretty kludgy, but it works
How about asking either God-Emperor or Cybah or Sephi or any of the other C++ people about this??
Hydromancerx
C2C Modder
I thought it would go like this ...
Earth Map -> Solar System Map -> Mars Map
Thus the time it takes to get to Mars is determined by how long it takes to travel from Earth to Mars on the Solar System Map.
Oh, that's another option.
GiuseppeIII
The Third Giuseppe
With multiple maps when leaving Earth where would the end up. Would they all go to the same spot. If so wouldn't that create battles?
Also when going into a planet would everybody land in the same spot?That would also create a bunch of problems
Also when going into a planet would everybody land in the same spot?That would also create a bunch of problems
Time for a status update:
I've almost got viewports where I want them! I am hopeful that tomorrow I will complete the viewport work, and tidy it up enough for anyone sufficiently interested to download the parallel maps latest version from that SVN (I'll post details when I think it's demo-ready) to see how it works. Next week should then be port-to-C2C week, at which point we should have reasonably functional viewport support as the first step to multimaps, with (I hope) immediate memory scalability benefits.
Once that is done we'll need the multimap turn-model work completing, which I'll help Lytning with once I'm done with the viewport stuff if necessary.
@AIAndy/Anyone techy:
It's a horrible hack in some ways. The things that really should be clean just aren't due to what I believe is bad caching behaviour and bad assumptions about where timeslices occur (outside the DLL) in the main game engine. The major nasty manifestation of this in the code is the need to delay various things by messaging timeslice. I'm basically using a simple state machine which processes its current state on each call to CvGame::Update() with various APIs setting start states from UI actions. The main occurance of this is when swapping into and out of the military advisor, which used to be a synchronous Python call from the handler for the button press, but has now become a more complex deferred action sequence, that invokes the Python for the advisor from within the state machine processing.
I've also had to do some inobvious, empirically determined things with some graphics entities that seem to not clean up properly even through the destroy-and-recreate cycle of a map switch (there seems to be some deeper hidden level of caching screwing thing up in the game engine which I've had to fool)
Once I've cleaned the code up I'll make sure it's well commented!
I've almost got viewports where I want them! I am hopeful that tomorrow I will complete the viewport work, and tidy it up enough for anyone sufficiently interested to download the parallel maps latest version from that SVN (I'll post details when I think it's demo-ready) to see how it works. Next week should then be port-to-C2C week, at which point we should have reasonably functional viewport support as the first step to multimaps, with (I hope) immediate memory scalability benefits.
Once that is done we'll need the multimap turn-model work completing, which I'll help Lytning with once I'm done with the viewport stuff if necessary.
@AIAndy/Anyone techy:
It's a horrible hack in some ways. The things that really should be clean just aren't due to what I believe is bad caching behaviour and bad assumptions about where timeslices occur (outside the DLL) in the main game engine. The major nasty manifestation of this in the code is the need to delay various things by messaging timeslice. I'm basically using a simple state machine which processes its current state on each call to CvGame::Update() with various APIs setting start states from UI actions. The main occurance of this is when swapping into and out of the military advisor, which used to be a synchronous Python call from the handler for the button press, but has now become a more complex deferred action sequence, that invokes the Python for the advisor from within the state machine processing.
I've also had to do some inobvious, empirically determined things with some graphics entities that seem to not clean up properly even through the destroy-and-recreate cycle of a map switch (there seems to be some deeper hidden level of caching screwing thing up in the game engine which I've had to fool)
Once I've cleaned the code up I'll make sure it's well commented!
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.
C2C port next week.
Similar threads
