Decoda

[Oneymus]

Decoda is a Lua IDE written by Unknown Worlds, makers of (most recently) Natural Selection 2. Decoda is designed to work as a debugger for external programs using Lua, originally written so the developers could step through the Lua they use (extensively) in NS2. After the release of NS2, they decided to release Decoda as an open-source project on GitHub.

As it turns out, Decoda works with Mudlet! In fact, as you can see in the picture linked, it's able to pull in the internal Mudlet Lua objects! You can step through, watch variables, and otherwise follow the flow of execution. There are some limitations; changes to the temporary files (@Untitled#) are not reflected in Mudlet, although changes in Mudlet are reflected in Decoda. It also pulls in .lua files external to Mudlet (LuaGlobals!) and .lua files required from within Mudlet (tested with my Vyzor files!).

So, while it doesn't seem possible to do all of your development in Decoda (should be possible to edit those external files, though), this will make it much easier to debug large projects. To make Decoda work with Mudlet, you only need to set a couple of options and hit F5.

Decoda is Windows only, unfortunately. And I haven't done enough testing to suss out all of the limitations of the interactions between the environment and Mudlet, but I feel like this will be an invaluable tool for the development of large projects in Mudlet.

[kevutian]

I was so eager for some awesome news and actual real-world application to come of this, but then I read the 'Windows only' part.

I now feel sad.

[Oneymus]

That was one of their motivations for releasing it as an open source project. While they may not have the time or budget to port it to other operating systems, they're hoping the community will be able to move forward with the project.

[Vadi]

That's pretty nice. I can't do anything with it until it works in Linux either, but there is ZeroBrane (http://notebook.kulchenko.com/) IDE that's cross-platform that has a debugger as well.

[Daagar]

I typically use VIM or Sublime Text, but the fact this can see 'into' mudlet is awesome. Would there be any chance of somehow going past the limitation of not being able to edit directly in decoda and have it show up in mudlet?

[Oneymus]

Would there be any chance of somehow going past the limitation of not being able to edit directly in decoda and have it show up in mudlet?

For external files (such as a .lua require()'d into Mudlet), yes, you can edit files outside of Mudlet, save them, and then reload them in Mudlet (the specifics of that are left to the user, but I did that extensively for Vyzor development).

The problem, however, comes when you work with Mudlet's internal Lua (the stuff in Triggers, Scripts, Aliases, ...). When you edit one of those in Decoda and try to save it, it prompts you to save a .lua. Furthermore, there is no way to notify Mudlet from within Decoda that a change was made; something like that would most definitely require a joint solution in both the Mudlet and Decoda sources.

So, while Decoda is not a perfect solution, it's currently the only solution I know of (I haven't looked into ZeroBrane) to set breakpoints and step through Lua being executed within Mudlet. Normally, debugging for me was echo-to-console, and very reactive as opposed to real-time. If someone wants to get serious with Decoda, I would suggest making your Mudlet innards as thin as possible, and do most of your heavy coding in external files. Again, I point to Vyzor as an example: beyond the suite of test Aliases and the single test Trigger, the only code that -had- to be written in Mudlet was the script to load the .lua files.

[Daagar]

Sorry, that question really was directed at the mudlet devs, for exactly the reason you mentioned. I do tend to code most of my own stuff externally just for the ability to use an outside editor. The debugging ability adds a whole new level! Heck, just loading it up the first time to test it out showed me a few areas where I had variables not being init'd properly