Messages

91

General Discussion / Re: EventScript - Eventing 2.0

« on: November 17, 2017, 10:26:51 AM »

I just added indexing. It means that you can specify either specific indexes, or ranges. This addition is just a leverage for the next update with labels. Please do tell if any errors occurs.

Example:

Code: [Select]

onActivate->Self->toggleEvents([1:3])
[ 500]onRelay->Self->setColor(1 0 0 1)
[1000]onRelay->Self->setColor(0 1 0 1)
[1500]onRelay->Self->setColor(0 0 1 1)


92

Add-Ons / Re: [Support] EventScript - Sharing events for the future

« on: November 17, 2017, 10:21:35 AM »

Added indexing

Download

93

General Discussion / Re: EventScript - Eventing 2.0

« on: November 17, 2017, 06:48:08 AM »

I am using Make Events Great Again. I'll make sure to disable it if I do any more testing in the future.

I wont deal with them, as they need to make their own adapter toward my parser. It's quite easy, as it's just a list with the events.I wont have time to contact them, so feel free to do so.

Another benefit of explicit, non-bracketed labels is that it might actually make code a bit more intuitive, and hence make parsing easier to a certain extent. If we go with bracket notation, we have to consider four different cases:

• no brackets - default behavior
• 1 bracket - label (?)
• 2 brackets - no label, enabled and delay
• 3 brackets - label, enabled, and delay

This would require you to pre-parse each set of brackets, and then decide how to treat each of them.

But with labels declared separately with colons, we only have to consider two cases for brackets:

• no brackets - default behavior
• 2 brackets - enabled and delay

I imagine this would require less (or no) pre-parsing, as the presence of a forward brackets indicates that the second case is the one to consider.

Actually, I said that both are optional, but in fact, I'll take this example as a show of what's valid:

Code: [Select]

[x][0]onActivate->Self->setLight("Player's Light")
[0][x]onActivate->Self->setLight("Player's Light")
[0]onActivate->Self->setLight("Player's Light")
[x]onActivate->Self->setLight("Player's Light")
onActivate->Self->setLight("Player's Light")

Yes, all five are valid. My parser will figure out what is correct, hence why adding a label to it wouldn't be such a problem. Just a couple more checks.

Another option could be blocking instead of labeling, e.g.

Code: [Select]

# Turn light on
lightOn {
[x][0]onActivate->Self->setLight("Player's Light")
[x][0]onActivate->Self->setEventEnabled({lightOn}, 1)
[x][0]onActivate->Self->setEventEnabled({lightOff}, 0)
}

# Turn light off
offStart {
[][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled({lightOff}, 1)
[][0]onActivate->Self->setEventEnabled({lightOn}, 0)
}
Albeit less flexibly, this feels more intuitive, and it looks a bit nicer to me. If we want to increase the flexibility of this method, we could allow for the inclusion of multiple blocks in a block reference, i.e. {label1, label2, label3}. And as the cherry on top, this method would probably be the easiest to code up, as it doesn't allow/encourage the use of arithmetic inside intervals/block references.

I would say, too, that the ability to nest blocks need-not and should-not be implemented with this. Eventing is more 1-dimensional than most programming languages, and hence doesn't need such complexities. Plus, nesting would add a whole other layer of complexity to the code.

As you say, this is not a way to go. And I will never make such a thing because it adds too much complexity to an easy problem. I would say that for now we'll go for the C-like labeling and I'll check with a few more if it's the best route.

94

Add-Ons / Re: [Support] EventScript - Sharing events for the future

« on: November 17, 2017, 04:58:44 AM »

Improved the parsing significantly.
Added an in-game editor for convenience and several other client improvements.
Many bugs fixed.

Download


Sadly, I doubt I'll be able to work any more on this in the next 3 weeks. But I do have plans for it, as mentioned in the discussion topic, so please do look forward while I improve this.

95

General Discussion / Re: EventScript - Eventing 2.0

« on: November 17, 2017, 04:34:15 AM »

That's good to hear! Best of luck on the redesigning. Making parsers is a bitch.

And I just finished rewriting most of it. There's only the one thing with output events and its parameters that needs to be adjusted so you may put the parenthesis on a new line, which you cannot do now.

Sure. How about this?

Code: [Select]

# Makes a brick change colors on a loop when toggled

# Start color changing (start with events enabled)
[x][0]onActivate->Self->playSound("Beep_Checkout.wav")
[x][33]onActivate->Self->fireRelay

# Stop color changing (start with events disabled)
[ ][0]onActivate->Self->playSound("Beep_Denied.wav")
[ ][0]onActivate->Self->cancelEvents

# Alternate between starting and stopping color changing
[x][0]onActivate->Self->toggleEventEnabled("0 1 2 3")

# Change colors
[x][0]onRelay->Self->setColor("0.898039 0.000000 0.000000 1.000000")
[x][500]onRelay->Self->setColor("0.898039 0.898039 0.000000 1.000000")
[x][1000]onRelay->Self->setColor("0.000000 0.498039 0.247059 1.000000")
[x][1500]onRelay->Self->setColor("0.200000 0.000000 0.800000 1.000000")

# Loop color changing
onRelay->Self->fireRelay

# Stop color changing when brick is blown up
onBlownUp->Self->cancelEvents


I ran your script and it parsed perfectly. However, it will display a warning for the colors if they don't exist in the colorset. Also, I noticed that on line 21 it didn't have any delay, which will destroy the whole purpose. I've put 2000 delay on it and will update all my examples to this instead and credit you.

Please note that I couldn't get the latter code to import to a brick. In fact, I tried pasting

Code: [Select]

[ ][500]onBlownUp->Player->Kill
from your example, and it gave me an error. It tells me I have an invalid amount of parameters.

Is fixed in next version.

Also, copying code from in-game does not seem to work. For instance, when I copy the aforementioned events from a brick, it gives me

Code: [Select]

-snip code-
which can not be pasted into another brick.

Looks like you are using an Add-On that might modify the default layout so when I read it I get bogus data. If so, please tell me and I'll find a fix around it.

While this would be simpler to parse, it's a bit clunkier, as per the disadvantages you listed. It's probably a bad idea to have labels attached to events. Granted, your label could always be listed like this

Code: [Select]

# Turn light on
[on1]
[x][0]onActivate->Self->setLight("Player's Light")
[on1]
[x][0]onActivate->Self->setEventEnabled([offStart:], 1)
[on1]
[x][0]onActivate->Self->setEventEnabled([on1, on2, on3], 0)

# Turn light off
[offStart]
[][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled([on1, on2, on3], 1)
[][0]onActivate->Self->setEventEnabled([offStart:], 0)
which would solve that problem. However, it doesn't change the weird naming problem. To fix that, you could simply pre-parse the square brackets at the beginning of an event listing, and allow the first to be named anything if 3 sets of square brackets are present instead of 2. It still feels a tad dirty from a coding perspective, though.

I think that labels at all is dirty. It's frowned upon in all languages but where it came from. It is sometimes a necessity, though. In our case, we're not using it like others are using it, so adding labels in such a fashion might confuse people, or make it obvious to them. Keep in mind, that when labeling is used with indexing [from:to], it's not obvious that it's to-1. By having it at the event, it might make it more apparent that we are aiming at the event, instead of the event after it.

96

General Discussion / Re: EventScript - Eventing 2.0

« on: November 17, 2017, 03:15:57 AM »

Labels [...]

I just thought about an another way to add labels, by using existing syntax.

Code: [Select]

# Turn light on
[on1][x][0]onActivate->Self->setLight("Player's Light")
[on2][x][0]onActivate->Self->setEventEnabled([offStart:], 1)
[on3][x][0]onActivate->Self->setEventEnabled([on1, on2, on3], 0)

# Turn light off
[offStart][][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled([on1, on2, on3], 1)
[][0]onActivate->Self->setEventEnabled([offStart:], 0)
As long as names within the square brackets doesn't contain only one x or only numbers(Nothing bad, as labels starting with numbers are not supported anyway), then it's considered a label. As before, this can be placed anywhere before the input name. This solution will allow the following:

• Labels are connected to the event, not confused to line, hence easier to read (Subjective)
• Opts to the current semantic of optional starting arguments (Might be confusing to some)

Of course, it has it disadvantages:

• Moving around events with labels might be more troublesome (Solved by placing it on its own line, wont break with semantic)
• Loss of labels named x (Who even want that?)

This is just a possibility. I still might end up using C-like labeling like Platypi/SadBlobfish suggested.

97

General Discussion / Re: EventScript - Eventing 2.0

« on: November 17, 2017, 12:38:32 AM »

Will this work with Make Eventing Great Again?

If it's the same as how events are currently working, it'll create scripts like normal. However, it wont magically make MEGA work by pasting scripts. I doubt I'll ever add such a functionality.

Edit: No, it will not work with it. MEGA does too much changes on the default structure, crippling my parser completely.

98

Add-Ons / Re: Event_Keypad - Create Keypads with Secure Passwords!

« on: November 16, 2017, 04:20:37 AM »

I read through you "wall-o-text" now and found out an misunderstanding of why a salt is used. Instead of explaining it with my broken english, I'll hand you a link to wikipedia to brief you about the topic:

Salt (cryptography)

tl;dr: Salt is to tackle the issue with rainbow-tables(precomputed hashes). Not to take down brute force attacks, which is what you explain.

Even if the salt is known, it would still be difficult with rainbow-tables. Brute force attacks is still possible. To tackle brute force attacks, the only way I can see is possible in Blockland is to add a time limit between failed tests. This shouldn't be needed, though, as it's hard as it is to type the password as it is now in a fast manner.

99

General Discussion / Re: EventScript - Eventing 2.0

« on: November 16, 2017, 04:10:57 AM »

Labeling was considered once while I was developing, but not something that was required. However, with your ideas I think it's entirely possible now. I've added an issue for it and will implement it while I'm redesigning the parsing algorithm. The redesign is important to solve several issues that was raised for the current design (Like: incorrect line numbering in certain cases; unable to locate certain errors).

If anyone is proficient in syntax highlighting, I would be thankful if they could implement it for Sublime Text or any other editor.

I do think the script should be case-insensitive, though. TorqueScript is already case-insensitive, so it should cause any conflicts. Hence, making things case-sensitive seems to add an unnecessary level of complexity. Any reason why you opted for case-sensitive?

Due to how the function findText works, that is not possible. However, if I can somehow use the event global variables myself, then I would find a way around to add this sort of functionality. Don't hold your breath, though, but I've already added it as an issue.

I would also recommend not including onActivate->Self->fireRelayNum in your example script, since it's a non-standard command. I was momentarily confused when I tried to paste your code, and it didn't work.

That is true. Would you mind to provide an example script? The current example is hastened just thrown together and does absolutely nothing of value and I'm not sure I can make a easy to understand event as possible.

100

Add-Ons / Re: Event_Keypad - Create Keypads with Secure Passwords!

« on: November 15, 2017, 01:40:11 PM »

no i totally understand your logic but do you /really/ need this level of security on a server? a serversided salt is already enough imo honestly - trying to reverse engineer the salt isnt efficient, esp with how long or short it can be

This is a password we're talking about. When people hear password and hashing they mostly think that it's the safest thing in the world and therefore reuses their password as they think it's the safest thing in the world. Some even go so long that they use a basic password, like 123456(Which is the most used password!), ignoring the fact that if others uses it, then the whole thing is compromised.

Yes, of course, there's nothing to secure really. Other measures could be made to ensure the safety of peoples houses. But for this one I can guarantee that at least one will loose their password this way because they're so naive for either reusing their password or using the most used password of all time. Never underestimate how either smart some people are, or how big of an idiot others are. It's better to be safe than sorry.

But I wont push this any further. I just wanted to get out my 2 cents on this as I call it a security concern worth noting.

101

Add-Ons / Re: Event_Keypad - Create Keypads with Secure Passwords!

« on: November 15, 2017, 01:10:37 PM »

even if pass is same people wouldnt be able to figure it out so it should be okay - given the way this works it probably only saves the hash if the host saves it, unless it converts the password into an event line saved into the brick

People download the save and discovers the hash. It then bruteforces on the server that had the hash with their own event until they find a match. It's no harder than that and could easily be made with a script for automation.

Once when I used the same salt on a database I found out that a test account I made had the same hash as an another account. That's because they had the same password. I could write a documentation if you really think it's tedious explaining it.

102

Add-Ons / Re: [Support] EventScript - Sharing events for the future

« on: November 15, 2017, 01:06:45 PM »

When I copy events, it seems to only use Linux line ending (\n) and not Windows line ending (\r\n).

TorqueEngine handles newlines in a weird way. It defaults to \n for NL and ignores \r completely when printed. The character is still there, but hidden. I've opened an issue to fix this, and probably will add more fixes as I go through the script.

Keep in mind, even without newlines, as long as you have an ending parenthesis or a newline before next event, it'll work just fine all on the same line.

103

Add-Ons / Re: [Support] EventScript - Sharing events for the future

« on: November 15, 2017, 09:40:25 AM »

No other language uses just a > for calling a function. C++ and C# use ->.

Don't forget PHP. XML and HTML uses < and > for tags.

104

Add-Ons / Re: Event_Keypad - Create Keypads with Secure Passwords!

« on: November 15, 2017, 08:21:22 AM »

No clue. Forgot it years ago and other people probably changed them a few times.
The point of making the salt unique and secret for the server was so that end users do not know the full hashing algorithm, making it much harder to brute force any hash, regardless of how complex the code is. Storing the salt with the brick would defeat the purpose of that. While it would make it difficult to brute force hashes as a batch (like you would if you were given a password database), it wouldn't allow the same level of security for individual ones. Using a secret server-wide salt means that those who don't know it will struggle to reverse engineer even a 4 digit numerical code.

I considered mixing the transform of the brick during the hashing stage, which would complicate brute forcing of batches. It would also resolve the possibility of an in-server brute force by building a event contraption that tries incrementing numbers against the hash taken from a numerical keypad. However, it would mean you have to reset your passwords if you move your keypad with a duplicator or something. That's one of a couple points where a bit of security was traded for usability. I did however leave the brick as a parameter to the add-on's hashing function, so if anyone feels like overwriting it, it's fairly straightforward to do so.

I can see your point, and I understood that it was something like that. However, would you consider making so you store first the checksum and the password hash as you currently do, but also add an another salt that is visible, but locked to the password? Why I want to have different hash per password is to reduce the possibility to have two hashes looking the same because two bricks really got the same password.

105

Add-Ons / Re: Event_Keypad - Create Keypads with Secure Passwords!

« on: November 15, 2017, 06:51:51 AM »

This is good an all, but why don't you make a salt for each keypad that is generated only for that hash? Most companies uses a unique salt for each user password. You are already storing the salt checksum, so storing the salt shouldn't be an issue.

Yes, I am well aware that knowing the salt makes it possible for attacks as well, but they still need to check all possibilities with the salt anyway, so why make it more complicated?