What would you like to see in Nexus?

Tysandr

Now that there's a contest for writing Nexus scripts, I've uploaded a couple of hopefully helpful aliases for budding contesters:

`echo simulates Mudlet's echo.

This allows you to push and test triggers without needing server input.

It utilizes client.handle_read and I will not be liable for any broken IAC-GA messages. 

To multiline, just replace newlines with +n.


`js simulates Mudlet's lua alias.

Beware: this utilizes the dirty eval() function.

I will not be held liable for any damage done to your browser/computer.



Click the sig for more.

W

Krypton

ECHO with \n newlines already exists serverside.

Laedha

Is anyone else having trouble with the wilderness map zoom since the update? I have mapmod installed and using that to zoom used to work for both the regular map and the wilderness map. Now it only works for the regular map. Is there some kind of command internal to nexus to zoom the mini map? I think the scroll wheel might work on a desktop but I use a laptop exclusively. 

Zahan

I'm not sure what you mean. 

One whole point of the wilderness map scaling in my mapmod plugin is because it lacked a zoom (else I'd just have set the zoom).  Instead, [in mapmod] you set the font_size and line_height according to your window size, to simulate zooming.

Laedha

Zahan said:

I'm not sure what you mean. 

One whole point of the wilderness map scaling in my mapmod plugin is because it lacked a zoom (else I'd just have set the zoom).  Instead, [in mapmod] you set the font_size and line_height according to your window size, to simulate zooming.

Thanks, I forgot that's how to change the size of the map. It got set back to 11 somehow. 

Tysandr

*Resurrect*

While trolling through Nexus code to discover if 'path track xxxx' is native to Nexus or serverside, I noticed something.

// exact, begins, substring, regexp
// used by aliases and triggers
var do_matching = function(text, pattern, type, whole_words, case_sensitive) {
    ...

    else {
        <b>// TODO: cache this for faster matching!</b>
        var re = pattern;
        ...
        try {
            <b>var exp = new RegExp(re, opts)</b>;
        } catch (msg) {
            print("<b style='color: red;'>RegEx Error in Pattern [" + re + "]:</b><br/>" + msg);
            return null;
        }
  ...

Looks like it's already planned to go ahead/be fixed.

Looks like do_matching is called by handle_triggers < read_data(packet)

Similar fix to my client created the biggest performance improvement. (Despite Fastdom being amazing.)

It really wasn't noticeable until I started coding for combat and generated upwards of 600 triggers. (I write a lot of redundant stuff lel.)

With 600 triggers generating regex on the fly, walking into a larger room with lots of parsing took about 200ms of processing time. When I prefab'd/cached(? is this the technical term) the Regex when the trigger was interpreted, I dropped that to about 12 - 20ms despite having (now) 735 triggers.

Would recommend fix sooner rather than later.

Shub

I'd really like more ability to move and resize the panels without having to make them all float. I like to have a thin strip on the left side, the main window, then two wider columns on the right side. I guess some JS mastery could make if possible.

Zekeros

I dislike the ability to make echos consistently the same colour, I didn't notice a way to store the colours I chose or even some pre-chosen colours. The slider makes it difficult to find the colour I had used, unless I missed something?

Tecton

Tysandr said:

*Resurrect*

While trolling through Nexus code to discover if 'path track xxxx' is native to Nexus or serverside, I noticed something.

// exact, begins, substring, regexp
// used by aliases and triggers
var do_matching = function(text, pattern, type, whole_words, case_sensitive) {
    ...

    else {
        <b>// TODO: cache this for faster matching!</b>
        var re = pattern;
        ...
        try {
            <b>var exp = new RegExp(re, opts)</b>;
        } catch (msg) {
            print("<b style='color: red;'>RegEx Error in Pattern [" + re + "]:</b><br/>" + msg);
            return null;
        }
  ...

Looks like it's already planned to go ahead/be fixed.

Looks like do_matching is called by handle_triggers < read_data(packet)

Similar fix to my client created the biggest performance improvement. (Despite Fastdom being amazing.)

It really wasn't noticeable until I started coding for combat and generated upwards of 600 triggers. (I write a lot of redundant stuff lel.)

With 600 triggers generating regex on the fly, walking into a larger room with lots of parsing took about 200ms of processing time. When I prefab'd/cached(? is this the technical term) the Regex when the trigger was interpreted, I dropped that to about 12 - 20ms despite having (now) 735 triggers.

Would recommend fix sooner rather than later.

Added this in today, you should see some pretty decent performance improvements if you've got a lot of triggers!

Tesha

Is there anything to convert a mudlet profile to a nexus profile? If there was, I'd probably switch. Otherwise it'd be waaaaaaaaaaaaaaaaaaaaaay too much work for me at the moment.

Atalkez

Two entirely different code bases, so no.