Rick

Just say Lua version or something because it'll work with that still.

Basically the water prefab seems like it will only work with a Lua project at this time because it must be using the App logic somewhere. This is actually an interesting thing which I haven't thought of. I always advocated to just use App.context/window/camera in entity scripts but I see now why that is wrong. I didn't make this water prefab but the person who did probably thought the same thing when they made it. Since Leadwerks for Lua was the first one out everything was working fine, but now that C++ is out these will be broken. Find in Script:Start() of the prefab what variable it's trying to access of App (App.?). There are other functions you can use that won't rely on App to get things like World::GetCurrent(), Context:GetCurrent(), etc. If it's the camera that it's trying to get from App then you'll have to do that another way.

If you want to make a game like Amnesia then yes you will need to learn programming or team up with a person who knows programming while you provide some other talent (are you an artist maybe?). Do you understand English well enough? I offer training sessions where I teach Lua, but you would have to understand English well enough to understand what I'm saying and possibly get prepared for frustration with me not understanding you fully.

I was just about to ask you the same No clue, but if I had to guess I think maybe something to do with making the controller work correctly with the terrain. I remember him talking about making terrain changes that broke the controller in certain situations. Maybe this tries to fix that but requires more processing if set to true?

In C++ the following returns NULL also. Texture* t = Buffer::GetCurrent()->GetDepthTexture(); The buffer comes back as valid but not any textures just like in Lua.

In C++ SetInput() says the last 2 are maxdecel (defaulted to 0.5) and detailed (defaulted to false).

@shadmar It's not really my way

@shadmar I think GetCurrent() would be best for that. http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/time/timegetcurrent-r494. I know you are just giving an example but perhaps a confusing one given there are better commands for timer/counter like functionality. I think GetSpeed() is more for moving non physics things at a speed that is the same on all PC's. @Vulcan the reason you get higher values on a lower end PC is that it's main loop is getting called fewer times than on a faster PC. So in order for movement of your non physics objects to be the same, the slower PC has to give higher values to make up for this slowness. You take this value and multiply it by your movement variable. A really fast PC will give you values less than 1 in order to slow things down so your non physics objects move the same since multiplying by a value less than 1 will reduce the final number. z = 0 z = z + (10 * App::GetSpeed()) To use Aggrors example: At 30 fps App::GetSpeed() returns 1 so the final value is 10 (z = 0 + (10 * 1)) At 60 fps App::GetSpeed() returns 0.5 so the final value is 5 (z = 0 + (10 * .5)). This needs to happen because your main game loop is getting called 2 times for every 1 time of the 30 fps so when the 60 fps is ran twice z will equal 10 which is the same value as the 30 fps running one cycle, giving you the same z movement speed on both PC's in the same amount of actual time real world time giving the same gameplay feel on both PC's. The main game loop on a PC will run as fast as possible which means how many times it runs in 1 second changes from PC to PC. This is a way to combat that and make it seem like all PC's are running the same. You only really do this for things that you need to be the same speed on all PC's like movement. For some other things like AI for example it may be fine that the main loop runs as fast as possible. Without something like this fast PC's would move non physics objects too fast and slow PC's would move non physics objects too slow and players wouldn't get the same experience.

Confirmed

One of the artists who advertise here, can't remember the name, had a great concept of having a generic human body with many accessories for body parts. The only issue I had with it is that I had to go into UU3D (or the like) and show/hide the parts I wanted to make my model, then export from there, then import to LE, otherwise the model size was huge if I left everything and tried to show/hide them via code (which I guess I'm sure if I could have done anyway) and it took forever to load. However, that concept is a pretty powerful one. If I could have the engine itself handle that and break out the character with my chosen accessories for me with a click of a button and a better interface to go through all the different accessories then it would be so easy to get a nice variety of characters. Community artists could also make additional accessories to use. Basically it's build a bear for 3D models with a nice easy interface to select from. Combine that with being able to attach any predefined animation onto that and you have something pretty special.

Yeah, prefabs would be great for that. You could combine a cone with a spotlight, and attach a script that could maybe resize the cone with the spotlight values inside Script:Start(). Same with a sphere and pointlight. Then just use the prefabs wherever you want to place your lights and you won't have to think about it ever again when you place a bunch in your scene.

You could always brute force it by making volume triggers where the light is shinning. When the character hits the trigger it sets a variable saying they are now be seen.

Could you not set the position to 0,0,0 of all your models and if they have their local offset already, which is what I was wondering if they do or not, then it would look exactly like it did in the 3D modeling app?

There might be situations that cause strange results with multiple cameras all shown at the same time. Like Mex stated above it's probably best to just use pivots as markers for where cameras should be positioned/rotated. You could probably show/hide multiple cameras if you wanted to go that route. I just find it cleaner and reduce any chance for errors by having 1 and just moving it around to markers.

Do the models not show that offset to their engine position widget thingy in the editor? I guess I haven't ran into that situation but I know in LE 2.x they did.

Generally you don't want 2 cameras. Why not just create the camera in code and be done with it?

RakNet was already open source. How is this new license different?

Dbl click a mdl from the Leadwerks editor under the Assets tab and it'll open up the model editor. If you drag a prefab into your scene you can then edit the parts of it however you want and resave it back.

You won't find that line anywhere. He's saying that's the line you have to put in your code somewhere to make this shader work. That's how you control the glow amount when you want to use it.

What was your test? Are you thinking it's just position/rotation and not a full entity object?

He said it was a teaser trailer. It's in his post and title, unless he changed that after you said the above.

Wait a min. When you say editor camera you mean that you created a camera entity in your scene using the editor? I thought you were talking about the viewport camera the editor uses behind the scenes for the 3D viewport (not listed in your scene tab). I'm confused as to what you mean now Charrua.

I think a camera is an entity so just change the Leadwerks::Camera* to Leadwerks::Entity* and give it a try. Or you can try casting it before you assign it. I find this very odd that it has the editor camera though. I wouldn't think it should have that entity in the map file itself. I wonder if this is a bug that it's there.

I still wish we had a way to get model instance specific data to shaders that isn't abusing the color field.

Send me a PM and we can see what works out.