Messages

76

Modification Help / Re: Client event optimizations, packages and case-insensitivity

« on: November 28, 2017, 04:31:33 AM »

Possible, but wouldn't it be easier to make a table from the start? It's most probably faster as well, but I haven't seen how findText works under the hood.

As I got the NTNames to work, and I can assume that event names wont change after server start, there is a chance that I'll do as Electrk suggested on Discord with generating the table once when opening the event window.

77

General Discussion / Re: EventScript - Eventing 2.0

« on: November 28, 2017, 04:27:53 AM »

I'm working on it. I'll just need to find a fix around that and then I'll get to work.

78

Modification Help / [EventScript] Client event optimizations, packages and case-insensitivity

« on: November 26, 2017, 04:58:34 PM »

This issue is quite complicated, but I'll try to explain what I want to accomplish and what I've currently done as detailed as possible.

What I want to do
My Add-On EventScript currently uses findText on the client for GuiPopUpMenuCtrl to get the id for an event in a selection. However, this function is case-sensitive, which resulted in a suggestion to solve.

Therefore, I planned to override/package four functions that handled the registration of event names and NT names, giving me a lookup table for names, also indirectly giving me a case-insensitive way to get names.

Code: [Select]

clientCmdRegisterInputEvent
clientCmdRegisterOutputEvent
SimGroup::CLIENTaddNTName
SimGroup::CLIENTremoveNTName

What I have done
I found out that the last two was actually possible to override completely, replacing the existing functionality with one that is significantly faster.

The two first is an another story. I've checked through trace, but they are untraceable. I tried override, but they are not called by BL, but when I call them manually, they are called normally. When I package them, it's the same as override.

Here is a pastebin with what I've done so far: event_table.cs

Possible solutions

• Package WrenchEventsDlg, so when opened it'll just generate the lookup table on the fly. This is worse performance-wise, as it means that it'll be called each time when opening the window instead of when the user joins the server.
• Generate the table locally before going through the events to reduce the maximum lookup to a minimum. Could work, but as this script parsing is done in one run, it means that there could be a possibility of small lag when there is lots of events that needs to be parsed. Especially for output events.
• Just don't do it. It's not worth the effort and are considered micro-optimization. It's not that big of a hit to the performance than one might thing, considering that everyone else is doing it. At worst, you'll have 60 lookups on a list of 60 events, which is only 3600 iterations in total.
• Package GuiPopUpMenuCtrl::add and store the table list in there, ignoring the findText entirely. Two problems arise here: It will be added for all lists and therefore will be a really ugly way to add such thing; If the same value is added twice, then this wont work, but luckily it wont as events are limited that way anyway.

Anyone got a better solution?
Feel free to discuss better possible solutions, or maybe if you got an answer to how to fix this, as that would be the best optimization on all cases.

79

General Discussion / Re: EventScript - Eventing 2.0

« on: November 26, 2017, 07:33:22 AM »

That looks alright, but I would make one change if I were you:

A better package name. In your case, I would suggest MEGA_EventScriptPackage.

Anyway, I'll see to add support for a more advanced system when it comes to input from other add-ons and consistency between scripts and events that have been copy-pasted. I left an issue to solve this eventually, but I cannot guarantee that I'll be able to add it the next few weeks. For now I got the urge to fix the case sensitivity and no-parameter-newline-hack. The problem that occurs with case sensitivity, though, is that it might slow things down as there is no real brick table available. I'll see to add such a thing soon so it'll become way faster to get the names and also make it case-insensitive.

80

Add-Ons / Re: Make Eventing Great Again

« on: November 25, 2017, 03:24:28 AM »

Would you mind adding support for EventScript?

I added how you may be able to do such a thing here.

Or at least tell me how I should fight this monstrosity?

81

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

« on: November 23, 2017, 12:44:29 AM »

Download this again. Made a quick fix for invalid ui path. Might resolve possible crashes when opening editor.

82

General Discussion / Re: EventScript - Eventing 2.0

« on: November 22, 2017, 03:47:42 AM »

We got problem with the Mac. Apparently they cannot use the keybind I set up. I'm currently working with Jam Jar to solve this issue, but if anyone else got information about it, please be free to let me know as that would be of big help.


Other than that, some client Add-Ons that heavily modifies the event window will break my script(Which is based on default behavior). So either I need to make a workaround for those, or I'll give a small scripting lesson of how easy it really is to make their own client implementation to work this issue out:

First off, override EventScriptClient_save and EventScriptClient_load. The first returns the script and the second takes in a script parameter.
Secondly, there is two functions that is used to parse the script: EventScript_toScript and EventScript_fromScript. The first one takes in a script and an error handler parameter and returns an object. The second takes in an object and returns a script.

The object mentioned is just a list. It is best described like this:

Code: [Select]

%list.count;
%list.value[%i, "line"];
%list.value[%i, "enabled"];
%list.value[%i, "delay"];
%list.value[%i, "inputEventName"];
%list.value[%i, "targetName"];
%list.value[%i, "NTName"];
%list.value[%i, "outputEventName"];
%list.value[%i, "params"];
%list is the object, count is the amount of events and %i is the index. The rest talks for itself.

As long as this is followed, it's really easy to implement this into their own Add-On. If anyone have anything else to say about this, then please be free to do so.

83

Modification Help / Re: [BL SOURCE CODE/REFERENCE] Building related functions

« on: November 22, 2017, 02:01:43 AM »

You shouldn't have to stress over getSafeVariableName. So long as you're not exporting $myVar* anywhere, you can use any string you want.

Fair point.

84

Modification Help / Re: [BL SOURCE CODE/REFERENCE] Building related functions

« on: November 21, 2017, 02:07:11 AM »

I've never heard of those functions before
that would be useful to know

This is the very reason that scripting to Blockland is difficult as there might be information available, but most of it is that you decipher yourself and never share it.

From what I know, expandEscape will add escape character(backslash \) for certain characters, like backslash (\) and quote (").
The other function, getSafeVariableName, will cleanup the string so it contains characters that could be used inside of a variable:

Code: [Select]

$myVar[getSafeVariableName($arrayIndex)];
Of course, anything could be put there anyway, but it's most recommended to use it to make sure you are in the green.

And as always, I could be completely wrong on this, then please correct me.

85

Modification Help / Re: [BL SOURCE CODE/REFERENCE] Building related functions

« on: November 21, 2017, 01:18:03 AM »

I've no idea why those RP functions are broken like that, but whatever.

They all used eval and had a way of manipulating it to run code.

The functions cannot be overwritten. So yeah, they'd have to be changed in an update. Hopefully not making the same mistake again.
[...]
Then for real serious stuff, there's breaking the function from existing entirely, so that people will stop doing dumb stuff to get backdoored add-ons to work on their servers.

That is RP Core. All those four functions had eval in it. The first one was obvious and I removed it due to that. The other three was perfectly fine, unless some other Add-On modified its variables to make it look like RP Core was the culprit.

I am well aware that I should have handled it differently, but at the time I was taken by surprise when Badspot suddenly pulled the plug without even giving a reason for it. I had a discussion with Iban about it as well, and now, 7 years later, I understand why he was bothered by it. However, I am really annoyed how both reacted instead of trying to help to fix it. For instance, there is this these handful of magic functions that will help with making data for eval work better:

Code: [Select]

expandEscape
getSafeVariableName
I didn't know them at the time, and no one told me about it either. Everyone expects new scripters to be an expert as everyone else. If you don't, then they are going to punch you so hard that you wont script anything ever again. I could add more, but that belongs to Drama.

86

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

« on: November 19, 2017, 03:16:33 PM »

Added mixing of indexes and ranges.
Fixed so index can have only one argument.
Fixed ui paths.

Download

87

General Discussion / Re: EventScript - Eventing 2.0

« on: November 19, 2017, 01:12:28 PM »

I added labels in the latest version. They work as the second version of what Platypi suggested. More information is in the OP. I might make a better guide later on as this progress. The op is not a mess, but it lacks information, and it's not consistent with how it's written. Whenever that will happen...

As I got some free time, I'm fixing up the indexing/range feature to make them more interleaved:

Code: [Select]

[3:7,9,15,20:23]

It's the exact same semantic as fireRelayNum, so it should be quite easy to make it.

Edit: Well, that went faster than I expected. Released an update with that addition.

88

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

« on: November 19, 2017, 08:47:52 AM »

Added labels.
Added more characters for target name.
Tells the user they cannot have numbers at start of input name.

Download

89

General Discussion / Re: EventScript - Eventing 2.0

« on: November 17, 2017, 12:53:34 PM »

<label:start>
lines
<label:end>

I am sorry, but that syntax is really ugly. I don't want to introduce XML into this. I'm going all in on Platypi on this now.

90

General Discussion / Re: EventScript - Eventing 2.0

« on: November 17, 2017, 12:23:00 PM »

You are absolutely correct. The main purpose of labels is in fact to name a position in the memory, which means that using them this way should work accordingly. However, I would like to point out that even though we have in this case addresses(line-number-ids), I like the second version that Platypi suggested, by putting the labels on the same location where they belong, which means that the indexing wont work like [start:end-1], but instead work like [start:end]. This shouldn't confuse the programmer as we are defining an inclusion range, from start to and including end.

I may of course be wrong in this, and that's why I leave it in the open for discussion. I might be able to add labels later this evening, but it'll be made so it's easy to change it according to how you guys really want it.