Do I have a doozy for ya...
Elmwood University. The way the author coded it... Variable changes aren't detected by URM. Instead of a choice leading to, let's say "RP +=1" it leads to "the next label" where variables change right at the start of it. So URM doesn't "properly" detect the change as usual since the code is so weirdly structured (but once you understand it, you get the logic)
here's a snippet of code...
Code:
ch "So who was your favourite, [pname]?"
scene e1cheer81 with dissolve
default e1bestsplits = "None"
menu:
"Chelsea":
$ e1bestsplits = "Chelsea"
jump cheertalk7ch
"Lydia":
$ e1bestsplits = "Lydia"
jump cheertalk7ly
"Ella":
$ e1bestsplits = "Ella"
jump cheertalk7el
"You were all great":
$ e1bestsplits = "All"
jump cheertalk7all
label cheertalk7ch:
call chlike from _call_chlike_2
call eldislike from _call_eldislike_1
scene e1cheer81 with dissolve
p "You were the best, Chelsea."
scene e1cheer84a with dissolve
ch "Aww, thanks! I think Ella was better though."
jump cheertalk8
label cheertalk7ly:
call lylike from _call_lylike_4
call eldislike from _call_eldislike_2
scene e1cheer81 with dissolve
p "You were the best, Lydia."
scene e1cheer82a with dissolve
ly "Thanks, gorgeous. But I have to disagree, I've got nothing on Ella."
jump cheertalk8
So when URM detects a choice... it only shows "jump cheertalk7ch"... and WHEN you start that label, chlike and eldislike are other labels that modifies variable values (if you know the variable name, URM will give you the value) but URM won't inform you of it.
it's not really a bug, at all, it's the way this code is structured. URM wasn't designed to "look that far" into the code... Think you can overcome this ?