Canardia

A sbx file doesn't have to be a complete scene, you can also load multiple sbx files, each having some other parts. All LoadScene does is to add entities to the world, it doesn't delete old entities .

You can do it quite easily. Just create programmatically a sbx file and then load it.

It works with both.

Many things in Editor stop randomly working from time to time. Then you can close all programs and suddenly they work again. Just had emitters stop working on firepit and a new emitter, but on one scene they worked, it's totally wierd B) I blame programming languages with garbage collection (like BlitzMax), as they allow the programmer to make randomly working code, since they don't crash each time when the programmer makes a mistake, and that's bad.

I haven't published GameLib 0.0.15.0 yet, but I'll inform when it's ready for download.

There were more things not working with Editor created scenes in gamelib. I have fixed so far skybox, water, sounds. Testing emitters now. Gamelib still supports 2.28 scenes, so I needed to add a variable to choose between non-lua and lua processed scenes: TScene::uselua=true is the default setting, so it will work with 2.3.

Ok, then it's better to free it also.

Doesn't seem to be needed, as the model disappears when I press the delete key in Editor.

It doesn't work with terrain the same way. You need to hide some wall inside the terrain, but there was some other way to do it too, which I can't remember right now.

I get those warnings in shaders.pak too, but everything seems to work. The only change I had to do in gamelib so far, was to add the skybox loader for Editor: (after the block with if(ek=="0")) ek=GetEntityKey(e,"skymaterial","nothing"); if(ek!="nothing") { GetFramewerk().GetRenderer().SetSkybox(LoadMaterial((str)string("abstract::"+ek).c_str())); }

I don't think the "Null Framewerk" message can be avoided, since the engine wants a global "framewerk" object, which can only be set from BlitzMax, as the structure of the framewerk object is completely different in other languages. I think Josh should remove the message completely.

You should place the books in Editor, as they are physics objects.

I would make all meshes out of smaller objects, and make each object a physics body. Then you can destroy and move everything.

The "Null Framewerk" message comes probably because I need to publish the framewerk object to LUA in GameLib. The shader errors might be because you didn't use the latest shaders.pak.

Ok, I can parent it to the lua object, but not to the entity, since then the animation would not work anymore. This seems to work fine, and it also deletes the cubes for each model you place in Editor: require "scripts/class" local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) object.cube=CreateCube() object.cube:SetPosition(object.model:GetPosition()) function object:Free() self.cube:Free() end end

Actually Josh changed it back, so Framewerk C++ has been now also changed back. There is no need for _adjust shaders anymore.

You need to run the updater, Framewerk C++ was changed yesterday.

I'm trying to spawn a cube when I place a model in editor, but Editor crashes when it tries to free the cube when I delete the model from Editor: function class:CreateObject(model) local object=self.super:CreateObject(model) cube=CreateCube() function object:Free() cube:Free() end end

You don't necessarily need any inventory system, if you use physics for the inventory

OpenGL does this automatically, you can check also when you are inside the building, how many polys are rendered.

Yes, everything works better without .NET

You don't use the newest engine.dll.

That's just because the bmx framewerk is not uptodate

You don't need to put anything back, since when Josh uploads the new shaders.pak, your Renderer.cpp will be returned to the original version also (when you run the installer).

str is "the null terminated C string which LE uses", it's not the same as char*, although it might be currently similar. At the moment it's also unsigned char*, since not all C++ compilers work with signed chars for strings. In future str might be also unsigned int*, if there are some multibyte string functions. The whole point of declaring your own types is that your code stays compatible with all current and future OS and hardware. LE uses also flt instead of float (which is used as "the floating point resolution which LE uses for GPU floating point numbers"), since GPUs might soon be all 64-bit, so you don't have to change any code then either, as the headers will then have flt defined as double. Note that for pure mathematical functions you should always use double, as it's about twice as fast as float. bool is also twice as fast as int.