I've been using Mudlet for a while now and I really like it.
There are just a couple of things I thought about, which would make it all even greater for me, if implemented. It's very well possible however that one or two of them already exist and I simply have failed to notice them. (I'm also still using 1.0.3 so I don't know whether some things have been added in 1.0.4.)
- My probably biggest wish: Logging to any file/directory. The introduction of an automated logging function was a great thing, but it doesn't allow me to set my own path/filename to log to (as other functions like table.save() do). If this path could be set in the setting this would already be a great start, but preferably you could indicate it in startLogging() as well.
- Color triggers are nice, but rather inflexible. In Zmud there are Ansi triggers, which capture the whole ansi codes along with the text and allow you to directly trigger off them. E.g.: ^\033[33m(.*)$
This has the main advantage that you can combine regex triggers with color matching in the same line, plus you can accurately match patterns in which more than one color exist. In Mudlet you can of course first match by regex and then do additional color checks in the script. But even that will fail/get very complicated in some cases, such as when trying to match a line that consists of any number of blue letters followed by any number of white letters. ANSI triggers would solve this.
- Bitwise operators would be a -huge- help for me. I know they aren't natively supported in Lua, but there are several libraries that provide them. Of course, you can imitate most of them by implementing your own functions, but that kind of ruins the cool speed advantage you get with bit operators. Is there any chance of getting these?
- Your profile isn't saved automatically during the session, but only when you close Mudlet (or click on Save Profile manually). Whenever Mudlet crashes (which is otherwise no huge deal in most cases) I therefore tend to lose everything I've scripted since I started Mudlet. I know, I know, it's my own fault for not saving the profile often enough. But some autosave feature that saves every couple of minutes, or even whenever you do "Save Item" would be nice.
- When quitting Mudlet I get the following prompt "Do you want to save the profile Achaea?", with the possible answers Yes and No. Both will lead to the client being closed. It might be good to have a third option "Cancel", which would abort the closing process.
- I'm missing a function to create a permanent trigger of any sort. Temp triggers work nicely for many cases, but sometimes I want to be able to create a trigger from a script that will be visible in the Trigger list and persist throughout sessions. Is this possible?
- The last one is probably more a bug report than a feature request: The number of "active Triggers" in the Trigger statistics seems to be based only on how many individual triggers are activated and doesn't take deactivated trigger groups into account. I.e. an active trigger in a deactivated trigger group still is counted as an "active trigger". It would be more useful to see how many triggers are actually being parsed by mudlet.
Oh, and sorry for taking so much space here...
Some feature requests
Re: Some feature requests
Iocun wrote:I've been using Mudlet for a while now and I really like it.
There are just a couple of things I thought about, which would make it all even greater for me, if implemented. It's very well possible however that one or two of them already exist and I simply have failed to notice them. (I'm also still using 1.0.3 so I don't know whether some things have been added in 1.0.4.)
- My probably biggest wish: Logging to any file/directory. The introduction of an automated logging function was a great thing, but it doesn't allow me to set my own path/filename to log to (as other functions like table.save() do). If this path could be set in the setting this would already be a great start, but preferably you could indicate it in startLogging() as well.
- Color triggers are nice, but rather inflexible. In Zmud there are Ansi triggers, which capture the whole ansi codes along with the text and allow you to directly trigger off them. E.g.: ^\033[33m(.*)$
This has the main advantage that you can combine regex triggers with color matching in the same line, plus you can accurately match patterns in which more than one color exist. In Mudlet you can of course first match by regex and then do additional color checks in the script. But even that will fail/get very complicated in some cases, such as when trying to match a line that consists of any number of blue letters followed by any number of white letters. ANSI triggers would solve this.
- Bitwise operators would be a -huge- help for me. I know they aren't natively supported in Lua, but there are several libraries that provide them. Of course, you can imitate most of them by implementing your own functions, but that kind of ruins the cool speed advantage you get with bit operators. Is there any chance of getting these?
- Your profile isn't saved automatically during the session, but only when you close Mudlet (or click on Save Profile manually). Whenever Mudlet crashes (which is otherwise no huge deal in most cases) I therefore tend to lose everything I've scripted since I started Mudlet. I know, I know, it's my own fault for not saving the profile often enough. But some autosave feature that saves every couple of minutes, or even whenever you do "Save Item" would be nice.
Mudlet already generates a ton of data with the current way... we need to create a way to archive/delete snapshots automatically before we add autosaving in. I'll be implementing this in Lua after the weekend, you're welcome to join me in it.
- When quitting Mudlet I get the following prompt "Do you want to save the profile Achaea?", with the possible answers Yes and No. Both will lead to the client being closed. It might be good to have a third option "Cancel", which would abort the closing process.
https://bugs.launchpad.net/mudlet/+bug/339809
- I'm missing a function to create a permanent trigger of any sort. Temp triggers work nicely for many cases, but sometimes I want to be able to create a trigger from a script that will be visible in the Trigger list and persist throughout sessions. Is this possible?
permTrigger in the enxt release
- The last one is probably more a bug report than a feature request: The number of "active Triggers" in the Trigger statistics seems to be based only on how many individual triggers are activated and doesn't take deactivated trigger groups into account. I.e. an active trigger in a deactivated trigger group still is counted as an "active trigger". It would be more useful to see how many triggers are actually being parsed by mudlet.
Oh, and sorry for taking so much space here...
Re: Some feature requests
1. You should upgrade to 1.0.5 as it contains some important bug fixes. Maybe it'll be available on Sunday.
2. Mudlet can do all the logging in the world for you. Set up a trigger on .* that triggers on every line and log - or selected text only - to any path you like. -> tutorials on Lua io support or maybe even log into a database (-> luasql) or over the network? (-> lua network modules)
3. Your color trigger example can be handled easily in Mudlet by the state machine.
condition #1->^.* trigger on begin of line (pcre)
condition #2->color trigger for your first color
condition #3->color trigger for your second color
AND trigger = yes
line margin: 0 (or whatever depending on your screenwidth, needs etc.)
OUTPUT:
Cluttered Workshop.
This large, spacious room is composed of a smooth stone floor and has numerous tables of various
sizes standing upon it. Each of the tables is covered with locks, some of which are fully assembled
while others range from barely recognisable to almost complete. There is a chandelier overhead,
turning slowly with what appears to be a magical globe of light within its glass frame, casting the
shadows within this room forcibly into the corners. An odd-looking machine stands in one corner,
manually operated and covered with strange metal etching devices. A hand-carved wooden sign stands
here. A runic totem is planted solidly in the ground. Standing here puttering with something in his
hands is Schliemann the Unlocker.#####matched
table {
1: table {
1: 'This large, spacious room is composed of a smooth stone floor and has numerous tables of
various sizes standing upon it. Each of the tables is covered with locks, some of which are fully
assembled while others range from barely recognisable to almost complete. There is a chandelier
overhead, turning slowly with what appears to be a magical globe of light within its glass frame,
casting the shadows within this room forcibly into the corners. An odd-looking machine stands in one
corner, manually operated and covered with strange metal etching devices. A hand-carved wooden sign
stands here. A runic totem is planted solidly in the ground. Standing here puttering with something
in his hands is Schliemann the Unlocker.'
}
2: table {
1: 'This large, spacious room is composed of a smooth stone floor and has numerous tables of
various sizes standing upon it. Each of the tables is covered with locks, some of which are fully
assembled while others range from barely recognisable to almost complete. There is a chandelier
overhead, turning slowly with what appears to be a magical globe of light within its glass frame,
casting the shadows within this room forcibly into the corners. An odd-looking machine stands in one
corner, manually operated and covered with strange metal etching devices.'
}
3: table {
1: ' A hand-carved wooden sign stands here. A runic totem is planted solidly in the ground.
Standing here puttering with something in his hands is Schliemann the Unlocker'
}
}
You see a single exit leading north (open door).
500h, 500m, 1400e, 1400w ex-
As you can see the table multimatches[n][m] now contains the entire text in the first color and the entire text in the second color - until the next color change.
You can build arbitrarily complex multicondition triggers.
NOTE: Good that you asked for it because there was a bug that prevented color conditions from being evaluated correctly within AND triggers. This has been fixed in 1.0.5. The multistate machine approach is much more powerful than ANSI regex triggers.
4. Bitwise OR is fast in compiled languages because OR is a basic instruction of the processor itself(->machine code). In Lua this would need to be emulated -> much slower. Note that Lua code does not get compiled into machine code - and be happy about it because otherwise every little error in your scripts would crash Mudlet.
5. Autosaving is, indeed, an often requested feature that will be addressed soon. However, before anything can be done in this respect we'd need to develop a smart archiving and file deletion policy. This is open for discussion and any good proposals are welcome.
6. 1.0.5 has a series of new functions:
howmany = exists( what, type )
howmany = isActive( what, type )
enableAlias()
disableAlias()
tempAlias()
permAlias()
permRegexTrigger() and a couple of more trigger types
permTimer()
resetFormat( windowName )
7. This would indeed be a bug.
2. Mudlet can do all the logging in the world for you. Set up a trigger on .* that triggers on every line and log - or selected text only - to any path you like. -> tutorials on Lua io support or maybe even log into a database (-> luasql) or over the network? (-> lua network modules)
3. Your color trigger example can be handled easily in Mudlet by the state machine.
condition #1->^.* trigger on begin of line (pcre)
condition #2->color trigger for your first color
condition #3->color trigger for your second color
AND trigger = yes
line margin: 0 (or whatever depending on your screenwidth, needs etc.)
OUTPUT:
Cluttered Workshop.
This large, spacious room is composed of a smooth stone floor and has numerous tables of various
sizes standing upon it. Each of the tables is covered with locks, some of which are fully assembled
while others range from barely recognisable to almost complete. There is a chandelier overhead,
turning slowly with what appears to be a magical globe of light within its glass frame, casting the
shadows within this room forcibly into the corners. An odd-looking machine stands in one corner,
manually operated and covered with strange metal etching devices. A hand-carved wooden sign stands
here. A runic totem is planted solidly in the ground. Standing here puttering with something in his
hands is Schliemann the Unlocker.#####matched
table {
1: table {
1: 'This large, spacious room is composed of a smooth stone floor and has numerous tables of
various sizes standing upon it. Each of the tables is covered with locks, some of which are fully
assembled while others range from barely recognisable to almost complete. There is a chandelier
overhead, turning slowly with what appears to be a magical globe of light within its glass frame,
casting the shadows within this room forcibly into the corners. An odd-looking machine stands in one
corner, manually operated and covered with strange metal etching devices. A hand-carved wooden sign
stands here. A runic totem is planted solidly in the ground. Standing here puttering with something
in his hands is Schliemann the Unlocker.'
}
2: table {
1: 'This large, spacious room is composed of a smooth stone floor and has numerous tables of
various sizes standing upon it. Each of the tables is covered with locks, some of which are fully
assembled while others range from barely recognisable to almost complete. There is a chandelier
overhead, turning slowly with what appears to be a magical globe of light within its glass frame,
casting the shadows within this room forcibly into the corners. An odd-looking machine stands in one
corner, manually operated and covered with strange metal etching devices.'
}
3: table {
1: ' A hand-carved wooden sign stands here. A runic totem is planted solidly in the ground.
Standing here puttering with something in his hands is Schliemann the Unlocker'
}
}
You see a single exit leading north (open door).
500h, 500m, 1400e, 1400w ex-
As you can see the table multimatches[n][m] now contains the entire text in the first color and the entire text in the second color - until the next color change.
You can build arbitrarily complex multicondition triggers.
NOTE: Good that you asked for it because there was a bug that prevented color conditions from being evaluated correctly within AND triggers. This has been fixed in 1.0.5. The multistate machine approach is much more powerful than ANSI regex triggers.
4. Bitwise OR is fast in compiled languages because OR is a basic instruction of the processor itself(->machine code). In Lua this would need to be emulated -> much slower. Note that Lua code does not get compiled into machine code - and be happy about it because otherwise every little error in your scripts would crash Mudlet.
5. Autosaving is, indeed, an often requested feature that will be addressed soon. However, before anything can be done in this respect we'd need to develop a smart archiving and file deletion policy. This is open for discussion and any good proposals are welcome.
6. 1.0.5 has a series of new functions:
howmany = exists( what, type )
howmany = isActive( what, type )
enableAlias()
disableAlias()
tempAlias()
permAlias()
permRegexTrigger() and a couple of more trigger types
permTimer()
resetFormat( windowName )
7. This would indeed be a bug.
Re: Some feature requests
Thanks a lot for your replies!
-I guess I'll try the custom logging. I just thought it would be a nice option to accompany the existing logging possibilities, but yes, it seems unproblematic enough to implement it on my own.
-As for the color triggers, I guess I'll just have to get used a bit more to Mudlet's trigger-"combos". I'm used to having it all in a single pattern line, but I guess Mudlet's way works just as fine. Your example here was very enlightening in this respect.
- Well, speed wasn't the main reason I asked for bit operators. I find them extremely useful in a multitude of situations, but mainly when doing stuff with bitflags/bitmasks. I guess I can just make my own functions to emulate these - I just thought the Lua libraries might be somewhat more efficient at this than what I would come up with myself to do this (combinations of loops, divisions, rounding functions and modulo operations, that go through the number bit for bit). It's clear of course that it would never be as fast as in a compiled language, but I thought it might be somewhat faster than the cumbersome solutions I might implement myself. But I may be completely wrong with that, being rather clueless about the architecture of Lua etc.
- I'm perfectly willing to wait for autosave until those archiving issues are settled. I'll just have to remember to click save profile every time I change something in my scripts. (Just yesterday I lost about a hours work by forgetting that
). Mostly a matter of self-control!
- great thing about those coming features. Looking forward to permTrigger! (Will killTrigger work on permTriggers too?)
-I guess I'll try the custom logging. I just thought it would be a nice option to accompany the existing logging possibilities, but yes, it seems unproblematic enough to implement it on my own.
-As for the color triggers, I guess I'll just have to get used a bit more to Mudlet's trigger-"combos". I'm used to having it all in a single pattern line, but I guess Mudlet's way works just as fine. Your example here was very enlightening in this respect.
- Well, speed wasn't the main reason I asked for bit operators. I find them extremely useful in a multitude of situations, but mainly when doing stuff with bitflags/bitmasks. I guess I can just make my own functions to emulate these - I just thought the Lua libraries might be somewhat more efficient at this than what I would come up with myself to do this (combinations of loops, divisions, rounding functions and modulo operations, that go through the number bit for bit). It's clear of course that it would never be as fast as in a compiled language, but I thought it might be somewhat faster than the cumbersome solutions I might implement myself. But I may be completely wrong with that, being rather clueless about the architecture of Lua etc.
- I'm perfectly willing to wait for autosave until those archiving issues are settled. I'll just have to remember to click save profile every time I change something in my scripts. (Just yesterday I lost about a hours work by forgetting that
). Mostly a matter of self-control!- great thing about those coming features. Looking forward to permTrigger! (Will killTrigger work on permTriggers too?)
Re: Some feature requests
Lua has only one data type for numbers, which is by default floating point (double I guess). So a bitwise operator couldn't be implemented low level anyway. The usual, and I guess fastest way to set flags in Lua would be to set boolean values in a table. Of course this requires a lot more memory than a bitmask, but unless you use an extreme number of flags this shouldn't matter.Iocun wrote:- Well, speed wasn't the main reason I asked for bit operators. I find them extremely useful in a multitude of situations, but mainly when doing stuff with bitflags/bitmasks. I guess I can just make my own functions to emulate these - I just thought the Lua libraries might be somewhat more efficient at this than what I would come up with myself to do this (combinations of loops, divisions, rounding functions and modulo operations, that go through the number bit for bit). It's clear of course that it would never be as fast as in a compiled language, but I thought it might be somewhat faster than the cumbersome solutions I might implement myself. But I may be completely wrong with that, being rather clueless about the architecture of Lua etc.