[TOT] The Test Of Time Patch Project

Is there currently a way to access the "AI role/domain-specific counter"?

http://users.tpg.com.au/jpwbeest/jp_hex.htm

Perhaps even by way of adding an oversized number to orders or movement?

@JPetroski 's Over The Reich needs to increment that counter when air units use 'k' to build a bomb and use up all their remaining movement for the turn.

It can be worked around, but this would be the best solution.
 
Last edited:
I have two questions that perhaps @TheNamelessOne or even @Catfish may be able to assist with to help me publish a scenario that is quite close to completion:

1. What is the integer for special resource terrain? For example, terrain has an integer of 0 - 15 and terrain with rivers has an integer ranging from -128 to -114. What is the integer for these types of terrain that have a special resource on them? I ask because currently we are tying the call up of ammunition to the terrain type, yet no units can fire on terrain with a special resource. I suppose an option would be wiping those resources as a last resort but of course this isn't preferable for most scenarios. Simpler would be to just add in additional integers allowing combat on those terrain types.

2. Do the new units follow the old units path in ToT in terms of hex editing? I need to change the native transport ability of unit 110. Am I going to find this byte where I would expect it (generally, in sequence after the first 80 units) or is it tucked away elsewhere now in the save structure?

Thanks to anyone who can assist with these very technical but very important questions!
 
I believe the nativeTransport ability problem has been solved using available lua functions.
 
1. What is the integer for special resource terrain? For example, terrain has an integer of 0 - 15 and terrain with rivers has an integer ranging from -128 to -114. What is the integer for these types of terrain that have a special resource on them? I ask because currently we are tying the call up of ammunition to the terrain type, yet no units can fire on terrain with a special resource.

In my testing of TOTPP 0.15.1, the value of tile.terrainType is unchanged if the tile has a special resource (but see "0100" below). I would greatly appreciate it if someone could explain how a Lua event can tell whether or not a tile has a special resource!

tile.terrainType uses two bytes, which are stored/returned as an integer. The first byte results in a number from 0 to 15 and this is the "base" terrain type. In the second byte:

0001 = I haven't seen this, and I don't know what it means, but this would result in the value of tile.terrainType being increased by 16
0010 = I haven't seen this, and I don't know what it means, but this would result in the value of tile.terrainType being increased by 32
0100 = This means that an ocean tile would have a special, except the tile is too far from land to ever fall within a city radius. The game suppresses the display of ocean specials in this case. It results in the value of tile.terrainType being increased by 64. Since this only applies to ocean tiles, which have a base value of 10, these ocean tiles will have tile.terrainType of 74.
1000 = This means the tile has a river. Unfortunately (in my opinion, since it adds unnecessary confusion), TOTPP evaluates this as negative 128 instead of positive 128, when adding it to the value of the base terrain type.

I raised the issue of negative 128 with TNO earlier in this thread:
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?
and he responded:
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).

Based on that response, I think the correct way to find the base terrain type of a tile would be tile.terrainType & 0x0F -- or if you want to avoid hexadecimal, tile.terrainType & 15.

we are tying the call up of ammunition to the terrain type, yet no units can fire on terrain with a special resource
You would need to account for ocean tiles on which a special resource is being suppressed, but I'm not sure what issue you might be having on other special resource tiles. Can you have Lua print the value of tile.terrainType to the console on every attempt to fire? But it seems to me that if you find the base terrain type using the bitwise "&" operator, you shouldn't have to worry about specials or rivers.
 
Last edited:
instead of checking tile.terrainType == desiredTerrain, I introduced tile.terrainType % 16 == desiredTerrain, and it seems to have worked
 
1000 = This means the tile has a river. Unfortunately (in my opinion, since it adds unnecessary confusion), TOTPP evaluates this as negative 128 instead of positive 128, when adding it to the value of the base terrain type.


This video explains twos complement, which is probably how lua is interpreting that byte.

0001 = I haven't seen this, and I don't know what it means, but this would result in the value of tile.terrainType being increased by 16
0010 = I haven't seen this, and I don't know what it means, but this would result in the value of tile.terrainType being increased by 32

I would hazard to guess these are the special indicators. It should be fairly easy to check.
 
I would hazard to guess these are the special indicators. It should be fairly easy to check.

I think I've figured it out. If the tile special is being animated, it changes from the basic terrain type to something else.

EDIT: P.S. I should have read Knighttime's post more closely, or just realized that he is clever enough to have checked special squares first anyway.
 
Last edited:
instead of checking tile.terrainType == desiredTerrain, I introduced tile.terrainType % 16 == desiredTerrain, and it seems to have worked
That seems reasonable, and you won't find me complaining about something that works. I've been trying to use bitwise operators in my own code, though, based on TNO's recommendation.

This video explains twos complement, which is probably how lua is interpreting that byte.
That's a good, detailed explanation. The essence of my question to TNO, I think, was that it seems to me that Lua isn't consistent about when it does this. I mentioned tile.terrainType and tile.improvements as two cases where Lua can return negative numbers, apparently using twos complement as you said. But I'm pretty sure I've encountered some other similar fields where an integer value in Lua was always positive, implying that the left-most bit was not being treated as a negative indicator (i.e., twos complement was not being used). Unfortunately the original post was awhile ago and I don't have an example handy at the moment. At any rate, that's why I said "unnecessary confusion", since there isn't an inherent need to be able to represent a negative number; and if there's inconsistency in how bytes are translated to integers, that's likely to increase the struggles of designers (especially those without a programming background) who would like to try their hand at Lua events.

I think I've figured it out. If the tile special is being animated, it changes from the basic terrain type to something else.
:sad: Too bad almost no scenario designers use animated specials! I always have them disabled. Thanks for this information though, and congratulations for figuring this out. How does this work -- do animated specials use the 0001 value in the second byte? or 0010?
But it does really seem odd to me -- and rather frustrating -- if non-animated specials (which are the norm in most scenarios) are undetectable by Lua!

EDIT: P.S. I should have read Knighttime's post more closely, or just realized that he is clever enough to have checked special squares first anyway.
:lol: Thanks -- I don't know if I'm worthy of "clever", but at least I do try to be "thorough"! I uncovered the meaning of 0100 (suppressed ocean specials) by a lot of experimenting, more than a sudden inspiration.
 
Last edited:
:sad: Too bad almost no scenario designers use animated specials! I always have them disabled. Thanks for this information though, and congratulations for figuring this out. How does this work -- do animated specials use the 0001 value in the second byte? or 0010?

This is a guess, and possibly wrong. The game randomly chooses specials to animate. When it does, it toggles the appropriate bit so that the map drawing function can easily tell that the square should be animated. When the game decides a certain tile no longer should be animated, the bit is turned off.

In Imperialism II, the terrain animations can't be turned off, so I presume that setting these bits is how arbitrary locations for special tiles has been implemented.

http://users.tpg.com.au/jpwbeest/jp_hex.htm#MapData

This gives one of the corresponding bits this explanation:
0x20 Only used for resource tiles. Indicates that the tile was being animated when the game was saved - no apparent effect.

I would hypothesize that one bit tells the program to animate one special type, the other bit tells it to animate the other one.

But it does really seem odd to me -- and rather frustrating -- if non-animated specials (which are the norm in most scenarios) are undetectable by Lua!

If that is desired functionality, we'll just have to reverse engineer the pattern of special resource distribution. The formula probably isn't that complicated.
 
If that is desired functionality, we'll just have to reverse engineer the pattern of special resource distribution. The formula probably isn't that complicated.

I think there's reason to figure out the bit/integer for the specials. It essentially would mean we have 45 terrains instead of 15. We've already seen how powerful lua can be when coupling terrain checks to just about anything else and having that many more options would be pretty special (for example, you might be able to use one as a "border" and certain fort units can only be built on a "border" and the border gets dynamically redrawn as different cities are brought under control -- perhaps a temple is built, etc).
 
FWIW, creating animations, especially from scratch, is no easy task. And I think the concept of working on or creating animations can seem intimidating to a lot of folks.
 
Not sure if its been suggested before, but since the turn system can be done both months and years at a time, would it be possible to add a day by day calendar as well?

An ability to switch between that and the standard turn systems mid game without reloading would be interesting as well, especially now that we have LUA scripting :)
 
Essentially identical, though with the Patch Project you can disable stack kills and the exploit of using air units to shield against ground attacks.
 
Here is another groundbreaking use of lua by Prof. Garfield in our scenario Over the Reich. This time, unit formation movement. It will mainly be used by aircraft in our scenario but I trust everyone can see the obvious implications for scenarios such as Imperialism in the future.

@TheNamelessOne I sure hope you'll return from sabbatical soon, because between this scenario and Napoleon by @tootall_2012 and @Knighttime , there are many interesting scenarios coming alive due to your hard work!

Over the Reich - Creation Thread
 
Top Bottom