Best practice: Adding new technologies to prerequisites

[Pi-C]

This is not about how to set a new technology as prerequisite to another, but about what happens after this. Say, I have added a new technology A to the prerequisites of technology B, so B can only be researched after A. No problem if you start a new game -- everything will be fine then. But suppose my mod is loaded into an existing game where B already has been researched: A is new, so hasn't been researched yet, so B shouldn't be available.

Again, no problem. I just add a migration script where I set "B.researched = false". But what if B is a prerequisite of yet another technology, C? If I've disabled B, the requirements for C aren't met and it shouldn't be available. So what's the best way to handle such cases?

I could ignore them, but this would look very strange, especially in upgrade chains (e.g. if "electric-energy-distribution-2" is available although "electric-energy-distribution-1" has been disabled). I could also traverse the complete technology tree and disable every tech with unresearched prerequisites. That would probably make me the most hated modder ever because I guess it would take some time until every technology has been checked -- and if my tech A should be an early technology (how about adding a prerequisite to automation-1?), running the migration could disable most of the already researched techs (think of a mega base where everything but infinite techs has been researched ages ago, until my mod was added).
(Apart from that: it's easy to go down the technology tree by looking for prerequisites of tech A, but there's no easy way to go up and find the mods that depend on A. I suppose there may be a reason for it …)

So, is there any recommended procedure?

[Solinya]

This is not about how to set a new technology as prerequisite to another, but about what happens after this. Say, I have added a new technology A to the prerequisites of technology B, so B can only be researched after A. No problem if you start a new game -- everything will be fine then. But suppose my mod is loaded into an existing game where B already has been researched: A is new, so hasn't been researched yet, so B shouldn't be available.

Again, no problem. I just add a migration script where I set "B.researched = false". But what if B is a prerequisite of yet another technology, C? If I've disabled B, the requirements for C aren't met and it shouldn't be available. So what's the best way to handle such cases?

I could ignore them, but this would look very strange, especially in upgrade chains (e.g. if "electric-energy-distribution-2" is available although "electric-energy-distribution-1" has been disabled). I could also traverse the complete technology tree and disable every tech with unresearched prerequisites. That would probably make me the most hated modder ever because I guess it would take some time until every technology has been checked -- and if my tech A should be an early technology (how about adding a prerequisite to automation-1?), running the migration could disable most of the already researched techs (think of a mega base where everything but infinite techs has been researched ages ago, until my mod was added).
(Apart from that: it's easy to go down the technology tree by looking for prerequisites of tech A, but there's no easy way to go up and find the mods that depend on A. I suppose there may be a reason for it …)

So, is there any recommended procedure?

It's not really clean to load in new data mods into an existing game, but people try anyway.

What I've seen other mods do is they would add A but leave B already researched (even if it means C is also available for research). It looks a little odd on the technology screen to run around and pick up a bunch of lower tier tech, but it doesn't take away something the player has already unlocked. Even if your mod modifies the recipes B unlocks, that's still OK - the player can figure it out and just research A to get the required intermediate recipes. But I don't think you should disable B unless you're completely replacing it or removing it. Undoing progress sucks, and what happens if they already have things built from B?

[Pi-C]

It's not really clean to load in new data mods into an existing game, but people try anyway.

Sometimes it's the only way to get to play with new mods. I'm already >350 hours into my current game and haven't even researched lasers yet, so you can imagine how long it will take me before I can make a fresh start.

What I've seen other mods do is they would add A but leave B already researched (even if it means C is also available for research). It looks a little odd on the technology screen to run around and pick up a bunch of lower tier tech, but it doesn't take away something the player has already unlocked. Even if your mod modifies the recipes B unlocks, that's still OK - the player can figure it out and just research A to get the required intermediate recipes. But I don't think you should disable B unless you're completely replacing it or removing it.

It's not only the intermediate recipes I care about, but also the technology unlocks. It doesn't make much sense to unlock a recipe for something that you can't produce yet because you can't make something of its intermediates yet, so I usually add A to the prerequisites of B if A is needed to make one of the recipes unlocked by B. (Same thing for other effects: Why should you get bonuses for rocket shooting speed if you don't even have the rocket launcher yet, for example? )

Aside from that, ignoring the gaps in the research tree is probably the right way to go. Such gaps aren't nice, but having to deal with that certainly is cheaper than ruining the complete factory. However, I probably should still reset the technologies I've added unlock effects to, or they wouldn't be available at all if the tech already has been researched -- right?

Undoing progress sucks, and what happens if they already have things built from B?

That's exactly what my extreme example of adding a prerequisite to automation-1 was about.

[Solinya]

What I've seen other mods do is they would add A but leave B already researched (even if it means C is also available for research). It looks a little odd on the technology screen to run around and pick up a bunch of lower tier tech, but it doesn't take away something the player has already unlocked. Even if your mod modifies the recipes B unlocks, that's still OK - the player can figure it out and just research A to get the required intermediate recipes. But I don't think you should disable B unless you're completely replacing it or removing it.

It's not only the intermediate recipes I care about, but also the technology unlocks. It doesn't make much sense to unlock a recipe for something that you can't produce yet because you can't make something of its intermediates yet, so I usually add A to the prerequisites of B if A is needed to make one of the recipes unlocked by B. (Same thing for other effects: Why should you get bonuses for rocket shooting speed if you don't even have the rocket launcher yet, for example? )

Aside from that, ignoring the gaps in the research tree is probably the right way to go. Such gaps aren't nice, but having to deal with that certainly is cheaper than ruining the complete factory. However, I probably should still reset the technologies I've added unlock effects to, or they wouldn't be available at all if the tech already has been researched -- right?

My personal opinion is adding a mod that changes prototype data to an existing save should be considered "best effort". It won't be perfectly clean, nor should it be expected to be clean, as there's so much a mod migration would have to take into account - and even then, migration scripts have limitations.

So as a player, if I had +10% rocket shooting speed but not the ability to make rockets after applying a mod mid-game, well, that's weird, but also because I applied a mod in the middle of a game, and I should be expecting weird side-effects if I do that. If I start a new game, the progression should make more sense.

The last question, I'm less sure about. I think I've seen mods reset that tech, and other mods where a migration script or even just a technology prototype update handled it just fine. For example, when the logistic system changed in 0.18.13, I had to add the new system bonuses to a custom tech in a mod I was using, and the save game where I had already researched that tech picked up the character slot unlocks without any migration script work. So the answer might be more specific to your particular situation.

I think if technology B unlocks an item, building, or system that the player could use before applying your mod, and your mod keeps that and maybe changes the recipe or adds additional items/buildings/systems to technology B, I would keep B researched and make sure the extra unlocks are applied to the existing save. If your mod completely changes what B unlocks, then it may make more sense to reset B.

[Pi-C]

Aside from that, ignoring the gaps in the research tree is probably the right way to go. Such gaps aren't nice, but having to deal with that certainly is cheaper than ruining the complete factory. However, I probably should still reset the technologies I've added unlock effects to, or they wouldn't be available at all if the tech already has been researched -- right?

I think if technology B unlocks an item, building, or system that the player could use before applying your mod, and your mod keeps that and maybe changes the recipe or adds additional items/buildings/systems to technology B, I would keep B researched and make sure the extra unlocks are applied to the existing save. If your mod completely changes what B unlocks, then it may make more sense to reset B.

I guess we actually mean the same thing here, "reset B" probably wasn't the best term to use, though. This should make it more clear:

Code: Select all

if B.researched then
	B.researched = false
	B.researched = true
end

According to the Lua API description, this would toggle all unlocks (and make sure newly added unlocks are unlocked as well). There also is technology.reload() which may have the same effect, but toggling just the one thing I care about (the research status + unlocks) seems more appropriate than reloading everything.