Thanks as always Stuart!

Yes, currently we are limiting tries to 12 and the display of the tries is 
hardwired to stop at 12 as well, but the instuctorcomment would be a great 
addition to document that.

Thank you!
 
Doug

 

Douglas Mills

Director of Instructional Technology

Department of Chemistry

University of Illinois


 

On 10/10/18, 3:28 PM, "LON-CAPA-users on behalf of Raeburn, Stuart" 
<lon-capa-users-boun...@mail.lon-capa.org on behalf of raeb...@msu.edu> wrote:

    Doug,
    
    Your script block in /res/uiuc/dmills/andino/CurvedArrows/CAAD2-2.problem 
contains:
    
    $tries=(&EXT('user.resource.resource.1.tries'))? 
&EXT('user.resource.resource.1.tries') : 0;
    #loop through the number of attempts and build an $attempts variable
    for my $i (1..$tries) {
         push @attempts, &EXT("user.resource.$i:resource.1.ans.submission");
    }
    
    The index used internally in LON-CAPA for each submission record need not 
correspond to the current number of tries, because LON-CAPA records each 
submission, including those that do not cost a try, such as submission of a 
previously submitted (incorrect) answer.  So you should loop over number of 
transactions instead of number of tries.  (In LON-CAPA the transaction number 
is called the version). To suppress display of any submissions made prior to an 
instructor reset, for a partID of 0 , for a responseID of 'ans' use the 
following:
    
    #looping from newest attempt to oldest attempt, and populating an array 
with submissions for response ID 'ans' in part: 0
    #submissions which do not cost a try are not included.
    #looping stops if an instructor reset is encountered.
    #the resulting array of submissions to display is ordered from oldest to 
newest.
    @attempts=();
    $tries=0;
    $version=&EXT('user.resource.version');
    if ($version) {
        $tries=&EXT('user.resource.resource.0.tries');
        if ($tries) {
            for (my $i=$version; $i>=1; $i--) {
                last if (&EXT("user.resource.$i:resource.0.regrader"));
                next if (&EXT("user.resource.$i:resource.0.tries") eq '');
                
unshift(@attempts,&EXT("user.resource.$i:resource.0.ans.submission"));
            }
        }
    }
    
    If you wanted to also include submissions from transactions which did not 
cost a try in the attempts array replace
    
    next if (&EXT("user.resource.$i:resource.0.tries") eq '');
    
    with 
    
    next if (&EXT("user.resource.$i:resource.0.ans.submission") eq '');
    
    and omit the if ($tries) condition.
    
    Because this loop could result in lots of calls to &EXT(), and thereby load 
your server, it would be prudent to hard code a maximum number allowed for 
$version, and include an <instructorcomment></instructorcomment> block to 
document that.
    
    
    Stuart Raeburn
    LON-CAPA Academic Consortium
    
    ________________________________________
    From: LON-CAPA-users <lon-capa-users-boun...@mail.lon-capa.org> on behalf 
of Mills, Douglas G <dmi...@illinois.edu>
    Sent: Wednesday, October 10, 2018 11:51:31 AM
    To: lon-capa-users@mail.lon-capa.org
    Cc: Mills, Douglas G
    Subject: Re: [LON-CAPA-users] Differentiate between tries when a problem is 
    reset?
    
    Hi All,
    
    Looking back through older emails I came across the unanswered question 
below. I thought perhaps sharing an example of this might help. Here is one of 
these problems published for public access (no authentication required but of 
course automatically in practice mode):
    
    
http://lon-capa.illinois.edu/res/uiuc/dmills/andino/CurvedArrows/CAAD2-2.problem<https://urldefense.proofpoint.com/v2/url?u=http-3A__lon-2Dcapa.illinois.edu_res_uiuc_dmills_andino_CurvedArrows_CAAD2-2D2.problem&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=VsGo3jOm8tGLd6f-KlhT-g&m=fZS1vrYiuyCYNn4oImEjX4r_J3yLINqVnl5m3iWhEdk&s=-Cw5K9ZxVa4xFiJrO-m-zkHfPgTu4fJzG0YzbbnCsDI&e=>
    
    (works most nicely in Chrome but will work in other browsers as well).
    
    If you give it a go, you'll see that when you've made a submission it adds 
an attempt link so that you can go back and look at your previous submissions 
in a meaningful way (previous tries shows information used for the display, not 
really anything meaningful to a student).  Because the instructor I am working 
with on this envisioned giving students only 12 tries on this type of problem, 
currently it will only display 12 tries (the public version linked above of 
course has unlimited tries since it is in practice mode, but providing the 
links to previous tries will fail after 12 tries).
    
    What I've discovered is that IF the instructor for some reason needs to 
reset the problem for a student, it starts over again as it should BUT after 
they've made a first try, if they click on the "attempt 1" link, it will 
display not their first try after the reset, but their very first try from 
before the problem was reset.  My question then is, is there some way to 
identify if there has been a reset that I could make use of to start again with 
the tries after the reset?  It's not a huge deal -- resetting won't occur 
often, but it's an annoyance and I do have other problem types that provide 
links to view previous attempts as well where I'm sure this is a potential 
problem.
    
    Thanks as always for any hints clues or advice that can be provided!
    
    
    Doug
    
    Douglas Mills
    Director of Instructional Technology
    Department of Chemistry
    University of Illinois
    
    
    From: "Mills, Douglas G" <dmi...@illinois.edu>
    Date: Wednesday, April 4, 2018 at 3:52 PM
    To: Discussion list for LON-CAPA users <lon-capa-users@mail.lon-capa.org>
    Cc: "Mills, Douglas G" <dmi...@illinois.edu>
    Subject: Differentiate between tries when a problem is reset?
    
    HI All,
    
    I've created a problem where viewing previous tries the normal way is not 
very meaningful to the students and so am referencing their attempts and giving 
them a series of links they can click on to display a visualization of their 
previous attempts. This all works fine. However, in the case where for whatever 
reason the instructor RESETS the student's access to the problem so that they 
can start over, Lon-Capa maintains the record of their attempts from before the 
reset and continues to reference those.  I'm wondering, therefore, if there is 
some way in the event of an access reset to differentiate between the new 
attempts vs. the old (pre-reset) attempts.  
user.resource.resource.<partid>.tries resets so that the number of tries is 
again 0, 1, 2, etc.  but 
user.resource.1:resource.<partid>.<responseid>.submission continues to keep 
track of ALL submissions.  I'm sure I'm missing something simple. Thanks for 
your help!
    
    
    Doug
    
    Douglas Mills
    Director of Instructional Technology
    Department of Chemistry
    University of Illinois
    
    _______________________________________________
    LON-CAPA-users mailing list
    LON-CAPA-users@mail.lon-capa.org
    http://mail.lon-capa.org/mailman/listinfo/lon-capa-users
    

_______________________________________________
LON-CAPA-users mailing list
LON-CAPA-users@mail.lon-capa.org
http://mail.lon-capa.org/mailman/listinfo/lon-capa-users

Reply via email to