Masterxilo

Just put it in the transparency world. Then it should always look like: Rendering a transparent mesh as usually but in a transparency world rendered over the final image will result in the same without having to code the mesh rendering from scratch. I'd only use ogl commands directly for helper lines or small, very dynamic meshes that don't require lighting and things like that.

Like and:

Particles are not affected by lights. Soft-particles are supported. Look at the cloud or smoke material to see how it's done.

http://leadwerks.com/werkspace/index.php?/topic/1173-unicode/

Now this is caused by the no-unicode-support. As you said: Your first problem was a windows <-> leadwerks engine problem, because windows writes a "." but in some regions a "," as decimal place separator in ini files. That would be no problem if only the windows functions would be used for saving and loading ini files, instead of a custom parser... (though using files from regions different than yours might also cause problems for the windows functions, not sure)

Scrolling ability and a "select all button" for the code widget/box would be useful. EDIT: Also this: http://leadwerks.com/werkspace/index.php?/topic/1196-rename-pages-to-tutorials (renaming Pages/Resources to Tutorials) would make sense.

To get sway working, make sure the vertex color of the parts you want to sway is white.

You could also use SVN.

That would be a good solution.

You can store notes in your profile: go to My Settings > Settings > Manage Notes (The "address line" (the first line on any page) will show "WerkSpace > Your control panel > Help Files > Manage Notes"). It says:

@Marleys Ghost You can always imagine situations where creating a vegetation layer at runtime will be useful for some cool effect for example. Let's say, you have a burned landscape and the player has to go and break a dam to let water flood the valley. After that, the grass will grow again -> paint new terrain layer texture at runtime (which is possible) and create grass instances (which is not possible atm).

I guess the request is just being able to create vegetation layers in code. Control is always good.

Sounds good to me. Except, I'd create the whole crack model right at the beginning and then "move" (by changing the uv texture lookup coordinates) the crack texture over the model, creating the wanted effect.

So true...

True, a way to load any file from a pak would be really neat.

Yeah, obviously, materials STILL can't be created in completely code. Unless you write to a file and load that later. Old posts on this: http://forum.leadwerks.com/viewtopic.php?p=34375#p34375 http://forum.leadwerks.com/viewtopic.php?f=16&t=4168 ...

You might be interested in: http://leadwerks.com/werkspace/index.php?/topic/1250-plane-to-hug-terrain/page__view__findpost__p__11632 You can get the slope by either reading out multiple heights and calcuationg it or by using TerrainNormal(). Unfortunately, there's no command to get the resolution of the terrain...

You should be able to change the road material easily.

Thanks for telling me, I fixed this.

That does the same and looks "uglier" to me. I prefer MyClass.foo(); (I usually name helper classes CMyClass and the default instance MyClass) over MyClass::Instance().foo(); Though that gives the advantage of being able to decide when to create the instance (it'll only be created at the first call)... Still, the code I posted should work the way it is and it doesn't -> compiler bug.

That default instance is there to avoid using the commands statically and to not having to deal with that utility class' creation/initialization and deletion/termination.

Hi there This is some really strange problem I just noticed. Try compiling this class which creates a default instance and has a function with an enum-type argument with default value: MyClass.h #pragma once enum MyEnum {EN_1}; class MyClass { void foo(MyEnum e = EN_1) {} void bar(int e = 345) {} } extern myClassInstance; MyClass.cpp #include "MyClass.h" MyClass myClassInstance; The compiler will complain about "myClassInstance" having no type (and says it can't assume default-int). Obviously, the class declaration somehow get messed up in a way that doesn't allow the declaration of instances right at the end anymore. This appears to be caused by the default argument for foo(). If you remove the default enum argument ("= EN_1"), it'll compile fine. The default int argument works without problems... It also works if I declare the instance normally, not external, but I don't want that. The way around this issue is as simple as declaring the external instance after the class declaration. Like: class MyClass {... }; extern MyClass myClassInstance; But that shouldn't be necessary, should it? What do you think? I guess that's an msvc compiler bug. Where to report these? Oh, and btw. I noticed there's already a SP1 for msvc 2008 express. Do I have to download that update myself somewhere or did M$ update take care of it? I'm not quite sure if it's already installed, the info dialog says "Version 9.0.xxxxxx... SP", but not SP1

Another problem (or THE problem) might be that the terrain switches to LoD versions with lower resolution, while your patch still thinks the terrain has full resolution. That happened with my decals too (go to the end of the video). There might be a way to avoid that though...

I agree with Michael Betke and Pixel Perfect. Leaving users who don't really need the additions of 2.3 but the bug fixes behind wasn't correct.

np