Changing the path of theaters....? What does everyone think?
-
I am proposing to all the theater developers that we change the path to the theaters. Instead of having it like below…
…data\Add-On (name of theater)
we have it like this…
…data\Theaters\Add On (name of theater)
This will just keep everything looking neat in the root folder. I know it seems small, but when you have alot of theaters installed and you are trying to work on the main KTO data…or even different theater data…it can get kind of confusing sometimes.
The only thing that would need to be changed are the Theater.tdf files and the theater.lst file
Like I said just a thought.
-
@cougar56th This would break any addons/tools which use the current directory structure. Not sure of any benefit. Most users would not even know it exists. (if it ain’t broke etc…)
-
@Fish44 said in Changing the path of theaters....? What does everyone think?:
@cougar56th This would break any addons/tools which use the current directory structure. Not sure of any benefit. Most users would not even know it exists. (if it ain’t broke etc…)
why? in the tdf there’s no reason to change main data directory…
-
I dont think it would break the tools. I just tried it in Mission Commander and it worked fine. The tool just has to be redirected.
-
Its definitely breaks the current version of Kneeboard manager, which works out what theatres you have automatically based on the current structure. I guess it will affect eziBoards also. Might not be a big fix for each, but a fix is required nonetheless.
I would welcome a re-structing of the theatres folders to make all theaters consistent (including KTO), along with streamlining pointers for the koreaObj folders, which sometimes are shared by theatres, and sometimes unique.
Might need a separate KoreaObj folder at the same level as the theatres, and each theatre would point to the appropriate one. So I think if there’s going to be a change of structure, it needs to be in a broader context for the theatres. There maybe other impacts on the theatres, but i can’t speak for those.
-
Isn’t
...\Data\TerrData\TheaterDefinition\Theater.lst
the source of truth for theater locations?That’s what AL code appears to look at.
https://github.com/chihirobelmo/FalconBMS-Alternative-Launcher/blob/master/Falcon BMS Alternative Launcher/TheaterList.cs#L15 -
@airtex2019 Or it can be what’s in the ‘E:\BMS437\Data’ folder perfixed with ‘Add-on’. As for example Add-On Mideast128 is considered as 1 theater in kneeboard manager, because it uses the same koreaobj folder, where the kneeboard dds files must go. The theater.lst says its got 2 theaters, If both theaters were displayed in the KBMZ, it would cause confusion, because restoring a kneeboard pack, from one theater would overwrite the set present in both theaters in the example above.
-
@airtex2019 the theater.lst file only says what theaters are in. The individual theater.tdf file tells how individual folder structure is set up. In the theater.tdf file it would just be a matter of putting Theater in front of Add-On XXX……
The alternate launcher would automatically see all that.