Sounds like my German class...
Dungeon Adventure MOD MOD
- Thread starter Lutefisk Mafia
- Start date
Sounds like my German class...
What is it you have against pickle? It's come up before in this thread, but no one could say what you don't like about it.
Lutefisk Mafia
Inscrutable Enforcer
@Kael:
Dynamically switchable maps. I already have this working, but not to the degree that I would like.
I already have a method that works just fine that lets a player move from map to map. It cycles pretty quick, too, although I have limited myself to 20x20 maps so far.
For example, on the "main" outdoor map, a player moves onto a tile that has ruins. In the actions bar, a new button appears that says "Enter Ruins." Upon clicking that button, the map switches to the indoor dungeon map. Moreover, within the dungeon, there is a spot where the player can go down a level to the "caves." Elsewhere on the main map, there are tiles that can enter other sub-maps, such as a forest or village. Essentially, this allows multiple maps to be linked together however the designer chooses.
Here is what I have working so far:
1. A main map with two different locations where sub-maps can be entered. The player can return from these sub-maps back to the main map, too.
2. The stuff that can be dynamically switched easily includes: terrain, elevation, features, bonuses, and RIVERS (this last was a pain to figure out!).
3. Right now, cities aren't easy to do, and can't be done at all without hacky methods. Right now, I have one "home village" city on the main map. When switching to a sub-map, the city gets moved and "stored" in an inaccessable corner. Same for unique units that aren't in play on the current map. This is a bad method because the need for more "storage slots" increases as you add more sub-maps. Before long, the storage slots overpower the useable space on the "map in play." Plus the AI gets frustrated when most of its units are (even temporarily) confined to a 1 tile prison!
4. The other downside is that my current method requires that the maps be input BY HAND into a series of matrices within the Python code. This is tedious, and does not allow for maps that can be changed and have those changes be remembered by the game when the same sub-map is re-entered later. For example, the player goes out into the wilderness and clears a bunch of forest tiles. He then move to a new map, and then comes back to the original one. The trees would be back!
So, the maps are dynamically switchable between different maps, which is cool and a lot of fun, but the individual sub-maps themselves are static.
Now - if I could reliably STORE the matrices I am using, full dynamic map switching would be possible -- and this is sort of the Holy Grail we have been looking for. This would make truly explorable lairs and dungeons possible in FfH2. This would make progessive scenarios possible.
This is the other thing I have been working on lately, as a break from the DA mod itself.
Right now, when a player moves to a new map, the code simply reads out the different matrices from within that particular "move to map X" function in the Python and applies the data to the map.
If I could get a storage method to work, the process would do a "plots by index" scan of the current map for each matrix type, store the data in a list or dictionary, and save it to a pickle or script or whatever. It would then read the information from the new map from storage and apply it to the screen.
"Storing" cities and units isn't all that tough -- it is just a matter of breaking down the job into elements and choosing a proper storage key. In the case of tile information, it is just the plot index, which is implied in the entry order of the list itself. For cities and units, the xy map coordinates suffice.
Just by way of example, to load a new map right now, my method:
1. reads all terrain types from a 400 element matrix (well a LIST actually, but I call it a matrix) for a 20x20 map and does a pPlot.setTerrainType() for each entry -- which maps out to a plots by index order.
2. Then it does the same for elevation.
3. Same for features.
4. Same for rivers.
5. Same for bonuses.
6. Then some less adept stuff to shove cities and units that don't "belong" on the current map into little 1 tile prison cells that are hidden behind mountains or other inaccessable terrain.
Okay I have babbled for a bit -- does this make any sense? I can SEE how it is possible to get what we have all wanted -- SUB-MAPS! -- but this pickling/scriptdata/sdToolKit business is killing me.
Here is a snippet of the "spell" code for moving into one example of a zone (sub-map):
Note that step six isn't in this code block. I'm still ironing out bugs for that bit -- and frankly, the ways I am using maps right now don't really require much in the way of city or unit storage. But this would cap off the method and make it very useful for other modders.
Also note that the matrix for rivers actually is a series of sub lists concentated in reverse order. I will eventually make all of the matrices like this, but for rivers is was a must-do. I found it impossible to visualize the rivers upside down. The concentation method makes the visual code block of numbers in the spell code an exact representation as it would appear on screen. For the uninitiated, the Civ4 plots start at 0,0 in the lower left corner. Plots by index does the same essentially, so if you are using a big list of numbers to be applied to plots by index number, you have to keep in mind that they will be applied in a sort of left to right, bottom to top raster scan. Thus, to make a 20x20 block of numbers in your code look like the screen, you need to uses a series of concentated lists of rows, reverse-ordered.
Dynamically switchable maps. I already have this working, but not to the degree that I would like.
I already have a method that works just fine that lets a player move from map to map. It cycles pretty quick, too, although I have limited myself to 20x20 maps so far.
For example, on the "main" outdoor map, a player moves onto a tile that has ruins. In the actions bar, a new button appears that says "Enter Ruins." Upon clicking that button, the map switches to the indoor dungeon map. Moreover, within the dungeon, there is a spot where the player can go down a level to the "caves." Elsewhere on the main map, there are tiles that can enter other sub-maps, such as a forest or village. Essentially, this allows multiple maps to be linked together however the designer chooses.
Here is what I have working so far:
1. A main map with two different locations where sub-maps can be entered. The player can return from these sub-maps back to the main map, too.
2. The stuff that can be dynamically switched easily includes: terrain, elevation, features, bonuses, and RIVERS (this last was a pain to figure out!).
3. Right now, cities aren't easy to do, and can't be done at all without hacky methods. Right now, I have one "home village" city on the main map. When switching to a sub-map, the city gets moved and "stored" in an inaccessable corner. Same for unique units that aren't in play on the current map. This is a bad method because the need for more "storage slots" increases as you add more sub-maps. Before long, the storage slots overpower the useable space on the "map in play." Plus the AI gets frustrated when most of its units are (even temporarily) confined to a 1 tile prison!
4. The other downside is that my current method requires that the maps be input BY HAND into a series of matrices within the Python code. This is tedious, and does not allow for maps that can be changed and have those changes be remembered by the game when the same sub-map is re-entered later. For example, the player goes out into the wilderness and clears a bunch of forest tiles. He then move to a new map, and then comes back to the original one. The trees would be back!
So, the maps are dynamically switchable between different maps, which is cool and a lot of fun, but the individual sub-maps themselves are static.
Now - if I could reliably STORE the matrices I am using, full dynamic map switching would be possible -- and this is sort of the Holy Grail we have been looking for. This would make truly explorable lairs and dungeons possible in FfH2. This would make progessive scenarios possible.
This is the other thing I have been working on lately, as a break from the DA mod itself.
Right now, when a player moves to a new map, the code simply reads out the different matrices from within that particular "move to map X" function in the Python and applies the data to the map.
If I could get a storage method to work, the process would do a "plots by index" scan of the current map for each matrix type, store the data in a list or dictionary, and save it to a pickle or script or whatever. It would then read the information from the new map from storage and apply it to the screen.
"Storing" cities and units isn't all that tough -- it is just a matter of breaking down the job into elements and choosing a proper storage key. In the case of tile information, it is just the plot index, which is implied in the entry order of the list itself. For cities and units, the xy map coordinates suffice.
Just by way of example, to load a new map right now, my method:
1. reads all terrain types from a 400 element matrix (well a LIST actually, but I call it a matrix) for a 20x20 map and does a pPlot.setTerrainType() for each entry -- which maps out to a plots by index order.
2. Then it does the same for elevation.
3. Same for features.
4. Same for rivers.
5. Same for bonuses.
6. Then some less adept stuff to shove cities and units that don't "belong" on the current map into little 1 tile prison cells that are hidden behind mountains or other inaccessable terrain.
Okay I have babbled for a bit -- does this make any sense? I can SEE how it is possible to get what we have all wanted -- SUB-MAPS! -- but this pickling/scriptdata/sdToolKit business is killing me.
Here is a snippet of the "spell" code for moving into one example of a zone (sub-map):
Code:
def spellLoadZone2():
caster=CyInterface().getHeadSelectedUnit()
iOcean = gc.getInfoTypeForString('TERRAIN_OCEAN')
iCoast = gc.getInfoTypeForString('TERRAIN_COAST')
iGrass = gc.getInfoTypeForString('TERRAIN_GRASS')
iPlains = gc.getInfoTypeForString('TERRAIN_PLAINS')
iDesert = gc.getInfoTypeForString('TERRAIN_DESERT')
iTundra = gc.getInfoTypeForString('TERRAIN_TUNDRA')
iSnow = gc.getInfoTypeForString('TERRAIN_SNOW')
iBorder = gc.getInfoTypeForString('TERRAIN_BORDER')
terrainList = [
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,70,70,70,70,70,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,70,20,20,20,70,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,70,20,20,20,70,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,70,20,20,20,70,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,70,70,70,70,70,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
]
iWallTall = gc.getInfoTypeForString('FEATURE_BULKHEAD')
iWallShort = gc.getInfoTypeForString('FEATURE_BULKHEAD2')
iDoorClosed = gc.getInfoTypeForString('FEATURE_HATCH_CLOSED')
iDoorOpen = gc.getInfoTypeForString('FEATURE_HATCH_OPEN')
featureList = [
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,10,20,10,20,10,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,20,00,00,00,20,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,10,00,00,00,30,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,20,00,00,00,20,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,10,20,10,20,10,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
]
elevationList = [
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
]
rr20 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr19 = [00,50,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr18 = [00,50,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr17 = [00,50,02,02,02,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr16 = [00,00,00,00,50,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr15 = [00,00,00,00,50,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr14 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr13 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr12 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr11 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr10 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr09 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr08 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr07 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr06 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr05 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr04 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr03 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr02 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
rr01 = [00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00]
riverList = rr01 + rr02 + rr03 + rr04 + rr05 + rr06 + rr07 + rr08 + rr09 + rr10 + rr11 + rr12 + rr13 + rr14 + rr15 + rr16 + rr17 + rr18 + rr19 + rr20
for i in range (CyMap().numPlots()):
pPlot = CyMap().plotByIndex(i)
pTerrain = terrainList[i]
if pTerrain == 00:
pPlot.setTerrainType(iOcean,True,True)
if pTerrain == 10:
pPlot.setTerrainType(iCoast,True,True)
if pTerrain == 20:
pPlot.setTerrainType(iGrass,True,True)
if pTerrain == 30:
pPlot.setTerrainType(iPlains,True,True)
if pTerrain == 40:
pPlot.setTerrainType(iDesert,True,True)
if pTerrain == 50:
pPlot.setTerrainType(iTundra,True,True)
if pTerrain == 60:
pPlot.setTerrainType(iSnow,True,True)
if pTerrain == 70:
pPlot.setTerrainType(iBorder,True,True)
pFeature = featureList[i]
if pFeature == 00:
pPlot.setFeatureType(-1, -1)
if pFeature == 10:
pPlot.setFeatureType(iWallTall, -1)
if pFeature == 20:
pPlot.setFeatureType(iWallShort, -1)
if pFeature == 30:
pPlot.setFeatureType(iDoorClosed, -1)
if pFeature == 40:
pPlot.setFeatureType(iDoorOpen, -1)
pElevation = elevationList[i]
if pElevation == 00:
pPlot.setPlotType(PlotTypes.PLOT_LAND, True, True)
if pElevation == 10:
pPlot.setPlotType(PlotTypes.PLOT_HILLS, True, True)
if pElevation == 20:
pPlot.setPlotType(PlotTypes.PLOT_PEAK, True, True)
if pElevation == 30:
pPlot.setPlotType(PlotTypes.PLOT_OCEAN, True, True)
pRiver = riverList[i]
if pRiver == 00:
pPlot.setNOfRiver(False, CardinalDirectionTypes.CARDINALDIRECTION_EAST)
pPlot.setNOfRiver(False, CardinalDirectionTypes.CARDINALDIRECTION_WEST)
pPlot.setWOfRiver(False, CardinalDirectionTypes.CARDINALDIRECTION_NORTH)
pPlot.setWOfRiver(False, CardinalDirectionTypes.CARDINALDIRECTION_SOUTH)
if pRiver >= 50:
pPlot.setWOfRiver(True, CardinalDirectionTypes.CARDINALDIRECTION_SOUTH)
pRiver = (pRiver - 50)
if pRiver >= 30:
pPlot.setWOfRiver(True, CardinalDirectionTypes.CARDINALDIRECTION_NORTH)
pRiver = (pRiver - 30)
if pRiver == 05:
pPlot.setNOfRiver(True, CardinalDirectionTypes.CARDINALDIRECTION_WEST)
if pRiver == 02:
pPlot.setNOfRiver(True, CardinalDirectionTypes.CARDINALDIRECTION_EAST)
# gc.getMap().updateMinimapColor()
# CyGInterfaceScreen( "MainInterface", CvScreenEnums.MAIN_INTERFACE ).updateMinimapVisibility()Note that step six isn't in this code block. I'm still ironing out bugs for that bit -- and frankly, the ways I am using maps right now don't really require much in the way of city or unit storage. But this would cap off the method and make it very useful for other modders.
Also note that the matrix for rivers actually is a series of sub lists concentated in reverse order. I will eventually make all of the matrices like this, but for rivers is was a must-do. I found it impossible to visualize the rivers upside down. The concentation method makes the visual code block of numbers in the spell code an exact representation as it would appear on screen. For the uninitiated, the Civ4 plots start at 0,0 in the lower left corner. Plots by index does the same essentially, so if you are using a big list of numbers to be applied to plots by index number, you have to keep in mind that they will be applied in a sort of left to right, bottom to top raster scan. Thus, to make a 20x20 block of numbers in your code look like the screen, you need to uses a series of concentated lists of rows, reverse-ordered.
Psychic_Llamas
Wizard in the Making
OMGOMGOMGOMGOMGOMGOMGOMGOMGOMGOMGOMG
Lutefisk youre a genius! *yells* HEY GUYS LOOK WHAT LUTEFISK HAS DONE!
Lutefisk youre a genius! *yells* HEY GUYS LOOK WHAT LUTEFISK HAS DONE!
![[to_xp]Gekko](https://civfanatics-data.community.forum/avatars/m/74/74677.jpg?1475248346){kind=avatar}
[to_xp]Gekko
QCT junkie
age of wonders style like the shadow realm?
Kael
Deity
Its incrediably slow.
Kael
Deity
We have a form of dynamically switchable maps, the scenario screen.
Basically its just an ingame way to load up a worldbuilder save (your static dungeons). Plus we can switch game options, players, pretty much anything.
The only thing we dont do is save the state of the old game to return to it (because thats not required in "Ice"). But I can definitly see how that would be helpful for you.
If you wanted to return to the state of the game before the map change you could just use the worldbuilder save process to write the game state off to a text file. Then reload when you cant to go back (the ingame reload is the real magic, but I already have that all tested and working).
If you want to bypass pickle entirely I can give you the ingame scenario load code.
Lutefisk Mafia
Inscrutable Enforcer
Yes, please! The more examples I have to look at of stuff that actually works, the better off I'll be.
But you already have a version of in-game WB read and write access working? You magnificent bast*rd, you! That would be exactly what we all need! (And much better than my old-school DOS shell matrix nonsense.
)If you would be kind enough to post the code here or send it to me, I would truly appreciate it.
Lutefisk Mafia
Inscrutable Enforcer
But come to think of it -- I think there is still merit in fleshing out my matrix idea, too. Requiring a WB scenario load every single time you switch maps would end up being slower if you needed to switch back and forth between maps frequently over a short time span.
A hybrid approach might be best. In-game WB loads for a major map change, but keep the matrix functions for frequently used sub-map stuff.
In any case, I look forward to looking at the WB code, Kael. And thanks!
A hybrid approach might be best. In-game WB loads for a major map change, but keep the matrix functions for frequently used sub-map stuff.
In any case, I look forward to looking at the WB code, Kael. And thanks!
One minor point I realized while reading your code: A leading zero is how python (currently) marks octal literals.
In your code it makes no difference, but it could surprise you later when you try to write 09, or if you decide to make your mapping three digits.
Lutefisk Mafia
Inscrutable Enforcer
That IS good to know, and thank you. I put in the leading zeros to make the in-code matrices perfect squares. It makes it easier to design levels when the entries are justified in this way, and look like a closer approximation of the game screen.
As long as I treat these as straight integers I should be okay, though, right?
edit: I suppose I could switch to an alpha string, like single letters, but I had problems getting that to work earlier.
xienwolf
Deity
Seriously Lute... you need to ditch Python. A lot of what you have done is not only quicker in C++, but also easier to code. You've more tham shown that you know how to code quite well, so I am sure that once you dip into the DLL you'll be very happy.
Kael
Deity
Yes, please! The more examples I have to look at of stuff that actually works, the better off I'll be.
But you already have a version of in-game WB read and write access working? You magnificent bast*rd, you! That would be exactly what we all need! (And much better than my old-school DOS shell matrix nonsense.
If you would be kind enough to post the code here or send it to me, I would truly appreciate it.
Not a problem. I wont be back to the mod for 9 days but I gladly send you the code once I get there.
Ive been down this road before and defer due to the following techncial challenges. Im not saying that this isnt a valuable course, I think its really exciting work. But I wanted to share ideas from the begining rather than have you do a bunch of work up front and then hit an insurmountable barrier.
The issues:
1. World switching- the graphics engine is a dog. Switching all plot untis, terrain, improvements and features on a regular basis is painful on any reasonably sized map.
Mitigation: The best option is a game design one that limits the players switching (ie: the player goes to a side map for a specific purpose, then exits when done). Going back and forth at the flip of a button is the dream but remains undeliverable with the current graphic engine.
2. The AI- Trying to get the AI to path through map layers is difficult but not impossible, a huge task but doable. Trying to get the AI to correctly allocate units across two maps, measure threats and enemies when making decisions. Decide which targets on which maps are the best goals for acquisition. All nearly impossible without a complete rewrite of the AI. Even thigns as simple as getting a worker on one map to travel to another to improve and build a road to a resource is goign to take a compelte rewrite of that section of code (and be much more complex).
Mitigation: Again a side map that is complete unto itself resovles thsi issue. There is no AI issues ebcause the ai only needs to make correct decisions for its map, and doesnt have to be aware of other maps.
3. Event tracking- Thigns that happen in one map will have to effect some events in the other. For exampel you wouldnt want Buboes to spawn in a side map if he had already spawned in the main map just because the AC was to high.
Mitigation: This will have to be coded to pass specific parameters back and forth between the two maps. Likewise which units to start the side map will have to be coded. And experience units gain ont he side map will have to be passed back.
4. Multiplayer- There is no decent way to have multiple maps for multiplayer.
Well, they are integers. The only difference is how you enter them.
01 == 1
02 == 2
...
07 == 7
However 08 isn't a number, for pretty much the same reasons 2q3 isn't a number. Nor is 09.
010 == 8
011 == 9
04234 == 2204
I'd drop the zero and use spaces to fill out the matrix. But as long as you only have two digits the only problem I can see is that you cant write 8 or 9.
Lutefisk Mafia
Inscrutable Enforcer
@Kael:
It seems we are thinking along similar lines:
1. World Switching -- The graphics engine IS a dog. But apparantly a dog that doesn't mind learning new tricks.
The switch on a 20x20 map is instant using the matrix method. I will try it with a much bigger map and see what type of lag results.
Moreover, I do not envision a parallel world that players can shift in and out of whenever they want. My method (and also mitigation) is exactly as you suggest. Players need to get to a certain feature like a staircase, mountain pass, or town tile before they can move to a new map. My scenarios also focus on a relatively few units being in play at any given time.
2. AI -- Only one map active at a time, so the AI only has to think about the current map. No way could I train the AI to deal with multiple layers!
3. Event Tracking -- well this would be nice to do with scriptdata or something. Otherwise I have to use those stupid "parking lot" tiles for unique units and cities, and use goofy workarounds like piling special promotions onto the player's main unit to keep track of important events.
4. Multiplayer -- Alas, there are so many things that we cannot do with multiplayer. Not even on the radar screen for DA or any other of my mods.
@xienwolf:
I had some bad initial experiences with C++ from which I am still traumatized. Maybe it is time for me to get over it, but I shudder at the thought of having to learn another language from scratch.
Everyone says that C++ stuff is faster than the Python. How much faster? And in this case, hardcoding maps the maps in the C++ would still result in static maps, wouldn't it? I guess I am leery of bollixing up my DLL files, but that's what backups are for, right?
It seems we are thinking along similar lines:
1. World Switching -- The graphics engine IS a dog. But apparantly a dog that doesn't mind learning new tricks.
The switch on a 20x20 map is instant using the matrix method. I will try it with a much bigger map and see what type of lag results.Moreover, I do not envision a parallel world that players can shift in and out of whenever they want. My method (and also mitigation) is exactly as you suggest. Players need to get to a certain feature like a staircase, mountain pass, or town tile before they can move to a new map. My scenarios also focus on a relatively few units being in play at any given time.
2. AI -- Only one map active at a time, so the AI only has to think about the current map. No way could I train the AI to deal with multiple layers!
3. Event Tracking -- well this would be nice to do with scriptdata or something. Otherwise I have to use those stupid "parking lot" tiles for unique units and cities, and use goofy workarounds like piling special promotions onto the player's main unit to keep track of important events.
4. Multiplayer -- Alas, there are so many things that we cannot do with multiplayer. Not even on the radar screen for DA or any other of my mods.
@xienwolf:
I had some bad initial experiences with C++ from which I am still traumatized.
Maybe it is time for me to get over it, but I shudder at the thought of having to learn another language from scratch.Everyone says that C++ stuff is faster than the Python. How much faster? And in this case, hardcoding maps the maps in the C++ would still result in static maps, wouldn't it? I guess I am leery of bollixing up my DLL files, but that's what backups are for, right?
xienwolf
Deity
Well, in C++ you could have the map set up to randomize the new elements. You would shift the array of plots which are currently used into an array of those arrays, and thus be able to save all of the layers of your map at once and have them easily shifted amongst.
For speed enhancement, you mostly notice it when you do a large loop. Otherwise I don't personally recognize much, but then again I haven't personally done much python. I can say that over half of what I have added to Fall Further at this point has been attempted in Python and abandoned due to excessive time cost. Thus far nobody has complained about time delays on any of my work except the interface (which was python, go figure). That doesn't mean it isn't causing delays though, just means that nobody has mentioned them
And learning C++ won't take you long. The patterns become pretty obvious pretty quickly, and the actual functioning bits and pieces aren't too different from Python till you get into the more complicated tricks of the code. And if you find some well commented DLL you can see plenty of examples and sort out the "fluff" which is required by the program from the "meat" which actually performs your tasks.
As for mistakes: That also ties into the whole "What is DOING something, what is NEEDED by the program?" question. The parts which the program requires are the lengthy compile process. So if you plan ahead a little bit and write all of that stuff in one big swoop, then you can do the pieces which actually DO something (and risk breaking things) with quick compiles. I am reasonably certain my current average is breaking the game at least 8 times per significant code change. But as long as you test the new stuff before you add too much, it doesn't have much impact overall (and if you set up a Debug DLL it's probably easy as heck to find... probably).
Other thing that I have found to be really nice is the commenting process. Instead of having to toss a # in front of EVERY DANG LINE, I can just place a /** and **/ around the code I want to de-activate. I've worked out my standard comment such that I can add a single / and delete a different one to completely remove a chunk of my code and restore the original. Makes swapping back to default even quicker
For speed enhancement, you mostly notice it when you do a large loop. Otherwise I don't personally recognize much, but then again I haven't personally done much python. I can say that over half of what I have added to Fall Further at this point has been attempted in Python and abandoned due to excessive time cost. Thus far nobody has complained about time delays on any of my work except the interface (which was python, go figure). That doesn't mean it isn't causing delays though, just means that nobody has mentioned them
And learning C++ won't take you long. The patterns become pretty obvious pretty quickly, and the actual functioning bits and pieces aren't too different from Python till you get into the more complicated tricks of the code. And if you find some well commented DLL you can see plenty of examples and sort out the "fluff" which is required by the program from the "meat" which actually performs your tasks.
As for mistakes: That also ties into the whole "What is DOING something, what is NEEDED by the program?" question. The parts which the program requires are the lengthy compile process. So if you plan ahead a little bit and write all of that stuff in one big swoop, then you can do the pieces which actually DO something (and risk breaking things) with quick compiles. I am reasonably certain my current average is breaking the game at least 8 times per significant code change. But as long as you test the new stuff before you add too much, it doesn't have much impact overall
(and if you set up a Debug DLL it's probably easy as heck to find... probably).Other thing that I have found to be really nice is the commenting process. Instead of having to toss a # in front of EVERY DANG LINE, I can just place a /** and **/ around the code I want to de-activate. I've worked out my standard comment such that I can add a single / and delete a different one to completely remove a chunk of my code and restore the original. Makes swapping back to default even quicker
Kael
Deity
@Kael:
It seems we are thinking along similar lines:
1. World Switching -- The graphics engine IS a dog. But apparantly a dog that doesn't mind learning new tricks.
Moreover, I do not envision a parallel world that players can shift in and out of whenever they want. My method (and also mitigation) is exactly as you suggest. Players need to get to a certain feature like a staircase, mountain pass, or town tile before they can move to a new map. My scenarios also focus on a relatively few units being in play at any given time.
2. AI -- Only one map active at a time, so the AI only has to think about the current map. No way could I train the AI to deal with multiple layers!
3. Event Tracking -- well this would be nice to do with scriptdata or something. Otherwise I have to use those stupid "parking lot" tiles for unique units and cities, and use goofy workarounds like piling special promotions onto the player's main unit to keep track of important events.
4. Multiplayer -- Alas, there are so many things that we cannot do with multiplayer. Not even on the radar screen for DA or any other of my mods.
@xienwolf:
I had some bad initial experiences with C++ from which I am still traumatized.
Everyone says that C++ stuff is faster than the Python. How much faster? And in this case, hardcoding maps the maps in the C++ would still result in static maps, wouldn't it? I guess I am leery of bollixing up my DLL files, but that's what backups are for, right?
This sounds perfect and I agree with you on all counts. Thats why I think "dual maps" is a possibility for your specific purpose but wouldnt work well for the main mod.
If you want an example of storing information in a plot using C++ check out the TempTerrain function. Its what allows plots to switch their terrain type for a little while, then switch back to the original type. I store the old terrain type on the plot just like your talking about using pickle for. You may want to consider a method like that instead as it isn't any more complex and gives you a lot more flexibility later on (if you want to start building functions using the "hidden" values).
xienwolf
Deity
Actually it would be fun to use a small map swap-out for Marnok's Dungeon Exploration. Just get a tiny little map with some random obstacles and random rewards scattered in it. Unit gets a nifty little promotion to grant the mobility it will need for the exploration which is removed upon completion of the dungeon.
Of course, then you aren't swapping 2 little 20 square maps, but a potentially gargantuan map with a 20 square one.
Of course, then you aren't swapping 2 little 20 square maps, but a potentially gargantuan map with a 20 square one.
Similar threads
- Locked
