Ok Turbine, Enough is enough

[Balfimli]

During the ROR beta I tested many of the LUA features, and found some that were not working.

I bug-file

and yet throughout the beta they were not fixed.

In the release notes, I quote:

Added IsMarkupEnabled, SetMarkupEnabled to the Label class. This will allow for a limited set of HTML style tags to be used for formatting text. Tags include<b>, <i>, <u>, <p>, and a custom <rgb=#XXXXXX> tag. Make sure you close them </>.

THE <b></b> AND THE <i></i> TAGS DO NOT WORK AND HAVE NOT WORKED THROUGHOUT THE BETA!

I am appalled that they were included in the release notes and were not fixed, despite my countless number of bug-files throughout the beta.

I only hope that the bug-files I posted were lost in transmission and you were oblivious to their status.

In the next patch I hope that we have a fix for this.

I am heavily disappointed!

EDIT: <p> is untested as it only appeared in the last round of beta

[Galuhad]

During the ROR beta I tested many of the LUA features, and found some that were not working.

I bug-file

and yet throughout the beta they were not fixed.

In the release notes, I quote:



THE <b></b> AND THE <i></i> TAGS DO NOT WORK AND HAVE NOT WORKED THROUGHOUT THE BETA!

I am appalled that they were included in the release notes and were not fixed, despite my countless number of bug-files throughout the beta.

I only hope that the bug-files I posted were lost in transmission and you were oblivious to their status.

In the next patch I hope that we have a fix for this.

I am heavily disappointed!

EDIT: <p> is untested as it only appeared in the last round of beta

Plugins are not officially supported so they unfortunately take lower priority over whatever else needs fixing. Usually an update for the API takes longer. It's something they will fix eventually, but only when the few devs who are involved actually get the time.

I've tested <p></p> and <rgb></rgb> and these are working fine.

[Garan]

During the ROR beta I tested many of the LUA features, and found some that were not working.

I bug-file

and yet throughout the beta they were not fixed.

In the release notes, I quote:



THE <b></b> AND THE <i></i> TAGS DO NOT WORK AND HAVE NOT WORKED THROUGHOUT THE BETA!

I am appalled that they were included in the release notes and were not fixed, despite my countless number of bug-files throughout the beta.

I only hope that the bug-files I posted were lost in transmission and you were oblivious to their status.

In the next patch I hope that we have a fix for this.

I am heavily disappointed!

EDIT: <p> is untested as it only appeared in the last round of beta

Please remember that Lua is only included as a Beta and only because a couple of devs have taken it on in their free time. This feature does not have much support within Turbine/WB as it does not generate any immediate income (despite the fact that many have pointed out that if properly implemented it will provide many free man hours of third party development time) and if people start posting inflamatory threads there is a very real possibility that it could be removed from the client altogether. Please be patient and supportive of the devs that ARE trying to expand on the Lua implementation. I have also been quite frustrated with the frustratingly slow pace of the Lua implementation but it is NOT the fault of the couple of devs that are doing this pretty much on their own.

There are bugs in the Lua implementation that will actually crash the client, such as passing a non-image resource ID to SetBackground() which have been documented many, many times and will probably be reported many, many more times before they get fixed. Is this frustrating? Yes. Of course. But it's a simple matter of lack of resources and prioritization. If we want to continue to have a Lua client at all, then we have to be supportive of the devs - no one wants to spend their free time working on something they feel will be unappreciated. Personally, I feel that an official "known issues" thread might go a long way toward relieving some frustration as it would indicate that the devs are aware of those issues and are working on them when they can...

[Ingaras]

I think the issue here isn't only that it doesn't work... but that there's release notes happily telling 'Look what we've added!' while they should know it doesn't work. I can understand it's quite frustrating to test something, file a dozen of bug reports and see Turbine act completely oblivious to the fact that it's bugged on release. Why would you then bother testing it in beta?

[Balfimli]

My problem with it is:

They included it in the beta release notes and it was broken,
Each subsequent round I bug-filed it as it still wasn't fixed,
And yet it still makes it into the release notes AND IT STILL AINT FIXED!

They should have at least pulled that line from the notes or amended it before it went public.

I know Lua is still a BETA in itself, what I'm not happy with is that they don't even give it enough notice to evaluate what is working and what should go into the release notes.

[Evendale]

Honestly I agree with the OP even though the example given is a trivial one. Plugins may not be "officially" supported, but if they expect people to spend time programming them, then they need to at least provide a stable environment that is somewhat documented and isn't too difficult to use.

There have been more than enough decently sized updates to the LUA API released each year; I just think the focus is all wrong. Please sort out all the bugs with the current API first, and add UI elements that are more usable, instead of continuing to add new features that bring along more bugs and more frustration, and not even bothering to fully document all the new events or the way some of the more obscure functions work, etc. It is especially frustrating when undocumented changes are made that effect existing plugins.

(unsurprisingly this is similar to the issues with releases to the game in general...)

At the moment, if you want to make a plugin that looks good you have to spend an incredible amount of time making your own UI elements, and working around all the subtle bugs/missing features.

Personally, I feel that an official "known issues" thread might go a long way toward relieving some frustration as it would indicate that the devs are aware of those issues and are working on them when they can...

Yes, even an unofficial list would be incredibly useful. I was intending to create a thread for this at one point, but I tend to just find a workaround for any issues I find, and then forget them, so most of the stuff I've come across isn't listed below.

Anyway, here's a small list of some of the issues I can remember off the top of my head You probably know of many more (NB: it's possible some of this info is incorrect, or some of these issues have been fixed since I originally encountered them):

Crashes/Issues/Things to watch out for:
- Crash when assigning a background asset ID that is invalid
- Inconsistent crashing when unloading plugins that have a large menu (including when logging out)
- Crash when unloading a plugin that added a non-menuitem to a menuitemlist
- Various other crashes if invalid arguments supplied to standard methods
- In a Lotro.Textbox, the flashing cursor disappears if it is right aligned (the standard Textbox control seems to be pretty much unusable)
- If you ever set the size of a control to less than 0, it will become basically unusable from that point onwards.
- Lots of issues around setting the min/max/value of a manual Scrollbar.
- Control focus is a bit buggy; sometimes controls seem to only partly have focus after a call to Focus(), and the only way to unfocus a control involves annoying hacks.
- The "resize" bug. I don't know if this is graphics card related, but often when updating the size of a window, one column of pixels is lost. It may be controls as well - this even applies to menus in the plugin manager window.
- To refresh effects applied to text, you sometimes need to re-set the text on a label. Hiding and reshowing a window can also avoid some issues (sometimes seems to prevent the resize bug).
- Creating a new control takes an oddly large amount of time, so you want to pre-load and reuse controls as much as possible.

Missing/Silly Functionality:
- No way to determine text width (in realtime without using the inefficient and slow scrollbar hack)
- TreeNode seems to be missing an "Expanded" event
- Plugin.Save limits you to one save every ~15s, but will perform multiple saves to the same file if more than one request within the same period.
- Key Events only seem to fire for keys that are bound to a LOTRO event ... or something. The "Tab" key event doesn't fire if a textbox has focus.
- When calling SetText on a textBox, the text overflows in the opposite direction than expected.

Would be nice:
- Many standard UI elements that are missing (drop downs, etc)
- Adjustments to most of the standard UI elements that do exist so they match the standard LOTRO elements, eg: The title bar on LOTRO windows is oddly wide - it should be the same as other windows or customizable.
- A way to add a title, or allow multi-select in ContextMenus
- A list of LOTRO asset IDs so we can make skinner friendly plugins and not waste resources replicating LOTRO images (or just fix the bug that crashes the game, so we can discover the values via IRV)
- A way to update the cursor icon
- A way to overlay a color over an image (without using a window overlay hack)
- DrawLine/DrawArc/etc methods
- Real time saving/loading would be nice (I don't understand the need for a one per 15s limit)
- Better ability to manage control focus (especially to eg. prevent the menu from opening on Escape)

[Balfimli]

- Real time saving/loading would be nice (I don't understand the need for a one per 15s limit)

This is to prevent people hiding stuff in a legit plugin that could potentially hang the game,

saving takes up quite a bit of memory in any piece of software, doing it many times per second may (probs will) crash the game

otherwise, some good points made

[Equendil]

This is to prevent people hiding stuff in a legit plugin that could potentially hang the game,

saving takes up quite a bit of memory in any piece of software, doing it many times per second may (probs will) crash the game

otherwise, some good points made

While they may have introduced the delay on saving data as a safeguard of some sort, the lua runtime resides within the event loop and you can make the game hang completely with just the following lua code: "repeat until false", which can also prevent the user from even reaching the task manager (at least on my single core computer).

[Evendale]

This is to prevent people hiding stuff in a legit plugin that could potentially hang the game,

saving takes up quite a bit of memory in any piece of software, doing it many times per second may (probs will) crash the game

otherwise, some good points made

As far as I can tell, the save/load restrictions work as follows:

a) When a call to Save is made, the next Save "event" will occur in 15s. At the 15s mark, all calls made to Save after the first call will run in the same frame, in sequence (even if you made multiple calls to save to the same file).
b) Additionally, each time you call Save, the entire lua object is copied (ie: and cached) until the next Save "event".
c) Load works the same as save, but on a separate cooldown.

So if you make 1,000 calls to save over a 15s period with the same object, you will have 1,000 cached copies of the object sitting around, and you will have 1,000 saves fire in the one frame, potentially stalling the game. Essentially it just groups all your saves up into one frame, having pretty much the opposite effect of what you suggest. You can easily crash the game (after a short delay) by firing off a lot of saves at once.

There seems to be no performance benefit to the current implementation, and a lot of downside.


Also, what Equendil said. If you want to crash the game, all you need is an infinite loop.

[Balfimli]

Yeh, it's still easy to crash the game with lua.

Especially using chat features

Anyway, does anyone know when the new lua documentation's coming as I want to read up on some bits that were added as there wasn't enough info given in the release notes for me to attempt anything with them.

[moebius92]

Is there any particular functionality you want to know about? It wouldn't surprise me if all of the new functions have been used by someone that posts here.

(I've been working with logic too long. The fact that I can't figure out how to write the above sentence resolve the for all-there exists/there exists-for all ambiguity bugs me. It's supposed to be a for all-there exists, by the way.)

[Balfimli]

Is there any particular functionality you want to know about? It wouldn't surprise me if all of the new functions have been used by someone that posts here.

(I've been working with logic too long. The fact that I can't figure out how to write the above sentence resolve the for all-there exists/there exists-for all ambiguity bugs me. It's supposed to be a for all-there exists, by the way.)

Erm... No, I'm stating something that nobody here will be using ATM

BECAUSE IT'S NOT WORKING.

Please read the post before stating things that aren't true

[moebius92]

Erm... No, I'm stating something that nobody here will be using ATM

BECAUSE IT'S NOT WORKING.

Please read the post before stating things that aren't true

Really? Because when you said:

Anyway, does anyone know when the new lua documentation's coming as I want to read up on some bits that were added as there wasn't enough info given in the release notes for me to attempt anything with them.

I thought you were asking for documentation on how some of the new functionality that was added worked.

Apparently not! Good to know.

[Balfimli]

There's no need to be rude.

I misunderstood what you meant, you said All of the features, I assumed it included the ones that were broken
My apologies.

What I really wanted was some information about the documentation, not information from (although they themselves are very good programmers) the people who post here.

I enjoy working things out for myself, using the documentation where necessary. I'd like to know where it is and when it's available.

[Kurru]

16 days i havent been able to even load the launcher thanks turbine

[Kamindra]

As far as I can tell, the save/load restrictions work as follows:

a) When a call to Save is made, the next Save "event" will occur in 15s. At the 15s mark, all calls made to Save after the first call will run in the same frame, in sequence (even if you made multiple calls to save to the same file).
b) Additionally, each time you call Save, the entire lua object is copied (ie: and cached) until the next Save "event".
c) Load works the same as save, but on a separate cooldown.

So if you make 1,000 calls to save over a 15s period with the same object, you will have 1,000 cached copies of the object sitting around, and you will have 1,000 saves fire in the one frame, potentially stalling the game. Essentially it just groups all your saves up into one frame, having pretty much the opposite effect of what you suggest. You can easily crash the game (after a short delay) by firing off a lot of saves at once.

There seems to be no performance benefit to the current implementation, and a lot of downside.


Also, what Equendil said. If you want to crash the game, all you need is an infinite loop.

My understanding is that if there are multiple saves within the 15s window, then only the last one is performed. I have not tested this, but that's my recollection. Based on that I dump out window position information every time one of the windows for a plugin I write is moved.

[Evendale]

My understanding is that if there are multiple saves within the 15s window, then only the last one is performed. I have not tested this, but that's my recollection. Based on that I dump out window position information every time one of the windows for a plugin I write is moved.

That's what I would have expected as well (who wouldn't). But then I noticed significant lag that was able to be reduced by not saving (the same object to the same file) every time a window was moved. So I tested the Save function in more detail and discovered what I posted above.

If you want to test it yourself:

local obj = { count = 1 };
for i=1,10000 do
    Turbine.PluginData.Save(Turbine.DataScope.Character, "FileName", obj);
    obj.count = obj.count + 1;
end

After ~15s from calling this command, the game will crash (after a few thousand saves for me). If you look at the settings file, you can see from the "count" how many saves were made in the same frame. This also shows that the object is getting copied - otherwise count would always be 10,000.

[Kamindra]

I think some documentation on what things do would help in this and many other instances!

[Feoktist]

Sorry for necroposting, but maybe you checked if <b></b> and <i></i> were fixed in U9 or U10?