DaveTheCoder I just don't feel like the file that contains all variables in my game belongs to the user:// directory. Is that not a core parte of the game itself?

I guess I could manually create the file at res://Game/, but the point of my game is to use the interface I made to help me create the playable experience of the game. That means that at any point while I'm playing I could use the interface to add an event that sets a new variable after played. And I want that to be registered in the file so I can track all my variables that will be created by events.

So this file will be a core part of my game. If it's in the user:// folder and gets deleted for some reason, I will not have any way to track all the variables created by events inside my game. Unless I make another tool that iterates all events and run it every time I start my project, which feels harder to maintain than having a single all-powerful file where everyone dealing with variables writes on.

      Godoten You never want to write user generated data to res://. Always write to user://.

        Godoten So this file will be a core part of my game. If it's in the user:// folder and gets deleted for some reason, I will not have any way to track all the variables created by events inside my game.

        You could say that about any application.

        The documents you create with a word processor or spreadsheet app are important to you. If those files get deleted, that's bad. So you make sure to back them up.

        But those files are user files. They're not part of the app itself.

        I recently added a feature to one of my Godot projects. It automatically backs up the app's configuration file, which is in user://, to a web server. The configuration file doesn't get automatically restored from a backup if it's missing; that has to be done manually. But it would be possible to do it automatically.

            OP want to make level editor for the unfinished game so that he could add the level into the game build he is building from within the game?

            If that file stores the state, the game should maintain one such file in res:// that represents the default state and is never written to, and optional other file(s) with the same structure in user:// that represent user generated state(s). If the game cannot find needed file in user://, it should fallback to loading the default state from res://
            Alternatively you can just hardcode the default state.

            There is one very practical reason for never storing any user generated stuff in res://. When doing a content update on platforms like Steam, its cm/versioning system will always make a direct clone of the newly uploaded directory/file structure. Meaning that everything your game saved in res:// will disappear when an update is made. You almost never want this. User generated data typically needs to survive updates. That's why you have user://

              xyz Yes! I guess that's how it's called, the state file!

              My idea is this: a game I can create while playing. My project right now is just a "master interface" that allows me to extend the game while playing it as if I'm in Minecraft's creator mode. For example, a simple button can add a new dialogue in that moment. I will be deleting this master interface from the final game, since it only contains creator tools.

              The intention was to create, modify or remove events while playing, which I find more straightforward than those dialogue plugins.

              So during the developing time (which requires to play the game) I already can create characters and dialogues using custom Resources. But I want to create that unique res:// state file that will never be modified after the game is exported without the creator tools.

              This file will not be generated by users, but by me. I guess I will be an user during the development, but this file belongs to res://.

              While I'm working in my game, some events may add a variable when I create them. For example, if I suddenly decide to add a fight, I can add "dungeon_9_fight = true" to the event creator, which should add it to the rest of variables.

              Then the game reloads and the event can add that variable to the user:// file as the user's state, but I need it also in another file that contains all possible variables or states so I can keep track of this. It's kinda like when those dialogue plugins allow you to add variables using dialogues, but those don't need the game to be running.

              Updates would not be a problem either, since any update include an updated "states sheet", or however it's called.

              • xyz replied to this.

                  Godoten You can always change the location to which you save the state during the development process. When you as the developer are changing the state, maintain the state file in res://. Just before the game is finished and handed to players to continue to change the state, switch to serializing the state(s) to file(s) in user://, and keep what you've done in res:// as the default fallback, as I described in the previous post.

                  The logic is simple. Everything that developer changes regarding the game - goes into res://. Everything that user changes - goes into user://

                  For protecting from user snooping around the files, you have the same options regardless of where the files are situated - either encrypt or pack to binaries.

                      xyz When you as the developer are changing the state, maintain the state file in res://.

                      That's the "problem", that I want to change the state through my game (a part of the game, which is the "creator mode", modifies the rest of the game) but I can't maintain the state file in res:// if I can't write to res:// while the game is running.

                      How is it that I can write to res:// when it comes to custom Resources, but not with other files? Is serialization the key of all this?

                      • xyz replied to this.

                          DaveTheCoder Sorry, I think I didn't explain myself correctly. The file I'm talking about won't be user-generated. It will be generated and modified by me using the 'creator mode' inside my game. I explained it a bit better in my reply above.

                            Godoten You write to res:// only when you're running the game. When user is running the game it writes to user://

                            You need to write the complete state only to the default version that's in res://. The user's version of the state doesn't need to have all the state. That's why using something like ConfigFile is handy here. Not only it can encrypt but you can check if something is in there. If something is missing (e.g. you added new things via an update and user's state doesn't have those) simply fallback to what's in the default state in res:// and then resave to user://

                                xyz Yes! This is pretty much what I want to do! But this is what I can't do:

                                xyz You write to res:// only when you're running the game.

                                Nothing happens when I use config_instance.save(res://Game/data) for example. I guess it's because the game is running, which makes the res:// directory read-only. Although I don't have this problem when saving new custom Resources for some reason.

                                ConfigFile.save() -> doesn't work with res://path while the game is running.
                                Resource.save() -> It does work with res://path while the game is running.

                                • xyz replied to this.

                                      Godoten When running from editor, res:// shouldn't be read only. Check the exact error code returned by save(). But it doesn't really matter where you save the state during the development, you can save it anywhere (including user:// or some absolute path) and put it into res:// once the whole thing is done and ready to be released.

                                          xyz
                                          Wait so it's only when the game is exported that you can't write in res://? Wow, I never made a distinction between running from the editor and from the exported game.

                                          The error is "0". This was the code:

                                          func _ready() -> void:
	var config = ConfigFile.new();
	var error = config.save("res://Game/Config/testfile.vars");
	print(error);

                                          Result: 0, and no file saved

                                              Godoten This was the code:

                                              That code creates an empty ConfigFile object and then writes it to a file.

                                              Try populating the object with some data.

                                              var config := ConfigFile.new()
config.set_value("Player1", "player_name", "Steve")
var error: Error = config.save("res://Game/Config/testfile.vars")
print("config.save result=", error)

                                              Also, verify that this directory exists: res://Game/Config.

                                                  DaveTheCoder I just found out what the problem was! Godot was not recognizing my .vars extension, so it doesn't show up in the Filesystem! I checked through Windows explorer and there are my files!

                                                  Thank you so much to everyone for the help, I learned a lot about Godot with this issue! Also, some people on Reddit told me that there is not much point on encrypting my files since people will just decompile my game looking for the passwords. But I think I will stick with a basic encrypted ConfigFile anyways.

                                                      Godoten some people told on Reddit told me that there is not much point on encrypting my files since people will just decompile my game looking for the passwords

                                                      That's like saying there's no point in locking your car or house doors, since people will just break a window to get in.