An idea for a new way of doing plugins
HTML, .Net, Actionscript (more specifically Flex Actionscript) and WoW add-ons. What do all of these have in common? They all use some form of markup to display visual elements, while letting the code handle the logic.
It's something I think LotRO plugins is missing - perhaps it wouldn't add anything functional to the API, but I feel it would improve organization of code, as well as making UI creation a bit easier. Unfortunately, I don't have direct access to the API source code, and can't "hard wire" support for some kind of markup...but, it may be possible to do the next best thing. If such markup can't be done outside of Lua; but, in theory, it should be possible to pull off an equivalent within it. Now, such markup would have to be written as a Lua string, but a combination of some form of markup parser/navigator class, in addition to a class designed to "translate" the markup into API code, should be able to do the job well enough. Now, like I said - this is in theory, based off of what I know of Lua and the API. As soon as I get a reliable internet connection back (looking like the 8th), my first project is going to be testing the feasibility of this idea, with the hope that I'll be able to use such a setup with Palantir v2 - as the number of visual elements in that plugin - makes it a perfect guinea pig for the concept. That being said, I'm interested in what you guys think about this idea - such as whether or not you think this would be an easier way of creating/laying out plugin UI elements than the existing way - or if you've seen some other method you think is better. If anybody is interested in such a method, let me know - and I'll go ahead and post my progress in this thread. If not, I'll just go ahead and play with it myself, and if it turns out to be acceptable, I'll probably just go ahead with it for my own projects, and leave it at that. |
I'd love to see lotro offer this kind of support, but in its current form I'd suggest starting with an app that translates between tag based and the object based that we currently have to work with. Preferably an app that translates between the skinning type tag system, that way as the API gradually exposes access, it is easier to covert over existing windowed examples into addon-land.
The idea I've been toying with is a "visual basic"-like lua addon, for dragging / dropping controls on blank window pane while in game and editing the properties. Lua language coupled with the lotro controls give all the necessary support to make this happen. Since the designer addon is in game, you get all of the sizing, etc.. correct w/o a bunch of reloads. I'd love to see the UI go more tag based. Much easier to lay stuff out that way (at least easier for my brain to visually lay it out that way). |
Quote:
For a brief time I was playing around with a plugin that would do something similar (although I was going for more of a Flash authoring method than Form Designer). In this case, the actual Lua code would be displayed in a window, where the user could copy/paste it into their own lua file. Unfortunately after realizing I was getting into way too many projects at once, I had to cut back, leaving the small amount of work I did accomplish to gather dust. Another reason, is that it seems I end up coming up with ideas that do get finished, in the process of actually writing plugins - such as the DUInterface library, which was written in the process of creating the options panel for Palantir, Palantir will again be the reason for another idea - this one. After noticing how much space was being taken up by UI related code, and contemplating the support of bar skins, it seems like the best way to go - provided I can pull it off. At this point, I think I'm going to stick with <Element> tags, just to at least mimic the existing skinning system, with the ID attribute, of course, being the unique identifier for that element. It will also include a "type" attribute, which will contain the class of the element. So, perhaps something like so: Code:
<Element ID="mywindow" Type="Turbine.UI.Window" X=10 Y=10 width="200" height="200"/> |
I too suffer from TMSPS (too many side project syndrome). I have a feeling the interface forums needs to form a support group for us. ;)
Suggestion I have regarding, would be to look into the addon authoring of some of the major IDE. There are many out there that already handle xml editing, syntax highlighting, and completion (if you include dtd or xsd support for your xml structure). The addon portion would then simply be a translation component for "export" or a preview type panel. I'd been looking at writing simple lotro api context support library for Eclipse, but got bogged down in TMSPS yet again. |
My training is in HTML and visual basic. I'd like to try making plugins but don't know lua and to be honest the UiBuilder is about the limit of my skill ATM but would love something that would make it easier for me to learn/adapt from my skills.
|
I'm finally going to be able to get around to testing this idea out, later today. The first test is going to be pretty simple - working out an easy way of importing/storing the markup, importing it and parsing it into something that can be easily worked with inside Lua.
The second test will be building off of the first, to create a proof-of-concept. This will basically be a demonstration of how it will work - importing the document, parsing it, and generating the UI it describes. I will continue to update this thread with any (significant) progress I make throughout the weekend - and beyond. If this does turn out to be feasible, I will release a beta version of the library as soon as I at least have all the base LotRO API implemented. External UI libraries will be supported as well, although DUInterface will have priority - as it contains UI elements that are necessary for the main purpose of this project (Palantir). Quote:
Still, it would be a good idea - I've noticed that there are those who prefer using an IDE for nearly everything, so I'm sure it would be useful. As far as previewing it, I don't think there's really a good way to integrate LotRO with any external apps - at least in that regard. I mean ideally, it would start up lotro, and load the plugin to test, in order to show it, but automatically logging in and selecting a character would be a headache - if not impossible, and you really can't send commands to the chat window externally. What would be nice is a LotRO plugin emulator that would use LotRO's Lua library - or at the very least - a reproduction of it, so you could at least see the result of what you were writing (regardless of markup support), without having to jump through all the hoops to do so. Unfortunately, even if the library is accessible via the Win32 API, this is way out of my league. The best I'd be able to do is translate the Lua code in C#, and attempt to simulate the result - which is really a very ugly way of going about it. As far as TMSPS goes, I'm pretty sure LI having a support forum for it would be akin to a bar holding an AA meeting :p Besides, even if such a forum existed, we'd all find something that would improve the program, and start another side project to do so lol Quote:
I mean, plugins in LotRO are really no different in complexity than creating a web app - so if it works for the web, why not do it with LotRO? |
Well...although my time to work on this got severely cut today, I did get enough of an opportunity to confirm that this is going to work - quite nicely! I do have some details left to work out, and a sizable amount of code to write, but the most important tests were successful.
I'm going to continue on here, adding on to my original concept - with more details about how this is going to work. Of course, everything is subject to change if it's required, as I go along - but a much clearer picture is starting to emerge. First off, a copy of the test markup I'm using for testing things out Code:
xmltest=[[ At this point, the process is going to go something like this: 1) import the UI.lua script 2) parse the document(s) building a "NodeTree", consisting of "Node"s, that will contain a table of parameters, a table of childNodes, the ID, and the type of node 3) Once the markup language is in a far more development/lua friendly format, the NodeTree will be traversed and the elements will be generated. I still have to decide on exactly how final interaction is going to take place, but for now, I think I'm going to go with storing the generated element in its node, and then "dumping" the elements to the screen - to give the developer control over the visibility of the generated UI, as well as allow for easier access to the individual elements. Some details about the structure of the project: Although the complete package is a means to an easier way of designing a UI with plugins, I see the opportunity for at least part of it to serve other needs. For that reason, this project will actually consist of two separate libraries, keeping all the XML parsing/navigation/management separate from the UI generation. This way, as the plugin system moves forward, and more data hungry plugins are created - authors will be able to easily provide updates and changes to their plugins, by using a common data structure, without having to generate (significant) Lua code in order to do so. That's the extent of what I have for today - another update will come Sunday - with hopefully more than just plans to show for it ;) |
Just a small update, but still significant, so I thought I'd share.
While my testxml I posted above is probably great for testing out basic UI generation, one root with one child isn't so great for testing out xml parsing. So, for that purpose, I went to data.lotro.com and used xml for an item I had in my browser's history. Unfortunately, at this point - CDATA will not be supported. At this stage, a CDATA tag would just add needless complexity to the project (both due to its non-standard tag structure, and the characters it uses). Two important steps were reached over the weekend. The first is the ability to grab the necessary information for a node, including attributes, values and tag names. The second is the ability tor read the entire xml string, grab the tags and innerText, and reproduce the tree, visually, in the chat window, based off of recognizing opening and closing tags. The next step will be bringing both of those together into a tree of Nodes, which will allow for logically accessing XML data via traditional means (i.e. getElementById, childNodes[x], attributes[x] etc). At that point the XML library (at least the input portion) will be functionally complete and I can move on to the UI generation. |
I'm a bit late on updating this thread with the latest work accomplished last weekend, but this is the state of the project right now:
Basic parsing/navigation functionality is done. At its current state, the XML string will be parsed into a tree of Node objects, which could then be navigated via the standard childNodes property, in addition to displaying nodeValue,nodeName and nodeType. So for instance, this works: Code:
myXML = parse(testxml); Code:
<classes> Code:
--local myclasses=myXML.childnodes... Code:
myClasses.childNodes[2].NodeName; Code:
(text node) Code:
<classes><class name="Burglar"/></classes> Code:
(text node) Like I mentioned, CDATA and XML creation/modification will not be supported initially, nor will namespaces. if, for some reason, users have a need for namespaces, or CDATA in their projects, I will be glad to add it in. However, CDATA support will require a change in the characters used in those tags - because this: Code:
<![CDATA[+22 Might]]> |
Alright, XML Library is done - at least done enough to move on to the fun stuff. What follows is a brief rundown of the library's API. When this is released, docs will be up on the wiki here. Besides, if you're familiar with dealing with XML on the web, you're probably not going to need much reference here in the first place.
Constructor Code:
myXml = DigitalUtopia.XML.Document(xmlString); Node This is the base class, which all other classes use. Properties nodeName nodeValue nodeType attributes{} childNodes{} firstChild lastChild nextSibling previousSibling parentNode textContent Methods isSameNode(nodeToCompare) hasChildNodes() hasAttributes() Element Standard tag-type node (only non-inherited properties/methods listed) Properties tagName Methods hasAttribute(attributeString) getAttribute(attributeString) getAttributeNode(attributeString) getElementsByTagName(tagString) getElementById(idString) Attribute An Attribute node consists of name/value pairs such as name="value" Properties isId name value ownerElement Methods none Comment/Text These two objects are different types, and different objects, but the same non-inherited properties/methods. (only non-inherited properties/methods listed) Properties data length Methods substringData(start,length) Document The special node that contains the rest of the node tree (only non-inherited properties/methods listed) Properties xmlVersion inputEncoding xmlEncoding xmlStandalone Methods getElementsByTagName(tagString) getElementById(idString) |
All times are GMT -5. The time now is 10:28 AM. |
vBulletin® - Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
© MMOUI