unvGetExtensionData and unvSetExtensionData

Freeform discussion about anything related to modding Transcendence.
Post Reply
User avatar
Betelgeuse
Fleet Officer
Fleet Officer
Posts: 1920
Joined: Sun Mar 05, 2006 6:31 am

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.
Crying is not a proper retort!
User avatar
alterecco
Fleet Officer
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?
Get your own Galactic Omni Device
Get it now. It's free!!
Image
User avatar
Betelgeuse
Fleet Officer
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.
Crying is not a proper retort!
User avatar
alterecco
Fleet Officer
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).
Get your own Galactic Omni Device
Get it now. It's free!!
Image
george moromisato
Developer
Developer
Posts: 2997
Joined: Thu Jul 24, 2003 9:53 pm
Contact:

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).
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.

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">&apos;(1 2 3)</Row>

</TranscendenceStorage>
Each row represents a single setting. The key encodes the UNID of the extension and the attrib passed in to unvSetExtensionData. In the example above, "a0000100" is the UNID; "test" is the attrib. The contents are the data.

As with other *SetData functions, any value (lists, structs, etc.) is valid, except objs (you need to store objIDs).
User avatar
alterecco
Fleet Officer
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.
Get your own Galactic Omni Device
Get it now. It's free!!
Image
george moromisato
Developer
Developer
Posts: 2997
Joined: Thu Jul 24, 2003 9:53 pm
Contact:

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.
Yup, I think that's a good idea.
User avatar
Betelgeuse
Fleet Officer
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
Crying is not a proper retort!
Post Reply