Args/Params for Dictionaries?

HegemonKhan
quick question:

do dictionaries have (aka: can they be given) args/params ?

otherwise, I'd have to use verbose/ugly/messy 'if/switch' Function scripting... (if I'm not able to pass in an Object arg/param into a dictionary script)
(or, how would be the best way to do this then?)

for a more clear example of what I'm hoping that I can do (via Dictionaries having args/params):

invoke (ScriptDictionaryItem (Script_Dictionary_Attribute_name, itemX, <arg/param: npc>))

<attr name="Script_Dictionary_Attribute_name" type="scriptdictionary" parameters="object_parameter">
<item key="item1">
Function_1_name (object_parameter)
</item>
<item key="item2">
Function_2_name (object_parameter)
</item>
</attr>


------------

additional question while on topic for this post:

which is more efficient/optiminal, using dictionaries vs using if/switch functions, does it differ after a certain point of size of data-content/number of operations (aka: for only a few operations, the if/switch function is more efficient/optiminal, but over x operations, then using a dictionary is more effective/optiminal ~ similar to how effective/optiminal different searching functions are based upon data/operational size: binary searching is more effective for large sizes whereas sequencial searching is more effective for small sizes)

The Pixie
I think the simple answer is no. I am not sure why you would want to; are you not better creating the dictionary just before invoking the script, so the values are all current?

When I was messing around I had to change the XML to this. I know Quest accepts (and generates) your style, but not for me this time. Not sure why.
    <Script_Dictionary_Attribute_name type="scriptdictionary">
<item key="item1">
Function_1_name (object_parameter)
</item>
<item key="item2">
Function_2_name (object_parameter)
</item>
</Script_Dictionary_Attribute_name>

I got this to work successfully:
dict = NewDictionary()
dictionary add (dict, "object_parameter", player)
scr = ScriptDictionaryItem(game.Script_Dictionary_Attribute_name, "item1")
invoke (scr, dict)

If your scripts have different parameters, you can add them all to the dictionary. It may not be quite as efficient, but would be easier.

If you are worried about efficiency, set up a loop that does it 10,000 times and time it, then do it the other way and see what the difference is. Personally, I would suggest simple and easy to understand are more important.

Why is a script dictionary better than script attributes on an object? Both are accessed via a string. The above example may well be easier that way, if you could attach the script to the object_parameter (or its type), and reference it in the scripts with "this".

HegemonKhan
oh ya, sorry about that...

I guess quest still doesn't have the (I was hoping it did in its most recent version):

<attr name="blah" type="blah">content</attr>

syntax working for dictionaries (and maybe a few other things too), as it still requires (only) the old style syntax:

<Attribute_name type="blah">content</Attribute_name>

HegemonKhan
the reason is, is that this is a long function chain (still working on the character creation system), which requires me to be able to pass args/params along through it... so if there's no way of giving a dictionary args/params, then I can't use them (easily/simply) in my long function chain... (now that my finals are over, I'm trying to get back into working on my game coding... which is still just the character creation part, lol)

HegemonKhan
ah, very ingenius, Pixie!

----------

dict = NewDictionary()
dictionary add (dict, "object_parameter", player)
scr = ScriptDictionaryItem(game.Script_Dictionary_Attribute_name, "item1")
invoke (scr, dict)


Pixie wrote:Why is a script dictionary better than script attributes on an object? Both are accessed via a string. The above example may well be easier that way, if you could attach the script to the object_parameter (or its type), and reference it in the scripts with "this".


---------

if I understand, generally/loosely, you're nesting or adding both of them as keys/values (or are creating two dictionaries and then using them together), which then allows you to use them together, which is in-effect the same as using args/params, right?

The Pixie
Yes, one dictionary has the scripts, the other all the parameters they want.

HegemonKhan
thank you Pixie for the help with the dictionary usage/information! :D

jaynabonne
(Edit: I realize now that I'm just repeating more verbosely what The Pixie already said, but I'll leave it anyway, in case it's helpful.)

As a possible alternative, depending on your design, you might be better off without a script dictionary at all. I'm not sure about the semantics of these script in relation to the object being passed, but if you're calling behaviors on an object, then you might be better off putting the scripts either onto the object directly (if for a single object) or into a type you inherit from (if shared across multiple objects).

The underlying idea is that a Quest object is effectively a dictionary anyway. And if you use "do" instead of "invoke", then you get a built-in "this" pointer. So moving the scripts onto the object (or an inherited type) means you can simply do:

do (npc, itemX)


to run your script. And you'd have (roughly - fix the syntax as needed, as I'm at work and going from memory):
<object name="npc">
<item1 type="script">
// stuff goes here
</item1>
<item2 type="script">
// stuff goes here
</item2>
</object>


Or you could encode it a bit and have

do (npc, "handle_" + itemX)


<object name="npc">
<handle_item1 type="script">
// stuff goes here
</handle_item1>
<handle_item2 type="script">
// stuff goes here
</handle_item2>

</object>

That might not work with your design, but I'm throwing it out there, just in case. (And if you did go the "do" route, it also has a variant that takes an arguments dictionary, in case you needed additional parameters beyond "this".)

In the entire time I've been using Quest, in all the various bits of coding I've done, I've never used a script dictionary. Using an object to hold the scripts has always been easier and more meaningful from a design point of view. Your mileage may vary. :)

The Pixie
jaynabonne wrote:... In the entire time I've been using Quest, in all the various bits of coding I've done, I've never used a script dictionary. ...

Same here

HegemonKhan
thanks Jay, about using Objects and 'do'. I'm still trying to wrap my brain around understanding Object usage in terms of what I'm trying to do for my design. I still look at it procedurally, using functions/scripting/dictionaries/invoke. It's going to take some time to change my brain over to using Object constructs more and how for what I want to do with my designs.

jaynabonne
If you have an npc, then you have an object already. This isn't a procedural vs object-oriented question. It's just a question of where you put the scripts: either on the object in question so you can take advantage of the fact that Quest will pass the relevant object for you, or in a separate dictionary, where you have to resort to the above per The Pixie to inject the object into the script yourself. If you remember that a Quest object *is* a dictionary (in fact, one that's easier to use, assuming you already have one), then it's no conceptual difference at all.

This topic is now closed. Topics are closed after 60 days of inactivity.

Support

Forums