Thank-you for the response. I am not wanting to call the variables into Maple until desired (in other words not all together at the start).
The reasoning is User A might only have 3 defined answers to the particular question while user B might have 7 defined answers. I was hoping the for loop would gradually gather all the answers rather than having them defined at the start of the call to maple.
A more thorough search through the Maple TA Online Help has shed some more light on this question. Including the command randomize(): in Maple-based variable definitions sets the initial state of the random number generator using a number based on the system clock instead of the default seed in Maple.
Thanks for looking into this! Unfortunately we do not (yet) have a local server for MapleTA, but this security issue could be an argument for becoming self-hosted. One way around the concrete problem (without self-hosting, I think) is to embed the needed (if not all) *.mla procedures directly via manual copy-paste into the startup code from the worksheet that defines the *.mla file. But this, of course, is much more cumbersome than the wished-for simple one-line reference to the *.mla file itself.
Your answer, however, then also induces a similar question concerning the use of repository files inside MapleTA itself, as thoroughly explained in: [https://mapletacommunity.com/topic/64/how-to-create-and-use-a-maple-repository-in-maple-ta]. Admittedly, I did not check this out yet, but the question is, if this functionality also has been depreciated or blocked in the meantime?
Ok, thank you. The possibility of allowing the student to navigate through other sites or programs while doing the exam is in discussion since it can be considered not compliant with standards concerning safe exams procedures, but this option can be taken into account.
Yes, I'm using the 2016 version. It worked, thank you! I used $x*$response.provachain1.1.1 in the response area, where $x=4; was defined as the only line of the algorithm. Good to know also that it is wrong to consider the (addable by the user) field "id" from "Information Fields" as equivalent to the "id" appearing in the source, which is not the case.