Feature flags #555

New Issue

2025-01-29T02:52:56Z

NQNStudios commented

2025-01-29 02:52:56 +00:00

(Migrated from github.com)

Both scenarios and game builds should have a StringMap containing newly added features that they incorporate. Game builds should write this map into replays, so replays can know which features were present when the replay was made.

In a sense this is like creating an extensible, piecemeal concept of "Legacy."

Like if we ever rearrange terrains i.e. in #414, scenarios created following that change should have a file with the flag "TerrainChange414" in it. Then, fileio_scen.cpp can check each scenario it loads for that flag. If it's absent, it will swap the terrain numbers of the scenario as necessary to match the updated engine expectations.

I guess it should also theoretically not make swaps on terrain types that have been overridden from bladbase

Both scenarios and game builds should have a StringMap containing newly added features that they incorporate. Game builds should write this map into replays, so replays can know which features were present when the replay was made. In a sense this is like creating an extensible, piecemeal concept of "Legacy." Like if we ever rearrange terrains i.e. in #414, scenarios created following that change should have a file with the flag "TerrainChange414" in it. Then, `fileio_scen.cpp` can check each scenario it loads for that flag. If it's absent, it will swap the terrain numbers of the scenario as necessary to match the updated engine expectations. I guess it should also theoretically *not* make swaps on terrain types that have been overridden from bladbase

CelticMinstrel commented

2025-01-30 00:56:37 +00:00

(Migrated from github.com)

Like if we ever rearrange terrains i.e. in #414, scenarios created following that change should have a file with the flag "TerrainChange414" in it. Then, fileio_scen.cpp can check each scenario it loads for that flag. If it's absent, it will swap the terrain numbers of the scenario as necessary to match the updated engine expectations.

I guess it should also theoretically not make swaps on terrain types that have been overridden from bladbase

There's one big problem with this example: you seem to be confusing terrains with terrain graphics. It doesn't make any sense whatsoever to swap terrains, but swapping terrain graphics makes perfect sense and is already done when loading legacy scenarios.

Side note: We shouldn't use flag names like TerrainChanged414. We should use names that make sense to describe what the flag does.

> Like if we ever rearrange terrains i.e. in #414, scenarios created following that change should have a file with the flag "TerrainChange414" in it. Then, fileio_scen.cpp can check each scenario it loads for that flag. If it's absent, it will swap the terrain numbers of the scenario as necessary to match the updated engine expectations. > > I guess it should also theoretically not make swaps on terrain types that have been overridden from bladbase There's one big problem with this example: you seem to be confusing terrains with terrain graphics. It doesn't make any sense whatsoever to swap terrains, but swapping terrain _graphics_ makes perfect sense and is already done when loading legacy scenarios. Side note: We shouldn't use flag names like `TerrainChanged414`. We should use names that make sense to describe what the flag does.

NQNStudios commented

2025-01-30 01:16:16 +00:00

(Migrated from github.com)

I think we would want to change terrains in some cases, for example if you load a new-format scenario that uses old-style terrain transitions and you want to free up those 12 terrain slots per transition, you'd want to swap all occurrances of the 12 specific transition types into the 1 smart transition terrain. Then add the feature flag to the scenario so that change doesn't happen again wiping out whatever terrains you use in the fresh places.

Side note: We shouldn't use flag names like TerrainChanged414. We should use names that make sense to describe what the flag does.

Well, we could theoretically change terrains multiple times. They'd need to be disambiguated.

I think we *would* want to change terrains in some cases, for example if you load a new-format scenario that uses old-style terrain transitions and you want to free up those 12 terrain slots per transition, you'd want to swap all occurrances of the 12 specific transition types into the 1 smart transition terrain. Then add the feature flag to the scenario so that change doesn't happen again wiping out whatever terrains you use in the fresh places. > Side note: We shouldn't use flag names like TerrainChanged414. We should use names that make sense to describe what the flag does. Well, we could theoretically change terrains multiple times. They'd need to be disambiguated.

CelticMinstrel commented

2025-01-30 02:15:09 +00:00

(Migrated from github.com)

I think we would want to change terrains in some cases, for example if you load a new-format scenario that uses old-style terrain transitions and you want to free up those 12 terrain slots per transition, you'd want to swap all occurrances of the 12 specific transition types into the 1 smart transition terrain. Then add the feature flag to the scenario so that change doesn't happen again wiping out whatever terrains you use in the fresh places.

You're right in one sense – the chance that you'd want to change terrains to use automated transitions is quite high. But is that even possible to automate?

You would need to convert the terrains themselves to use transitions, and you would need to update the maps to replace all the old transition tiles with the correct base tile.

I guess maybe it could be automated for the built-in terrains (id < 90) as long as their images haven't been changed from the default. Maybe even if the images have been changed… if I recall correctly, changing the images in legacy BoE didn't alter the transition behaviour in the editor?

Well, we could theoretically change terrains multiple times. They'd need to be disambiguated.

Sure, but using an issue number is a terrible way to do that. There's no guarantee that the project will always be hosted on GitHub. We can disambiguate by appending a version number or a date instead.

> I think we would want to change terrains in some cases, for example if you load a new-format scenario that uses old-style terrain transitions and you want to free up those 12 terrain slots per transition, you'd want to swap all occurrances of the 12 specific transition types into the 1 smart transition terrain. Then add the feature flag to the scenario so that change doesn't happen again wiping out whatever terrains you use in the fresh places. You're right in one sense – the chance that you'd want to change terrains to use automated transitions is quite high. But is that even _possible_ to automate? You would need to convert the terrains themselves to use transitions, and you would need to update the maps to replace all the old transition tiles with the correct base tile. I guess maybe it _could_ be automated for the built-in terrains (id < 90) as long as their images haven't been changed from the default. Maybe even if the images _have_ been changed… if I recall correctly, changing the images in legacy BoE didn't alter the transition behaviour in the editor? > Well, we could theoretically change terrains multiple times. They'd need to be disambiguated. Sure, but using an issue number is a terrible way to do that. There's no guarantee that the project will _always_ be hosted on GitHub. We can disambiguate by appending a version number or a date instead.

NQNStudios commented

2025-01-30 02:17:13 +00:00

(Migrated from github.com)

Yeah, fair enough.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: openboe/oboe#555