6 réponses à ce sujet

[TimelordDC]

Maybe I've just been messing with this for too long to see the obvious solution but I am stumped.
How do I write a script to accept parameters?

The conversation editor has an option under Plots and Scripting to have a script in the Condition/Action fields and a parameter field to pass a parameter.

As far as I've seen, scripts either have to have a void main () or a int StartingConditional() and neither of those can accept parameters (already tried and compiler throws an error) So, how do I retrieve the parameters passed to the script?

The wiki mentions GetConversationEntryParameter but it is just a function (this function was actually included in the 1.03 patch). Doesn't the script's main function (main or StartingConditional) need to have the argument defined so it is passed into the code within?

Thanks!

Modifié par TimelordDC, 06 octobre 2010 - 06:02 .

[TimelordDC]

Duh. Should've tested more. Apparently, the GetConversationEntryParameter is a magical function

The script engine stores the conversation parameter passed somewhere and when GetConversationEntryParameter is called from within a script, it correctly passes that value.



Tested with a conversation and script and appears to work correctly.

[Mengtzu]

I'd forgotten all about that. I'm glad it's finally working



Do we think it's generally better form to use a plot script to call our parametised functions rather than doing it in conversation though?

[TimelordDC]

I guess plot scripts should be used where possible but in some cases, parametrized scripts will be needed. In my case, I am doing this for a game played through conversations and it will be a headache using plot flags - my script will be swarmed with WR_GetPlotFlag and WR_SetPlotFlag calls.

This way, I can use different integers for nodes and store them in arrays for easier comparisons (fetch, iteration, etc.). I guess this can be done through plot scripts too but instead of a for loop used to get the array index based on the choice, I will have to do that in every plot flag set case...and calculating the result would involve a few more defined flags with their own calculations. Too much writing



Though I just realized after writing everything that we can't have more than 6 options in the player's response...the already convoluted dialogue flow just got more convoluted *sigh*

[Mengtzu]

I wasn't really suggesting changing how you did your function, just calling it from the plot script - so if it was a sliding block puzzle or something you'd do



case SLIDE_NORTH: {

DoBlockPuzzleSlide(BLOCK_SLIDE_NORTH);

break;

}



Where BLOCK_SLIDE_NORTH is an integer constant defined somewhere.



It's a bit better for readability and maintenance, but it's extra effort. The "is it better form?" question wasn't rhetorical



In any case it's much better to be able to use paramaters from conversation than not - thanks for letting us know it's working!

[TimelordDC]

Of course. I was just giving an example as to why one way is sometimes preferable over the other

Modifié par TimelordDC, 07 octobre 2010 - 12:13 .

[Proleric]

Good find.

Of course, you don't always need to use cases in plot scripts.

For example, if you have a clock face, assign the hours 1-12 to plot flags, then you can write generic code that does arithmetic or look up on the plot flag.