[TOT] The Test Of Time Patch Project

Greizer85 said:

I could simply make boats cheap but risky to use. The aesthetic benefit is imo well worth it. The text could simply be edited (to something like 'Your ship is ambushed from the shore!'). If it's not too much trouble, I'd appreciate this possibility; ofc I realize it's not high priority.

Is it possible to disable huts altogether? In the default game or ToTPP? I just realized that I have no use for them, as they only add needless randomness to the game. And getting techs from huts would be disastrous for balance, as there will only be about 30 techs in my scenario, containing everything the standard game has.

Also, I second the nuclear option that PlutonianEmpire suggested.

Click to expand...

Actually, you already can disable huts altogether even without this project. In rules.txt, under cosmic, the second to last line is the bitmask for the huts, which tells the game on which map not to generate huts. going from right to left, setting the values to 1 for the first four digits tells ToT not to generate any huts on any map. So for your situation, it would look like this: 00001111

Hope this helps.

Also, on an unrelated note, automated settler units do not seem to be doing their jobs right, if at all. For example, I would have two settler unit types, one for building transport sites to other maps, the second unit type without this ability. After pillaging the site on both maps, the automated settlers with no build capacity would cluster around the old tile where the transport site once was, endlessly trying to move between maps at that location. And this would be even when multiple nearby cities would be pumping out pollution like crazy and contributing to global warming.

And automated settler units with build capacity just work the othee maps like crazy completely leaving their home cities on the home map in the dust with just roads and irrigation while the newer cities on the "new" map get farms and railroads to no end.

PlutonianEmpire said:

Actually, you already can disable huts altogether even without this project. In rules.txt, under cosmic, the second to last line is the bitmask for the huts, which tells the game on which map not to generate huts. going from right to left, setting the values to 1 for the first four digits tells ToT not to generate any huts on any map. So for your situation, it would look like this: 00001111

Hope this helps.

Click to expand...

It sure does! Thanks a bunch; I'm still not that familiar with the modding possibilites of Civ II (and especially ToT). It's kinda hard to figure some things out since most of the links are dead in the various guides etc.

Here is a screenshot of my Finland map for y'all to feast your eyes upon, and to showcase the aforementioned river problem:
E.g. the long like of lakes in the Southwestern corner of the map is supposed to be a navigable river, but it looks really awkward with the 'lake' graphic. I won't be *totally* crushed if this won't happen, but I will be, say, 26 % crushed because of it, with a deviation of 3,5 %.

Question: Where do I put the new @COSMIC2 section in my rules.txt? Anywhere within the file? Or at a specific location?

I put it after @Cosmic #1... Seemed logical enough, and it worked fine. I do suspect it will work anywhere, though (as long as it's kept separate from the other sections).

Ah, ok. Thanks.

Also, I just got this idea, and I'm kinda surprised no one thought of it. The SDI Defence improvement. It has a 100% success rate, and is almost always impossible for spies to destroy. Adding modifiers to these under @COSMIC2 would probably provide a lot better gameplay.

Hmmm. Was it mentioned earlier at all whether there was a limit as to how much modifications ToT can handle from this project?

Because I'm encountering new AGW bugs, even though the AGW fix is applied. (I mentioned this earlier, I believe.) So I dunno if we reached some sort of limit on how much can be fixed/modded/added, or something else?

Here, on the third map (Pluto), AGW occurs even though there is one pollution tile (the first AGW bugs.sav file). And then it maxes out and skips all the other cycles (the second AGW bugs.sav file).

Finally, I noticed that when being attacked by custom nuclear units not in the default unit slot for the default Nuclear Msl., the "so and so use nuclear weapons!" dialog doesn't pop up. Can anyone confirm or refute?

PlutonianEmpire said:

The SDI Defence improvement. It has a 100% success rate, and is almost always impossible for spies to destroy. Adding modifiers to these under @COSMIC2 would probably provide a lot better gameplay.

Click to expand...

Sure, great idea!

PlutonianEmpire said:

Because I'm encountering new AGW bugs, even though the AGW fix is applied. (I mentioned this earlier, I believe.) So I dunno if we reached some sort of limit on how much can be fixed/modded/added, or something else?

Here, on the third map (Pluto), AGW occurs even though there is one pollution tile (the first AGW bugs.sav file). And then it maxes out and skips all the other cycles (the second AGW bugs.sav file).

Click to expand...

There could well be other bugs left in the AGW code. I'll look into it after the 0.5 release, which I'm hoping to finish by the end of the week.

PlutonianEmpire said:

Finally, I noticed that when being attacked by custom nuclear units not in the default unit slot for the default Nuclear Msl., the "so and so use nuclear weapons!" dialog doesn't pop up. Can anyone confirm or refute?

Click to expand...

As long as the custom unit has an attacking power of 99 or greater, the game will treat it as a nuclear weapon, including showing the associated dialogs. These dialogs are only shown to human players, obviously .

I've finished version 0.5. Here are the changes:

• Fix for unit selection in the city screen, only the first 16 units could ever be selected.
• Fix for unit disband option in the support box of the city screen, which allowed disbanding of non-disbandable units.
• Fix for the teleporter city improvement, cities on maps a unit is prohibited from entering will not show up in the list anymore with this patch enabled.
• Added a @FERTILITY section to RULES.TXT where you can choose the terrain types the AI will settle.
• Two additions to @COSMIC2:
  • No stack kills: Configurable stack kill mechanics.
  • Mountain height: Configurable mountain height of 32, 48 or 64 pixels for each map.

Detailed information about the patches is available in the launcher. For an overview of all patches, see the included README.txt. Happy gaming!

Great news -- especially the stack kill mechanic! -Someone ought to make a Reddit thread about this, to gain more exposure. Not sure how many people have ToT though. Also, imo you should change your nick to TheAwesomeOne, as it's well warranted.

No suggestions this time, as I'm on a camping trip atm. I will spend July ei n Norway, but after that maybe I'll finally start making use of all the great improvements that you've offered. Imagine if they'd released the game in this state... *passes out from excitement*

TheNamelessOne said:

I've finished version 0.5.

Click to expand...

Excellent. Thanks, too - given that 5 out of 6 were requests of mine. I've updated guides on my website to clean up old advice made obsolete by the ToTPP. I've also added a ToT installation guide that includes the ToTPP.

I had a chance to play around with those larger mountains: pilfered some mountains from Civ3 and ran a ton of filters over them to make them compatible with the terrain I commonly use for ToT.

Oh yes, some more lists:

ToTPP Bugs

• When the 'Override health bars' option is enabled, unit stacks are no longer indicated by overlapped shields (like the ones in the image below).
  
  
  
  On that theme, can the brightness of the darker back shield be scaled up in line with the UnitShieldColor setting, ie, lower contrast? In the screenshot above, UnitShieldColor = 28.

Feature Requests

• An option to map units available for production within a city to specific city names, or the presence of a city improvement or wonder.
• An event trigger: @IF UnitType present at Location co-ordinates @THEN... (check made during movement phase?)
• Set the default zoom level to Standard instead of 2 steps zoomed in. On a similar note, can the game be forced to load the zoom setting stored in the SAV file the first time it's loaded? The default zoom kicks in whenever you load a game for the first time after switching folders.

Can you shed any light on the use of the MoveUnit event action? It's my understanding that the MoveUnit orders can only be applied to a unit with no existing orders, ie, one that has just been created. As a result, its effectiveness is somewhat limited. Can the MoveUnit command be reapplied to units within its location boundaries, overriding existing 'go to' orders?

With the new mountain options, is it possible to make 2x2 tile or 3x3 tile large singular mountains?

Greizer85 said:

Great news -- especially the stack kill mechanic!

Click to expand...

Catfish said:

Excellent.

Click to expand...

Glad to hear you liked it!

Catfish said:

I had a chance to play around with those larger mountains: pilfered some mountains from Civ3 and ran a ton of filters over them to make them compatible with the terrain I commonly use for ToT.

Click to expand...

Sure looks a lot better like that. Any chance you could upload that TERRAIN2.BMP somewhere?

Catfish said:

When the 'Override health bars' option is enabled, unit stacks are no longer indicated by overlapped shields (like the ones in the image below).

Click to expand...

Ah yes, I thought that might have been the case. I'll look into it.

Catfish said:

An option to map units available for production within a city to specific city names, or the presence of a city improvement or wonder.

Click to expand...

There's a single function to determine whether tribe x can build unit y in city z, so it is not impossible. But available units for AI controlled cities are slightly different from those for human controlled cities (basically only the best unit for a particular role is available), I'd have to see if it would work together with that.

Catfish said:

An event trigger: @IF UnitType present at Location co-ordinates @THEN... (check made during movement phase?)

Click to expand...

I might do something with new events in the near future. But in the current event structure there's not a lot of space left and many fields are already used for multiple purposes (exactly the reason why some actions cannot be combined). I've just made the event heap size allocation configurable last week (for 0.6, EventHeapSize in @COSMIC2), so now I can make some serious changes. I'd like to add some proper scripting stuff, getting/setting of variables, comparisons, arithmetic, etc., things that I feel are sorely lacking in the current implementation (there's really only CHECKFLAG/FLAG).

Catfish said:

Set the default zoom level to Standard instead of 2 steps zoomed in. On a similar note, can the game be forced to load the zoom setting stored in the SAV file the first time it's loaded? The default zoom kicks in whenever you load a game for the first time after switching folders.

Click to expand...

Every time I load a save the first thing I do is press Shift-Z, and every time I think, "yeah, I should totally fix that". So I'll put it at the top of my list.

Catfish said:

Can you shed any light on the use of the MoveUnit event action? It's my understanding that the MoveUnit orders can only be applied to a unit with no existing orders, ie, one that has just been created. As a result, its effectiveness is somewhat limited. Can the MoveUnit command be reapplied to units within its location boundaries, overriding existing 'go to' orders?

Click to expand...

The documentation in MACRO.TXT states:

The program only activates units that are (1) not fortified, (2) not on sentry duty, (3) not already headed for a destination, (4) not building fortifications, and (5) not nuclear weapons.

Click to expand...

Let's go through these statements and I'll say whether they are true or false.

1. not fortified: false, no such check is done. Fortified units are moved just fine.
2. not on sentry duty: true, a check for unit order 3 is made.
3. not already headed for a destination: true, but only by virtue of the next item.
4. not building fortifications: true, but not just that. All orders above 4 (Build fortress) as well are checked as well, and the unit is not moved in any case. So the Goto order is handled by this case, not the previous.
5. not nuclear weapons: true, it checks if the attack power of the unit is >= 99.

So, the documentation is somewhat lacking concerning the affected unit orders. Only units with order values <= 2 are moved.

BTW, have you ever been able to get a MoveUnit action with a unit parameter of anything other than AnyUnit to work? Probably not, the value is checked against the unit ID instead of the unit type ID, so it will never work (unless in very serendipitous circumstances). I'll fix this.

PlutonianEmpire said:

With the new mountain options, is it possible to make 2x2 tile or 3x3 tile large singular mountains?

Click to expand...

Not without sacrificing 4 or 9 of the mountain slots. I thought Catfish posted about this a while back, didn't he?

TheNamelessOne said:

Sure looks a lot better like that. Any chance you could upload that TERRAIN2.BMP somewhere?

Click to expand...

Yep. Tweaked them a little: darkest shadows aren't black any more, dithered the foothills and shifted hues a tad for better blending. Included Terrain1.bmp because I increased the colour saturation of the mountain base tile - these mountains have grassier foothills. Good enough for now.

TheNamelessOne said:

I've just made the event heap size allocation configurable last week (for 0.6, EventHeapSize in @COSMIC2), so now I can make some serious changes. I'd like to add some proper scripting stuff, getting/setting of variables, comparisons, arithmetic, etc., things that I feel are sorely lacking in the current implementation (there's really only CHECKFLAG/FLAG).

Click to expand...

That'll be interesting.

TheNamelessOne said:

BTW, have you ever been able to get a MoveUnit action with a unit parameter of anything other than AnyUnit to work? Probably not, the value is checked against the unit ID instead of the unit type ID, so it will never work (unless in very serendipitous circumstances).

Click to expand...

I'm pretty rusty on this stuff, but IIRC, the answer is no. I checked my WotR scenario (which accounted for most of my MoveUnit testing); they're all AnyUnit events and I'm pretty sure I tested MoveUnit with specific unit types at some point. Thanks for the info.

One thing I've noticed, is that cities defended entirely by units that can't be bribed, can still be subverted and incited for revolts. Is this a bug of the game, or a part of the game's design?

And feature request: Might it be possible to modify that animated globe in the ToT map view so that all the maps are correctly wrapped to a sphere? Personally, especially when playing on maps that appear equi-rectangular in the game (such as 100x100), seeing a whole hemisphere and 75% of the other hemisphere at the same time has always kinda bugged me. The same issue affects the world maps in Civ 4, which is one of many reasons I avoid that game.

Later Edit: Also, I've noticed an issue with map wrapping on round maps. A city on one side of the "International Date Line" of the map can take and use a tile for resource on the other side of the "IDL" even though another city on that other side is already using it. I take it this is a known bug?

I've completed version 0.6. I'm releasing somewhat sooner than planned, but because of major changes to memory allocation I figured you all could help me test it. Here's the changelog:

• Fix for the MoveUnit event: Allows a unit type name as the "unit" parameter of the MoveUnit event action, as was intended according to the documentation.
• Fix for looping resource animations: Fixes a bug where the last frame of a looping resource animation would be rendered even when animated resources were disabled.
• Fix for resetting city names between games: Resets the city name counter when a new human-controlled civ is created.
• Fix for city working tiles: Fixes a bug where cities on opposite sides of the International Date Line (x-coordinate 0) could both work the same tiles.
• Added a second parameter to the UnitShieldColor key of the Shield colors patch, to set the color of the background shield used to indicate unit stacks.
• Rewrote memory allocation to allow patches to use heap functions, replacing the obsolete Global functions.
• The city & unit limit patch now uses growable heaps (i.e. memory is allocated on the fly when needed) for the "Find City", "Supply & Demand", "Airlift", and "Transporter" dialogs, preventing crashes when playing with very large numbers of cities.
• For @COSMIC2:
  • Event heap: More (or less) memory for events. By default it uses a growable heap, making event memory unlimited for all intents and purposes.

Also two bug fixes:

• Fixed a bug in the Custom resources patch where saving the game didn't restore the current map index correctly.
• Fixed a bug in the Override health bars patch where the overlapping shields indicating unit stacks didn't show up.

Detailed information about the patches is available in the launcher. For an overview of all patches, see the included README.txt. Happy gaming!

TheNamelessOne said:

I've completed version 0.6.

Click to expand...

TheNamelessOne said:

Fix for resetting city names between games: Resets the city name counter when a new human-controlled civ is created.

Click to expand...

That can be annoying at times.

TheNamelessOne said:

Event heap: More (or less) memory for events. By default it uses a growable heap, making event memory unlimited for all intents and purposes.

Click to expand...

Awesome. A major feature for scenario designers.

I've got an issue here. For some reason, native map transport just isn't working right for one of my air units. Specifically, a "P 717-200", a settler unit, meant to be a domain 3 unit, was given native map transport via events.txt. The problem is, I just can't get it to natively transport from map 0 to any of the other maps, even though it is a domain 3 unit, and tile it is on is a land tile on all 4 maps. Similar issue with ocean tiles on all 4 maps. Strangely, if I send it to the top map via a city's spaceport improvement, and I put it on most tiles, it'll natively transport normally, but when I transport it to map 0, all native ability fails again and I have to go back to a city with a spaceport.

And yes, I changed it to an air domain unit, with any range at all, the problem persisted. Is this fixable at all?

It's caused by the flag for map 1 (first secondary map) in column B (@UNITS_ADVANCED), ie, cannot build unit on map 1. The info on my FAQ page is incorrect. If flag 1, column B, is set, then native transport from map 0 is blocked. If flag 0, column B, is set, then native transport from maps 1-3 is blocked. Will investigate further. Another fix for TheNamelessOne?

PlutonianEmpire said:

I've got an issue here. For some reason, native map transport just isn't working right for one of my air units. Specifically, a "P 717-200", a settler unit, meant to be a domain 3 unit, was given native map transport via events.txt. The problem is, I just can't get it to natively transport from map 0 to any of the other maps, even though it is a domain 3 unit, and tile it is on is a land tile on all 4 maps. Similar issue with ocean tiles on all 4 maps. Strangely, if I send it to the top map via a city's spaceport improvement, and I put it on most tiles, it'll natively transport normally, but when I transport it to map 0, all native ability fails again and I have to go back to a city with a spaceport.

And yes, I changed it to an air domain unit, with any range at all, the problem persisted. Is this fixable at all?

Click to expand...

There are two separate bugs at work here. The first occurs when checking if native transport is possible at all. If any transport relationship with a map where the unit is not allowed is encountered and the unit is currently on the other map of the relationship, then all subsequent relationships are also disallowed (a variable is not properly reset). Because the 0-1 transport relationship is encountered first in your game, and map 1 is disallowed, all maps will be disallowed when transporting from map 0, disabling native transport completely.

The second is that the NATIVETRANSPORT dialog completely ignores the "disallowed on map" setting from @UNITS_ADVANCED. So here the problem is that if any map is allowed, all maps are allowed.

Both bugs will be fixed in 0.7.

TOTPP doesn't do anything when I click on it, and I've installed it in the directory...