Latest cottle version broke my scripts

[Transcan]

Latest cottle version broke my scripts.

I store all the configurable variables in a single script for easy modification for users. For example:

{set reportAtmoPressure to 1}
{set reportAtmoTemperature to 2}

Also, I have a script with a bunch of functions inside that are often used in all scripts. For example, functions that handle plurals and gender.

The way I work is to call both scripts "config script" and the "runtime script" at the very beginning of each script that is going to need said functions or config variables.

For example:
This is a section of the Material collected event script

{_ Script de apoyo _}
{F(".Shirka Preferences")}
{F(".Shirka Runtime")}
.
.
.
{creaArticulos(event.name)}   {_ Function inside ".Shirka Runtime"  if the word is feminine {set o to "a"} else {set o to "o"} }
{creaPlural(event.amount)}     {_ in this case is equal to:  {if event.amount > 1: {set s to "s"} {set es to "es"}} }

{if reportMaterial:
   {event.name} {OneOf("conseguid{o}{s}", "obtenid{o}{s}", "recolectad{o}{s}")}
}
.
.
.

Well, all this setup doesn't work with the latest update because now variables are local to the script they are on.
My whole personality is useless because it heavily depends on such custom functions.

Is there a way to change that behaviour to how it used to be?
Maybe using a Cottle keyword or something, like DocumentConfiguration.TrimNothing

EDIT: Actual version 4.1.0-b2
Version that introduced the change: 4.1.0-a1

EDIT2: From time to time I get these errors coming from the "runtime script" mentioned above:

Error with.Shirka Runtime script: Collection modified; enumeration operation may not be executed.
Error with.Shirka Runtime script: An item with the same key has already been added.

[Tkael]

Unfortunately there is no option / switch to exactly bring back the old behavior with the new version of Cottle.
I'm sorry about that but still feel that it's necessary to continue with the updated Cottle version.

With that said, thank you for taking the time to explain your concerns. While some changes will be required, I think we will be able to adapt your personality to the new Cottle version.

• .Shirka Preferences: The set assignment is only available in the current context. I would suggest that you take advantage of the SetState and perhaps GetState functions to store variables in a more context (including using a child script to set preferences which you can then retrieve in the parent script).

• .Shirka Runtime: I did some experimenting today and will be adding two new functions (with currently planned names of SetFunction and RunFunction) in the next release that I believe you will be able to similarly use to store your custom functions in a flexible context (including using a child script to set helper functions which you can then retrieve in the parent script).

These functions also allow you to only set each function or preference once (for example at the File Header or Commander continued event). :-)

[Transcan]

Hi, thanks for your quick answer, I'm glad this adversity can be circumvented.

Although, I was thinking in a different approach that maybe is easier to implement and takes less coding effort:
Something like an #include command that simple merges one script with another.

Create a new command (for example: I()) that instead of execute a child script, it simple paste the context of that script into the actual one, becoming part of it. This way the variables used in both will be in the same level of context.

In fact I used the F() function like that for my case. Both scripts (preferences and runtime) doesn't has any return whatsoever.

I see the potential of your approach for the preferences script: Calling it only one time and save all the variables in SetState() to retrieve them later when needed with GetState() is very nice, neat and I guess it's even more efficient. I think I'm going to walk this path and made this change.

But for the Runtime script, it is too complex: In the later example creaArticulos() and creaPlural() not only change one variable, but several at once. For example, creaArticulos() code is:

{set creaArticulos(texto) to:
    {if esPlural(texto):
        {if esFemenino(texto):
            {_ femenino plural _}
            {set del to "de las"} {set l to " las"} {set el to "las"} {set o to "a"} {set s to "s"} {set n to "n"} {set un to "unas"} {set e to "a"}
        |else:
            {_ masculino plural _}
            {set del to "de los"} {set l to " los"} {set el to "los"} {set o to "o"} {set s to "s"} {set n to "n"} {set un to "unos"} {set e to "o"}
        }
    |else:
        {if esFemenino(texto):
            {_ femenino singular _}
            {set del to "de la"} {set l to " la"} {set el to "la"} {set o to "a"} {set s to ""} {set n to ""} {set un to "una"} {set e to "a"}
        |else:
            {_ masculino singular _}
            {set del to "del"} {set l to "l"} {set el to "el"} {set o to "o"} {set s to ""} {set n to ""} {set un to "un"} {set e to "e"}
        }
    }
}

As you can see it prepares a bunch of variables to change the spoken output. (Yes, Spanish is a pain in the ass for machine text handling ^_^; )

If the SetFunction and RunFunction takes that into account then it would be a perfect solution for my issue.
But without knowing how difficult is going to be to implement those functions I think the I() would be easier to implement, I don't know.

[Tkael]

An #include command isn't really possible through Cottle. It could be possible but would require additional pre-processing to identify those commands and stitch scripts together before anything was passed into Cottle to render. That would be a fairly complex solution.

That said, embedding additional set or function assignments inside a stored function definitely breaks the implementation I have at the moment too... it can only handle simple functions. 🤔

[Tkael]

Hi there. I've added an #include style feature that I think will meet your needs. It will prepend scripts in the order you specify and then render everything together as if it were a single script.


It will be available in the next release.

[Transcan]

Wow! Perfect! Thank you so much!
You saved me a lot of reworking ^_^;