Jump to content
  • entries
    943
  • comments
    5,899
  • views
    924,384

Back to Werk


Josh

2,348 views

 Share

In my last development blog, I wrote about some design problems I faced, and why I wasn't sure how to proceed. I've resolved these issues by building the debugger and game output display close to where they will be most likely to be used, the Script Editor.

blogentry-1-0-33659800-1330147438_thumb.jpg

 

I was pleased to find that my Lua debugger code I wrote about a year ago works perfectly. This allows breakpoints, code stepping, and the display of variable values in your game. It works with any Leadwerks3D executable, so you can even examine and debug the Lua state in your C++ executables. (This does not debug C++ code or other languages, as there are already appropriate tools for that.) I like to combine the callstack and variable display into one tree view, so you can quickly navigate the program.

 

I decided it made sense to build the game output and debugger into the script editor, because that is where you are most likely to use it. Even if you are debugging Lua in a C++ application, you still want to be able to double-click on the call stack and display a script in the editor. The only situation where this design doesn't really make sense is if you launch a C++ application and just want to look at the program's output. In that situation, it is a little strange to need to open the script editor to do that.

 

The actual executable to be launched will be controlled in the project settings. The default for a Lua program will be a copy of the interpreter executable that gets added the project folder. You can specify the script in a command line field, like this:

+script $scriptfile

 

Where "$scriptfile" gets replaced with the file name of the currently selected script file in the script editor. For a C++ application, the project will simply be set to call the executable the C++ template sets up a project for. If any of that sounded confusing, take a look at how maps are launched in 3D World Studio (or even Valve's Hammer Editor, for that matter). The bottom line is it's set up automatically when a project is created, and you probably will never need to change it, but the capability is there if you need to.

 

Previously I wrote that it's better to name a thing with a specific name that describes most of what it does, rather than to broaden the description to become fully encompassing but vague. The same holds true for program and workflow design. The debugger and game output display are built into the script editor, where they will be the most useful overall. It's not "correct" in a hyper-analytical way, but it makes sense and is convenient.

 Share

4 Comments


Recommended Comments

Where "$scriptfile" gets replaced with the file name of the currently selected script file in the script editor.

 

So we will have to switch to our main lua script tab in the editor to run our game each time? For a project why not just create a "main.lua" file automatically for us and just have that be the default script that gets passed to the interpreter? Let us change it if we want (or not even as it's not a big deal to make us use a file named main.lua file) but defaulting will just be easier. Then it also doesn't require a person to switch back to the main lua script each time to run their game. People will constantly forget to do that while they are editing entity scripts and I don't know about anyone else but I run my game constantly while programming. I would picture when I open up the Lua editor for the first time main.lua always opens up and it has a default base LE program already in there. This will be much more friendly for new people and advanced people can modify it as they see fit. Not that big of a deal for experienced programmers but very friendly for newbies to have it all setup already for them.

 

Is there any case where you'd ever want to just run an entity script as the main script? I wouldn't think it would even work if you did because it wouldn't have the game setup code like the main file would. So that would seem to make more sense to be a one time setup thing and not a constantly selecting the main file tab. Picture that workflow of having 10 scripts open for various entity scripts that we are programming. Make a change, switch back to main script, run game, go back to entity script. Rinse and repeat 20 times in an hour. OR just run the game no matter what script you are in. That's much easier and will avoid the <Press run game> <ERROR> "SOB forgot to switch to the main lua file tab again"! It's also more like other programming languages that don't require you to go to the file that has int main in it to run each time. That would be a nightmare.

Link to comment

All I really need are two hotkeys, like F11 and F12 which both can launch a cmd or exe and get the sbx filename as parameter. Then I would put under F11 the actual game.exe, and under F12 the Code::Blocks IDE.

Link to comment
Line numbers please.

We use the standard interface for Windows and Mac, and these don't support line numbering. You can double-click on a function in the debug tree to go to the appropriate line, and the current line number is displayed in the status bar. It's a compromise, but the native text rendering looks sooooo much better than Scintilla or something like that.

So we will have to switch to our main lua script tab in the editor to run our game each time? For a project why not just create a "main.lua" file automatically for us and just have that be the default script that gets passed to the interpreter? Let us change it if we want (or not even as it's not a big deal to make us use a file named main.lua file) but defaulting will just be easier.

That's a good point. I'll see what happens when I start actually using it.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...