Musketeer/ Knight slot

Here's my first attempt at the 'copy game' script. Your destination game should be able to contain the entire source game. The destination map should be at least as large as the source map, and the destination game should have at least as many maps as the source game. (If you want to be able to cut off part of the source, let me know, and I'll make the adjustments.)

Extract this script, and place it somewhere convenient. Load your source game, open the Lua Console, and use the Load Script button to run copyGamePieces.lua. Select 'yes' for the text box. A message will be written to the console when the script finishes running. Something like:
Code:
Game data written to C:\Test of Time\1637823026pasteGameData.lua
The file will be written to your main Test of Time directory. The prefix number is derived from the current time, to minimise the chance of accidentally overwriting a file.

Next, load your destination game. Save a backup. Open the console, and Load Script the file that was just created. This message should appear in the console:
Code:
To paste the game data saved in this file into your new game, run the command
placeData(topLeftTileDestinationX,topLeftTileDestinationY)
The topLeftTileDestination is the tile where the (0,0) tile of your original game should go.
So, if you want the (0,0) tile of your original game to be on the tile (20,10), type this command into the console:
palceData(20,10)
Note: transporters are replaced by pollution, since Lua can't place transporters.

Choose the tile where the top left corner of the old map should go, and write down the coordinates. For example, (25,15). Then, type
Code:
placeData(25,15)
into the command bar beside the load script button.

Press Enter, and the game should be changed to have all the data copied into the new game. The starting year can't be copied, but a message will appear telling you the number to set the cheat menu to. If your scenario has transporters, you'll have to put them in manually as well.

If the script runs successfully, you'll get a message like this printed to the console:
Code:
The starting year for this scenario is 0
Everything Placed

Let me know if something goes wrong. This seems to work, but I've only tested on a relatively simple saved game, so there might be errors that didn't get caught. Feel free to send me the source and destination files if you have trouble (this is actually preferred, since it will be easier for me to diagnose and fix). Also let me know if you need any additional functionality (e.g. you want to renumber the landmasses).

EDIT: Updated script to require the player to enable custom resources for each map before pasting data. The previous version of the script simply enabled it automatically, but it turns out that command has a bug at this time.
 

Attachments

  • copyGamePieces.lua.zip
    5.4 KB · Views: 43
Last edited:
Note to self, city sizes:
1 - 10,000
2 - 30,000
3 - 60,000
4 - 90,000
5 - 150,000
6 - 210,000
7 - 280,000
8 - 360,000
9 - 450,000
10 - 550,000
11 - 660,000
12 - 780,000
13 - 910,000
14 - 1,050,000
15 - 1,200,000
16 - 1,360,000
17 - 1,530,000
18 - 1,710,000
19 - 1,900,000
20 - 2,100,000
21 - 2,310,000
22 - 2,530,000
23 - 2,760,000
24 - 3,000,000
25 - 3,250,000
26 - 3,510,000
27 - 3,780,000
28 - 4,060,000
29 - 4,350,000
30 - 4,650,000
31 - 4,960,000
32 - 5,280,000
33 - 5,610,000
34 - 5,950,000
35 - 6,300,000
36 - 6,660,000
37 - 7,030,000
38 - 7,410,000
39 - 7,800,000
40 - 8,200,000
41 - 8,610,000
42 - 9,030,000
43 - 9,460,000
44 - 9,900,000
45 - 10,350,000
46 - 10,810,000
47 - 11,280,000
48 - 11,760,000
49 - 12,250,000
50 - 12,750,000
51 - 13,260,000
52 - 13,780,000
53 - 14,310,000
54 - 14,850,000
55 - 15,400,000
56 - 15,960,000
57 - 16,530,000
58 - 17,110,000
59 - 17,700,000
60 - 18,300,000
61 - 18,900,000
62 - 19,530,000
63 - 20,160,000
64 - 20,800,000
65 - 21,450,000
66 - 22,110,000
67 - 22,780,000
68 - 23,460,000
69 - 24,150,000
70 - 24,850,000
71 - 25,560,000
72 - 26,280,000
73 - 27,010,000
74 - 27,750,000
75 - 28,500,000
76 - 29,260,000
77 - 30,030,000
78 - 30,810,000
79 - 31,600,000
80 - 32,400,000
81 - 33,210,000
82 - 34,030,000
83 - 34,860,000
84 - 35,700,000
85 - 36,550,000
86 - 37,410,000
87 - 38,280,000
88 - 39,160,000
89 - 40,050,000
90 - 40,950,000
91 - 41,860,000
92 - 42,780,000
93 - 43,710,000
94 - 44,650,000
95 - 45,600,000
96 - 46,560,000
97 - 47,530,000
98 - 48,510,000
99 - 49,500,000
100 - 50,500,000
Flags
Shut all negotiations event:
@IF
Negotiation
talkermask=0b11111111111111111111111111111111
listenermask=0b11111111111111111111111111111111
@THEN
@ENDIF
 
Last edited:
Question. Is there a (Lua) way to remove all stackable terrain (airfields) from an old scenario, other than one by one, by hand?
 
Question. Is there a (Lua) way to remove all stackable terrain (airfields) from an old scenario, other than one by one, by hand?

You can enable debug scripts in the TOTPP Launcher, then use CTRL+SHIFT+F1 to open a menu to remove fortresses/airbases.
 
Is it possible to spawn a resource on a sea tile using the Lua console?
First, enable custom resources by using CTRL+F8.

You can then place/remove resources by hand in cheat mode using CTRL+1, CTRL+2, CTRL+0.

If you want to do this from the Lua Console, you can use
Code:
civ.getCurrentTile().terrain = civ.getCurrentTile().baseTerrain:getTerrain(1)
(replace 1 with 0,1,2 depending on the resource you want to place)

If you want to do this in event code, replace civ.getCurrentTile() with the variable for which the relevant tile is assigned as a value.

Let me know if you need more explanation.
 
First, enable custom resources by using CTRL+F8.

You can then place/remove resources by hand in cheat mode using CTRL+1, CTRL+2, CTRL+0.

If you want to do this from the Lua Console, you can use
Code:
civ.getCurrentTile().terrain = civ.getCurrentTile().baseTerrain:getTerrain(1)
(replace 1 with 0,1,2 depending on the resource you want to place)

If you want to do this in event code, replace civ.getCurrentTile() with the variable for which the relevant tile is assigned as a value.

Let me know if you need more explanation.
To notice,

if civ.getMap(MapNumber).customResources == false, then altering it for it to be true using Lua ingame erase all existing resources.
One shall then store them before changing this value if he don't wanna lose these locations.

This is important for mods, where the Lua code is applyed to custom games.

Maybe something to add in the Template @Prof. Garfield ?
It was coded uglyly in the mod I provided few time ago.
 
To notice,

if civ.getMap(MapNumber).customResources == false, then altering it for it to be true using Lua ingame erase all existing resources.
One shall then store them before changing this value if he don't wanna lose these locations.

This is important for mods, where the Lua code is applyed to custom games.

Maybe something to add in the Template @Prof. Garfield ?
It was coded uglyly in the mod I provided few time ago.
If you activate it with CTRL+F8 when designing the scenario, the option exists to preserve the locations of existing specials. There's a bug with changing customResources in code.
EDIT: Updated script to require the player to enable custom resources for each map before pasting data. The previous version of the script simply enabled it automatically, but it turns out that command has a bug at this time.
I describe it here.
 
Unlike classic ToT (where you can't), is it even possible to change the railway movement bonus to something else?
 
Unlike classic ToT (where you can't), is it even possible to change the railway movement bonus to something else?
Here's the movement multipliers patch description:

Allows configuration of the cost of movement along railroads, roads and rivers as well as the movement cost for units with the alpine flag.

These multipliers are configured using the COSMIC2 keys 'RailroadMultiplier', 'RoadMultiplier', 'RiverMultiplier' and 'AlpineMultiplier' and can be enabled individually.They take 2 values, the first needs to be set to 1 to enable the multiplier, while the second value determines the movement cost. E.g. setting 'RailroadMultiplier' to 1, 6 means a unit can move 6 tiles along a railroad for 1 movement point. Setting the movement value to 0 means the movement cost of the underlying terrain is used, setting it to -1 means movement is unlimited.

In game, all enabled movement multipliers are combined into an aggregate movement multiplier (exactly their least common multiple). This number multiplied by the movement rate from @UNITS must be less than 256 for each unit. You'll get a friendly warning when this limit is exceeded.

If Lua is enabled, registers the 'totpp.movementMultipliers' table.

To change with Lua during the game, you use
Code:
totpp.movementMultipliers.railroad = newRailroadMultiplier
You'd also have to change unitType.move for all units to reflect the new aggregate movement multiplier. The "Custom Cosmic" module that I'm working on will handle that sort of thing for you.
 
@Prof. Garfield Thank you so much! It worked!
I see the concept where the lua multipliers would be even more useful but i cannot articulate it yet. Like different units spending different point rates on different terrains, i.e an alpine unit moving normally on glaciers, tundras or mountais but taking movement penalties in swamps or jungles, and the opposite for Vietcong. I have to think about it.
 
Here's the movement multipliers patch description:

Allows configuration of the cost of movement along railroads, roads and rivers as well as the movement cost for units with the alpine flag.

These multipliers are configured using the COSMIC2 keys 'RailroadMultiplier', 'RoadMultiplier', 'RiverMultiplier' and 'AlpineMultiplier' and can be enabled individually.They take 2 values, the first needs to be set to 1 to enable the multiplier, while the second value determines the movement cost. E.g. setting 'RailroadMultiplier' to 1, 6 means a unit can move 6 tiles along a railroad for 1 movement point. Setting the movement value to 0 means the movement cost of the underlying terrain is used, setting it to -1 means movement is unlimited.

In game, all enabled movement multipliers are combined into an aggregate movement multiplier (exactly their least common multiple). This number multiplied by the movement rate from @UNITS must be less than 256 for each unit. You'll get a friendly warning when this limit is exceeded.

If Lua is enabled, registers the 'totpp.movementMultipliers' table.

To change with Lua during the game, you use
Code:
totpp.movementMultipliers.railroad = newRailroadMultiplier
You'd also have to change unitType.move for all units to reflect the new aggregate movement multiplier. The "Custom Cosmic" module that I'm working on will handle that sort of thing for you.
Wait...so if I understand this correctly, we can now enable per unit movement multipliers using Lua? E.g. an artillery unit can move using different multiplier than infantry on the same road?
 
@Prof. Garfield Thank you so much! It worked!
I see the concept where the lua multipliers would be even more useful but i cannot articulate it yet. Like different units spending different point rates on different terrains, i.e an alpine unit moving normally on glaciers, tundras or mountais but taking movement penalties in swamps or jungles, and the opposite for Vietcong. I have to think about it.
Wait...so if I understand this correctly, we can now enable per unit movement multipliers using Lua? E.g. an artillery unit can move using different multiplier than infantry on the same road?

Yes, when I release the "Custom Cosmic" module, different units will be able to have different movement multipliers, move costs over terrain, and some other stuff. Done by filling out tables (and calling a function to 'register' the information). I put out some documentation in this post, and the unit stuff has been tested. (At least for human players. There is a small chance I'll discover that the AI breaks something.) Some of the customisation options for cities are actually going to be for tribes instead, due to the fact that some cosmic settings need to be changed before onCalculateCityYield is called.
 
Yes, when I release the "Custom Cosmic" module, different units will be able to have different movement multipliers, move costs over terrain, and some other stuff. Done by filling out tables (and calling a function to 'register' the information). I put out some documentation in this post, and the unit stuff has been tested. (At least for human players. There is a small chance I'll discover that the AI breaks something.) Some of the customisation options for cities are actually going to be for tribes instead, due to the fact that some cosmic settings need to be changed before onCalculateCityYield is called.
WOW! This is major! I can imagine having different types of "alpine" units, depending on a kind of terrain they move through. E.g. camel-mounted troops not being able to move through mountains with same alpine multipliers as in deserts.
 
Top Bottom