Is it Possible to have Teleportation Tiles?

probably you could use the Rebase Mechanic from the Aircraft to get that working, because it's Basically the same thing you're want to have happen
It's too city based.

The question I have when thinking about this... is one plot a replica of another so that if you are at plot A you are also at plot B? This is the complicated part of it if you aren't doing the portal down the edge of a plot for when you move through that edge rather than at the plot itself.
It also exhausts the movement points available for the plane, something extremely undesirable, especially for air units and ships, as they tend to have lots of movement points, sometimes 15 and beyond.

Another issue you may have OP is taking into account terrain damage or what may happen to units that exhausts their movement points just after teleporting, do they teleport back? Are these two tiles when one in the same? How does auto-exploring and AI pathings take into account that?
Just food for thought, I would be glad to help you out a bit but I honestly have no idea how to solve that.
 
Rebasing is easily designed and reprogrammed - the actual teleportation side of anything is as easy as it gets (though one must ask things like are you attacking when you teleport and such) but the AI side is monstrously difficult.
 
As Toffer said, the AI is not far from understanding it if you use the edge transition approach instead of the teleportation approach. The A* heuristic breaks a bit at the transitions but at worst that means it does not find the fastest route or takes longer to find it.
Implementing that approach into the innocent little function plotDirection (and the similar ones at the same place) would probably go a long way towards working correctly. That means instead of returning the plot in that direction directly you first look into that plot and if it is a transition plot (new member) instead return the plot it refers to. The path finding at least uses that function to find the adjacent plots.
Then you just need some way to mark the plots as transition plots.

On the other hand anything like having to end turns on teleportation plots or special missions are very hard to implement in the AI.
 
As Toffer said, the AI is not far from understanding it if you use the edge transition approach instead of the teleportation approach. The A* heuristic breaks a bit at the transitions but at worst that means it does not find the fastest route or takes longer to find it.
Implementing that approach into the innocent little function plotDirection (and the similar ones at the same place) would probably go a long way towards working correctly. That means instead of returning the plot in that direction directly you first look into that plot and if it is a transition plot (new member) instead return the plot it refers to. The path finding at least uses that function to find the adjacent plots.
Then you just need some way to mark the plots as transition plots.

On the other hand anything like having to end turns on teleportation plots or special missions are very hard to implement in the AI.
I see, you basically redirect the call as if it would be going to the new plot, like forwarding a phone number. Makes sense. I wonder how deep that goes, and maybe what other areas that may need to be applied or if this is the only one central place that such a redirection would be necessary. hmm... with some proper world builder interactions and deeper application into multimaps, this could have a very universally valuable application - could be used to create portal effects of a sort as well. I will probably have to strongly consider diving into this at some point.

I wonder if the approach to a tile from a particular direction could be determined to be the triggering cause for redirection/forwarding, rather than the actual tile itself. That would seem more generically useful.
 
I wonder if the approach to a tile from a particular direction could be determined to be the triggering cause for redirection/forwarding, rather than the actual tile itself. That would seem more generically useful.
Yes, that should work too. In general you are changing the adjacency graph here so you can define that if you go a specific direction from a specific plot you end up on a certain other plot. So you could also store the information on the plot you come from.
 
Yes, that should work too. In general you are changing the adjacency graph here so you can define that if you go a specific direction from a specific plot you end up on a certain other plot. So you could also store the information on the plot you come from.
Yeah, makes sense. Very interesting.
 
this conversation made me wonder how the game handles regular wrapping, as at a certain point the tile count goes from say "-1, 50" to "1, 50" unless I'm also lost about how that works :D I'm more familiar with Hexagonal math
 
this conversation made me wonder how the game handles regular wrapping, as at a certain point the tile count goes from say "-1, 50" to "1, 50" unless I'm also lost about how that works :D I'm more familiar with Hexagonal math
I've often wondered that myself but haven't done more than a cursory look at the code that handles it so still find it a little mysterious.
 
this conversation made me wonder how the game handles regular wrapping, as at a certain point the tile count goes from say "-1, 50" to "1, 50" unless I'm also lost about how that works :D I'm more familiar with Hexagonal math
This is mainly done by the plot function in CvMap.h which handles requests for negative coordinates and too large coordinates by wrapping them if wrapping is enabled in that direction.
 
This is mainly done by the plot function in CvMap.h which handles requests for negative coordinates and too large coordinates by wrapping them if wrapping is enabled in that direction.
I started getting a little curious about this from a graphics perspective... Can I assume that the graphic looping is handled in the exe beyond this element of functionality that's located in the dll?
 
Top Bottom