Garan

I believe the Turbinisms are fairly rare. Most of them are covered in my Noobs thread on the LotRO forums, such as issues with internationalization when saving/loading data or gracefully sharing event handlers with other plugins or the "plugin" object that only exists during initialization as a reference to Plugins[] table entry for a plugin. I'm sure there's a few others but that thread covers most of them.

Earthsuit

Yeah. All that makes sense now. Still trying to get my head wrapped around the tables. Are there a lot of these "Turbinisms" or are they fairly isolated?

Garan

Hi,

All that line does is gets the current environment's name as a string so that I can reuse modules and reference things like my Resources folder without hardcoding the plugin's name in the path. It makes it a lot easier to prototype new plugins as my "generic" plugin template can just be copied to a new folder and then I can get right to writing new code without worrying about hardcoded paths.

Executing getfenv(1) when a plugin is loading returns a table that Turbine creates which contains an entry "_" which points to a table with an entry named "Name" which is a string value that contains the namespace for the file currently being parsed and executed. This is just a side effect of how Turbine implemented lua and won't be documented anywhere. I found it simply by dumping the various environments as the plugin was loading, running and unloading to the script log and reviewing the results.

Due to the nature of lua, that entry could as easily be referenced as getfenv(1)["_"]["Name"]. The underscore is just a name like any other string - granted it looks a bit odd as though it should be part of something official but it's just a Turbinism. I suspect they used the underscore to try to avoid collisions with names that users would create for objects since theoretically users can reference anything by starting at _G so any name they used could conceivably be stomped on by a user.

Earthsuit

Greets.

Wasn't sure where to ask you about this. But you mentioned here would be as good a place as any.

In Main.lua for Alerter, as well as several other files, the first line is:

I'm fairly sure I understand WHAT this line does, but I'm not exactly sure HOW it does what it does. The part I have trouble with is "._.". I'm assuming that the single dots are a means of accessing indexed fields in the function's table, however, the underscore confuses me since I cannot find a reference to it in the lua documentation I've looked at.

Any help you can provide, or documentation you can point me to, would be very appreciated.

Thank you in advance.

Earthsuit

Thanks for the very quick response. I can only imagine how frustrating it must be given Turbine's decision to not continue to support Lua API and the resultant deterioration of plugin effectiveness. The work that you and other authors have done, the knowledge you have accumulated, is very important to many of us. It is a shame, but what can be done? :shrug:

Beyond that, your explanation about what is happening on the Tell channel helped. I've modified the pattern to detect ANY activity and just alert me to that fact. Not as nifty and I would like, but it's something. I have also incorporated your enhanced pattern for the kinspeak channel. That works perfectly. As for the log, I only wanted to see if there were a clue there (that I might understand) of what was causing these behaviors.

As always, thank you for your labors and patient support.

Garan

Hi.

There seem to be a couple of issues. Unfortunately, part of what you are trying to do can not currently be done because Turbine broke part of the Lua chat system - the incoming messages include a Sender argument which used to work for the /Tell channel and was broken (reported yourself as the Sender) for all other channels. It seems to be reporting yourself even for /Tells now. That being said, the text you are seeing in your chat window are not the values that are sent to Lua so things like the sender and time stamp are not part of the incoming message and should not be included in the Pattern. The third column of the Alerter Log window is the actual exact text of the incoming message which you should be matching with your pattern.

Your first example, trying to capture Tells includes what looks like an attempt to account for time stamps and the sender name which explains that issue. Unfortunately, since the args.Sender value is no longer valid even in Tells, there is actually no way to currently capture the name of the person sending you a tell. Otherwise, I was providing the args.Sender value (the second column of the Alter Log window) to the alert Message as the %S value - basically you would embed %S in your response message where you wanted the sender name to be but since it's broken at Turbine's end there isn't much point atm.

Your second example is due to the way that Turbine renders text enclosed by <Select> tags. If you look at the Alert Log entry you will see that your character name is enclosed by an object link tag (so that you can hover over the link and interact with the name as a player entity). Unfortunately, Lua text fields automatically render those links in a small font. You can eliminate the link (and Turbine's enforced font size) by removing the tag from the captured text. To eliminate the tag, change your pattern to:
which will account for the Select tag and capture the name as the first capture and the message as the second capture. Note in the closing tag the use of the "." instead of the "\" character, there is some oddity that I don't recall off the top of my head that prevents matching the actual original text but the period accounts for it.

As to the Custom Logs, they are special log files for use with a future enhancement. By checking the "Save to Custom Log" (that will change to "Save to Alert Log" in 1.08) checkbox in the Response tab, the entry will be added to the current session log and saved when the plugin unloads. They are not for dynamic interaction, rather for later review to determine which alerts are triggered in a given session, etc. Ver 1.08 should include a viewer for reviewing the current log as well as past logs, until then they aren't particularly useful, especially since the data being saved in the logs will change significantly with 1.08. There are still some issues with the log display which will hopefully be ironed out soon.

Earthsuit

Howdy. I'm trying to capture tells, but it just won't do it.

This is the pattern:
%[%d*:%d*%]%s(.*):

and the message:
%1 has told you something.

log entry (with Show Log):
Tell Garphorfiel greets

In an unrelated mistake, I am trying to capture kinship chat entries, but while it displays the message, the name is always in a smaller font than the rest. It all should be in [24] Trajan Pro Bold:

Pattern:
%[Kinship%]%s(.*):

Message:
%1 has said something.

log entry (with Show Log):
Kinship Garphorfiel [Kinship] <Select:IID:0x020A00000040C950>Reallycute<\Select> : Howdy

And another issue is that it does not create a custom log.

I'm sure these issues are my own doing somehow. I've tried removing the plugin and adding it back. I've tried deleting all definitions. It just doesn't do what I'm expecting. For instance, when someone posts in world chat, I get a log entry similar to the Kinship detection.

Garan

Well, after a bit of testing I found that the entire issue can be resolved by putting Bootstrap into its own Apartment - this will fix the conflict with Alerter as well as any other plugins that use Turbine's Class.lua file (Equendil provided a conflicting version of this file with his plugin). To fix this, simply copy the line:
<Configuration Apartment="Bootstrap"/>
directly after the line:
<Package>Equendil.PluginMng.Main</Package>
in the bootstrap.plugin file located in the Plugins\Equendil folder.
The entire bootstrap.plugin file should look like:

<?xml version="1.0"?>
<Plugin>
<Information>
<Name>Bootstrap</Name>
<Author>Equendil</Author>
<Version>1.4</Version>
</Information>
<Package>Equendil.PluginMng.Main</Package>
<Configuration Apartment="Bootstrap"/>
</Plugin>


I have noticed that Bootstrap won't even load with one of the versions of the Turbine samples installed, it just generates an error when loading but since that doesn't seem to be affecting you currently it shouldn't be an issue. I merely mention it since you may have to stop using Bootstrap altogether if you find that you want to load any of those plugins that use that particular version of the Turbine sample files.

FWIW, I have noted that my own Class.lua file could cause a similar conflict so I will be fixing that in a later update, however, fixing that will not fix all of the conflicts, including Bootstrap stomping on the Unload event handler so the separate apartment is still the best answer.

EDIT:
Bootstrap version 1.4 (current as of this post) also has a typo which prevents many plugins that share its apartment from exiting cleanly. Equendil overrode Turbine's RemoveCommand function but has a bug in his code so any plugin that shares Bootstrap's apartment (the generic apartment) and removes its commands prior to completing other unload event housekeeping such as saving data will never unload correctly. To fix this, you can simply change one line in Bootstrap. Change line 28 in Shell.lua from:
to:

joethemaster

I think my next step is just to unload EVERYTHING....create the Alerts that I want, then go back to using Bootstrap and all of my other plugins. Because as I said, even if I make alerts on the fly, they will continue to work until I log and I really enjoy the features of Bootstrap.

It may be a little inconvenient, but at least I now have a work around and it saves me from having to re-enter all of my alerts when I log in.

Thank you for your help again, I really appreciate your plugins and the amount of feedback and support you provide. I truly am grateful for your time and commitment you have for your tools that you have provided.

joethemaster

I think it may be a combination of the above.

I am 99.9% sure, the very first plugin I ever used was "Bootstrap". I have been using it for a few weeks and was the first plugin I installed (because I did not know about the new builtin Plugin Manager and I like how you can quickly load and unload individual plugins), and Alerter worked with it running and being launched by this plugin.

You patched which fixed some issues, but I think it then MAY have caused a conflict when Alerter is unloaded.

I have been playing with this (and logging on and off the entire time because I noticed that even though the SAVED message appears, it does not actually write to the file until I log off of the character), and unloading all of the plugins (except all of yours and Bootstrap) the error happens...I then used Plugin Manager to go in and load all of your other plugins first and then Alerter (without Bootstrap) and it works.

I have spent about an hour loading, unloading, logging off and back on and testing different things.

I do not know if that helps...but thank you for directing me to look at all of the other plugins and verifying that others were not having this issue.

Thanks!

Garan

Hi Joe,

There seem to be four possibilities for what you are describing:
1) I may have introduced a bug in the latest update
2) A file system problem is preventing the plugin from writing the file
3) Another plugin has somehow stomped on the save data routine (alerter runs in a shared environment)
4) Another plugin is crashing the client when unloaded and preventing other plugins from completing their unload handlers

Option 1 doesn't seem to be the problem as I have done some significant testing of the save/load settings and other users don't seem to be experiencing this issue.

You have already eliminated most of the possible issues with Option 2 by deleting the .plugindata file but I am slightly concerned that a new file is not generated so this could still be an issue with the file system. There is also a shared file for "shared" settings in the AllServers folder called "Alerter_SharedAlerts.plugindata" which might have an issue. The simplest way to test file system issues is to rename the Plugindata folder, start the client, make some changes, log out, log back in and see if the changes took effect - if they did then the problem is in your file system and you need to dig deeper, if not, then the problem is not likely in your file system, especially if other plugins are saving settings. Don't forget to delete the new plugindata folder and rename/restore the old one AFTER the client is closed.

Option 3 can be fairly common for users with many plugins. Many authors are not aware of some of the rules for properly implementing unload event handlers and they can accidentally overwrite the unload event handler instead of adding to it. The best way to diagnose this is to start the game and log in as usual, then execute the chat commands, "/plugins unload" to unload ALL plugins, then "/plugins load Alerter" to load just alerter. Then make some changes and execute the command "/plugins unload" again followed by "/plugins load Alerter" and see if the changes stayed. If they did then another plugin is causing the problem. However, this may also be related to Option 4.

Option 4 is tested the same way as Option 3, but generally, if you issue the "/plugins unload" chat command, the offending plugin will simply cause the client to crash to the desktop, but not always. Sometimes, plugins won't crash on unload until after a series of events have occurred, such as joining a party or having certain effects applied - basically, whatever underlying issue is causing the client crash. There are a couple of documented problems with the Lua API, such as not properly removing shell commands and accessing certain shared objects that can cause the client to crash, particularly when unloading the plugin.

So, if, when you execute the "/plugins unload" command, the client either crashes or the save issue goes away, then you have to try running without loading each plugin one at a time to determine which plugin is causing the issue. Note, this may take a while as you should completely close the client between attempts to be sure your underlying client hasn't become unstable.

Let me know how you make out.

joethemaster

I recently started using UI's for LotRO and came across this plugin, it was exactly what I was looking for (although I was trying to find something that would allow an audio trigger, but the flashing text works). I installed it and it worked, a few days later there was an update and I updated. Now nothing will save (to be persistent from logging out and back on) since the first time I entered an alert, even though when I click the save button it flashes the save update message.

When I create (or modify) an entry it will work and works until I log out, so it is being cached, but my initial file not being updated.

In my troubleshooting, I have deleted the entry under my character's name in the PluginData directory, but the file will not auto-generate.

I do not know if it is because of multiple UI's that I have loading or if there is something different in the most recent patch, but any help would be greatly appreciated (so I do not have to recreate my alerts every time I log in).

Thanks

Earthsuit

So, lua uses a subset of perl regex. Nice. That will make setting patterns very much easier.

Thank you.

Garan

The issue seems to be the pattern in your KinSpeak alert. You appear to have realized that the characters "[Kinship]" do not appear in the login/logout messages or kin messages from you (your messages contain "[To Kinship]"). So, to isolate only incoming chat, you wanted to match "[Kinship]" but in Lua Patterns, the square bracket characters are special characters denoting a "set" of characters, any one of which can be considered a match for the whole set. Basically, the pattern "[Kinship]" was matching anything that contained any of the letters K, i, n, s, h, i, or p. To fix this, you have to escape the special characters using the percent character, "%[Kinship%]" and your patterns will now match as you expected.

Additionally, you can add a "Capture" to your Online and Offline patterns by using parentheses and a wildcard pattern. For instance, for Online use "(.*) has come online%." Note that I escaped the period with a percent sign as well to make it a required character (using the period by itself would only require any single character not specifically a period). The point of the Capture is that you can then echo the captured part of the message in the response using %1, %2, %3, etc to refer to captures in the order they occur in the message, so the Message "%1 Online" would show the name of the person who had come online plus the word "Online".

More about Lua patterns can be found at
http://www.lua.org/manual/5.1/manual.html#5.4.1

Earthsuit

I'm having a little difficulty. When either the KinOnline or KinOffline alerts are triggered, they all seem to be triggered. They work fine pressing the test button, but live execution has different results. Here's an album of the alert setups:

Alerts