I have this line of code in my program:
Code: If L=6:Then:"M->Str1:11->T:50->V:End
It basically jumps to a random point in the code when I use it within the game I'm making. I haven't tested it for a different program, though. The variables used, in order, are enemy appearance, text color for that enemy, and its health.
I have DCSE installed, but I disabled Hybrid BASIC libraries, just in case that was interfering with this. Once I removed this line of code, my program worked normally.
Try making it multiple lines. That quotation mark is making everything on that line a string.
EDIT: In addition, it is generally a good idea to write code on separate lines (usually) in order to make it more readable and easier to debug.
MateoConLechuga wrote:
Try making it multiple lines. That quotation mark is making everything on that line a string.
EDIT: In addition, it is generally a good idea to write code on separate lines (usually) in order to make it more readable and easier to debug.
Thanks. I'll see if that solves my problem (and of course it was a simple solution 
).
Edit: It does, although I'm not sure how, because a → usually closes all quotation marks. Either way, I'll take it.
I have moved this topic to TI-BASIC, which is a more appropriate place for it to reside. To address the problem in question, that STO (->) symbol should indeed terminate the string; I'm not sure what's going on. If you disable the Doors CSE parser hook, does this problem vanish or remain? Regardless of whether this is a Doors CSE or OS bug, it would be good for us to get to the bottom of it.
I have had this problem before; it seems like when you use the colon to separate storing to a string variable, it likes to take the entire line as a string. I think it may be along the same lines as being unable to place Lbls after a colon.
KermMartian wrote:
I have moved this topic to TI-BASIC, which is a more appropriate place for it to reside. To address the problem in question, that STO (->) symbol should indeed terminate the string; I'm not sure what's going on. If you disable the Doors CSE parser hook, does this problem vanish or remain? Regardless of whether this is a Doors CSE or OS bug, it would be good for us to get to the bottom of it.
How do I disable the parser hook? Now, the code only works when it's skipped over, with the fix Mateo suggested.
It appears to be a DCSE bug, because there are no Lbl commands in the structure that that code is in leading back to an earlier point.
MateoConLechuga wrote:
I have had this problem before; it seems like when you use the colon to separate storing to a string variable, it likes to take the entire line as a string. I think it may be along the same lines as being unable to place Lbls after a colon.
Which calculator and OS did you experience this on? I've never run into either of the issues you mention on older calculators.
I've experienced this issue when working with Pokemon Purple. Weregoose stumbled upon the fact it was a problem, and we pawned it off as an issue using Celtic2.
KermMartian wrote:
MateoConLechuga wrote:
I have had this problem before; it seems like when you use the colon to separate storing to a string variable, it likes to take the entire line as a string. I think it may be along the same lines as being unable to place Lbls after a colon.
Which calculator and OS did you experience this on? I've never run into either of the issues you mention on older calculators.
Well, here's an example of this problem: From what I know, it happens on the TI83/84+ series, no matter the OS; this was tested on a TI 84+ with 2.55 though.
Code: "Matt->Str1:Lbl A:Disp Str1:Goto A
At first you would think this displays "Matt" over and over again, but it just quits and throws Error:Lbl. Just another reason not to use Lbl and Goto unless absolutely nessasary.
EDIT: However, if you do this:
Code: "Matt->Str1
Lbl A:Disp Str1:Goto A
It works just fine. I haven't yet come up with an explanation...
EDIT: It could be that when the OS searches through the program during runtime to find the label, it will ignore the lines that have an unclosed " around them, which means that that could also be why it happens inside of conditionals as well.
Something you need to know about the BASIC parser. It's broken. It does a lot of dumb things. BrandonW went on a rant one night in HCWP that lasted.. I don't even remember, as he explained a lot of dumb things it does that could be done better.
Needless to say, it was quite amusing.
I think Kerm even went on a tangent as he traced issues it had..
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
