Josh

The current version of BMX will work with some combinations of modules, and not with others, so it's partially fixed. Since I would have to send additional examples to Mark, describe the problem, test his results on Windows and Mac, and no one else seems to be even doing this, I am not going to pursue it. I am just writing here because this is an example of knowing when to quit something that isn't important. The benefits of using a module namespace are not overwhelming, and continued testing would eat more resources than I want to devote to this. It works fine now with the "le" prefix on everything, and doesn't require any additional effort, so I am moving on.

Exactomundo. Of course, I expect 95% of the content of the articles section will probably be tutorials.

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. 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. 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.

If you're describing problems you ran into that are specific to your own project, I would make it a blog entry, unless it was a sort of post-mortem thing, "this is what we learned", etc. that is written to help others who are likely to encounter similar problems. For example, I wouldn't submit an article to GameDev.net that is shameless self-promotion, but if I put it in the context of a more academic discussion, then an article about my project would be acceptable.

An article contains information that helps other people, either with technical, business, or other matters. A blog is more of a self-promotion thing, where you can talk about yourself in whatever way you want. There could certainly be some overlap there, but that's up to you. Tutorials are appropriate for this section, and in fact will probably form 95% of the content, but they should be in the format as described above.

I don't think this has been explained very well, because people are posting anything but articles in the articles section. An article is formatted text. You can include images, blocks of code, a download file, and one or more videos, but if there isn't a few paragraphs of text, it isn't an article. This is what articles should look like: http://www.gamedev.net/#articles This is an example of an article that includes images, a download file, videos, and code: http://www.leadwerks...o-animation-r11 The articles section is not a place to post a single file, video, or bit of code with no discussion. If you have a tutorial in PDF or another format, you may post it in the general discussion forum, but I do not like having a bunch of tutorials in disparate formats, which is why we don't offer a place for these. The articles section provides a place where they can all be readable online, in a consistent format. Do not post links to external files or images in articles, because they may becomes dead links in the future. You have the tools to include everything you need in the article contents. I'm very happy when people contribute to the community's knowledge, but I am going to have to start enforcing some standards in the presentation of the material. It's really a mess right now. Of the four community articles that appear on the front page here, not a single one is an actual article: http://www.leadwerks...e/page/articles

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.

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.)

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.

Sometimes I run into situations where I don't really know how to structure things. I don't mind this, because it usually results in some really elegant design once I figure out what to do. I just play with ideas and try not to force anything, and when the right idea arises, I will recognize it. Explaining a problem to someone else can help facilitate that process. How many times have you solved a difficult problem right after you posted a description of it on a forum somewhere? The procedure of explaining it logically to someone else can help you think more clearly about it. And so, we have today's blog topic. Below is a very rough start to the script editor. The syntax highlighting system was written about a year ago, and works beautifully, using the native text widget on both Windows and Mac. In the Leadwerks3D source code, there is a base class called an "AssetEditor". From this class the material, model, shader, texture, font, and script editor classes are derived. Like the other asset editor windows, only one instance of the script editor window will be allowed open at any time. Unlike the other asset editor windows, which display only one asset at a time, the script editor will use tabs to display multiple files. Scripts aren't a typical asset like a material or a model, so it's fine for them to behave a little differently. Any Leadwerks3D application can have its Lua state debugged. The engine uses networking commands to communicate with a debugger on a specified port. This means the engine can communicate with a debugger whether it's part of a C++ program, C# app, or standalone Lua interpreter. The debugger can display the Lua callstack and shows all variables and values in the Lua state, including full examination of C++ objects and members! I do not intend for Leadwerks3D to "play a game" in the editor. We've tried that approach and there are a lot of problems. I want Leadwerks3D to be a very solid and stable level editor, with a visual interface to do everything you need. I also want better consistency between Lua and C++ programs. Therefore, Leadwerks3D will use a run game system more similar to 3D World Studio than the Leadwerks Engine editor. A dialog will allow you to choose the application to run, command-line parameters, and other settings. These will be saved between sessions, so you can hit a key to do a "Quick Launch" and run your game. It would be possible to hook the Lua debugger into any application as it is launched, which could be very helpful. Let's go back to the script editor now. My inclination is to have F5 launch an interpreter and call the script for the currently selected tab. However, I don't think it's a good idea to use multiple game launch modes, I already described a uniform game launch mode for both Lua and C++ applications, but that seems sort of counter-intuitive if you are working in the script editor and just want to run something really quickly. There;s also the question of whether we want to provide a standalone script editor and debugger outside of Leadwerks3D. Or should the debugger be a standalone application as well, since someone might want to use it with a C++ application? You see there are a lot of options and a lot of possible ways to set this up. What about Lua compile errors? I can print that out in the engine log, but how will the editor display it? If a compile error occurs, should the program pause and display the line it occurred at? What if the user just doesn't care, and wants the program to keep going? Alternatively, the user may want to just hit F5 in the script editor and check for basic syntax errors, which the command LuaL_LoadString() will detect. That's pretty much all my questions at this point. I don't expect anyone to come along and solve my problems, but the process of describing and discussing the issues will help me come to a resolution.

In the near future we will gain the ability to add tags to articles, so the language can be specified with a tag.

You can attach a zip file in your article, just like a forum post: http://www.leadwerks.com/werkspace/page/articles/_/programming/introduction-to-animation-r11

Explorer.exe crashes randomly in Windows XP anyways. I notice it often hangs when copying more than a few megabytes of files. Yep.

I want this on my iPad!

That does seem to be where all BMX's troubles originate.

I'll be interested in this if you get a working example of the messages thing.

Preferably nothing. This is an example of what it looks like when you specify a video ID in the article: http://www.leadwerks.com/werkspace/page/articles/_/business/interview-with-michael-betke-of-pure3d-r85

Cool, so you can make your own task manager? There's a predefined BlitzMax tag you can specify for your posts, FYI.

I was getting a reliable crash on GCCollect and finally traced the problem back to this. Never store externed C objects in a resizable array.

I generally prefer tutorials to be self-contained and not link to external resources that may become dead links in the future. You can attach a zip file in the article contents itself.

I just put the tutorial section up to prevent people from posting PDFs in the articles.

Revenue = sales x price. Price alone doesn't matter if your market size on mobile is 100 times bigger

I don't want the articles section to be a list of download links. I recommend pasting the contents of your article in the text field. You can also add up to three videos and they will appear on the first page of your article in an attractive format.

I don't think you even need to restart the program. Just go the the help>register menu item and enter your key.

This probably won't happen any time soon because it would be an extensive modification of the templates. Most of the customizations on this site are just CSS edits.