TTLG|Thief|Bioshock|System Shock|Deus Ex|Mobile
Results 1 to 8 of 8

Thread: Squirrel - Optional Parameters not set -> abort.

  1. #1
    Member
    Registered: Jan 2012
    Location: Gèrmany

    Squirrel - Optional Parameters not set -> abort.

    I know you guys are new to this too but maybe your old knowledge can help.

    For a script I want to have 3 optional parameters in the Design Note, accessible via userparams().Name (a squirrel table).


    But if a parameter is not set and I call it via userparams().Name the script immediately aborts.
    So I can't even do a 'if (userparams().Name != null)' check


    Any idea how I could test if a parameter is set and still continue even if not?

  2. #2
    Member
    Registered: May 2002
    Location: Between dreams and shadows...
    Disclaimer: I've only the most passing experience with Squirrel, so this may be total rubbish...

    What you probably need to do is catch the exception, so something like

    Code:
    name = "";
    
    try {
        name = userparams().Name;
    } catch(err) {
        name = "Some default";
    }
    
    ... now use name...

  3. #3
    Member
    Registered: Jan 2012
    Location: Gèrmany
    Perfect solution
    Thank you.

    Good to know another keyword

  4. #4
    Member
    Registered: Aug 2001
    Location: Virginia, USA
    Code:
    local name = "Name" in userparams() ? userparams().Name : "NoName";

  5. #5
    Member
    Registered: May 2002
    Location: Between dreams and shadows...
    That'd be a better approach, yeah!

  6. #6
    Member
    Registered: Nov 2001
    Location: uk
    [quote =Daraan;2352817]Thank you caffe. Great info.
    Edit: Did I get this right _get would also work and would be faster than in checks?[/quote]

    The three ways of dealing with an index that might not be there are:
    setting a default, trying it and catching and ignoring the runtime error
    Code:
    local tParams = userparams()
    local x = 0;
    try
    {
       x = tParams.XParamName;
    }
    catch(ex)
    {} // nothing in the catch as we already set a value against it and it'll throw an error at the . and not do the =
    Not the ideal way to handle that sort of thing, I would only tend to do that if I was doing tointeger or tofloat on it that *that* might throw an error if you can't pre-know the content of the string is going to be a number

    in
    Code:
    local tParams = userparams()
    local x = 0;
    
    if ("XParamName" in tParams)
    {
       x = tParams.XParamName;
    }
    tidier, more obvious, faster

    metafunctions and delegates

    Code:
    local tAllValuesDefaultToZero = {_get = function(index){ return 0;}}; // this _get function will be called when you try to access an index that isn't there (the index is passed to it)
    local tParams = userparams();
    tParams.setdelegate(tAllValuesDefaultToZero ); // tell the VM that we want to use that _get on this table
    local x = tParams.XParamName;
    Total overkill for what you're using it for and probably not the right answer for anything in a thief script but useful to know, tend to use that sort of thing for when I'm passing two very similar data structures to the same code and don't want to have to care which of the two it is.


    The other thing to notice from the code in your other thread is that I did local tParams = userparams() then accessed tParams multiple times. That is MUCH faster than calling userparams multiple times

  7. #7
    Member
    Registered: Jan 2012
    Location: Gèrmany
    Quote Originally Posted by caffeinatedzombeh View Post

    Code:
    local tAllValuesDefaultToZero = {_get = function(index){ return 0;}}; // this _get function will be called when you try to access an index that isn't there (the index is passed to it)
    local tParams = userparams();
    tParams.setdelegate(tAllValuesDefaultToZero ); // tell the VM that we want to use that _get on this table
    local x = tParams.XParamName;
    The other thing to notice from the code in your other thread is that I did local tParams = userparams() then accessed tParams multiple times. That is MUCH faster than calling userparams multiple times
    Didn't use delegate in my short test runs just now. As you said good to know. Might come in handy in my part time job.
    Will start to tidy it up even more

    Thanks a lot!

  8. #8
    Member
    Registered: Mar 2001
    Location: Ireland
    For NVScript, I have a function which takes a parameter name and a default, and returns the one or the other depending on if the param exists or not. It also prepends the script's name before the param, which may or may not be useful depending on how you want to use the scripts. (I favour having the full script name before each param.)

    Writing a base script with that kind of functionality in Squirrel might be useful.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •