suggestion: consider adding SE_GetKeyValueNames

[vonotha]

As far as I know, the only way to access KeyStore is by using SE_GetKeyValue function.

In order to access a particular stored data, you need to know its name.

But I am not aware of a method to learn what data is currently stored.

This limits KeyStore usability for sharing data betweem scenario scripts. The only quite clumsy way seems to be keeping a list of ALL shared key values in a scenario attached script called by scripts attempting to access KeyStore.

[vonotha]

Let me give a concrete example.

I've got a script checking time from the last event triggering.

And it is doing it for various events.

Currently, checking time elapsed for a number of events, either requires hard coding event data in the monitoring script, or loading some external event-specific definitions.

It looks like that:

ScenEdit_UseAttachment('Lua script: elt_definitions.lua') -- loading external definition file

current_time = ScenEdit_CurrentTime()


-- event specific processing; depending on two externally defined tables: ETL & ETT
for i, elt_name in ipairs( ELT ) do

elt = ScenEdit_GetKeyValue( elt_name )

ett_m = ETT/60

print(elt_name.. ', ETT='.. ett_m.. 'm, '.. elt)

if elt ~= '' then

elapsed_time = (current_time-elt)

print('elapsed= '.. elapsed_time)

if elapsed_time >= ETT then
print('OVERTIME '.. 'ett_action_'.. elt_name..'.lua')
ScenEdit_UseAttachment('Lua script: ett_action_'.. elt_name..'.lua') -- event-specific action
end

end

end

Having possibility to query for available stored data, would allow to get rid of additional definition file.

NOTE: This early code contains some debugging facilities.

[michaelm75au]

There will be a new Lua function in future build that will dump out the key store as a Lua table.
ScenEdit_GetKeyStore

[vonotha]

There will be a new Lua function in future build that will dump out the key store as a Lua table.
ScenEdit_GetKeyStore

Good news, again, thanks a lot!

I'm dealing with this limitation now, but it is far from efficient, and having access to KeyStore brings interesting possibilities.

[KnightHawk75]

There will be a new Lua function in future build that will dump out the key store as a Lua table.
ScenEdit_GetKeyStore

Good news, again, thanks a lot!

I'm dealing with this limitation now, but it is far from efficient, and having access to KeyStore brings interesting possibilities.

This is a good addition, but just fyi it's often easier to manage a whole bunch of vars by storing them as a stringified table in one key, or just a few, instead of what I see often is people using dozens of separate keys like somethingunit1....somethingunit40. Not that such methods don't work for simple things like basic counters or flags, but tables makes life so much easier. Also with stringified tables you also don't have to worry about losing and having to convert back type information during the the save or load process either. In fact the only place I don't use it now is for cases where say something is updated every second (say a elapsed gametime seconds counter), as in that case a separate key may be more performant than re-saving a table of them constantly... depending on how large said table may be (~1kb makes no real difference, but 100kb would).

So in your example, if I understand correctly, why not just store an events table for that scene stored in one known stringified key, restored at startup, then you can check if said events exist in that scene's instance of said events table?

edit: btw if you don't know what I mean by stringify I can explain.

[Kushan04]

This is a good addition, but just fyi it's often easier to manage a whole bunch of vars by storing them as a stringified table in one key, or just a few, instead of what I see often is people using dozens of separate keys like somethingunit1....somethingunit40. Not that such methods don't work for simple things like basic counters or flags, but tables makes life so much easier. Also with stringified tables you also don't have to worry about losing and having to convert back type information during the the save or load process either. In fact the only place I don't use it now is for cases where say something is updated every second (say a elapsed gametime seconds counter), as in that case a separate key may be more performant than re-saving a table of them constantly... depending on how large said table may be (~1kb makes no real difference, but 100kb would).

So in your example, if I understand correctly, why not just store an events table for that scene stored in one known stringified key, restored at startup, then you can check if said events exist in that scene's instance of said events table?

edit: btw if you don't know what I mean by stringify I can explain.

I'd love to know more and see an example of this. I'm one of those that tends to have a lot of keys that need stored.

[KnightHawk75]

I'd love to know more and see an example of this. I'm one of those that tends to have a lot of keys that need stored.

I'll write up a thread with sample and include my little wrapper for it. (I think I did it before for jgardner? but it probably got buried as a response vs it's own thread).

[blu3s]

This function stores a table as keys in a single variable. I have not tested it myself


https://wiki.weaponsrelease.com/index.p ... _Later_Use

[KnightHawk75]

This function stores a table as keys in a single variable. I have not tested it myself


https://wiki.weaponsrelease.com/index.p ... _Later_Use

That'll work for basic table, and basically just stores comma delimited strings I think right? It's the sort of thing I used to do before i found stringify back in late cmano days, and never looked back.

I think this https://www.matrixgames.com/forums/view ... 6&t=392975
works much better imho, handles nested tables and basic type preservation, peeps are welcome to cut out the wrapper around stuff if they want and just lift the meat, but should work as is I including couple samples and more some more information dumping around things that come up when storing lots of data vs a little.

[blu3s]

I think this https://www.matrixgames.com/forums/view ... 6&t=392975
works much better imho, handles nested tables and basic type preservation, peeps are welcome to cut out the wrapper around stuff if they want and just lift the meat, but should work as is I including couple samples and more some more information dumping around things that come up when storing lots of data vs a little.

Undoubtedly a much more complete and elaborate method yours, with a very good explanation. Thank you very much.