Ticket 696 is so close to 736 I am surprised one was fixed and the other was not. The only difference is 736 wants those settings to be in its own file for a given mod. This has several advantages. You can share settings without editing the files easily, with a single file approach any setting sharing would override all mod settings. External tools would be much easier to make if they didn't have to worry about messing with and breaking all the various settings and just needed to edit your interface file.
Not as bad as I first thought (kind of like a single xml file was just as powerful before we split it up) but would still be nice to have separate files.
unvGetExtensionData and unvSetExtensionData
- Betelgeuse
- Fleet Officer
- Posts: 1920
- Joined: Sun Mar 05, 2006 6:31 am
Crying is not a proper retort!
- alterecco
- Fleet Officer
- Posts: 1658
- Joined: Wed Jan 14, 2009 3:08 am
- Location: Previously enslaved by the Iocrym
On a related note, i made a comment on ticket #696. Is it ok to just reopen the ticket or do you need us to set it to some other state for you to notice a comment on a closed ticket?
http://wiki.neurohack.com/transcendence ... #comment:3
Also, I guess ticket 736 overlaps in such a degree that it should be closed. Or is there some functionality that the new functions do not provide that we need, Betel?
http://wiki.neurohack.com/transcendence ... #comment:3
Also, I guess ticket 736 overlaps in such a degree that it should be closed. Or is there some functionality that the new functions do not provide that we need, Betel?
- Betelgeuse
- Fleet Officer
- Posts: 1920
- Joined: Sun Mar 05, 2006 6:31 am
I think it should be closed. It would be nice to have more than one settings file but it is not a major thing.
one solution would be for scope to accept a file name, the one called cloud would be synchronized as needed with the server. That would allow mods the depend on that to always have a local backup. Even if a given player has never directly connected to the internet they can still share the data with someone who has allowing them to use those mods.
one solution would be for scope to accept a file name, the one called cloud would be synchronized as needed with the server. That would allow mods the depend on that to always have a local backup. Even if a given player has never directly connected to the internet they can still share the data with someone who has allowing them to use those mods.
Crying is not a proper retort!
- alterecco
- Fleet Officer
- Posts: 1658
- Joined: Wed Jan 14, 2009 3:08 am
- Location: Previously enslaved by the Iocrym
George, would you mind sharing a bit more information about how you have implemented this?
From a development pov, if all the writes from unvSetExtensionData go into the same file, then resetting that data will erase all other mods data (plus settings, if it is stored in that file). It might be nice if all mods have their own db file (not only from a development pov, but also as Betel points out, one could share a file with a particularly fun/special/wow set of data).
From a development pov, if all the writes from unvSetExtensionData go into the same file, then resetting that data will erase all other mods data (plus settings, if it is stored in that file). It might be nice if all mods have their own db file (not only from a development pov, but also as Betel points out, one could share a file with a particularly fun/special/wow set of data).
-
- Developer
- Posts: 2997
- Joined: Thu Jul 24, 2003 9:53 pm
- Contact:
Right now, everything is stored in a single file (Storage.xml). I load all the data at startup (even for extensions that aren't used or have been deleted) and save the whole thing when then game shuts down. This was the easiest thing to do that fit within my time budget.alterecco wrote:George, would you mind sharing a bit more information about how you have implemented this?
From a development pov, if all the writes from unvSetExtensionData go into the same file, then resetting that data will erase all other mods data (plus settings, if it is stored in that file). It might be nice if all mods have their own db file (not only from a development pov, but also as Betel points out, one could share a file with a particularly fun/special/wow set of data).
It wouldn't be impossible (in 1.09 or beyond) to allow each extension to have its own file. I would have to create a new directory and put everything there. Personally, I'm not sure I see the use case. Sharing settings manually across players seems like a limited case (e.g., if you're going to share settings you'll probably need a mechanism to flip between different settings within the mod; that means you're going to have to merge files anyway [either by hand or with a tool]).
If it turns out that sharing settings is really common, then I'll add better mechanisms.
Here is an example of the file:
Code: Select all
<?xml version="1.0" encoding="utf-8" ?>
<TranscendenceStorage>
<Row key="a0000100_test">'(1 2 3)</Row>
</TranscendenceStorage>
As with other *SetData functions, any value (lists, structs, etc.) is valid, except objs (you need to store objIDs).
- alterecco
- Fleet Officer
- Posts: 1658
- Joined: Wed Jan 14, 2009 3:08 am
- Location: Previously enslaved by the Iocrym
Hmm, ok, that seems like a good compromise. Lets see if sharing settings actually becomes relevant. It is cool that it is possible to open up the file and edit the settings manually. (That will probably solve the cases i have where sharing is necessary, ie. development).
Perhaps we could add two more functions, unvGetExtensions and unvGetExtensionKeys, so that it is possible for G.O.D to list the keys set by an extension? If you think that is not silly, then I will make ticket for them.
Perhaps we could add two more functions, unvGetExtensions and unvGetExtensionKeys, so that it is possible for G.O.D to list the keys set by an extension? If you think that is not silly, then I will make ticket for them.
-
- Developer
- Posts: 2997
- Joined: Thu Jul 24, 2003 9:53 pm
- Contact:
Yup, I think that's a good idea.alterecco wrote:Perhaps we could add two more functions, unvGetExtensions and unvGetExtensionKeys, so that it is possible for G.O.D to list the keys set by an extension? If you think that is not silly, then I will make ticket for them.
- Betelgeuse
- Fleet Officer
- Posts: 1920
- Joined: Sun Mar 05, 2006 6:31 am
sounds fair, maybe in the future we can close then open the storage.xml with a function so we can use make tools communicate with transcendence in real time and to be able to run code snippets from a text editor instead of the console.
for example
(unvLoadExtensionData) ;would read the Extension Data from the disk
(eval (unvGetExtensionData 'local 'snippet)) ;would evaluate the code written to the xml file allowing the use of a text editor instead of the console for debugging
for example
(unvLoadExtensionData) ;would read the Extension Data from the disk
(eval (unvGetExtensionData 'local 'snippet)) ;would evaluate the code written to the xml file allowing the use of a text editor instead of the console for debugging
Crying is not a proper retort!