klepto2

Without using bmx it will be impossible as the required functions are not exposed. But for bmx here is the part of code from my extended dll which handles the TileVisibility. Located in EX_Sceneloader.bmx from this package http://www.leadwerks.com/werkspace/files/file/289-extension-dll-source-release/ : If Int(String(map.ValueForKey("hiddentiles"))) > 0 Local vfile:String = StripExt(SBXReadFile) + ".vis" Local vstream:TStream vstream=ReadFile(vfile) If vstream If vstream.size()=terrain.resolution*terrain.resolution Local x:Int Local y:Int For x=0 To terrain.resolution-1 For y=0 To terrain.resolution-1 terrain.SetTileVisibility(x,y,vstream.ReadByte()) Next Next 'vstream.readbytes(terrain.newtonHeightFieldCollisionTag.m_attributes,terrain.resolution*terrain.resolution) terrain.UpdateVisibilityTexture() Else AppLog "Visibility file is wrong size.",APPLOG_WARNING EndIf vstream.close() Else AppLog "Failed to load file ~q"+vfile+"~q.",APPLOG_WARNING EndIf loader._progresscount:+1 EndIf You might find other useful info in the dll source like manual vegetation painting etc.

As long as you are not using seperate contextes for each thread and use shared memory there is no way making it threadsafe. @metatron: As far as i remember your mt sample was based on loading the meshes seperatly before loading the scene in another thread. And due the instanced nature of le this might have worked. But as soon as you load a new mesh outside the mainthread le/opengl will crash and this has nothing to do with mutexes.

Hi, for more info you should checkout Josh's Blog . And as far as I Know the ETA is not so far as it seems.

It was meant to give the line a thickness. As far as I know the radius parameter was never finished and working. A sample: Lets take a rocket with a radius of 10 cm, if you check the impact with this linepick method the rocket may leak through tiny holes < 10 cm. If you add the radius it accuratly dtonate at eg the crack on a wall.

Hi Josh, just for your information. I have succesfully build a static module (no dll needed anymore) with the latest source of scintilla. I just need to get access to a mac to get the mac part working. Hopefully i can get it.

Unfortunatly the waterplane is handled internally and the script only uses the framework commands for the water. But as we can access the world and cameras of the specific layers it might be possible to port the DrawReflection code to lua. One problem might be the background rendering, as the skybox is handled also internally we need to render everything like the normal render which may lead to performance issues.

Hi, how about exposing the various buffers from the Framework to lua? I was thinking about this feature last evening while porting my scattering code (bmx) to lua and checking out shadmars ocean shader (which is really awesome). What would be the benefit of this feature: - scripts and shader built outside of the framework may access these buffers - different shaders can work together (eg: currently shadmar uses a cubemap to simulate the reflection, this breaks a working combination of mine (scattering shader) and the ocean shader. What may solve this: - Expose the different buffers to lua - Expose functions which can produce reflections independent from the framework water I don't know if this feature is realistc, but i think it might be essential for combined user defined environment scripts. thx in advance klepto2

You need at least a Control instead of the Full Window. Take the one suggested by Aggror or check mine included in here: http://www.leadwerks.com/werkspace/files/file/242-extensions-for-lenet-including-samples/ Both controls are original for Windows.Forms so you have to wrap it into a WindowsFormsHost. But be aware, mixing Forms and WPF has multiple downsides. An alternative maybe sharpGL which has a native WPF OpenGL Control. I haven't tried it yet, but it may work. Hope this helps. If not, feel free to contact me via PM.

Nice work, can't wait to get my hands on it @Scott: If I remember correctly there was Blog from Josh where he describes exactly your idea: http://www.leadwerks.com/werkspace/blog/1/entry-758-back-to-the-art-pipeline/

- mesh based emitters - trail particles - events (particle died, particle born, etc..) - multiple emitter areas (spherical, square,...)

Hi, I'm using a base texture (the correct colormap) which fits the entire terrain. Then I add different texture layers with blend 0 to achieve details. This way you can have details for cliffs, sand or mud. You can see it a bit here: http://s2.photobucket.com/albums/y48/klepto2/?action=view&current=moddablechar-gmf.jpg I will post a more detailed screen later.

Hi, I don't believe it is a win7 thing. This is more related due the debug mode in bmx, But this is normal behaviour. In other languages this may not behave like this with LE, but thats because most languages use a release dll of leadwerks with no debug info at all where you use a real debug version of LE in bmx automatically.

Are you using Roads? If yes, there was a bug with NVidia Driver and the Leadwerks Roads. To get rid of this problem you might need to install the latest beta driver from nvidia.

Could you post the part of the log where the texture load is listed, also the code where you set the abstract path and load the texture (alternatively the material file)

TFormPoint(position,srcentity,null) should do the trick.

Here GMFSDK.zip

Very cool, can't wait for 2012. Maybe you can make the suffixes configurable. Maybe a list where you can add or remove suffixes for certain slots.

I don't know AC3D, but it looks as you set the texture scale in it. Leadwerks, doesn't handle texturescales, instead you need to to adjust the UV coords of your model to match the desired look.

I have created one by myself and also tested yours now, and both lead to a crash. Some nice addition, if you create a new scene from scratch, you can build roads and they are ok. If you then load a map containing roads, the map itself loads, but the roads are not visible. A "Rebuild Roads" makes the roads visible again. I believe it may have something to do with the serialisation of the roads, this seems to be corrupt. Edit: The previous empty scene works just for some maps like the one posted by macklebee. The desert_highway.sbx still crashes but not that early as before.

I have tried a clean install and i'm getting the same crash, as soon as there are roads involved *CTD*

Hi, you may found something useful here: http://www.leadwerks.com/werkspace/files/file/289-extension-dll-source-release/ The "EX_TerrainVegetation.bmx" contains functions which shows how to access the layers, add instances and remove instances. With some modification you may figure out how to retrieve the position of a single instance.

The idea is very nice. Some hints from my point of view: - when using blitzmax, you don't need to provide the engine.dll - protect and pak your assets - write your own ingame gui, even if you want to integrate wikipedia, you may do this by manual parsing the page or by using something like Awesomium or Berkelium - i know the models are wip or placeholdes, but try to fix the materials of the palms. texture0="abstract::palm_fronds.dds" texture1="abstract::palm_frondsDOT3.dds" alphatest=1 cullface=0 shader="abstract::mesh_diffuse_bumpmap_sway.vert","abstract::mesh_diffuse_bumpmap_alphatest.frag" shadowshader="abstract::mesh_shadow_sway.vert","abstract::mesh_shadow.frag" - take a look on "Steering Behaviors For Autonomous Characters" at http://www.red3d.com/cwr/steer/

It looks like you mixed global and local positions. As the scan pivot is child of the bot you should use: EntityPosition(scanPivot,true) for receiving the global position.

I doubt he means this I more believe he means a 2 menu items (toolbox and contextmenu) where you can comment/uncomment a bunch of code with just one click. Take a look at Visual Studio where this feature is embedded. (Blide has it as well, also most other IDEs).

Ok, I think i have the reason. if you call renderworld the engine sends the opengl commands to the gfx card. This process is async and glSwapBuffers waits till the gfx card processed all commands. So the real rendering time is total + flip time.