The Test Of Time Patch Project

Discussion in 'Civ2 - General Discussions' started by TheNamelessOne, Dec 22, 2013.

  1. Prof. Garfield

    Prof. Garfield Deity Supporter

    Joined:
    Mar 6, 2004
    Messages:
    3,602
    Location:
    Ontario
    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.
     
  2. Konig15

    Konig15 Warlord

    Joined:
    Nov 4, 2007
    Messages:
    219
    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.
     
  3. Prof. Garfield

    Prof. Garfield Deity Supporter

    Joined:
    Mar 6, 2004
    Messages:
    3,602
    Location:
    Ontario
    Yes it is Lua, and it would be possible to tailor the bonus to only apply if the airfield tile is being worked.

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

    Konig15 Warlord

    Joined:
    Nov 4, 2007
    Messages:
    219
    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:
     
  5. Prof. Garfield

    Prof. Garfield Deity Supporter

    Joined:
    Mar 6, 2004
    Messages:
    3,602
    Location:
    Ontario
    My guess is that you disabled the Movement Multipliers Patch (under extra cosmic parameters). You'll have to run TOTLauncher.exe to change that.
     
  6. Konig15

    Konig15 Warlord

    Joined:
    Nov 4, 2007
    Messages:
    219
    Oh that fixed it right quick! Thank you!
     
  7. Blake00

    Blake00 King Supporter

    Joined:
    Sep 24, 2016
    Messages:
    898
    Gender:
    Male
    Location:
    Australia
    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.

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

    .
     
  8. Prof. Garfield

    Prof. Garfield Deity Supporter

    Joined:
    Mar 6, 2004
    Messages:
    3,602
    Location:
    Ontario
    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.
     
    Blake00 likes this.
  9. Knighttime

    Knighttime Warlord

    Joined:
    Sep 20, 2002
    Messages:
    293
    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 likes this.
  10. Blake00

    Blake00 King Supporter

    Joined:
    Sep 24, 2016
    Messages:
    898
    Gender:
    Male
    Location:
    Australia
    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! :)
     
  11. AyCe

    AyCe Chieftain

    Joined:
    Mar 3, 2019
    Messages:
    85
    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.
     
    Last edited: Sep 17, 2021
  12. Prof. Garfield

    Prof. Garfield Deity Supporter

    Joined:
    Mar 6, 2004
    Messages:
    3,602
    Location:
    Ontario
    There is an inconsistent bug with the TOTPP Lua "negotiation" event:

    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):
    Code:
    civ.scen.onNegotiation(negotiationSettings.negotiation)
    
    and define the function in question in LuaRulesEvents\negotiationSettings.lua
    Code:
    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:
    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.
     

    Attached Files:

  13. Knighttime

    Knighttime Warlord

    Joined:
    Sep 20, 2002
    Messages:
    293
    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.
     
  14. Prof. Garfield

    Prof. Garfield Deity Supporter

    Joined:
    Mar 6, 2004
    Messages:
    3,602
    Location:
    Ontario
    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.

    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.
     
    Knighttime likes this.
  15. Prof. Garfield

    Prof. Garfield Deity Supporter

    Joined:
    Mar 6, 2004
    Messages:
    3,602
    Location:
    Ontario
    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
    UnitVisibility.png

    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.
     
    Last edited: Nov 6, 2021
    CurtSibling likes this.
  16. TheNamelessOne

    TheNamelessOne Warlord

    Joined:
    Dec 18, 2013
    Messages:
    204
    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.
     
  17. TheNamelessOne

    TheNamelessOne Warlord

    Joined:
    Dec 18, 2013
    Messages:
    204
    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). 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! :)
     

    Attached Files:

    Civinator, Tanelorn, amadeus and 10 others like this.
  18. JPetroski

    JPetroski Deity

    Joined:
    Jan 24, 2011
    Messages:
    3,892
    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).
     
    AyCe likes this.
  19. Prof. Garfield

    Prof. Garfield Deity Supporter

    Joined:
    Mar 6, 2004
    Messages:
    3,602
    Location:
    Ontario
    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.
     
    CurtSibling, Knighttime and JPetroski like this.
  20. TheNamelessOne

    TheNamelessOne Warlord

    Joined:
    Dec 18, 2013
    Messages:
    204
    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.
     

Share This Page