[TOTPP] Lua Scenario Template

[Prof. Garfield]

Just 1 map. But perhaps there are other spots in my rules.txt that reference multiple maps. I'll give it a check and report back. Many thanks!

That shouldn't matter. My template has rules for 2 maps, but I was able to load a saved game with 1 map and only one NumberOfTerrainTypes.

Just run civ.getAtlasDimensions() in the console, and confirm that there is one map.

 

[ThichN]

I found that the other mod I am working on had a base of the Fantasy mod, which threw things off. Once I replaced entries in rules.txt with the Original file, it worked great. I had another Q, but long form code. Will PM you.

 

[Prof. Garfield]

The Lua Scenario Template has been updated.

There is a fix to a minor oversight in navy.lua, so that sea units leaving a land tile only leave with allowed units on board. Previously, the check was for sea transports leaving cities, but Battle of Italy proved this was an oversight.

The important update is that I've re-written diplomacy.lua. If you have used diplomacySettings.lua, you may wish to ask for advice before upgrading an existing scenario.

The old system for "freezing" treaties is removed, since it was confusing.

Under the new system, there are a couple of functions:

diplomacy.enableEndogenousTreatyChanges(tribe1,tribe2)
diplomacy.disableEndogenousTreatyChanges(tribe1,tribe2)

"Endogenous" means that the behaviour is being driven internally, rather than being imposed externally. I know it's technical word, but I couldn't think of a better one. If endogenous treaty changes are enabled, then the process of changing treaties can come from within gameplay. If they are not enabled, the changes must come externally from the scenario designer.

By default, endogenous treaty changes are allowed, unless an event calls disableEndogenousTreatyChanges for a pair of tribes. At that point, any treaty changes they make will be immediately reverted, until enableEndogenousTreatyChanges is called for them.

If you want endogenous treaty changes to be disabled by default, you call this function in diplomacySettings.lua for the relevant tribes

diplomacy.disableEndogenousTreatyChangeByDefault(tribe1,tribe2)

Basically, if you don't want tribes to be able to change their treaties through in game negotiation, you use diplomacy.disableEndogenousTreatyChangesByDefault for every pair of tribes in diplomacySettings.lua. A loop to do this is provided within comments.

The Gift Menu (Key 2) has been rewritten.
This isn't much of a change for scenario designers, though you'll have to adapt the code that is used to forbid giving away certain tiles or techs to the new system.

There is a system to prevent technologies from being traded, captured (with a city), gifted, or stolen (by diplomat), even if they can be researched by a tribe.

This code takes over tech group 7 as a tech group that no tribe can research or own. If there is a situation where the game might try to give a tech to another tribe (negotiations are started, a diplomat is active, or a city is taken), relevant techs are assigned to group 7 for the duration of that situation.

For each of trade/gift, captured, and stolen, you can register a true/false function to determine if the tech can be transferred.

The diplomacy module provides a way to convert a simple table to a set of these functions, and that is done by default in diplomacySettings.lua. This basic system allows you to set 4 possibilities:

--[[
stopTechTransferTable[techObject.id] = {
    * noPrereqs = bool
        - If true, then the tech can't be given or traded to another tribe, or conquered, or stolen, if the receiving tribe doesn't have the tech's prerequisites.
        - If false (or nil), a tribe can receive the tech even if it  doesn't have the tech's prerequisites.
    * noTrade = bool
        - If true, then the tech can't be given or traded to another tribe.
        - If false (or nil), a tribe can receive the tech through diplomacy.
    * noConquest = bool
        - If true, then the tech can't be received by conquering a city.
        - If false (or nil), a tribe can receive the tech by conquering a city.
    * noTheft = bool
        - If true, then the tech can't be stolen with a diplomat or spy.
        - If false (or nil), a tribe can steal the tech.
    }
    If there is no value for a particular tech object, then all these
    values are considered false
]]

As always, let me know if you have any questions/concerns/problems.

 

[Prof. Garfield]

I have an important bugfix.

The supplementalData module (which is the backbone of the data, unitData, cityData, tileData and other data modules) has a bug where flags that have a default value of 'true' will never be reported as 'false' by flagGetValue, even if they have been set to false.

I'm know I've given @tootall_2012 and @ThichN advice which involves using modules derived from supplementalData, but I don't know if they've used a flag with a default value of true. It is much more natural to use false as the default value.

This doesn't impact the flag module which has been in the template for years. In fact, the reason I discovered the bug is because I was re-writing the flag and counter modules to be interfaces with the newer 'data' module, and I needed to transfer state data in order to make the new version saved game compatible.

I'm particularly annoyed this bug slipped through, since I put a great deal of effort into testing the supplementalData module.

 

[Prof. Garfield]

I've updated the template to deprecate the flag.lua and counter.lua modules, in favour of the data.lua module. The reason for this is that the data module works the same way as unitData, cityData, and the other data modules. They all have the same function calls, so everything is consistent. The reason for not just having 2 parallel systems is that some other modules can alter their behaviour based on designer supplied flags and counters. E.g. the canBuild.lua module can use flag statuses to determine if an item can be built.

If you update your scenario files, the flag and counter modules will now just call functions in the data.lua module. You will not need to re-write your existing flag and counter calls and definitions. (If you want to re-write, ask me for advice, since it could go wrong.)

 

[Petromax]

Is it possible to allow land units to attack sea units?

 

[Prof. Garfield]

Is it possible to allow land units to attack sea units?

I can think of two possible ways of doing that.

1. Give the land unit a key-press munition, which is an air unit, and so can attack offshore. There have been techniques to make the AI use munitions, also.
2. Reserve a terrain type as "pseudo ocean", which is impassable to land units that can't attack sea units. During each turn, you place pseudo ocean under all ships at sea (or maybe just on the coast) except for those owned by the active tribe. Then, ground units can enter the ocean tile to attack the sea unit. You'd have to adjust the combat settings events so that the ship didn't get the caught in port disadvantages.

 

[Petromax]

That sounds promising. Another question: is it possible to add more parameters to units (besides the standard attack, defense, hp, fp, move)?

 

[Prof. Garfield]

That sounds promising. Another question: is it possible to add more parameters to units (besides the standard attack, defense, hp, fp, move)?

I'm not sure exactly what you mean here. Can you give a concrete example?

 

[Petromax]

I'm not sure exactly what you mean here. Can you give a concrete example?

Such as adding a Range value

 

[Prof. Garfield]

Such as adding a Range value

In the template, I added an option under MechanicsSettings\simpleSettings.lua for land/sea units to obey a range set up in rules.txt

-- gen.activateRangeForLandAndSea(restoreRangeFn=nil,applyToAI=false)
-- restoreRangeFn(unit) --> bool governs when a unit's range is restored
-- and is checked when entering the tile and also after the unit has been
-- given its last order for the turn (i.e. when the unit has all movement
-- expended and the next unit is activated, or at the end of the turn if it
-- still has movement points e.g. if sleeping).  
-- If true, range is restored, if false it is not
-- By default, range is restored in city squares and on airbases
-- If you want to clear movement points (like for air units) do it in this function
-- Land and Sea units must now abide by range limitations set in rules.txt (if they are not 0)
-- if applyToAI is true, the AI will lose units when it violates these limits

simpleSettings.rangeForLandAndSea = false
if simpleSettings.rangeForLandAndSea then
    gen.activateRangeForLandAndSea(nil,false)
end

There are lots of things that can be done to change how the game works, but that sort of thing has to be evaluated on a case by case basis. We're not changing the original game code here. Lua just adds new code, which can sometimes be used to create new game mechanics. There is also the issue that the AI won't know how to deal with the new mechanic. For example, the AI won't return to base if the above setting is applied to it, since it wasn't programmed for land/sea units to have to obey range.

 

[Prof. Garfield]

A few modest updates.

combatModifiers
The combat modifiers module (and leaderBonuses, which uses it) can now specify functions instead of fixed values. Here's an example:

-- Artillery defends against other artillery using its attack stat
-- instead of its defense stat
combatMod.registerCombatModificationRule({
    attacker = "artillery",
    defender = "artillery",
    dCustomAdd = function(attacker,defender)
        return defender.type.attack - defender.type.defense
    end,
})

If you wanted, you could combine this with some counters and make a scenario where you don't know how good your generals are, and must guess based on the results of combat.

civilopedia

The civilopedia module now lets you assign entries based on traits. I think this module hasn't been noticed. What it does is allows you to add remarks about stuff within code by calling

civilopedia.description(item,description)

or

civilopedia.traitDescription(traitString,description)

When you are ready, you can run a script, and all your notes will be aggregated into a describe.txt file. There are a bunch of examples in the LuaParameterFiles\samplePedia.lua file.

legacy events

The legacyEventBuilder.lua file can detect more mistakes, because it references a new file legacyEventValidator.lua. I'll likely expand the latter file to make more checks as time goes on, but if you find it flags valid legacy events, you can change the name of the file and continue your work until I have a chance to look at it.

duplicate file checks

I recently added code to check for duplicate files to events.lua. Duplicate files can cause problems if require finds the wrong one, and you have no idea why your changes aren't changing anything. Unfortunately, the code I found online to do this opened the windows command prompt box a few times (which I didn't notice since I usually work with Linux). I have changed events.lua so that the require function now checks for the duplicate files.

 

[Prof. Garfield]

I've started to write some new Lua Lessons. I'm using the same feedback thread as for the originals. I've tried to make the introduction to programming as gentle as possible.

 

[Prof. Garfield]

I've updated the template. The onCityProcessed execution point is now onJustBeforeCityProcessed (although onCityProcessed still works), and there is now an onJustAfterCityProcessed execution point as well. These both use civ.scen.onCalculateCityYield, with some checks in code to make sure that the event only happens at the right time. It turns out that onJustAfterCityProcessed is possible, since civ.scen.onCalculateCityYield is called twice during the start of turn city processing phase (or more, if you look at the city).

OnJustAfterCityProcessed struck me as a useful execution point when I was helping @ThichN with bonus production for cities. If a bonus disappears on a turn, it is best if it disappears right away, in case you zoom in on the city. I'm sure there are other uses for the event as well.

I also added gen.cityProduction(city,item) which makes the city "produce" the item immediately, including executing the onCityProduction event.

There were also some minor documentation changes.

 

[ThichN]

Just wanted to put here that I installed the new template into my scenario, and pressing "1" and "2" came up with options in addition to placing terrain: "1" asked me to display messages, and "2" asked if I wanted to give a gift to another tribe.

 

[Prof. Garfield]

Just wanted to put here that I installed the new template into my scenario, and pressing "1" and "2" came up with options in addition to placing terrain: "1" asked me to display messages, and "2" asked if I wanted to give a gift to another tribe.

You can remove (or temporarily comment out) those effects in MechanicsFiles\keyPressSettings.lua.

 

[Prof. Garfield]

I've added a new Lua Lesson, Loops and Tables.

 

[ThichN]

@Prof. Garfield I managed to get the customMusic module / patch to work perfectly for my last project, but for some reason am having difficult with it. I downloaded the patch and placed it into ToT/lua, and the music files. Is there anything else that I need to be doing to get the music to play?

 

[Dadais]

Is there anything else that I need to be doing to get the music to play?

Get the music option "on" ? (game/game option/"music" box)

Advice from the guy who hardly played music .
You could check if it works by doing (game/pick music).
Otherwise, you can also launch a music using Lua and, per exemple, a onKeyPress.

Please notice that, while sounds are overlapping, only one music is played at a time.

 

[Prof. Garfield]

@Prof. Garfield I managed to get the customMusic module / patch to work perfectly for my last project, but for some reason am having difficult with it. I downloaded the patch and placed it into ToT/lua, and the music files. Is there anything else that I need to be doing to get the music to play?

In LuaParameterFiles/customMusicIntegration.lua, there is a line

local useCustomMusic = false

which must be set to true (in addition to the TOTPP music patch being enabled). Otherwise, the game will refer to whatever playlist is in <Test of Time Directory?\lua\extendedMusicSettings.lua.

I'm pretty sure that the end user doesn't need to have the Extended Music Patch installed to get custom music with customMusicIntegration.lua. The older version needed it, because files would be overwritten in the Test of Time\Music folder, and I didn't want everyone shipping code that overwrites files.