L B

The final result is really impressive. Reminds me of Borderlands terrain; lots of playable plateau areas and realistic, sharp cliffs.

Updated the list with the latest update. First 3 items fixed.

As in "Build > Clean Solution"? That doesn't work. If you build twice in a row, it won't link the second time, so you won't get the warnings again, but if you rebuild, you will.

If you like working on the latest IDE, or if you have a paid license for the latest IDE, you likely won't want to revert to Visual Studio 2010. The argument that it's required for XP support is hardly valid, as most technology enthusiasts and industry professionals made the choice to leave that obsoleted operating system. Moreover, VS2012 can compile perfectly fine for XP, even if Leadwerks had to (for some obscure reason) use MFC. Luckily, if Josh isn't willing to include a VS2012 build or project template, you can still use VS2012, as long as you have VS2010 installed. I haven't tested if this trick works from a paid VS2012 and an express VS2010, but it works if both are express (and is likely to as well if both are paid): Download and install VS2010 Open up VS2012 and your Leadwerks project If prompted to upgrade the project to VS2012, accept and go through the wizard Right click your project > Properties... Change "Configuration" from "Active(Debug)" to "All Configurations" Go to the Configuration Properties > General tab Change the "Platform Toolset" from "Visual Studio 2012 (v110)" to "Visual Studio 2010 (v100)" Click OK to apply and close Enjoy!

Getting the same here. From S/O: http://stackoverflow...-not-found-with Josh didn't include the PDB (program database) file that VS compiles when in debug alongside the lib files. Usually, you could just disable the warning through /wd4099 in the compiler or /ignore:4099 in the linker. However, Microsoft has made it un-ignorable by design, which is so frequent and annoying that this happens: The only solution that actually exists on your end is to patch your linker. You heard that right, go hex edit the link.exe file in your Visual Studio installation. If you don't mind doing that, here's an article that describes how: http://michaelnoland...-was-not-found/ (But really, it's a mistake from Leadwerks not to include vc100.pdb. It shouldn't be our burden to fix that warning).

Created a project for C++, opened up Visual Studio, tried to build, but it can't find Leadwerks.h. I can't find it myself in Windows search. In which folder is it supposed to be? Edit: Rick told me it's supposed to be in \Engine\Source, but I only have "headers.zip" there on a clean install. Is the source dir missing from the server?

Looked for a while as well. Is there a way to see which surfaces are available in the model editor?

From playing with the editor within the last hour as a "vanilla" user, here's what I miss for my workflow: Important: Option to toggle grid (Set grid size to 0, although could be a checkbox) Option for mouse look sensitivity Option for camera move speed Ability to import more than one file at once from the import dialog "Import..." right-click menu button in the asset list Shortcut for import (Ctrl+Shift+I on Windows, Cmd+Shift+I on Mac) Delete shortcut in the asset list (Del on Windows, Cmd+Backspace on Mac) Rename shortcut in the asset list (F2 on Windows, Enter on Mac) Cut/Copy/Paste shortcuts in the asset list (Ctrl/Cmd+X/C/V) Ability to drag assets in the asset list to other folders Grouping by object-type in the scene treeview Shortcut for gizmos (e.g. Alt+M/Alt+R/Alt+S/Alt+Z for move/rotate/scale/shear) Shortcut for recently loaded maps (Ctrl/Cmd+1/2/3/.../9) Option to lock Z-axis when rotating in the model and material editors Ability to select multiple models and batch-resize them Ability to select asset from right-click menu on instance Would-be-kinda-nice: Icon for the import menu item Instant search in the scene treeview (possibly with a shortcut, e.g. F3) Option to toggle hardware AA (should be feasible with forward-OGL)

^this.

I agree with better object collapsing, jump-to-script from the flowgraph and autocompletion. None of these are priorities, but they'd surely help the flow. But then again, these might be already here and we just haven't seen them in the short video.

As if there was someone other than Josh behind that Admin account.

If you call a date it'll give you pressure. Humans work better under pressure.

I'd call March 1st too. At least, not anything before.

Odds are that I'll make a C# wrapper for Leadwerks 3, whether Josh or Mika like it or not (provided Leadwerks 3 still works with a main DLL). In all likelihood, it won't work for Xamarin and thus portable devices. It'll just be a wrapper for Windows, which is fine for a lot of people who still target this massive audience and don't want to waste hours on the intricacies of low-level development or on the volatility of scripting. That being said, if I can reconcile with C++ (the ex-girlfriend analogy truly was good), I'll probably use C++ myself for Leadwerks.

Haha, I agree with Josh. Don't use your own custom, globally unknown and confusing type defs. If you feel like "float", "int", "unsigned char", etc. are not specific enough and platform variant, use stdint.h (which is, you know, explicit, standardized and known by most C/++ programmers). int => int32_t unsigned short => uint16_t unsigned char => uint8_t etc. http://stackoverflow...e-or-not-stdint

These command names are like the recognizably-shaped gift you see wrapped under the Christmas tree.

I for one prefer a single monitor. After using duals for about 2 years, I came to the conclusion that I was wasting time managing a second screen.

While I agree that the "command" "pattern" (both in quotations intentionally) is ridiculous, the simple approach of saving every state of the program for each action is lazy (but that's not bad per se) and extremely memory consuming. What I'd do is have a reverse action for each action, push the action to a stack, and pop the reverse on undo. Tadah.

We can testify. -Every Leadwerks 2 user, ever.

"Windows supports binary files, so use them." "For what?" "For everything."

Smart pointers really do seem interesting. I wouldn't want to have to manage my ref count either. Think of the Lua scripters, who use this language to avoid the complexity of C++. If they don't want to deal with pointers, they certainly wouldn't want to deal with reference count either. They'd want it to "Just work".

I just got the title's pun!

Josh mentioned wanting to use states. However, I can see how that can grow to a high RAM usage fast. I use something similar to the command pattern too usually.

So close! Keep it up!

That's not a fatality. Yes, with people who do not understand how memory management works and do not call delete, this will happen. If you code properly, it won't. In the same spirit, using your newly proposed system will lead to invalid reference count crashes or objects that stay in memory indefinitely when they shouldn't, because people forget to call "IncRefCount" or "Release" or call them too often. Constructors are not passable through a DLL for other languages, I think this was the reason. Also, in languages that require class wrapping (Java, C#, etc.), using static classes allowed to have 'Entity::Create' instead of 'Engine::CreateEntity', which is a nice syntactic sugar.