"Scrolling" tech trees

[Shadowstrike]

This is an ida I've been thinking about for the last couple weeks. Consider the following:

You want to make a vast, and historically accurate scenario of a portion of the world. The number of unit slots would not suffice so multiple rules fules are in order. But what happens if you run out of advance slots? Then you have a problem. Here's where the "scrolling tech tree" comes in. You could have periods each using aboubt half the tech slots. Research ends when you end one period. Then, you load the other period and all the units have become long obsolete.
When that period is done you load the next period which uses the same slots at the first periods's.

But wouldn't you already have those techs? I hear the crowds asking. Well, no, because of a bunch of well placed TakeTechnology events. (only availible in TOT if my memory doesn't fail me) Then, you can scroll back and forth, as many times as you want and allowing nearly infinate technologies. Of course, you would have to keep one advance to hold all the previously allowed improvements and the ones with build orders also have to be held over to avoid the problematic "settler memory loss" problem.

Of course, this assumes that you'll run out of technology slots, which is not very likely.

Does this system work? Has anyone proposed it before? Will it work well in a scenario?

[Shadowstrike]

Oh, by the way, your free to use this idea in any new scenario, mine won't be coming out anytime soon.

[DarthVeda]

It's an idea I've had before but it's never been very useful.

[Michael Daumen]

Each time you did a taketechnology event you would have to make sure rules.txt is edited to remove the techs you want to replace. Interesting. It would probably work best with a bunch of techs that everyone has at the start, so that no one falls "ahead" when the change is made. And then use some checkflags to tell you when to change files after every nation has the right techs. Just when I thought ToT was good for one thing.
[This message has been edited by Michael Daumen (edited July 20, 2000).]