[TOT] The Test Of Time Patch Project

Hi, can someone double check that last zip I uploaded? When I mentioned the sneaky enable technology event, I noticed there was just one action for just one tech. Yet somehow, enabling just that one tech (tech id 63; chronoscpters, aka Plumbing, or Plu), it enabled all of the advances in its branch, both the techs before and after Plu in the tree. Is this normal or a bug?
 
I can't get the extra terrains to work. THe first change needed, if I understand correctly, is to add aline to @COSMIC2 in tules.txt. ShHould I create this line in the rules.txt? I can't find the you're referencing.
 
What the HELL is THIS?! An undreamt and unbelievable breakthrough!

Now I'm so excited, I have to post even before trying out that Patch. And as you can see it's only my ninth post in two years. I don't do it often but now I feel I simply have to.

I have to admit I've been always turned off by TOT because of the non-blinking units. I know the heaven-sent but nameless one thinks it's only of minor priority, but for most of those who still stick to MGE it's one of the main reasons to do so.

These are my suggestions to merge both versions:

1. blinking units (like in MGE)
2. acceptable fighting graphics (like in MGE)

And here are some ideas I had more than a decade ago, but I don't know how much work that means for you:

3. Is it possible to introduce a completely new unit type? Let's say workers who can't build cities. I think most people involved in creating scenarios would die for such a unit type which can repair and improve infrastructure without colonising.
4. Is it possible to increase the number of players?

Hell, I'm nervous, I have to drink a glass of wine to calm down first - before I trying out!

You're doing a great job, Nameless!
 
Hi, can someone double check that last zip I uploaded? When I mentioned the sneaky enable technology event, I noticed there was just one action for just one tech. Yet somehow, enabling just that one tech (tech id 63; chronoscpters, aka Plumbing, or Plu), it enabled all of the advances in its branch, both the techs before and after Plu in the tree. Is this normal or a bug?

This is normal. Macro.txt says this on the subject:
In rules.txt, advances are separated into modules; keep in mind that changing the permission state for any advance in a module changes the state for the entire module.

So basically, with EnableTechnology, you're setting the state for the group the advance is in. In your case Plu is in group 1 (@CIVILIZE2), and you're changing the state for the group from 2 (@LEADERS2) to 0.

I can't get the extra terrains to work. THe first change needed, if I understand correctly, is to add aline to @COSMIC2 in tules.txt. ShHould I create this line in the rules.txt? I can't find the you're referencing.

I was just being thick. Sorry!

No prob. I could imagine if the documentation were a little light. But I guess it's working for you now?

I have to admit I've been always turned off by TOT because of the non-blinking units. I know the heaven-sent but nameless one thinks it's only of minor priority, but for most of those who still stick to MGE it's one of the main reasons to do so.

These are my suggestions to merge both versions:

1. blinking units (like in MGE)
2. acceptable fighting graphics (like in MGE)

I'll see what I can do. I might up the priority a notch. ;)

3. Is it possible to introduce a completely new unit type? Let's say workers who can't build cities. I think most people involved in creating scenarios would die for such a unit type which can repair and improve infrastructure without colonising.

Catfish requested something similar:
Add a unit flag in rules.txt that prevents a role 5 unit (settler) from founding cities. Or unit flags which assign various settler/engineer abilities to non-settler/engineer units, ie, irrigating, mining, terrain transformation, and road, fortress, airbase and transporter building.

Though it would be problematic for the AI to use such a unit, it looks like.

4. Is it possible to increase the number of players?

Not without rewriting the entire game, and I only had that planned for next month. :rolleyes:
 
With 16 terrain types, I hope? ;)
I'm keeping that mod classic Civ2 purist-friendly, so I'm afraid it's graphics-only.

They don't, they're leftovers from older versions. In ToT, these are read from HICOLOR.BMP. "Mouse" is used to convert screen coordinates to tile coordinates (e.g. when clicking on a tile), "Mouse2" is used to show the cursor arrows when "Move units w/ mouse" is enabled. I think you can override them by putting HICOLOR.BMP in a subfolder, but there's no real point in that.
Yeah, I figured they were probably defunct vestiges. Thanks for the explanation.

0.8 is ready. Here's the changelog:
Thanks again for those.

Hi, can someone double check that last zip I uploaded? When I mentioned the sneaky enable technology event, I noticed there was just one action for just one tech. Yet somehow, enabling just that one tech (tech id 63; chronoscpters, aka Plumbing, or Plu), it enabled all of the advances in its branch, both the techs before and after Plu in the tree. Is this normal or a bug?
Restricting Technologies - A Guide to Using CIVILIZE2, LEADERS2 and EnableTechnology
 
Some new ideas:
- It would be great if you could raze/evacuate your city, so that they don't get conquered.
- Thinking about new unit types - what about diplomats/spies that can't bribe (flag) cities?
- Barbarians shouldn't ask for money to spare a defenseless cities, just conquer it.

I thought the barbarian city bribe was random. You can refuse to pay, and that does the same thing you want.
 
Not sure if it has been brought up or already made aware of, but when enabling the flags for water units to traverse rivers, it also enables the "hidden/invisible until attack flag".

Speaking of which, I have also noticed that units that don't have the ability to see units with the @UNITS2 invisibility flag, can still attack such units. In my " PlutoRising" scenario, for example, I recently added random generation of Barbarian Tornado and Winter Storm units to events.txt, among others, and it seems kinda silly to see stealth fighters attacking weather phenomena. Perhaps a flag could be added somewhere or a new @COSMIC2 setting could be made to give the player a degree of control of some sort regarding this?

Ah, I completely forgot about that page. Bookmarked so I don't forget again. :)
 
Not sure if it has been brought up or already made aware of, but when enabling the flags for water units to traverse rivers, it also enables the "hidden/invisible until attack flag".

Can't seem to reproduce, what are the exact conditions?

Speaking of which, I have also noticed that units that don't have the ability to see units with the @UNITS2 invisibility flag, can still attack such units.

Yes, if they happen upon the square they can indeed attack such units. I don't think that's a bug.

Finally pulled my finger out and uploaded the new version.

:goodjob:

Out of curiosity, did you add all those keys to @COSMIC2 because you're still getting interference from other rules files? Just adding
MountainHeight, 48
NoStackKills, 1
should be sufficient (at least that was my intention), all the others fall back to their default values. Let me know if there's still a bug there.
 
Out of curiosity, did you add all those keys to @COSMIC2 because you're still getting interference from other rules files? Just adding
MountainHeight, 48
NoStackKills, 1
should be sufficient (at least that was my intention), all the others fall back to their default values. Let me know if there's still a bug there.
No, it's there for ease of editing and testing. Note that the hidden health bar bit, unused in the Original game, is also present in the @UNITS table. I don't recall encountering any instances of the Original game failing to load the defaults. With version 0.8, I get the @COSMIC2 values from the Original game overriding the defaults for scenarios that are based on the Original game, ie, where SAV/SCN offset 0x3D6 = 0. This seems dependent on whether the line, @COSMIC2, is present in the rules files. If it's not, as is the case for nearly all older scenarios, the @COSMIC2 parameters from the Original game are loaded. If it's there, then the defaults are loaded.
 
No, it's there for ease of editing and testing. Note that the hidden health bar bit, unused in the Original game, is also present in the @UNITS table. I don't recall encountering any instances of the Original game failing to load the defaults. With version 0.8, I get the @COSMIC2 values from the Original game overriding the defaults for scenarios that are based on the Original game, ie, where SAV/SCN offset 0x3D6 = 0. This seems dependent on whether the line, @COSMIC2, is present in the rules files. If it's not, as is the case for nearly all older scenarios, the @COSMIC2 parameters from the Original game are loaded. If it's there, then the defaults are loaded.

That's behaving as expected then, the other sections also fall back to the rules from the base game, and I'm using the same function. I realize that in this case it makes less sense, since older scenarios won't have it, as you said. Though it does make sense for the MountainHeight setting, since terrain bitmaps are inherited as well.

I'm planning to move the MountainHeight patch into the more general terrain overlays patch anyway, at that time I'll also change the @COSMIC2 inheritance.

Other things I'm working on for the next release:
  • Fix for the "end player turn" not updating remaining units;
  • City improvement flags;
  • Active unit indicators, including blinking units as in MGE;
  • Combat animations as in MGE;
  • An option to disable incremental rush buying, locking the order for the remainder of the turn after the first time
 
That's behaving as expected then, the other sections also fall back to the rules from the base game, and I'm using the same function. I realize that in this case it makes less sense, since older scenarios won't have it, as you said. Though it does make sense for the MountainHeight setting, since terrain bitmaps are inherited as well.
That works correctly when the scenario has no Terrain2.bmp file, but most do have one (with 64x32 mountains). That produces graphical artefacts if the Original game has been modified and its value deviates from the default.

I'm planning to move the MountainHeight patch into the more general terrain overlays patch anyway, at that time I'll also change the @COSMIC2 inheritance.
OK, I'll wait and see how that plays out.

Speaking of graphical artefacts, I was reminded of a few when updating scenarios to the ToTPP:

1. Overloaded Civilopedia

Spoiler :
This looks a bit of a mess. Vertical scroll bar?

2. Defence Minister + Long Unit Names

Spoiler :
Names run into the stats.

3. Irrigation Overlays Rivers

Spoiler :
Can you change the order of superimposition for irrigation and rivers? They got farmland right.

  • City improvement flags;
:goodjob:
 

Attachments

  • ToT_Civilopedia_Window_Overload.png
    ToT_Civilopedia_Window_Overload.png
    81.8 KB · Views: 489
  • ToT_Defence_Minister_Long_Names.png
    ToT_Defence_Minister_Long_Names.png
    122.6 KB · Views: 538
  • ToT_Irrigation_Farmland.png
    ToT_Irrigation_Farmland.png
    101.6 KB · Views: 499
Okay, I just noticed a blatant violation of the forbidden map rules during gameplay. I caught the AI using a unit on map 0 that was not allowed on map zero; including having no ability of its own to use transport links for maps other than the two other maps it is allowed on (map 1 and map 2, using just a single 1 bit under column E in @units_advanced). I caught the Russians using a LO troopers to capture a city (Depthenia, on the Northwestern quadrant of the map), even though it had been prohibited from map 0 the entire duration of the game, unless I missed something.

And yes, the check map transport fix is selected in the launcher.

Edit: And numerous turns prior to that autosave, the Russians were spawned by the Americans losing their capital. I don't know if that may have contributed to this issue. :dunno:

Can't seem to reproduce, what are the exact conditions?
Aha! I figured it out. :) The text on the description box when "Navigable Rivers" is highlighted, says to add a 1 on the rightmost bit of the G column, so when I did that, I got a unit with the Invisible flag, but I already had a one on the leftmost bit under G, to cancel out the sprites, which was the real trigger for Navigable Rivers. I figured it out when a unit without sprite cancellation was given a bit on the far right wasn't going up rivers. So the ToTPP launch box should probably be rewritten to say to add the leftmost bit under G, rather than the rightmost. You'll see what I mean in the zip that I'm uploading for different reasons.

Yes, if they happen upon the square they can indeed attack such units. I don't think that's a bug.
Good to know; thanks! :)
 

Attachments

  • blatant_violation.zip
    173.4 KB · Views: 160
The text on the description box when "Navigable Rivers" is highlighted, says to add a 1 on the rightmost bit of the G column...
From the ToTPP Launcher:
Allows a naval unit to sail on rivers by setting the 9th bit (the rightmost bit is the first) of column G in @UNITS_ADVANCED to 1.
If the rightmost bit is the first, then the 9th bit must be the leftmost. It's reverse programmer notation (right to left) for all the bitmasks (note that @LEADERS2 is not a bitmask, so it reads left to right).
 
From the ToTPP Launcher:If the rightmost bit is the first, then the 9th bit must be the leftmost. It's reverse programmer notation (right to left) for all the bitmasks (note that @LEADERS2 is not a bitmask, so it reads left to right).
Indeed. Joke's on me then, again. :) Thanks. :)
 
Simply amazing TheNamelessOne. I can't wait to see scenario creators put these tools to work.

A request of my own:
Remove the character limits for describe.txt entries.
 
The patch is amazing!

Are you looking for more ideas? I don't know if its possible, but I would love to have an option to run different modpacks without overwriting the original version of the game. It would make modpacks much more usable.
 
I don't know if its possible, but I would love to have an option to run different modpacks without overwriting the original version of the game. It would make modpacks much more usable.
I'll second this one. The ability to launch custom mods (distinct from scenarios by the world-building phase) from their own folders via the @MAINMENU could prove very popular.

And I'll *cough* chime in with a few more:

Feature Requests
  • An indication somewhere in the game (eg, status bar and/or Civilopedia) that terrain has been flagged as impassable. Along similar lines, an indicator for the 'Can navigate rivers' flag for ships (Defence Minister and/or Civilopedia).
  • Pillaging control: the ability to restrict pillaging to specific units or restrict the types of pillaging.
  • 21 flag slots in Cities.bmp so that specific national/tribal flags can be used for mods (as opposed to scenarios where the tribes in play are locked).
  • Set a maximum number of attacks per turn, either globally or for individual units, to limit units with high movement rates.
  • Give wonders objective multipliers. Set in @IMPROVE?
  • Alternative media formats, eg, 24-bit colour PNGs (perhaps with with partial transparency), more modern video codec support (even official videos could be re-encoded with something more recent than the obsolete Indeo, which is no longer supported by Microsoft), better audio - better than the diabolical 8-bit, 22 kHz, PCM WAV files. I realise that this one's probably a bit out there.
  • Allow 15/16-bit (or 24-bit, see previous) colour Title pages.
  • The ability to limit the playable tribe options in the menu when starting a new scenario or mod.
  • Allow the @CITYINFO box (or similar alternative) to appear when left-clicking foreign cities, without the Trade tech requirement and its associated commodity demand list, when the Objective Victory Flag has been set. It's much easier than having to scroll through the @FINDCITY window (Shift+C) when checking objective values.
 
Top Bottom