Anyone any clues on whats causing it?
Unknown Error
Unknown Error
I'm recieving this error but the place it points too is just a bit above my head.
Re: Unknown Error
A string.split that was given nothing to split
Re: Unknown Error
Congratulations, you have been promoted to the rank of Captain Obvious.
This might be tied into it (seems like the function its referring to involves colours). Signing into Achaea and sending messages both cause Mudlet to crash, if i comment out getFgColor() then it works fine (well, no colour but no crashing either).
EDIT:
Tested it with "ii" too, which also contains blank lines and the same crash occurs. Guess it could be selectString too if the line is just empty space.
Go Captain Obvious, use your obvious powers!!!
This might be tied into it (seems like the function its referring to involves colours). Signing into Achaea and sending messages both cause Mudlet to crash, if i comment out getFgColor() then it works fine (well, no colour but no crashing either).
Both messages and the sign-in screen have empty lines, could be the cause?
EDIT:
Tested it with "ii" too, which also contains blank lines and the same crash occurs. Guess it could be selectString too if the line is just empty space.
Go Captain Obvious, use your obvious powers!!!
-
- Posts: 186
- Joined: Sun Nov 14, 2010 5:57 am
Re: Unknown Error
Could start with 1 not being a douche, and 2 getting rid of the extra end in your script, but that's just me.
Re: Unknown Error
You need to check the return value of selectString() to find out if an error occurred i. e. an invalid or impossible selection. If you use functions that operate on an undefined selection, the behavior is undefined and Mudlet may even crash. Usually, I've added safety code that traps those exceptions and silently ignores those cases, but obviously not in this case. I'll look into this and fix it if necessary.
PS: Your local variable "line" overshadows the built in global "line" that holds the current line as a string value.
PS: Your local variable "line" overshadows the built in global "line" that holds the current line as a string value.
-
- Posts: 186
- Joined: Sun Nov 14, 2010 5:57 am
Re: Unknown Error
I've noticed at least two occurances of people overwriting global variables on accident, perhaps a new global var access scheme is in order? Even just prefacing them with an _ or something to keep people from messing them up might help out.
Re: Unknown Error
I wouldn't like to be using _line and etc all over. They just learn quickly upon discovering the error, eventually the knowledge will spread so support for discovering this source of error will be quick. We'll do a better job of describing these special variables in the manual as well.
I think this sort of education and ease of use will trump the added complexity, personally.
In this case especially, since line is a local, all that means is that he won't be able to access the global line directly - which, if he knows about and wants to access, he'd either change his local then or use _G.line. So it's a non-issue in this example.
I think this sort of education and ease of use will trump the added complexity, personally.
In this case especially, since line is a local, all that means is that he won't be able to access the global line directly - which, if he knows about and wants to access, he'd either change his local then or use _G.line. So it's a non-issue in this example.
Re: Unknown Error
Also, tons of people have already used global variables like line all over the place in their scripts. They'd all have to go around and change things again - possibly after a period of not realizing this had changed and getting quite frustrated at why their scripts no longer work. It might cause more headaches than it would prevent.
Re: Unknown Error
No, this is not going to happen because Mudlet's #1 dogma is to always stay backward compatible.
What we should look into, however, is that internal variables of the Lua API should be renamed to something that is not likely to be chosen as variable names by end users. This won't affect many places anyways.
What we should look into, however, is that internal variables of the Lua API should be renamed to something that is not likely to be chosen as variable names by end users. This won't affect many places anyways.