Josh

The fact that there have been zero commercial games with Leadwerks so far indicates we are doing something drastically wrong. To solve a problem, you have to first admit it exists. The brutal reality is that people are generally making beautiful walkthroughs with left-handed guns, and very little else.

I like that you did GameLib, but it's not enough on its own. If that approach worked, it would have happened already.

I completely missed this topic. Regarding navigation meshes vs. A*, I don't really see what difference it makes. If one works, and the programmer is familiar with it and can produce actual results, that is infinitely better than a theoretical alternative that might or might not have any real advantage. Thanks for posting this.

Gamelib, yes, but it's a framework you add components to. You cannot interchange C++ components. You have to include headers and files, and there's a compiling step, and one code file might rely on a library that conflicts with something else...technically, it's possible to share C++ code, but it's just such a pain in the bum no one bothers. Can you drop the code for someone else's groundhog AI into your C++ project? Not without so much work, it makes you seriously question whether you ought to bother. With Lua, you download the code, press F5, and it works immediately, across all supported platforms.

Haha, ToLua works! The code below will print out "No Name, Joe, Joe", as it should. Thanks Mika for investigating this months ago, but the issue with Luabind is so obscure I can't blame you for not finding that. Its documentation and presentation really does appear better, but I think ToLua wins. for i=0,self:CountChildren()-1 do child = self:GetChild(i) if child.name==nil then Print("No Name") child.name="Joe" Print(child.name) else Print(child.name) end end for i=0,self:CountChildren()-1 do child = self:GetChild(i) if child.name==nil then print("No Name") else Print(child.name) end end

There I go, breaking my own design parameters. You're probably right about that.

Well, who put out more games in 2010? The FPSCreator community, or the Leadwerks community? I don't think doing away with programming is the answer, but I do think that providing a framework within which we can code together is critical. Okay, so your main program should be in C++, C#, or whatever, and that's fine. But I believe very strongly in the power of Lua for game interactions. When you write code in C++, you are branching development away from the rest of the community, because from then on, your code and their code can't be combined. Not easily. Therefore, every C++ programmer is an island. With Lua, code can be readily shared. We now need a standard way to code interactions so that the shared code can be more interesting than self-contained game objects.

Ah okay, you can just add this in the .pkg file: $using namespace le3;

I have it working, but ToLua's namespace system is really obnoxious. By default, the command namespace is included, so all functions are like this in the Lua state: le3.LoadModel() Why is everything I didn't write so badly designed?

That solution is just like using GetChild() and CountChildren() methods, which isn't nearly as cool. It also means you will never have stuff like this: a = surface.vertex[4].position.x

Does ToLua++ support std::vectors and lists, so I can do stuff like this?: C++: class Entity { std::list<Entity*> kids }; Lua: local child for child in entity.kids do --do stuff end

That's probably a lot better for C++ integration than Lua, but until they get a JIT compiler, the speed will never compare.

Actually... -The output file is a .cpp file. -The input file HAS to use the .pkg file extension. Don't know why, I guess it made sense to the programmer. When I use an .h file, an output file is generated, but it doesn't contain any classes or constants from the header file.

Oh, I see.

It's been amended to be more specific about code and executable files.

Here's what the console displays when the -h switch is used: tolua++. exe -h usage: tolua++ [options] input_file Command line options are: -v : print version information. -o file : set output file; default is stdout. -H file : create include file. -n name : set package name; default is input file root name. -p : parse only. -P : parse and print structure information (for debug). -S : disable support for c++ strings. -1 : substract 1 to operator[] index (for compatibility with tolua5). -L file : run lua file (with dofile()) before doing anything. -D : disable automatic exporting of destructors for classes that have constructors (for compatibility with tolua5) -W : disable warnings for unsupported features (for compatibility with tolua5) -C : disable cleanup of included lua code (for easier debugging) -E value[=value] : add extra values to the luastate -t : export a list of types asociates with the C++ typeid name -q : don't print warnings to the console -h : print this message. Should the input file be omitted, stdin is assumed; in that case, the package name must be explicitly set. pause Press any key to continue . . . So I try putting this in a .bat file: tolua++.exe -h pause And this is displayed: tolua++. exe -H "entity.h" ** tolua internal error: [string "tolua embedded: src/bin/lua/doit.lua"]:34: #no package name nor input file provided. stack traceback: [string "tolua: embedded Lua code 23"]:6: in main chunk pause Press any key to continue . . . It looks like the input file is not being read?

It says "including", not "limited to", but you have a point, especially if anyone sells code.

You won't have a U.S. tax ID obviously, but it would be better for me to have whatever your country uses. I'm working on the assumption Leadwerks will be audited at some point. Yay for 1099 forms. This information will only be stored in physical form (papers in a filing cabinet). I will not store sensitive information like this on hard drives, CDs, or any other electronic medium. I recommend you only include you tax info on the paper copy you mail to me.

The evaluation version might still be painting terrain on the CPU. It changed a while back to use the GPU, so it's super fast now. New evaluation kit will be released within a month.

I prefer art assets because it requires less work from me, but will judge other things on a case by case basis.

The Leadwerks Merchant Agreement is available here: http://www.leadwerks.com/files/Merchant Agreement.pdf Instructions for applying to become a Leadwerks Merchant will be forthcoming.

The Leadwerks Asset License is available here: http://www.leadwerks.com/files/Asset License.pdf All free and paid files in the Asset Store are distributed under this license. A notice and link has been added to the file display page: http://www.leadwerks.com/werkspace/files/file/214-2-medieval-weapons/

I don't know how the videos should be laid out, so I just left it as is for Tom to do something with. I don't like the big grid of thumbnails, but I don't know what exactly should be done.

I think so, yes

Removing the interior faces may help. It's hard to tell what's going on without seeing the actual .3dw file.