I can write a bot that transcribes it into a different syntax, but would need to look at it closer, I just don’t think it is worth the time involved, at least for me.
I don’t have my mac on in front of me, but for a mac it is something like this:
“cmd”: ["/Applications/CoronaSDK/Corona Terminal", “main.lua”]
This is what works for me. If anyone is getting errors with this has error codes are you getting?
I’ll just post my build settings so as not to be completely speaking out of the ether…
OSX 10.8.3 (AKA Latest) + SublimeText2 v2.0 2210 (which I think is more or less latest of v2)
Standard Corona SDK install (that is, to Applications/)
{ "working\_dir": "${folder}/", "cmd": ["/Applications/CoronaSDK/Corona Simulator.app/Contents/MacOS/Corona Simulator","$file\_path"], "selector": "source.lua" }
I’m more than happy to stand corrected on how that should work for OSX but so far that’s the best I can do (and for me the “working_dir” line has no effect thus far.)
Use this for the cmd line and see if you have better luck.
I can start up my mac later to check.
“cmd”: ["/Applications/CoronaSDK/Corona Terminal", “main.lua”]
Build multiple times : multiple clients (same problem as before)
Attempt to open from a sub folder : “The document main.lua” could not be opened. Corona Simulator cannot open files in the “Lua Source Code” format." (same problem as before)
As a side note if you leave the “working_dir” line in while calling that modified “cmd” line, you can’t build at all. Even main.lua gives you the sub folder error message.
I’ll test it on a mac tonight. On Windows it works fine, you can also use $ProjectDir but have to have a project.
That would be great, thanks. I’m not surprised it works fine on Windows as I don’t remember having much in the way of problems there, but OSX has been something of a black box to me as far as ST2 is concerned.
I just looked at my mac,
"cmd": ["/Applications/CoronaSDK/Corona Terminal", "main.lua"]
Does in fact work and it works much nicer than Windows as it is integrated rather than a separate shell.
As for working_dir, I am seeing issues with it on OSX, but seems to work fine with Windows. Going to check to see if I can get a better way to make this work.
Yeah, I just tried using that line by itself…
Builds: yes
Builds from subfolder: no
Reloads sim or creates second instance?: second instance
Hopefully you have some ideas about this later. 
I got it working last night. Sometimes I get a 2nd instance, but most of the time as soon as I save the file in ST2, the existing instance restarts for me.
One thing I noticed is that I have to have an active tab to the folder where my main.lua is. If I’m on a tab that’s in a different directory it won’t start.
Also, Under Tools->Build System you have to select Corona. I did this in one project and everything was fine, went to another project and it was set to something else, so it seems like it needs set on a project-by-project basis.
All of my projects run using ST2 project files (located in the root of their respective projects). main.lua is always open because I use it for keeping notes. And mine auto-selects CoronaSDK as the build system, I assume because I save main.lua first and make sure that’s set to Lua (CoronaSDK) as the language.
Just having the tab open for me doesn’t affect anything- you have to build (Cmd+B ) from a file in the root folder or you’ll get the error message. But as far as I can tell it can be any file from root (well, any lua file). But I’ve never, ever seen build restart an instance. The only time an instance restarts (in my experience) is if you save - the SDK detects changes and auto-reloads.
If you add the “selector”: “source.lua” it will cause it to automatically use that build system for .lua files. Then you can just leave it on automatic. Otherwise you have to select Corona. If you pick it, it will save the build system chosen on a project by project basis.
Ah, always wondered what “selector” did.
Any luck with a better method, cspence?
Selector is similar to source in snippets.
Only problem is if you code lua for other things, it will use the same build for all, but you can get fancy and do alt-builds so you hit a control key when hitting control B and you get a menu which one you want to use.
Nothing new yet, I’m looking into it, but I think it may be a Corona thing, checking with Corona and Sublime, but Sublime is slower than slow for anything support and likely never to get a response.
Interestingly enough, I gave your code a try for the Windows build.
{
“working_dir”: “${folder}/”,
“cmd”: [“C:\Progra~2\Corona~1\Corona~1\corona~1.exe”, “main.lua”],
“selector”: “source.lua”,
“shell”: true
}
But…it just loads Corona and the shell window; there’s no errors but the game is not run by the simulator, either. Switching ~1 with ~2 at the end gives the error “C:\main.lua not found.” Not sure which one tries to load Corona.Debugger vs. Corona Simulator, though.
(Incidentally; Lots of .c errors from Corona if I attempt to run .CAF files via the windows simulator. Sim framerate goes from 30fps solid on OSX to 3 on W7)
I have my simple build code which works w/o problems on win machines:
{
“cmd”: [“C:/Program Files (x86)/Corona Labs/Corona SDK/Corona Simulator.exe”, “${project_path}/$project_base_name/main.lua”],
“shell”: true
}
As you can see, the only thing you shoud do is to save ST project file in the same folder where your source files folder is and to give to your project the same name as source files folder has.
It should look something like:
Zombies(folder)
Zombies.sublime-project
Zombies.sublime-workspace
In this case you can open project with no files open and you’ll still be able to run it in the simulator.
Hi Everyone,
I got the API list from Lua Glider IDE, it downloads the raw corona .lua files for its own autocomplete.
This seems to be a common misconception about our autocomplete stubs. We actually went through the docs ourselves and created these lua files. In no way did we download any corona source! We would appreciate if you asked us before porting over our hard work to another IDE. The point of doing it this way as opposed to putting into a database or xml file is that we can use the same scanning engine for both autocomplete stubs and your own code. All the luadoc comments you see you can use for your own code and get the same type aware autocompletion you see for the Corona API. Also, it allows for some very powerful stuff. Like for instance:
--- @DeepInspect -- @param object @class DisplayObject -- @param bodyType @optional @class string @enum "static", "dynamic","kinematic" -- @param optionsTable -- @return -- function physics.addBody(object, bodyType, optionsTable ) object = Body end
what the code snippet does is attaches a Body class to the first parameter.The addBody function transformed the object parameter into a physics body object. Rather than using some obscure xml format to describe this behavior, we just use a simple lua function.
The result can be seen with the autocomplete:
btw “Body” is just a lua table that looks like this:
---@extends DisplayObject local Body = {} Body.angularDamping = 1 Body.angularVelocity = 1 ---@enum "static", "dynamic", "kinematic" Body.BodyType ="" Body.isAwake = true Body.isBodyActive = true Body.isBullet = true Body.isFixedRotation = true Body.isSensor = true Body.isSleepingAllowed = true Body.linearDamping = 1
What is the purpose of the DeepInspect directive? When Glider inspects a lua function (either the stubs or your own functions) it “runs” the function in our homemade Lua virtual machine that analyzes the function to figure out a few things:
- What are the parameters? What types are they? How many are there?
- What is returned? How many returns? What are the types of those returns?
- Where is this symbol being used? Has it been used before? Is this a declaration?
All this information is extracted automatically from parsing and analyzing lua source code. The Luadocs just help out the analyzer but they are not strictly required. For most functions, the first inspection result can be cached and reused, but there are a few functions with side effects that must be “re-run” every time. This is what the @DeepInspect directive does.
Take for instance:
Glider can figure out all this so you don’t have to remember it or refer back and forth to documentation yourself.
And best of all you don’t need to learn any xml formats, its all just plain Lua code. And you can create your own stubs for your project, just create skeleton functions and the autocomplete entries will show up for you and the rest of your team.
We are going to open source our stubs and the Glider Corona Plugin. We need help updating the stubs to make the smartest autocomplete you have ever seen for lua. Please let us know if you are interested in contributing, we will create detailed documentation for how to create effective autocomplete stubs.
Regards,
M.Y. Developers
Thank you so much! That works great 
I’m going to start using command B from now on! Nice find
woo more Sublime fans! been using it since the original.
I have my simple build code which works w/o problems on win machines:
{
“cmd”: [“C:/Program Files (x86)/Corona Labs/Corona SDK/Corona Simulator.exe”, “${project_path}/$project_base_name/main.lua”],
“shell”: true
}
As you can see, the only thing you shoud do is to save ST project file in the same folder where your source files folder is and to give to your project the same name as source files folder has.
It should look something like:
Zombies(folder)
Zombies.sublime-project
Zombies.sublime-workspace
In this case you can open project with no files open and you’ll still be able to run it in the simulator.