Canardia

It will bring you to r5, but the full installer includes also "The Zone" map.

You can try them out in Editor.

I think Josh should give you the 2.3 upgrade for free, because then we can celebrate the complete migration of the userbase to 2.3! I'll buy a bottle of champagne when that happens too

What I have learned is that the symptom of randomly disappearing objects when camera angle is changed, is often based on the viewdistance of the scene pivot or some other entity to which your model is parented to. Try setting the viewdistance to infinite for the weapon and also for the entity to which it is parented.

Yes, unfortunately. The infinite option makes scenes very heavy to render and should not be used, but since the other ranges are too small for real games, that's the only thing you can do at the moment. However, there will be a new command which allows you to adjust the near (=0), medium (=1) and far (=2) ranges yourself, then it will be perfect. I hope that command comes in 2.32R6.

"viewdistance"="3" LE 2.32R4V4 displays by default only objects which are closer than 20m. There is also the "far" distance, but it's also only 100m or so. Normally games need around 2000-10000m range of objects, so you have to use the option viewdistance=3 which means infinite. Josh said this makes things easier for newbies, but for professionals it seems to make things much more difficult In addition, if you have entities parented, then the parent's viewdistance counts also, so make sure you have viewdistance=3 for everything which you need further away than 20m. A neat trick is to say: EntityViewRange(scene,3,1); so all objects in the scene will be visible. After that you can selectively set the view distance for objects which are always closer than 20m visible (for example unmovable objects inside a room which has no windows and the door is opposite to a corridor).

However, if the game engine lacks advanced features, you can't do them with an easy-to-use Editor either You can do some of those with coding, but many of them need to be part of the engine.

It should execute both scriptd as they are (+1, then -1). Developers can use the require statement to include other script they want to inherit and override, so the engine should not change and confuse the behaviour of Lua scripts.

Newbies don't make games, no matter how good the Editor is. I want more game engine features to the engine itself. Today I saw also a PhysX demo where the player model was a ragdoll and it combined bone animations and ragdolls seamlessly, even including joint stiffnesses:

It makes sense to have physics features available for entities, although I think they are really models then. Most objects you work with in game development are models; meshes are only used for programmatically animated or additionally constructed with physics elements (in ragdoll fashion), and entities are more like internal 3D objects like pivots and sources. The high level 3D objects should be always called models, not entities. Else you confuse everyone without any logical reason, unless you find a good new name for the core entities.

You should use voxels for lots of detailed "high polys". Modern voxels are little 3D cubes and they look much better than the first generation 2D sprite voxels. I think LE should also use voxel terrain, since the polygon terrain has only problems with size and accuracy. Crysis and C4 uses voxel terrains too.

Have you checked the CreateCustomerBuffer C++ example in the Wiki?: http://www.leadwerks.com/wiki/index.php?title=Buffers#CreateCustomBuffer It works without using the Graphics() command, so it should do exactly what you need for Qt.

You could modify Qt to call LE's Graphics() command to create the OpenGL context.

The GUI should not setup the OpenGL context, but only use OpenGL commands to draw to the existing OpenGL content. I've done already a custom GUI for LE, and it works fine without any additional setup.

The bug is in Editor's Save routine. It doesn't save the scaling from the model in Editor, but writes originally 1,1,1 as scale. When you enter manually the correct scale values with Notepad++, then Editor loads them correctly, and also saves them correctly after that. But you always have to modify the scale values in Notepad++, since Editor keeps the model's scale value whatever it was originally when it loaded the scene. You could make a lua script which prints the current scale values of the model on the screen, and then you can copy those values to Notepad++ when editing the sbx file.

I use only brands which I know to fail the least, and I never got any problems with my self-built PCs. MB must be Asus, HDs can be Western Digital or Samsung, RAM must be Kingston, CD/DVD/BR drive must be Samsung or LG, Sound Card must be Creative Labs, NIC must be Intel, CPU must be Intel, Mouse must be Logitech, Keyboard must be IBM, PSU must be Zalman, Case must be Akasa, GPU must be NVidia or year 2010+ ATI.

You can read the terrain tile height positions with engine commands (TerrainHeight()), and draw 3D lines with OpenGL on them.

What did google say about theora c++ library downloads then? I didn't check, but I would assume you need need to download theora to use theora, since it's not part of microsoft sdk.

Use the SDK updater, it can resume when the download breaks.

You can run the SDK updater as many times you want, and it will say 0 files updated in 2 seconds if there were no differences to your existing files.

To Rick: Yeah, I had the same idea about having a production and testing version of the same game in development. I develop in the testing version, and then move tested and working parts to the production version of the game, which is then also available to all team members via git. I'll stick now with LE 2.32R4V4 in the production version, and only upgrade when everything in the testing version works. That way my game development will never pause again when something in the engine doesn't work. Thanks to git, I have also a automatic backup of every changed file of the product version all the time available, and I had to revert some files already.

I believe the removing of ini files is planned because Josh wants to consolidate their functionality in lua files. It will be much harder to make ini files then, unless he has some cool idea how to enter the ini values in a lua file. Maybe some global function like: key("myname","myvalue") key("myname2","myvalue") In general, I've been often against Josh's changes first, but after he has explained to me why he did it, I had to agree that it was indeed a better solution. So yes, when Josh announces some changes, he should explain why it is better, because most people - including me - can't see the benefits without getting an explanation.

I don't like getting rid of ini files either, and I will reimplement them in gamelib then. At least it gives me a reason to implement them a bit better then, like detecting comments in ini files, and supporting also int and float values and not only strings, and maybe also userdata. Also a #include inside the ini file would be cool, and a common.ini file which is done for all models, and a default.ini which is done for models which don't have an own ini file.

Ah yes, I think the latest template changes I made with Roland were only made in his new wizard. So this "not officially supported" wizard is the better supported wizard now I would suggest that Josh includes this new wizard in LE also.

You can still use the C++ Framewerk, although it hasn't been updated to the latest changes in the integrated Framework. Framewerk brings the benefit that you have better control over the rendering, because Framework is still missing the more detailed rendering commands. The only bad thing about Framewerk is that it doesn't work with Lua scripts which use framework.