Pattern match with molecular editor

A question type where the user enters their response using the JavaScript Molecular Editor, and the response is then graded using the OU's pattern-match algorithm.
Price option: Free

Supports Moodle 2.1-5.0 See all versions
Latest release: 10 months ago
Installations: 316
Downloads (last 90 days): 89

Frankenstyle name: qtype_pmatchjme
Question types
Open University

Comments

Comments are no longer open for new posts. Existing comments remain available to read.

Great spot jason. Sorry about that.
It turns out that the zip in the Plugins directory is a bit out of date.
The git repository https://github.com/moodleou/moodle-qtype_pmatchjme is more up to date but there are two fixes that still need to be deployed to it.
I'm in the process of applying and testing the fixes. Then I will push to the repository and get the plugin zip in the plugins database updated.
I am running into issues with this plugin on my moodle 2.6.4 installation. I have installed version 1.4 following the instructions listed here however when I create and preview a question of this type in moodle the JME applet does not load.
I see in my access logs that a request is being made for /question/type/pmatchjme/jsme/jsme.nocache.js
This file(s) are not included in this plugin. I have the jmol/jsmol filter installed in my moodle installation. Any help would be appreciated
George can you find out exactly what the molecule or the correct answers are so that I can try them.
I had a client reported the following JME problem. Please help to identify the issue.
"
The JME editor now seems to work perfectly; however, the question engine does not recognize either of the correct answers when they are given. I assume this is a problem with the pattern match mechanism, since there is a function in the JME Editor to acquire the SMILES string and it is identical to the SMILES string entered in the question (although the question version requires escape characters, as per the manual: http://labspace.open.ac.uk/mod/oucontent/view.php?id=470268&section=5.5.2). "
Now is OK, new install was without problem, upgrades problem was in history track.
That is roughly what I am doing. I will ask you to peer review the patch when it is done.
Hi,
Thanks for fixing this Tim. I was using get_string to fetch the human name for the SMILES character suffixing the character with 'smiles' and then passing it to get_string. I guess one way to fix this might be to prepend big_ onto an upper case character and convert it to a lower case character appending that to smiles and looking up the translation with get_string
Ah. Well of course in SMILES 'c' and 'C' have clear, and different, meanings. 'c' is aromatic (as in benzene rings); 'C' is aliphatic (straight chains). Which tells you what to call them to distinguish them for the SQL.
Just to explain what is going on here. There are actually two different strings here: smiles_c and smiles_C. You can see those are different. I can see those are different. MySQL thinks they are identical.
However, it is probably not a great idea to have two language strings that differ only be upper/lower case, so I will fix this.
We're about to start looking at 2.3. I'll get this issue fixed as part of that.
Error in language pack in version 2.3 (2012081600) occurs too. Very sad for us.
thanks nice info..video pool