[TOT] The Test Of Time Patch Project

[Prof. Garfield]

Is it possible to restore the airfield "bug"? The one in regular Civ 2 that treats airfields as having railroads and farmlands? For pre-modern scenarios, it allowed a bit of flavor, like it was used as villages in Crescent and Cross and Monasteries in Fading Lights. Both were wonderful flavor.

onCalculateCityYield could allow you to add some extra production to the city based on if there was an airbase being worked, but those extra resources wouldn't show on the worker allocation map.

 

[Konig15]

onCalculateCityYield could allow you to add some extra production to the city based on if there was an airbase being worked, but those extra resources wouldn't show on the worker allocation map.

So I'm thinking that's Lua, and more importantly, it would be a flat bonus to every airfield tile? And if this is so, considering I already put up two threads in the last 24 hours would it be spamming to ask further questions in a new thread? Cause this ceases to be a patch question has become a Lua question.

 

[Prof. Garfield]

So I'm thinking that's Lua, and more importantly, it would be a flat bonus to every airfield tile?

Yes it is Lua, and it would be possible to tailor the bonus to only apply if the airfield tile is being worked.

And if this is so, considering I already put up two threads in the last 24 hours would it be spamming to ask further questions in a new thread? Cause this ceases to be a patch question has become a Lua question.

I'd just add it to the other question thread you started. Threads change direction all the time.

 

[Konig15]

I need help ith the Lau patches. There are NO instructions on updating the Lua in the TOTTL menu and when I try and play The Cold War or Over the Reich I get the following message every time I click on a unit


Welcome to the TOTPP Lua console.
Running Lua 5.3.6 Copyright (C) 1994-2020 Lua.org, PUC-Rio

Keyboard shortcuts:
Ctrl-F1: Prints this help text
Ctrl-F2: Aborts running script
Ctrl-F5: Reruns last script
Up/Down: Scrolls input history

The Cold War 1947-1991
By John Petroski
Requires TOTPP v. 15.1 or higher
C:\Civ2\Test of Time\The Cold War 1947\generalLibrary.lua:1993: attempt to index a nil value (field 'movementMultipliers')
stack traceback:

 

[Prof. Garfield]

I need help ith the Lau patches. There are NO instructions on updating the Lua in the TOTTL menu and when I try and play The Cold War or Over the Reich I get the following message every time I click on a unit


Welcome to the TOTPP Lua console.
Running Lua 5.3.6 Copyright (C) 1994-2020 Lua.org, PUC-Rio

Keyboard shortcuts:
Ctrl-F1: Prints this help text
Ctrl-F2: Aborts running script
Ctrl-F5: Reruns last script
Up/Down: Scrolls input history

The Cold War 1947-1991
By John Petroski
Requires TOTPP v. 15.1 or higher
C:\Civ2\Test of Time\The Cold War 1947\generalLibrary.lua:1993: attempt to index a nil value (field 'movementMultipliers')
stack traceback:

My guess is that you disabled the Movement Multipliers Patch (under extra cosmic parameters). You'll have to run TOTLauncher.exe to change that.

 

[Konig15]

My guess is that you disabled the Movement Multipliers Patch (under extra cosmic parameters). You'll have to run TOTLauncher.exe to change that.

Oh that fixed it right quick! Thank you!

 

[Blake00]

Wow! I somehow completely missed TNO's big return and the new version. I'm still rocking Win7 as well so hopefully I won't have some of the issues I've seen others reporting.

Added a BarbResearch setting to the AI tweaks patch.

Does that mean what I think it means.. that you can make the Barbarians research technologies like the regular 7 Civ slots?

.

 

[Prof. Garfield]

Does that mean what I think it means.. that you can make the Barbarians research technologies like the regular 7 Civ slots?

Haven't tried it, but it looks like it. Here's the relevant patch description:

Adds configurable tweaks for AI behaviour to @COSMIC2.
Available keys are:
- AICapitalizationLimit: Number of units after which the AI switches to Capitalization. Default is 512.
- BarbOffensiveUnitLimit: Maximum number of offensive barbarian units per landmass. When this limit is reached, barbarian cities stop producing units. Default is 16, set to -1 for unlimited.
- BarbUnitSupport: When set to 1, allows barbarian units to have a home city. Normally, barbarian-produced units have none. Defaults to 0.
- BarbResearch: When set to 1, allows the barbarian tribe to own technologies. Defaults to 0.

 

[Knighttime]

Agreed. Actually I think barbarian cities could always generate research points, which are applied towards learning a new tech. If enough points are accumulated towards their current research goal, the barbs will learn that tech just like any tribe. You can also give a tech to the barbarians via events, and they retain that knowledge as you'd expect -- but only for the remainder of that turn. At the beginning of each new turn, the barbs have all of their techs wiped away (regardless of how they were obtained), and I think their research progress counter is zeroed out.

So my understanding is that this patch just causes those two steps to be skipped, meaning barbs can then accrue techs normally across turns just like the other 7 civs.

 

[Blake00]

That is going to be fascinating for my 'play as Barbarians' video series as it'll be very interesting to see if this new change still works when the player takes control of the Barbarian faction 8th slot. I filmed my ToT play as Babarians video 2 or so years ago (before I made that fateful decision to go back and change all my videos to cover Civ scenarios too, leading to years of collecting work lol) but I might have to scrap it and do a better video if this works!

 

[AyCe]

I have a Win10 PC where the "Decrease CPU Usage" fix (pretty sure it's that one, based on testing, but could be wrong) will sometimes (other times it works just fine) lock the game up in the main menu (or the intro movie, if you don't click it away fast enough), as described here:
https://forums.civfanatics.com/threads/the-test-of-time-patch-project.517282/page-56#post-16074435
When I deactivated that fix in particular it ran normally again.

On that note, sometimes the game will just close (no "encountered an error" window) with the patched civ2.exe while the AI is doing its turn. This can be "semi-reliably" reproduced with a savegame, but only on some machines, and not 100% every time. I tried nailing down which fix causes this, as it works fine 100% of times tried in the unpatched civ2.exe, but so far whenever I though I had found the effect it turned out to later still close.

Edit: Since disabling the CPU fix no more "just-closes crashes" have happened.

 

[Prof. Garfield]

There is an inconsistent bug with the TOTPP Lua "negotiation" event:

onNegotiation
civ.scen.onNegotiation(function (talker, listener) -> void) -> void

Just now, I noticed that the Lua Function Reference seems to be incorrect. Based on a version of the page I downloaded before, I think it is supposed to be:

onNegotiation
civ.scen.onNegotiation(function (talker, listener) -> boolean) -> void

If the registered function returns false given the talker and listener, the two tribes are not supposed to be able to talk. However, I have occasionally noticed that the AI will sometimes still initiate negotiations.

I have attached a version of Boudicca that has this issue. Load the beforenegotiation.sav file, and the AI should offer to negotiate at least once during its turn.

I register the negotiation event in events.lua (line 359):

civ.scen.onNegotiation(negotiationSettings.negotiation)

and define the function in question in LuaRulesEvents\negotiationSettings.lua

local legacy = require("legacyEventEngine")
local negotiationSettings = {}
function negotiationSettings.negotiation(talker,listener)
    --civ.ui.text('negotiation check. talker: '..talker.name.." listener: "..listener.name)
    --legacy.doNegotiationEvents(talker,listener)
    return false
    --return legacy.canNegotiate(talker,listener)
    --return true
end
return negotiationSettings

I know this function is being read, since I can toggle the text line on and off. I did also notice that when negotiation was attempted, the 'talker' was the Romans, instead of the listener.

When I tried to make a simple scenario to demonstrate this problem (I converted the classic WWII scenario), I wasn't able to trigger the bug. So, there must be something more subtle going on.

There, I successfully prevented the French and Axis from talking with this code:

civ.scen.onNegotiation(function(talker,listener)
    --civ.ui.text('negotiation check. talker: '..talker.name..", listener: "..listener.name)
    if talker ==civ.getTribe(3) and listener == civ.getTribe(7) then
        return false
    end
    if talker == civ.getTribe(7) and listener == civ.getTribe(3) then
        return false
    end
    return true
    end)

I would appreciate any insight.

 

[Knighttime]

There is an inconsistent bug with the TOTPP Lua "negotiation" event:
...
I would appreciate any insight.

I agree that this doesn't accomplish everything I would hope, but I've never been entirely sure what counted as a "negotation". For example, the AI can launch a "sneak attack", right? but they do without opening any negotiations first -- that's the whole point. And if they can make war without negotiating, it may only be "fair" if they could also make peace...

So as a scenario designer, I'd typically like to use this event to persist diplomatic states exactly as they are, but I've never been sure if that was a reasonable expectation.

In Medieval Millennium, this wasn't an issue for me (since I wanted to allow all standard negotiating behavior). But in Napoleon, despite attempting to block all negotations between tribes:
civ.scen.onNegotiation(function (talker, listener)
return false
end)

... I added the following comment:
--[[ If two tribes are at war, it seems that blocking negotiation between them ought to prevent them from signing a Cease Fire or a Peace Treaty.
However, if two tribes are at peace, it's possible that even without negotiating,they can still declare war and attack.
In testing, it seems like tribes sometimes AI tribes can both declare war on each other and sign peace treaties with each other, *despite* all negotiation being blocked! ]]

To resolve this, I had to track the "correct" relations between tribes in memory, and then I created functions enforcePeace(), enforceAlliance() and enforceWar() and ran them very frequently (in onActivateUnit(), I believe) to undo the results of any unwanted changes and put diplomatic states back to the proper values.

So, I guess I too would appreciate any insights @TheNamelessOne has to offer.

 

[Prof. Garfield]

So as a scenario designer, I'd typically like to use this event to persist diplomatic states exactly as they are, but I've never been sure if that was a reasonable expectation.

As far as I understand, the 'macro' events can prevent tribes from negotiating. This means that tribes can be forced to stay at war and be forced to stay allies, but peace can be broken for permanent war. I'm mostly concerned that Lua at the very least be able to achieve the same things that the macro system can.

To resolve this, I had to track the "correct" relations between tribes in memory, and then I created functions enforcePeace(), enforceAlliance() and enforceWar() and ran them very frequently (in onActivateUnit(), I believe) to undo the results of any unwanted changes and put diplomatic states back to the proper values.

I've written similar code for the diplomacy module of the Lua Scenario Template, and I believe it was used in the Reformation scenario. Of course, having this feature built in would make things easier.

 

[Prof. Garfield]

I'd like to offer a few more suggestions for additions to the TOTPP Lua events. As always, my perceptions of the relative importance of features might be different from that of other designers.

Addition: Make unit visibility editable

Reason: Makes automatic scouting easier. Would have been nice in OTR, for a couple reasons. One is that at night planes get moved a few squares away after surviving an attack, but they are still visible to the attacker. Another is that some units were automatically 'scouted' each turn if they were in range.

Existing Workaround: Create and delete a unit nearby to reveal the scouted unit. Can't hide units again with this method, however.

Perceived Importance: Medium. I doubt not having it would cause a game mechanic to be scrapped completely, but this did cause a limitation in an actual scenario.
Saved game format

Addition: City founded event after city construction is confirmed.

Reason: Simplifies code. At the moment, if a city is cancelled, some results of a city founded event persist, such as changes to the terrain.

Existing Workaround: Use onActivateUnit unit to check if a city was actually built, and reverse the effects if it is not. A bit awkward, and runs the risk of there not being another unit to activate.

Note: Keep the city founded before confirmation event, since that is useful too. E.g. to warn player if city will be deleted if built on that square, or to suggest a city name. (Also keep for backwards compatibility.)

Perceived Importance: Low to Medium. The work around is adequate if someone really wants the event.

Addition: Make civ.scen.params.startingYear a 'set' field.

Reason: Would allow variable duration of turns in combination with changes to civ.scen.params.yearIncrement.

Existing Workaround: Use a turn number instead of a date, and provide the date to the player in a popup screen.

Note: Changing civ.scen.params.yearIncrement doesn't immediately change the year displayed. You have to make a relevant cheat mode change, or reload the game.

Perceived Importance: Low to Medium. I personally think that the workaround is adequate, however I think this came up in discussion at some point, and displaying a correct month/year display would certainly be preferable to a turn counter. It would also be easier to plan events by date if the date displayed is correct (I wrote a 'calendar' module to convert between turns and date, using the startingYear and yearIncrement fields).

Addition: Make spaceship object fields settable.

Reason: Easier for experimentation, and it could be useful to change this for a scenario involving a space race.

Perceived Importance: Low, I think. I didn't even notice they weren't settable until trying to experiment with the Cenauri arrival event. @Knighttime has a space race in Medieval Millennium, so he might have a bit more insight into the value.

Addition: Make unit type and improvement names settable.

Reason: For units, could allow "decoy" versions of units, where the difference is visible only to the owner. For improvements, could allow different flavour for different tribes. E.g. mosque vs. church.

Workaround: Have different rules.txt for each player.

Perceived Importance: Low. If this wasn't done because it is difficult, then I probably wouldn't bother. If it was just overlooked, then it would have some value. If it could be paired with changing the unit type's image, then it would facilitate 'recycling' unit types without batch files, and would probably be of high value. I believe that @JPetroski has a project that is recycling unit types.

Addition: Enable changing a unit's type.

Reason: Simplifies promotion/demotion, especially if there is some sort of tracking individual units (I don't know of a scenario that tracks individual units on any significant scale, however).

Workaround: Delete and re-create the unit.

Perceived Importance: Very low. Only do if easy, since the workaround is pretty good.

Addition: Fix this Zone of Control Bug

Reason: Transferring units and cities between is more complicated than just looping over the units on a tile and changing ownership.

Workaround: Teleport units to a different tile, and then teleport them back after changing ownership.

Perceived Importance: Low to Medium. Writing a function to transfer the contents of a tile using the work around isn't too difficult, except that sometimes there isn't an obvious point on a map to move the units to temporarily.

Addition: Have option to stop land/sea units from having reduced movement points based on damage.

Reason: Reduced combat effectiveness doesn't always correlate with reduced movement. For example, in OTR, convoys that were damaged should still have moved at full speed to attempt to escape further damage.

Workaround: With the unit activation event, the unit type's movement allowance could probably be changed to compensate. (In OTR, we just turned off the 'unit has moved' flag for the convoys, so they could heal while still moving, so I haven't tried this.)

Perceived Importance: Low to Medium. This could be useful, but individual scenarios can probably find ways to deal with this issue if they really need to.

 

[TheNamelessOne]

If the registered function returns false given the talker and listener, the two tribes are not supposed to be able to talk. However, I have occasionally noticed that the AI will sometimes still initiate negotiations.

I've managed to track this down, the bug manifests itself when the onNegotiation callback is called indirectly from another Lua callback (in this case onUnitKilled, which calls createUnit, and the new unit triggers the negotiation attempt). When this happens the Lua stack looks different, and the wrong index is converted to a boolean, making it seem to return true here.

I'll add a fix for this in 0.17.

 

[TheNamelessOne]

Release 0.17:

• Added the Pikemen flag patch, which fixes the movement rate check for units with this flag.
  
• Added the Ship disband patch, which prevents disbanding a ship at sea from disbanding other ships.
  
• Rewrote the Decrease CPU use patch to be more responsive.
  
• LUA: Added trade routes and commodities.
• LUA: Added onChooseDefender to override the defender for a tile.
• LUA: Added onGetRushBuyCost to override the rush buy cost.
• LUA: onActivateUnit can now optionally fire after each movement.
• LUA: Added unit.visibility, made tile.owner settable, made all space ship fields settable.
  
• Better handling for Lua errors outside of protected mode. Fixes crashes when returning unexpected types from Lua.
• Fixed handling of Lua return values when another Lua frame was already on the stack.
• The civilopedia will now show changes made by the Initial trade arrow for roads patch.

Since this release I'm using VS2019 to build TOTPP, and this build depends on the Microsoft C++ runtime libraries (https://aka.ms/vs/16/release/vc_redist.x86.exe; Windows XP needs an older version: https://download.visualstudio.micro...B54210E2764C8836F4E9DEFA345/VC_redist.x86.exe). Install this if you get an error on launch.

As always, detailed information about the patches is available in the launcher. For an overview of all patches, as well as installation instructions & requirements, see the included README.txt. For Lua API documentation see the Lua reference thread. Happy gaming!

 

[JPetroski]

Rewrote the Decrease CPU use patch to be more responsive.

What does this one do? Just curious if I might see an end to the AI moves timing out/"thinking" on modern windows systems (basically the game continues and I can hear sound but I can't see the AI moves usually which makes playtesting a real chore or at least compels one to move over to an XP machine for it).

 

[Prof. Garfield]

A quick test has revealed that the activate unit event now runs when a unit is selected from the city screen menu. That was an annoying bug that I'm very glad to see fixed.

 

[TheNamelessOne]

What does this one do? Just curious if I might see an end to the AI moves timing out/"thinking" on modern windows systems (basically the game continues and I can hear sound but I can't see the AI moves usually which makes playtesting a real chore or at least compels one to move over to an XP machine for it).

It improves user experience during periods of continuous CPU usage (the moving star field in the background of a launched space ship illustrates this well, compare 0.17 to an older version and you'll see what I mean). So AI moves might well be affected. But personally I never had much trouble with the old patch, so I can't tell you for sure if it helps with that.