Add unique mem card dir for each mod #57
Conversation
| @@ -130,6 +127,17 @@ std::string get_current_executable_path() { | |||
| #endif | |||
| } | |||
|
|
|||
| std::string get_mod_name() { | |||
| //Returns the name of the folder that gk is in, useful for detecting name of mod for unique saves and other implmentations. | |||
There was a problem hiding this comment.
in development though the binary will be like out/build/Release/bin/gk.exe, so won't you end up with bin as the mod name? not the end of the world but maybe a bit confusing... I'm not sure what's the best way to avoid having some sort of MOD_NAME_PLEASE_CHANGE_THIS somewhere...
There was a problem hiding this comment.
Yeah, in development source everything would still share saves like it currently does in the bin folder.
There was a problem hiding this comment.
I'm not sure what's the best way to avoid having some sort of MOD_NAME_PLEASE_CHANGE_THIS somewhere...
imo, this isn't a bad thing -- but you obviously want it somewhere sensible. It's far better for a mod to provide a name than for the tooling to just try to assume or figure it out.
The most obvious reasons that comes to mind are imagine if two mods have the same name / if the folder structures of the mods change / etc.
- In the short-term, this could just be a CLI arg that the launcher(s) provide.
- In the long-term, mods would have their own project file that could set metadata like this.
There was a problem hiding this comment.
I kinda liked it just being dependent on the name of the folder myself, but yeah we could add some metadata somewhere I guess. I mostly just named this function badly. Its more get_folder_name() and not mod_name for certain things and having one source of truth yeah falling back to a json/metadata in ONE spot is good.
|
Anyways at least I am a fan of the currently implementation for now, even if the wording could be better. I think using the parent directory name of the gk executable is decent and easy to explain. If people really want a different solution then let me know. I prefer the current implementation but am willing to listen to ideas/do not feel passionate enough to block or anything. |
|
close this? should be supported by vanilla opengoal now and merged into mod base already |
Fix mac assets leftover logic in build pipeline
No description provided.