macklebee

Ok, but what about if you go to the Assets tab? Dragging and dropping an asset still has the terrain editing active. As far as standard interface behavior, the interaction is the same for the user. LE2, I had to press a button to switch from the terrain panel/window to the assets panel/window. In LE3, I just have to press a tab to do the same. I fail to see the difference when both will drive the same event based on one click... but eh... not a big deal to me really because I've already conditioned myself to take 1 second and press the 'Select Object' button when I am done editing a terrain.

In LE2, you got around this by disabling the object selection/3d gizmos whenever terrain editing was enabled and to get to new assets you had to press the 'Objects' button. In LE3, you can swap tabs now from terrain to assets/objects/scene without having to select the 'Select Object' button. Perhaps a change is needed to only enable terrain editing features when the terrain tab is active and to disable all object selection/3d gizmos.

Has that not always been the case? I always assumed when you were done with the terrain you would have to select the object selection button to get out of terrain editing? Did this used to automatically switch to object editing previously?

Assuming the terrain works similar to LE2 terrain, the height used in SetHeight() is a value between 0 and 1, where 1 was equal to the max altitude. In lua, I do not see what sets this altitude and currently I can only get the terrain to move up 1 meter. As for the collision, its working automatically for me, so not sure why it isn't for you. Edit-- I take that back... the altitude is set just like it was in LE2 - by using SetScale(). terrain:SetScale(1,10,1) will set the max altitude to 10 meters. So if your perlin noise generator sets the height between 0 and 1 then you should see results.

http://www.leadwerks.com/werkspace/topic/10830-entityemitsound-loop-stop-and-restart/ essentially for your purposes EmitSound() is useless in the LE3 implementation... suggest you just create your own source for the time being so you can control it as needed.

@Scrot - Dont get me wrong - i like the shadertool - its a fun to play around with - makes me wish the LE shader editor was standalone. I just want to make sure people actually understand what shadertool is actually doing for you. For shader learning - suggest looking at the inherent LE shaders, looking at shadertoy.com, googling glsl, playing around with the shadertool inherent shaders if you buy, downloading the old defunct RenderMonkey app, etc... posting questions here in the forum... @Einlander - and that is understandable - as you can jump from directx to opengl in the same app and also see a realtime effect by changing node properties (whereas in LE you have to press the RUN button). I like the layout as well - but I think some here were thinking this negated having to write shader code at all and it was just dragging and dropping existing nodes to handle the shader itself. In reality you still have to write the shader code. You are just using visual nodes to replace similar LE commands like Model:Load, context:Render, context:SetColor, etc...

that sounds like a bug to me - or at least maybe the editor needs to remove certain properties based on the type of object?

But that is my point - majority of the nodes are just for recreating the context/buffers, setting colors, rendering, etc... yes there are two nodes available for the vert/frag but it still requires you to write the shader code into those vert/frag nodes. Edit- eh whatever floats your boat, i guess... just seems for someone wanting to learn shaders for use in LE, you are doubling your required learning to get to the same point.

Ive noticed that with other things like just loading models then releasing them in older versions. i havent tried in more recent versions though. But I saw the same results in game as well as the editor - adding something raised the memory but removing them did not lower it.

Thats what i am trying to understand why people are thinking this is a godsend? Instead of just using a default App script to create the context/buffer, or load a model, render, etc, you have to learn how to use their node system to do the same thing. Again the only thing that would transfer over is the vert/frag due to Josh working with their developer. Its nice that there is a future possibility that its vert/frag will be converted to a useable LE shader, but it will still require you guys to learn how to implement the shader in LE. And with this program you still have to write shader code.. so what feature am I missing that is getting people excited? <--serious question, not condescending.

is it possible to get explanations for the uniforms? for example what is the difference between cameradrawmode vs cameraprojectionmode? I assume one sets it as ortho/perspective.. projectioncameramatrix vs cameramatrix etc...

Good news as I have this, but still unclear where the benefit of having to write the shader code in their system versus just writing it in the LE shader editor. But in any case, I and others would like to have the LE system info as well - preferably explanation of all the default uniforms. http://www.leadwerks.com/werkspace/topic/10926-question-about-matrix-conversion-to-leadwerks-shaders/

http://www.leadwerks.com/werkspace/topic/10914-shader-tool/#entry79827

yep, the script works just fine for me. Do you get any errors/warnings? Have you tried another font? As for what you need to provide to reproduce the problem - if its model/csg/physics related then typically the model or a map will be needed; if it is something driven by code, then provide a simple example script.

are you setting the context's font after you load the font size you want? local font = Font:Load("Fonts/Arial.ttf",36) self.context:SetFont(font) Edit- On a side note, I am not sure why you uploaded a *.map file? It would be more helpful to see your script.

so you're saying that we shouldn't expect indirect global caustic transparency any time soon? gotcha!

That seems strange as I can add an emitter to a scene, load the scene via script, and it works just fine. The only problem I have had is with using sprite sheets with an emitter that is part of a prefab. If the sprite sheet emitter was part of a prefab, it would just show the entire sheet instead of individual tiles. Are you using the beta?

Not offhand. I just tried LE2's lua object collision function with an oildrum by printing out force and speed values and it seems to work. Results: Speed: 1.8775409460068 Force: 0,0,0 Speed: 1.8775409460068 Force: -2.0766906416725e-008,109.9765625,0 ... ... What is the entity being used in the callback? Is the character controller 'entity0'? Worse case, you could try manually calculating the speed of the controller whenever it is airbourne. You could also try GetBodyVelocity(), but I cannot remember if it will work on a controller.

how are you reading the value of force? if memory serves, its a Vec3 in that function.

I figure this would cause someone to get their panties into a bunch. The point being made was that a lot of focus had been applied to what essentially is a niche market for LE as a product and for LE developers. And when I mentioned 10% of sales, I was being generous. I suspect on a monthly basis, it is no where near that but only Josh knows the real numbers. Josh has repeatedly stated in the past and even recently to focus more on things that will give more bang for the buck.When Josh has to spend any time to resolve an issue with linux, it means he is focusing his efforts on something that does not benefit majority of his customers. Its as simple as that. And if you are not using the steam user group as an indication of what to focus your engine or game development on, then I have no idea what market you think you are in. I suspect the LE developers group closely resembles similar numbers as the Steam user group when it comes to platforms being used. As for what steam machines will do to the overall linux share, it is all speculation at this point. But we have all heard for years that linux would be taking over as a dominant gaming platform but it still has not happen. Granted if it does actually increase, then LE and its developers may be in a good position.

Well thats the issue - the navmesh building in the video I posted said he was using multithreading so I assume that would help remove the lag you would encounter by calling BuildNavMesh(). And there is a difference between the character not being able to move forward because something is in its way (which is what we have now) and that character finding a new path to its destination because the navmesh was dynamically rebuilt to incorporate an obstruction (which is what the video shows above).

The latest Beta build (labeled as 'Beta - latest build for testing') will crash the editor with an 'Assert failed' error message if I delete an existing object from my scene. To reproduce just open an existing tutorial map and delete an object. It will cause a consistent crash with the 'Moving Platforms' tutorial map but yet doesn't seem to effect the 'terrain' tutorial.

That is understandable - if everyone that uses LE was trying to create large terrain scenes, but there are plenty of people that are making corridor shooters or small CSG maps that this would be a useful feature. Seems like that could have been left in but with a warning on usage.

Thats interesting to me because your development video that shows the navmesh generation was essentially squares but when I got LE3.2, the navmeshes were like your picture above. Its like something was lost or corrupted between then and now. Also, it seems the dynamic navmesh generation was removed (or apparently only available to c++).

The LE shader editor was a major selling point for me to return to LE as shader editing/creation was a painful process in LE2. I find myself spending more time playing with the shader editor than anything else - just too bad the script/shader editor is not standalone from the world editor itself.