[TOT] The Test Of Time Patch Project

In the other news, I'll probably release 0.3 in a few days. No big new features, but it fixes a couple of significant bugs in the game:
  • A proper fix for AI hostility. Sometimes the attitude modifier wasn't initialized properly, so it was using large random values, leading to the worst possible attitude.
  • Fixed the rule 2 restrictions in @LEADERS2 so that forbidden technologies cannot be stolen. Caused by the game doing the check for the wrong tech.
  • Fixed the movement rate listed for units in the Civilopedia so it respects the cosmic road multiplier. Replaced a hard-coded division by 3 with a division by the road multiplier.
  • Non-transformable terrain could be transformed into a weird, undefined terrain type using the O-key. This was already fixed by the "Transform requires tech" patch, but I'll split it in two, a bug fix and a feature patch.
  • Multiplayer Build World phase + CPU fix hangs the game. Fixed by not yielding during network polling.

Interesting observation. I have never played TOT, but in many games of regular Civ2 I have not noticed that. In my current game, GOTM 152, Russians and Chinese could expand by either going east or west and both chose west. I will try to remember to keep an eye on this.

Your observation makes perfect sense from an algorithmic point of view though. The AI has to pick a direction to expand in first and rather than picking one randomly the order is hard coded.
It might be a westerly direction; it's been a while since I played civ regularly and I just got back into it, so I don't remember exactly.

And the terrain part in the previous quote box, I've noticed that in MGE at least, hitting transform again on the weirded out terrain undoes it, but with a side-effect of adding a river tile to it. At first, I was like "wtf", but considering I've tweaked the rules in some of my scenarios to allow terrain transforms to go full circle with specific combinations of all three transform methods (mining, irrigation and transform; and leaving room for farmable and/or minable lands of course), I realized I could exploit this bug for full-scale, in-game geo-engineering, literally reshaping entire planets -- including coastlines and rivers! Sadly, I think it results in an entirely new bug -- river tiles floating on top of ocean tiles. Slightly annoying, yeah, but also a little bit funny. :lol:
 
Could you explain the purpose of this? Are you talking about the tiles in Terrain2.bmp or those affected by @TERRAIN2 in the rules?
The bitmap. It's for purely aesthetic reasons, mainly to increase mountain relief.

Excellent work on the path finding and health bars. I won't add to your list today. ;)

Interesting observation. I have never played TOT, but in many games of regular Civ2 I have not noticed that.
AFAIK, AI for ToT's standard game is the same as MGE. I've never noticed it either, but I've mostly played scenarios with pre-existing cities. Ran a half-dozen 7-AI-tribe-zero-ocean test games and I can't pick any directional patterns.

And the terrain part in the previous quote box, I've noticed that in MGE at least, hitting transform again on the weirded out terrain undoes it, but with a side-effect of adding a river tile to it.
See post #7 of this thread.

@boccio:

Use for non-commercial purposes is fine. In this community attribution is considered polite. Distribution with licences that run contrary to these is not fine.
 
One thing I've noticed in regards to AI behavior, is that it seems to have a preference for building their cities in a mainly easterly direction; an issue especially apparent on land-dominated maps, and it is true in almost every game I play, both ToT and MGE. And as far as I can tell, the AI doesn't seem to care much about their western parts until they're blocked by either other civs or terrain. Might this be fixable?

Edit: another AI habit I've noticed is that the AI, after a while, sets the production orders of every single one of their cities to (capitalization), even if they have a pitiful army.

I'd love to make some improvements to the AI, but unfortunately this is one of the hardest parts of the game to make changes to, mostly because you can't easily observe the effects of such changes. At least not without playing through a large part of the game, which would take a lot of time. Maybe in a later stage of the project, when I've analyzed more of the game's code.

The bitmap. It's for purely aesthetic reasons, mainly to increase mountain relief.

Ah, I see now. There's not a lot of pixels for some proper peaks indeed. ;)

Something else that will make it in 0.4:

COSMIC2: Extra cosmic parameters (goes into RULES.TXT) to configure previously hard-coded parameters on a per-scenario basis. Example:
Code:
@COSMIC2
TradeGoldMultiplier, 50
TradeScienceMultiplier, 50
FortifyDefense, 3
FortressDefense, 4
CityWallsDefense, 6
CityPopulationLossAttack, 1
CityPopulationLossCapture, 2

Unlike @COSMIC, it's a collection of key, value pairs (because you can enable/disable specific patches, a particular order wouldn't work), terminated by a blank line. The keys so far are:
  • TradeGoldMultiplier & TradeScienceMultiplier: A percentage applied to the gold/science revenue when a trade route is created. So at 50, revenues are halved. Defaults to 100.
  • FortifyDefense, FortressDefense & CityWallsDefense: The defense bonus for fortified units, fortresses and city walls, respectively. Like terrain defense bonuses, multiply by 50% to get the percentage of the normal defense value a unit defends with. E.g. 3 * 50% = 150% defense bonus. Defaults are 3, 4 and 6, respectively. Also, these bonuses don't stack, a fortified unit in a city with walls will only use the CityWallsDefense value (like in the unmodified game).
  • CityPopulationLossAttack & CityPopulationLossCapture: Determines if a city suffers population loss after a successful attack/capture. Valid values are 0, 1 and 2:
    0 - default, will lose population;
    1 - will not lose population;
    2 - will lose population, except when size=1 and the loss would destroy the city;
 
All your improvements sound simply amazing! I might have to get back to Civ... ;)
 
I just noticed a lolhueg 900 mb update pack in my windows update panel, likely containing stuff to prohibit memory modding like this project. I noticed it for at least my OS, win 8.1. Might it impact the project at all?

Also, have you considered pollution-killers? I know the project someone did for MGE had them, allowing the disabling of pollution from both cities and nukes, and turning off global warming as well.

And when hitting shift+c, as well as checking supply/demand for uranium, I crash to desktop; I take it that was one of the potential stability issues from high city and unit numbers? :) I use 2048 for cities and 8192 for units, since I modded the Original game to use all four map slots.

And um, when I had global warming going on, on all 4 maps, from a massive nuclear war I triggered between AI's, the base map, (map 0) when the the first GW cycle completed, it skipped all remaining cycles and went straight to the "swampworld" end-result of Civ2 AGW. Is that a ToT bug or another potential stability issue?

Anyways, I love your work on this! Awesome project indeed. :)
 
I just noticed a lolhueg 900 mb update pack in my windows update panel, likely containing stuff to prohibit memory modding like this project. I noticed it for at least my OS, win 8.1. Might it impact the project at all?

ToT with ToTPP runs fine on Windows 8 proper, I haven't tried 8.1 yet myself. I expect it to keep working just fine, but let me know if there are compatibility issues.

Also, have you considered pollution-killers? I know the project someone did for MGE had them, allowing the disabling of pollution from both cities and nukes, and turning off global warming as well.

Could be added as cosmic parameters as well. Of course, there's "Eliminate pollution" in the scenario parameters already, but that's all-or-nothing.

And when hitting shift+c, as well as checking supply/demand for uranium, I crash to desktop; I take it that was one of the potential stability issues from high city and unit numbers? :) I use 2048 for cities and 8192 for units, since I modded the Original game to use all four map slots.

That's more of a general warning than referring to anything specific. There's the potential for overflow in a few places (e.g. Defense minister statistics if you have more than 255 units of a type), so something unexpected could happen somewhere.

If you experience CTD's, make sure you're running ToTPP on ToT v1.1, without other patches. If that doesn't help, try it without running ToTPP at all. If you're sure the issue is caused by ToT v1.1 or ToTPP, please post the crash details and I might be able to pin it down.

And um, when I had global warming going on, on all 4 maps, from a massive nuclear war I triggered between AI's, the base map, (map 0) when the the first GW cycle completed, it skipped all remaining cycles and went straight to the "swampworld" end-result of Civ2 AGW. Is that a ToT bug or another potential stability issue?

Could be a bug, so if it's a reproducible situation feel free to post the details. ToTPP is about fixing bugs after all!

BTW, thanks for the kind feedback, guys! :)
 
That might be the issue then, I think I mighr have applied one of the patches, but I forget which. And the issue I had on win 8 proper was the installer failing to show up at all, when I inerted the disk for ToT 1.1. Autoplay would show, I would click install, then nothing happens for a long time, with the "preparing to install" progress bar sitting at 100%, and then just quits without doing anything.

And for global warming, I also noticed that sometimes, a map will get a ton of pollution in short order, usually from nuclear war, and the agw icon will show for a while and increase in size, but then all of a sudden, just disappears, and nothing will happen, even though the number of polluted tiles continues to skyrocket.

And I am able to recreate the shift+c CTD issue, as well as the AGW issue I just mentioned in the paragraph above, and so saved it into a zip file.
 
And I am able to recreate the shift+c CTD issue, as well as the AGW issue I just mentioned in the paragraph above, and so saved it into a zip file.

I managed to reproduce and fix both issues. The CTD is caused by the game running out of heap space after adding ~400 cities to the dialog. I've changed the heap size to scale with the number of cities in game (same issue affected the Supply/Demand dialog).

The issue with global warming skipping cycles is caused by the game checking whether adjacent tiles are ocean tiles; the higher the number of adjacent ocean tiles, the sooner the tile is changed to swamp. However, instead of looping 8 times, it loops 20 times (they probably got confused with tiles in the city radius), thereby accessing 12 invalid memory locations in the adjacency-array. The end result is that the number of ocean tiles reported is too high. After forcing global warming on your save after changing it to 8, tiles got changed to desert instead.

These fixes will go in 0.4, which I'm planning to release soon. Many thanks for reporting this, especially the dialog issues!
 
I've completed version 0.4. Here's the changelog:

  • Fix for the ModifyReputation event action to allow negative modifiers.
  • Fix for global warming skipping cycles. Caused by a missing bounds check.
  • Overridable health bars: Allows hiding of unit health bars for specific unit types by setting a flag in @UNITS
  • @COSMIC2: Extra cosmic parameters to configure previously hard-coded parameters on a per-scenario basis. Patches using this section:
    • Trade revenue: Apply a percentage to the gold/science revenue of caravans.
    • Defense bonus: Configure the defense bonuses for fortifying, fortresses and city walls.
    • City population loss: Configure whether a city suffers population loss after a successful attack/capture.
    • Unit shield colors: Make shield colors brighter / darker.
  • Fix for some dialogs (e.g. "Find City") causing a game crash when playing with large numbers of cities.
  • Improved the patch selection window, adding separators and grouping
  • The city & unit limit patch is no longer required to be enabled, and acts more like an ordinary patch now. If you're upgrading from a previous version, you'll have to enable it explicitly now.

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

Attachments

  • TOTPPv04.zip
    89.4 KB · Views: 236
Hey, I can actually fully zoom in to units with hidden health bars without them disappearing off the screen, and I can't see those health bars perched at the top of my screen any more, either. :goodjob: Damn, you've got me poking around in this game again.

FortifyDefense, FortressDefense & CityWallsDefense
Great. That nearly made it to one of my earlier request lists, but I thought I might have been getting a bit carried away and called it a night.

There are a number of other combat variables listed in Marquis de Sodaq's combat guide. Many of these values were obtained empirically from the vanilla game; there are a few minor errors here and there.

CityPopulationLossAttack & CityPopulationLossCapture
Thanks for adding that. That's a major one for the scenario designers. I like the multiple options.

Unit shield colors
And multiple brightness levels, too. I can see why.

I've, ahem, got a few more items for the lists:

ToT Bugs

  • City screen GUI. You can't select stationed units beyond the 16th in the native ToT interface or beyond the 22nd in the classic interface (City Layout toggle). The latter has no scrolling mechanism in the units box, so you can't view units beyond this limit either.
  • Hitting Ctrl+N avoids the check for ranged air units running out of fuel. [Edit: Ditto for the trireme lost at sea check.]
  • A Leonardo's Workshop unit upgrade causes a loss of veterancy. Yeah, I'd call this a bug.
  • Terrain with a 50% defensive penalty is listed as 'Normal' under 'Unit Defence Bonus' in the Civilopedia.

Feature Requests

  • Multiple levels of veterancy. Number and multipliers set in rules.txt.
  • Combat bonuses imparted to other units in the same tile, eg, leadership bonuses. Highest values, non-cumulative when multiple 'leaders' present.
  • The Movecost and Defence values for resources in the @TERRAIN tables (rules.txt); is it possible to force the game to read them?
  • An extra 16 pixels in height for city icons. Like the mountain thing in Terrain2.bmp.
  • An option to calculate fertility (1st 4 bits of the 6th byte for each tile in the map data), for tiles other than plains and grassland (terrain slots 2 and 3), during the world-building phase of the game.

For other ideas, there are exploits listed in ElephantU's Tips and Tricks page, eg, Oedo years, black clicking, precharging settlers/engineers.

Great job. :bowdown: This patch doesn't get half the attention it deserves.
 
Great job indeed. :goodjob:

Now more bug reports from my end.

When running an ai-only game with my current ruleset, I've noticed that when a new tech is discovered and a civ has Leo's Workshop, some units are upgraded to a new unit that is meant for a completely different domain. An example would be a sea unit that expires on X7, and X7 contains 3 new units (one land, one sea, and one air), and instead of being upgraded to X7's new sea unit as one would expect, it is instead replaced by the land unit, resulting in multiple land units "sleeping" on sea tiles.

In addition, I've noticed that the list of available units to produce in a particular city shrinks if a civ is run by an AI than by a human player. Meaning, a human player can build that unit just fine, yet the AI can not, because it can't find it in the build orders list.

And additionally, if one is playing with new techs added to an existing list of techs, a research-able advance whose prerequisites have been fully acquired and said advance can be researched, but for some reason, it doesn't show up in the list at all, even though it is free to research. An example would be when transitioning into the modern era, a decent list of advances to discover is displayed on the selection dialog, and once you select one and it has been discovered, the tech selection dialog then lists only one or two advances, even though 5 or 6 are fully available.

And finally, I've noticed that units that are not allowed to be disbanded, can be disbanded via the city screen, usually through the "supported units" box.

Anyways, here's my new zip. :)
 
In addition, I've noticed that the list of available units to produce in a particular city shrinks if a civ is run by an AI than by a human player. Meaning, a human player can build that unit just fine, yet the AI can not, because it can't find it in the build orders list.
See here. It's a hack to massage the AI in the standard game into creating sensible build orders. It's a nuisance for mods and scenarios.

And additionally, if one is playing with new techs added to an existing list of techs, a research-able advance whose prerequisites have been fully acquired and said advance can be researched, but for some reason, it doesn't show up in the list at all, even though it is free to research.
See here. Is that what you're getting?

And finally, I've noticed that units that are not allowed to be disbanded, can be disbanded via the city screen, usually through the "supported units" box.
Confirmed (Support box) for both ToTPP and unpatched. I'd never noticed that before.
 
See here. It's a hack to massage the AI in the standard game into creating sensible build orders. It's a nuisance for mods and scenarios.
So, was that an error by the game designers or a deliberate thing?

See here. Is that what you're getting?
I don't know, tbh, but I'll pay closer attention to that to see if it matches.

Confirmed (Support box) for both ToTPP and unpatched. I'd never noticed that before.
I double checked to see if it appeared in the Units Present box to be sure, but the disband option was greyed out as it should be, so no issues there. :)
 
So, was that an error by the game designers or a deliberate thing?
I'm certain it's deliberate. Maybe it's a bit harsh to call it a hack, rather, a set of AI restrictions designed for the standard game, hard-coded for all game types. In any event the AI needs some method to determine which units it will build next. This, on the other hand, I definitely consider to be a hack.

You could probably say the same thing about the use of hard-coded engineer, partisan, fanatic and spy slots over unit flags. I doubt modding was first and foremost on Brian Reynolds' mind when he developed the original game.
 
True, although since we're talking about ToT, an exception could be made for Engineers, since ToT allows modders to select which units get Engineers abilities on their own. :)
 
A Leonardo's Workshop unit upgrade causes a loss of veterancy. Yeah, I'd call this a bug.

I think this is deliberate. The veterancy flag is explicitly removed during the upgrade. Even so, it could be made configurable.

The Movecost and Defence values for resources in the @TERRAIN tables (rules.txt); is it possible to force the game to read them?

Sure, the values are already parsed, they just go unused.

An option to calculate fertility (1st 4 bits of the 6th byte for each tile in the map data), for tiles other than plains and grassland (terrain slots 2 and 3), during the world-building phase of the game.

I'm pretty sure this restriction was added originally to speed up the world building process. The algorithm is pretty naive, for each tile calculating fertility scores from the 20 adjacent city-radius tiles. Should be no problem for modern computers though.
BTW, there's a hard-coded override for these terrain types: if the game type is Fantasy, the fertile terrain types are 3 and 5 for map 2, and 3, 4 and 5 for map 3. So even the ToT developers ran into this restriction.

PlutonianEmpire said:
And finally, I've noticed that units that are not allowed to be disbanded, can be disbanded via the city screen, usually through the "supported units" box.

Indeed. Consider it fixed in 0.5 :)
 
I think this is deliberate. The veterancy flag is explicitly removed during the upgrade. Even so, it could be made configurable.
Ahah. Sometimes it can almost be a disadvantage to receive the upgrade.

I'm pretty sure this restriction was added originally to speed up the world building process. The algorithm is pretty naive, for each tile calculating fertility scores from the 20 adjacent city-radius tiles. Should be no problem for modern computers though.
That reminds me, fertility is also recalculated during the game, for example when a city is created or destroyed. It appears to operate under the following rule:

Catfish said:
For each tile within a city's 45-tile zone:

City Created: If Fertility > 7 then Fertility = Fertility – 8, else Fertility = Fertility
City Destroyed: If Fertility < 8 then Fertility = Fertility + 8, else Fertility = Fertility

It explains why when two or more cities have overlapping zones, the tiles within the region of overlap are not devalued more than once. It produces an absurd situation when you have two or more cities with overlapping zones and one of them is destroyed.

 
Long time since I've logged on here; seems the project is proceeding nicely. :) Those city-wall and fortress fixes will be a god-send for my scenario project, if I'll ever manage to continue it (got sidetracked by rl issues and then my interest kinda waned for now).

I can't remember if I mentioned it before, but is it possible to make it so that only one unit dies when a stack of units is attacked (and the defender is defeated)? It would save me a lot of trouble placing invisible fortresses, and would be an overall convenience for many scenario makers, since stacks dying is one of the more antiquated mechanics of Civ II.

EDIT: Oh! And the placeable resources! :eek::goodjob: Major kudos on that one! Now I'm tempted to edit my world map... :mischief:

EDIT: What about the Coastal Fortress defense modifier? I can't recall what it is by default, but couldn't it be made modifiable in the same way as the one for City Walls? It's a minor inconvenience at best (especially given the farcical naval AI), but still, it'd be nice. ;)
 
Long time since I've logged on here; seems the project is proceeding nicely. :)

Welcome back, mate. It's proceeding steadily indeed. :)

I can't remember if I mentioned it before, but is it possible to make it so that only one unit dies when a stack of units is attacked (and the defender is defeated)? It would save me a lot of trouble placing invisible fortresses, and would be an overall convenience for many scenario makers, since stacks dying is one of the more antiquated mechanics of Civ II.

I've done some work on it already. For land stacks it's working well, for ships carrying land units too (I destroy the cargo), but for submarines and carriers carrying air units it's a bit more tricky. The carrying unit is not stored with the transported units in that case (you can see that by having another carrier or sub move over a tile that has one already, it will pick up all cargo. This doesn't happen with transport ships). So I don't know what the cargo was when a carrier or sub gets killed (assuming multiple carriers/subs in one tile). I could just leave them in the air, assume they got launched before the ship went down.

EDIT: Oh! And the placeable resources! :eek::goodjob: Major kudos on that one! Now I'm tempted to edit my world map... :mischief:

Please do, it would be great having such a map to play on!

EDIT: What about the Coastal Fortress defense modifier? I can't recall what it is by default, but couldn't it be made modifiable in the same way as the one for City Walls? It's a minor inconvenience at best (especially given the farcical naval AI), but still, it'd be nice. ;)

Shouldn't be much of a problem to add that one.

I've also been doing some work on the map rendering for 0.5. The experience should lead to 16 terrain types in the end (but just not in 0.5 yet). For now, mountains that are actually higher than the surrounding hills:
Spoiler :


Compare vanilla:
Spoiler :


I like how things get partially obscured behind the mountains, it really does add depth to the map (I just stretched the bitmaps in terrain2.bmp for this screenshot, it will look even better when someone creates proper 48 pixel mountain bitmaps (Catfish? :mischief:))
 

Attachments

  • mountains48.jpg
    mountains48.jpg
    46.6 KB · Views: 946
  • mountains32.jpg
    mountains32.jpg
    45.9 KB · Views: 880
Top Bottom