More animation could be nice, although it's probably getting ahead of the programming as we only have proof of concepts of animation so far, and none enabled in C7 yet.
I think Vuldacon may be on to something with the waterfall/billboard examples as well - that would be a smaller stepping stone than a whole terrain set with animation, and could be implemented as resources. For what it's worth, animated resources are one of the things that stands out as a nice thing in Civ V to me as well. Those adorable foxes representing furs? It almost made you not want to build a trapping hut.
Uh...a quandary: I've added a dialog on MainMenu to select a Civ3 Home, and I'm putting that in GlobalSingleton. Buuut...
(condensed for quoting)
Ok, I'm concluding that
- Civ3 Home needs to be in GlobalSingleton - We need to access it from multiple scenes, but we really don't need it elsewhere except for ImportCiv3, but we're already calling that with a full path from the Godot code
- The Util path finders don't need to move out of C7 for similar reasons
- Let's refactor all path finder calls to pass Global.Civ3Home - It's some parameter repetition, but putting pass-through convenience functions in GlobalSingleton is just too icky and opens the door for multiple code paths to exist to get a file path which is bound to cause issues
Edit: On a different note, I may change the Civ3 home dir-selector dialog to exist in the scene. This will persist the last-browsed folder in the scene file across runs which is a PITA for dev-time (because git and different devs having different folders) but will be handy for users. Actually, come to think of it, I should really just persist the path itself outside of the dialog.... Any ideas on how to avoid MainMenu.tscn updating in git every commit while allowing users to persist their folder selection? My only idea is to add MainMent.tscn to .gitignore and just remember to manually add any intentional changes. (Edit to the edit: Oh,
clean filters are a thing that might do here, but unsure how that works cross-platform and cross-tool.)
The way I implemented Settings/Preferences in my editor would provide another option, and one that I've been happy with over the years with the editor, even if it might not be the most preferred route in all cases.
That is, having the settings themselves be static. The thinking is that a setting is static, and you'll only ever have one instance of it per copy of the editor that is running. If they are static, any area that needs to know what the user's settings are can do so quickly and easily, without any awkward work-arounds.
(Technically, the editor only partially does this. In some places it uses a static reference to a Settings object instead. But what I described above is what I found worked best, and newer parts of the editor, and subsequent non-Civ projects, work like what I described above)
An example from another project, in Java:
Code:
public class Settings {
public static int CONSOLE_WIDTH = 80;
public static int CONSOLE_HEIGHT = 25;
public static int PAGE_DOWN_MARGIN = 2;
public static String LINK_STYLE = "External";
It may be less "clean" in theory, and is less functional, but to me the resulting code is cleaner and simpler than passing a static variable (in the example, Global.Civ3Home) everywhere. As long as there is one source of truth for the variable's value (Global.Civ3Home), in practice I prefer the simpler API of pass in what's relevant to the Util methods, and have them go use Global.Civ3Home themselves.
I'm also increasingly favoring persisting settings locally, because of the different dev folders issue you mentioned. It's already getting old re-setting the home directory on the SAV import script. I took the 1993 approach in my editor and saved the preferences in the local directory, in an INI file. A more "sophisticated" approach would be to store it somewhere in the user directory; the old "AppData? Roaming? LocalLow? My Documents?" question. *shrug* Almost any option would be better than having local folders be synced across Git. Which, come to think of it, wouldn't the local folders in MainMenu.tscn cause it to not work for the general CFC audience for the "Babylon" preview?
. I vaguely recall getting something of that sort working around 2014, but it's been long enough that how my team at the time did it no longer comes to mind.
