Development Blog

Make it so that F5 launches a .cmd file, which it creates from a list item field like in 3DWS. It should have also parameters, which Editor replaces with actual values. A F5 script could look like this:

{workvolume}:
cd {workdir}
cd source
mingw32-make
if errorlevel 1 goto errors
cd ..distro
game.exe {parameters} {scenefilename}
goto over
:errors
notepad++ errors.log
:over

 

And what F5 then compiled this into would be a launch.cmd file which looks like this:

d:
cd projectsgame1
cd source
mingw32-make
if errorlevel 1 goto errors
cd ..distro
game.exe 640 480 data/maps/level1.sbx
goto over
:errors
notepad++ errors.log
:over

 

There could be a set of favorite scripts which F5 can run, and also a default script which would be like:

luac {projectname} > errors.log
if errorlevel 1 goto errors
engine.exe {projectname} {parameters} {mapfilename}
goto over
:errors
notepad++ errors.log
:over

Getting the printed output of the program is not a problem. I can just create a process and read the output directly. I'm thinking more about the workflow and ease of use.

I have to agree. The number of times I've come up with a solution while explaining the problem to someone... and most of the time the someone I explain it too doesn't not understand programming but it still helps find a solution because you are pouring out your thoughts into words and for some reason that makes things make more sense.

Regarding the debug thing. Maybe a simple UDP socket on localhost would solve the problem of sending info from the program to the editor. Just a suggestion.

There's no technical problems. The problem is one of workflow. What is the best way to design this to work? (The UDP socket is actually exactly what I am doing. It allows the debugger to communicate both ways for code stepping.)

Isn't debugging done in Code::Blocks IDE? I don't quite understand why you need debugging in a CSG Modeller. 3DWS didn't have that either, and I never missed it.

3DWS didn't have that either, and I never missed it.

Maybe because you didn't have it And this is not the same thing. In 3DWS you had no scripts to debug, right-

But the programming should be consistent between all languages, including Lua. Most people probably prefer Code::Blocks for Lua projects also, because it has very sophisticated plug-ins for code clips management, and is thus more suitable for larger game projects than a simple text editor.

For the lua compile errors I would think following Visual Studio's model of having a window at the bottom of the editor that will show each error would work well. We can dbl click each error line to go to the error in the file.

 

I currently use Notepad++ for Lua programming in LE. Mainly because it has tabbed browsing of files which I think would be very handy in your script editor. Sometimes we have to bounce back and forth between scripts and without tabs it's very inefficient today.

 

Are you giving us access to an "int main" type of script like you do today or is that hidden from us and we work with these scripts that we attach to entities only?

 

I would have a separate button/key for syntax checking only. This is common in SQL editors where you have one option to check syntax, then another option to actually run it. It's very handy and with all these little scripts LE 3D will have I can see that being handy also.

 

So F6 to "compile" the script to check syntax errors and if errors show up a window at the bottom of the editor to allow us to go to the error line.

 

F5 to actually run the game. I wouldn't think you'd ever just run one script itself would you? I guess at first glance that wouldn't make much sense to me as it's part of the entire game and can have many connections/requirements to/from other scripts.

 

If a run-time error happens, stop the game on that line, and open the file that contains the error in another tab and highlight it yellow and show the error in a messagebox.

Since i am not a native english, i hope that i misunderstood the part of not being able to launch a script as a whole game, currently all my game is based on lua scripts which call each other and a launch (F5) button is all what i need.

I don't know 3DStudio but i hope we can do the same as now.

Sorry for my fear but i hope someone will chill me out

Don't worry, whatever Josh comes up with, you will be still able to do the following always:

1) Press Ctrl-S in Editor

2) Press F5 in ScriptEditor to compile (if changed) and run the game

because you have to be able to do that anyway for all other languages also:

1) Press Ctrl-S in Editor

2) Press F9 in Code::Blocks to compile (if changed) and run the game

 

Josh is only trying to integrate the Lua Editor into Leadwerks Editor, which is kinda useless in my opinion anyway. It could be just left out. Or he could find a way how to make the above 2 steps even easier, although it's OK how they are now too.

ok thanks for clarifying this

I don't see any point in setting up Leadwerks3D to launch command-line compilers for C++ or other languages (though you could). It gets very complicated for so many languages and platforms, and the feedback would be inferior to just using the real IDEs for that language. I just see it as launching either the script interpreter, or your own executable that you define.

 

I've been using C++ so long, that I am used to a big wall of text whenever I hit F5, but I think the feedback when Lua loads a file is just a single error line if anything goes wrong. Therefore, there is no need to print out a bunch of compile information. If you press F5 in the script editor, the Lua file can be evaluated, and if any syntax errors exist, a message box can pop up and the line in question can be highlighted. This is simply evaluating the syntax of the script, not running anything.

 

Now when we want to launch a scripted game, I can either launch it from the script editor, using the script in the selected tab, or I can do it through a "run game" dialog where you define whether it's a scripted game or your own executable. The advantage of the "run game" dialog is you can launch script and C++ games and debug their Lua states in one interface. However, I feel like it's more natural and easier to launch a script by hitting a hot key in the script editor, which is my main point of conflict in this design.

 

Should the debugger and game printed output dialogs be built into the script editor window? That seems logical, but what about C++ applications? Am I going to make a separate script debugger and output window for those? It's a bad idea to have two versions of the same interface.

but I think the feedback when Lua loads a file is just a single error line if anything goes wrong.

 

This could be inefficient if it's the case as you could have 20 syntax mistakes and it'll only show you the first one? Then you have to keep syntax checking over and over again? Sounds like a pain.

 

The advantage of the "run game" dialog is you can launch script and C++ games and debug their Lua states in one interface

 

People using C++ will most likely be launching their game from the C++ IDE so they can debug their C++ code. I know most C++ coders here were upset that Lua was "required" to get some editor information from models in a map. The C++ people seem to not really want anything to do with Lua. They (I) won't create an exe of their C++ program just to then launch it from the editor because you lose the ability to debug your C++ code which will have the bulk of logic in it. Any attempt to merge the editor with their IDE will most likely fail and not be a smart use of your time (imho).

 

I personally think your Lua design is mixed mode which makes things more difficult. You seem to still want to give an "int main" type Lua file and not fully commit to the Lua model script system for total interaction of the entire game logic for games using Lua. If you did, then your engine.exe program would be the only thing you need to launch when we press Play from the editor. You setup properties in the editor that engine.exe reads and uses for certain things like debug info. engine.exe should be a very generic game loop that reads settings from a file to determine specific things it should be doing. All your game logic should then be defined in the model Lua scripts. There is no need to then give us an "int main" Lua file. There would be no point in it.

 

Just so you are aware, this isn't me being radical. A good number of engines don't provide an "int main" to the developers and amazing games have been created with them. For LE Lua I think it'll help to take "int main" away as it starts to shape how people code with it. If there are too many possibilities it segregates the community.

 

On the C++ side:

Like I was saying I don't think the C++ people will be pressing Play from the editor. They will be running their game from their C++ IDE loading the map they are working on from the editor.

I agree with Rick, when I write a game in C++, I don't want it be infected with Lua at all, and wasting valuable memory for its GC and interpreter. I need all memory for my game to get the maximum content at maximum speed (everything loaded into memory makes things much faster).

 

But like I already said to diedir, if there would be a way to make the 2 keystrokes less (well actually 3 keystrokes, since there is Alt-Tab between them too).

 

Maybe F5 in Editor could be programmed to switch to the Code::Blocks IDE window, and then send a F9 keystroke. That would actually work! Then you can use your favorite language and your favorite IDE, and only the window class and F9 key would need to be configured in Editor. And you would have a debugger too for all languages.

This could be inefficient if it's the case as you could have 20 syntax mistakes and it'll only show you the first one? Then you have to keep syntax checking over and over again? Sounds like a pain.

That's just the way Lua works. It stops on the first error. This actually annoys me about C++ because one syntax errors causes a whole cascade of errors, and you end up with 40 error messages because you forgot one semicolon.

 

Maybe F5 in Editor could be programmed to switch to the Code::Blocks IDE window, and then send a F9 keystroke. That would actually work! Then you can use your favorite language and your favorite IDE, and only the window class and F9 key would need to be configured in Editor. And you would have a debugger too for all languages.

One of my design rules is not to rely on or try to integrate third-party tools I don't have complete control of. This is slightly different, but recall all the problems that arose when I relied on the third-party Newton serialized format.

 

I personally think your Lua design is mixed mode which makes things more difficult. You seem to still want to give an "int main" type Lua file and not fully commit to the Lua model script system for total interaction of the entire game logic for games using Lua.

That's correct. I think a global script is always needed for a Lua game and attempts to abstract that away end up being more confusing.

 

The ability to debug the Lua state of a C++ program is a new idea you have not been exposed to before, but I think it will end up being very useful, especially for professional studios. Think about when your game code is done and artists are producing maps for the game. They'll want to be able to easily launch the game with the current map, and they will want to be able to inspect the Lua state to see if something goes wrong.

I still think the window class + keystroke macro should be possible with F5, or then F9 in Editor, if you do some wierd stuff with Lua states in F5.

Or then you could add the possibility to write Lua or dll plug-ins for Editor, then the community can make that.

It'll be interesting to see how this works and if it will be different enough than how Lua works with LE today to provide real code sharing, but I'm not very optimistic about it because it still allows different design approaches which will reduce the amount of sharing. Not having access to "int main" doesn't limit a game in any way.