[TOT] The Test Of Time Patch Project

I know this isn't exactly what you asked for, but this might help you achieve what you're hoping for to some extent, regardless:

Lua allows us to cross reference a unit type against a unit location to achieve a result. You could have one "fortress" unit represent Eben Emael, Brest Litovsk, and Sevastopol, and they would all have different text/effects so long as you included their coordinates as part of the trigger.

Though not as useful for moving units, you could nontheless expand the concept by having larger coordinates (a "box" if you will) that corresponds to a particular theater or region. Then, for example, you could have a different effect when a GI is destroyed in Italy than in Normandy or the Ardennes.

It's not perfect, but it's way better than what we had before :)
 
Each unit, regardless of type, has it's own individual number. Could ToTPP enable us to use Lua (or traditional events for that matter) to use this as a trigger for an event? For example, destroying a specific infantry unit triggers some event, whereas destroying an identical, but different unit does not. That would allow using the same type of unit a number of times as individual triggers, instead of having to use multiple unit slots for multiple triggers.
Hi!
To weigh in a bit - actually you can use the ID right now, it's only a question of getting the info in the first place :)
If you know the id of a specific unit and you define
Code:
civ.onUnitKilled(...
...
if unit.id == xxx then
...
end
...
end)
then this will fire only for this specific unit and none else.

Thats actually how i adress cities in my lua code - I get the ids once and then only reference these. For units there might be some issue in case you think about units which are built or created somewhere along the timeline in a scenario (you would have to continuously scan the unit list to catch new placements and stuff), but other than that ...

If its a more general question (like the "GI in ..." example JPetroski mentioned), then coordinate checks work too, definitely.
 
Hi!
To weigh in a bit - actually you can use the ID right now, it's only a question of getting the info in the first place :)

Good news, because getting the unit number is dead simple. Just use the cheat menu and "reveal map". Click on the unit you want and the number of each unit is listed in brackets after its nationality in the status box. This could be very useful! :think:
 
Just a final disclaimer - I'm not entirely sure if it is the exact same number since I never checked it :)

You could try to ensure that via the lua console (ctrl-shift-f3) if you look at the output of
Code:
for u in civ.iterateUnits() do print(u.id, u.type.name, u.location.x, u.location.y, u.location.z)
- this should give the list of all units, printing their IDs, tile locations and type name :)
 
Thanks Tech. Forgive me for being dull, but whatever I try pasting into the bottom line, it always comes out as black (except for the two I have mentioned). If, for example, I wanted to add yellow, what would be the code? 0xb8b8b8 = Grey/Light blue I've been experimenting, but nothing seems to work :wallbash:
 
It's going great. This is my first co-operative project, something I have been hoping to do for many years. We have most of the game built and it's now at the event's stage. We're going to be using Lua. ToTPP and Lua have increased possibilities for scenario designers vastly. John & Grishnach have already included a ton of new features in Caesar's Gallic Wars and we're planning to incorporate many of these, as well as new experimental features in The Rise of Macedon. There are some teething problems getting to grips with Lua, but that's to be expected. Hopefully, the work John, Grishnach, The Nameless One and others are putting in will begin a new era of scenario creation.
 
Release v0.15.1, containing some fixes and minor features:
  • The Lua patch exports a new library globally ("totpp"), where patches can register their own Lua tables to expose functionality.
  • The Movement multipliers patch now registers the "totpp.movementMultipliers" table.
  • Fixed a crash bug in civ.ui.loadTerrain.
  • Fixed a bug in civ.scen.onCanBuild, where the callback was called twice for each wonder instead of once.
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. Happy gaming! :)
 

Attachments

  • TOTPPv015.1.zip
    368.3 KB · Views: 2,447
Thanks for the new version, TNO, this sounds very promising! It seems that the movementMultipliers table is initially empty though. Is this a foundational piece, that you're intending to fill out with appropriate keys/values in a later TOTPP release? Or is this something that's fully ready for use by scenario developers, we just need to populate it? (If the latter, I'm not quite understanding what keys are valid to use here.)

I've recently found a few other anomalies in trying out various aspects of Lua and TOTPP, and I wondered if you (or perhaps someone else in the community) could help me out:

1) For organizational purposes, I tried splitting some Lua functions out into a second .lua file, located in the same scenario directory as events.lua, which I would "require" from the main events file. However, this returns the following:
Code:
C:\Games\Civ2ToT\TestScen\events.lua:62: module 'events2' not found:
   no field package.preload['events2']
   no file 'C:\Games\Civ2ToT\lua\events2.lua'
   no file 'C:\Games\Civ2ToT\lua\events2\init.lua'
   no file 'C:\Games\Civ2ToT\events2.lua'
   no file 'C:\Games\Civ2ToT\events2\init.lua'
   no file 'C:\Games\Civ2ToT\..\share\lua\5.3\events2.lua'
   no file 'C:\Games\Civ2ToT\..\share\lua\5.3\events2\init.lua'
   no file '.\events2.lua'
   no file '.\events2\init.lua'
   no file 'C:\Games\Civ2ToT\events2.dll'
   no file 'C:\Games\Civ2ToT\..\lib\lua\5.3\events2.dll'
   no file 'C:\Games\Civ2ToT\loadall.dll'
   no file '.\events2.dll'

I would have thought that '.' would be my scenario directory and '.\events2.lua' would succeed, but apparently not. It finds my events2.lua file just fine if I move it to one of the locations listed above with a fully qualified path. For the sake of distributing a scenario, though, it seems highly advisable to keep all events files in the scenario subdirectory if possible. Any thoughts?

2) The new "onCityFounded" trigger works very well, except that in my testing it fires as soon as I give the command to build a city (i.e., as soon as I hit 'b'), while the "What Shall We Name This City?" dialog is still up on the screen. The city object received by the trigger contains the city's name as if that was finalized, but in fact I can change it in that dialog box. In fact, I can actually click "Exit" and undo the entire build, so that a city is not founded and my Settler unit still exists and is active. Would it be possible to delay the trigger so that it fires immediately after you click OK in that dialog box?

3) I've encountered a few issues with Lua returning negative values that seem unexpected. Specifically, in at least a couple places, some things return -128 instead of +128, which seems like a situation involving signed/unsigned bytes. One example is tile.terrainType: this normally returns 0 through 15, unless the tile has a river. The river seems to subtract 128 from the normal value -- so a Grassland tile is "2" but a Grassland with a river is "-126". Another example is tile.improvements, where I think pollution (0x80 bitmask value) returns "-128". Is this working as intended? Is trial and error the best approach to see what is returned in similar cases, or is there a more general/consistent rule?

As always, thanks for the great work and for any further help you can provide.
 
Thanks for the new version, TNO, this sounds very promising! It seems that the movementMultipliers table is initially empty though. Is this a foundational piece, that you're intending to fill out with appropriate keys/values in a later TOTPP release? Or is this something that's fully ready for use by scenario developers, we just need to populate it? (If the latter, I'm not quite understanding what keys are valid to use here.)

It's not empty, I just haven't provided the documentation in the Lua thread yet. I'll do that shortly, but in the meantime you can try the keys 'road', 'railroad', 'alpine', 'river' and 'aggregate'.

1) For organizational purposes, I tried splitting some Lua functions out into a second .lua file, located in the same scenario directory as events.lua, which I would "require" from the main events file. However, this returns the following:

[...]

I would have thought that '.' would be my scenario directory and '.\events2.lua' would succeed, but apparently not. It finds my events2.lua file just fine if I move it to one of the locations listed above with a fully qualified path. For the sake of distributing a scenario, though, it seems highly advisable to keep all events files in the scenario subdirectory if possible. Any thoughts?

A valid point, the scenario directory is not in the search path atm. I'll be sure to add this in a future version. As a workaround, you can require 'package', and add the directory to package.path yourself. See the documentation for require & package for more information on how modules are loaded.

2) The new "onCityFounded" trigger works very well, except that in my testing it fires as soon as I give the command to build a city (i.e., as soon as I hit 'b'), while the "What Shall We Name This City?" dialog is still up on the screen. The city object received by the trigger contains the city's name as if that was finalized, but in fact I can change it in that dialog box. In fact, I can actually click "Exit" and undo the entire build, so that a city is not founded and my Settler unit still exists and is active. Would it be possible to delay the trigger so that it fires immediately after you click OK in that dialog box?

Ah yes, this should run a little later - I'll change it.

3) I've encountered a few issues with Lua returning negative values that seem unexpected. Specifically, in at least a couple places, some things return -128 instead of +128, which seems like a situation involving signed/unsigned bytes. One example is tile.terrainType: this normally returns 0 through 15, unless the tile has a river. The river seems to subtract 128 from the normal value -- so a Grassland tile is "2" but a Grassland with a river is "-126". Another example is tile.improvements, where I think pollution (0x80 bitmask value) returns "-128". Is this working as intended? Is trial and error the best approach to see what is returned in similar cases, or is there a more general/consistent rule?

It shouldn't really matter as it is just representation, except in the case of terrainType, since there is no way to add or remove rivers now (I restrict the values to 0-15 on assignment, I'll have to change this). Just make sure you use bitwise operators in tests and assignments (e.g. to test for the presence of a river, use tile.terrainType & 0x80, to add pollution to a tile, use tile.improvements = tile.improvements | 0x80).
 
Top Bottom