Quote:
Originally Posted by Chompy
If you can pinpoint things directly, lets say variable name being the same as the key order, why just not check if it exists?
Lets take a modular example, with great possibilities when it comes to expanding the concept as a system.
http://pastebin.com/A21Yc1sA
I had to pastebin it, since I got an Access Denied when trying to post the code.
I wrote it without testing it, but the general idea should be there. I also made it much bigger than it had to be, but it was fun. Could easily become something bigger, it's quite flexible if some more changes are done to it. Also made it so you have to enable the possibility of doing combos.
This code is not done at all, I just wrote it for this post to illustrate an example.
|
I have a lot of respect for the amount of effort you put into that example. However, I need to respectfully disagree.
To begin, I assume you put this._ instead of just this. because their typing something like "function()" would have done "this.function()" - and makevar would cause that to retrieve the function's value. Or typing 'x' would return this.x in that scenario. In yours, this._x would be safe, as would this._function(). I get that.
However, I feel if you wanted to test for a variable without just outright doing this.(@var) due to potential exploit or mistake, then why not do something like this.code.(@var)?
That would retain its security/lack of false positives, without having to use makevar(" " @ " ")-type of stuff. What do you think of that?
In addition, I see an overarching flaw with the entire concept there.
If a player typed "dreanm" over 0.5 seconds (fast typist), it would fail. I'm sure they'd quickly realize "oops, I hit N when reaching for M!" and quickly re-type "dream" over 0.5 seconds. In such a scenario, the player basically spend about 1-1.5 seconds typing "dreanmdream" -- and it wouldn't even function. As a player, that would lead me to believe that perhaps "dream" is not the correct answer.
Since a player wouldn't KNOW that the reset time is 2 seconds, it could cause problems. If they went to type "dream" but typoed and put "dres" and then realized "ugh I accidentally hit S" and then only waited 1.5 seconds and began typing "dream" over, the script would probably intercept them around the "a", resetting their text back to nothing, and then receiving "am."
As an aside -- in that scenario, it looks like your script would actually interrupt them when they hit the "a" to perform a grab. Is that intended? Or perhaps my glance was a bit too cursory. If so, I apologize. But if the "a" didn't perform a grab in this scenario -- what would? Pressing "a" and then waiting 2 full seconds for it to register?
Back to the original point: so the player now has "am" and realizes the script didn't work. They might think "Hmm I'll try again" and immediately start typing "dream" -- except now the code sees they've put "amdream." Doesn't work again.
By now, the player probably gives up the idea that it's "dream." Sure, a smart player might take his hands off the keyboard, wait 5-10 seconds, and re-type it with a "clean slate" so-to-speak, but not all players will be that keen to how the system might work.
Do you see what I am saying, regarding this user-unfriendliness? The reason I had my "freeflow" style (which you referred to as "combos") is so that a player could put 0295892058025asdf258058 and still get credit for "asdf" as soon as that final "f" was hit, while putting "qawesedewfs" would not register "asdf" because "asdf" is not in one place altogether.
I never intended for "combos" to work the way you seem to understand, where "asdfqwer" should do some special function (equal or better than "asdf" + "qwer"). In where I put "// code triggers" I was implying that when the "f" was typed of "asdf," the script would stop reading the player's text, begin a fixed delay period, execute the function associated to the "asdf" code, and finally resume reading the player's text when said function terminated. I simply wanted the "freeform" continuity of typing for these such mistakes and typoes! If I may, I'd like to add that I believe the "combos" idea is a neat one, it just wasn't my idea.
When I saw you explain your method (before I saw your script), this is how I interpretted your explanation. Let me reiterate that I think it's a great idea of a method to do this, and I appreciate you bringing it to my attention.
PHP Code:
//#CLIENTSIDE
const prefix = "code";
const remove = 2;
const codeLength = 4;
enum codes {
"asdf" = true;
"qwer" = true;
"zxcv" = true;
"etc1" = true
};
function onKeyPressed(temp.keycode, temp.key) {
this.text @= key;
temp.test = text.substring(text.length() - codeLength - 1, codeLength);
if (codes.(@text)) {
this.trigger(prefix @ text);
}
scheduleEvent(remove, "remove");
}
function onRemove() {
this.text = this.text.substring(1);
}
function onCodeASDF() {
// This would occur if a player typed asdf, even if they typed "qsasdfrwg" -- the "rwg" wouldn't register, "asdf" would trigger and begin a function. Reading would resume (with no text) once the "asdf" function concluded)
}
In THAT interpretation, I could see your idea being highly efficient. Even still, due to the limitation of '4', I don't think it's worth it. Also, I have doubts that this system is more efficient than the 'in' method I discussed in my second post (suffers same limitation).. And outside of that interpretation, I don't see a gain of efficiency.
I know that you said that my original method involved a loop, but how is that less efficient than what you posted? Because switch()case: is that much more efficient due to being slightly more low-level than a loop? That's the same order of magnitude of checks (a system with 50 different codes: in my system, it's a loop of 50. In your system, it's 50 case: checks. Same order of magnitude. 50 checks for both!). I think that's splitting hairs at that point, and there's no denying that for such a small efficiency gain, my original method was far more readable and editable, only requiring an entry change into an array at the top (+ function definition), as opposed to having to add a new "case:" into the middle (+ function definition). I will definitely give you credit where credit is due, though, and say that your critique made me consider an "array"-based system, which I truthfully believe to be the most efficient system.
Final note: I still think my original script to be the most readable, and retains high editability even to non-scripters.