Rick

Session 2 & 3 are up in the first post

You can't remove the default character controller shape. You would simply not use it. However this means you have to control the physics of a shape that you make to act like the character controller, which isn't an easy task to get right and will most likely end in frustration . If your models are either clipping through you can either scale things down so they don't or just deal with it. Some will tell you that games like L4D and alike have models clipping and it's not that big of a deal. It's your call on the amount of effort you want vs the benefit you are getting from it. ie. It's not as simple as you're hoping.

Any model that has an fbx format will work.

The character controller you have on the pivot gives you a cylinder shape for your character. If you have Nother shape and put them in the same location which would put them inside each other they might act badly. Multiple ppl have found the default character controller phyics limiting but otherwise you have to build your own which isn't easy to do well.

You can do > or < checks and snap to a desired angle if the checks are valid.

Just to clarify you are running in Release mode and not Debug mode? Sometimes that trips people up.

Curious as to why you are creating a shape for the player model?

Thanks guys. My wife has a new work schedule which means she has to leave the house at 5:30 AM with the kids so since I'm up early to help I figured I'll make a 30 min(ish) video each day/every other day, after they leave. Since I'm up early I should be productive right

Session 1 Project setup Model importing Animation sequence breakout Texture importing Material Creation http://youtu.be/OHPP67rJ1Ok Session 2 Top/Down Camera following Player movement by clicking http://youtu.be/r6VFT6oudus Session 3 Player animation Some level design Wall hiding/showing http://youtu.be/jpOu4basufE Session 4 Basic enemy setup Basic attacking in place http://youtu.be/CC2OsQpS-S4 Session 5 Restructure of Player:UpdateWorld() Move then attack when clicking an enemy Face enemy before attacking http://youtu.be/mmGgL9nrTgo Session 6 Show progression done off camera with attacking enemies, gates with triggers Start of coroutines (I screw up with coroutines but it's worth a watch if not for laughing at me ) http://youtu.be/iqIcPf4RjKw Session 7 Coroutines http://youtu.be/Ya7CwPBbSJ0 Session 8 Progress so far http://youtu.be/rt7AWxfjTEc

Woot! I'm excited for this!

This was easier to do in Lua when Leadwerks allowed multiple Lua scripts per entity since you'd be able to have one component per Lua script and then attach the components you wanted to an entity in the editor. It's still doable but now requires we make our own glue code and the editor isn't going to help out any with this style.

I have seen this also in my training sessions I do with this one person where we are making a chess game. It happens weekly. CrazyM, Josh is going to ask for a map file so once it happens attach the map file to this post for him to check out.

So are you saying at the point of the pixel shader, there is no lighting in the scene yet? The lighting of the scene is done after the shaders run?

That's be great for "burning" dead characters on the ground. Add a little particle effect of red things floating upward. Care to share it?

local context = Context:GetCurrent() refractionbuffer = Buffer:Create(context:GetWidth(),context:GetHeight(),1,1); So the context gets created in the App "class" in a Lua application and the App class is global to the Lua project so you can just do App.context to get it. However in a C++ project there is no App class so instead you have to use Context:GetCurrent() to get the current context in Lua, which in most all applications there is only ever one context anyway.

Guessing you have a C++ project with this? The App variable only exists in a Lua application so this might have only been meant for a Lua app at the time of creation (standard edition probably wasn't even out at this time). Can probably change it with Context:GetCurrent().

Collision.LineOfSight worked perfectly for this. Thanks.

I'm confused. This is mouse picking not character collision with hitboxes or anything. It's like an RTS where you click to move the character. [edit] Oh I get it. This is like giving the ray a collision type and then the regular collisions will happen between the ray collision type and whatever that would collide with normally.

I have some csg as floors. Their collision type is set to Scene. I have some csg acting as triggers as well. I have a top down diablo style camera where I left click to move the character to a point. The issue is sometimes the camera angle has me clicking on a trigger and not the floor resulting in the player not moving to the floor position (but the trigger is invisible so the player would wonder what is going on). To remedy this I added Collision.Scene to the camera:Pick() as the collisiontype parameter, thinking that now it would only pick the csg floor (since it's set to Scene for a collision type) and skip the triggers. However when doing this I can't move at all now. How is my thinking wrong with this? if self.camera:Pick(mpos.x, mpos.y, pickinfo, .1, true, Collision.Scene) then

Once you download VS 2013 express desktop edition, in the LE editor under the Assets tab you should see a Projects/Windows (assuming you are using Windows). Right click that folder and select Open Folder. Inside you'll see a few files. Dbl click the .sln (solution) file. This is the Visual Studio file that holds the project. Once it's open in the top middle you will see a dropdown that says Debug or Release. You will need to build both. Select menu option Build->Build Solution. Then switch to the Release ( or debug, I can't remember which is shown first) and do the same thing. The build will show a bunch of stuff happening at the bottom. If everything goes well you can now run the exe in Leadwerks editor. You can also run it from Visual Studio. You will see a play button in the toolbar at the top. Any changes you make in C++ will require you to rebuild. If you make changes in the editor only it won't require a rebuild in visual studio.

With the C++ version you have to have Visual studio 2013 express (Desktop version) and compile the exe yourself before trying to run the game from the editor.

That's interesting in the example above. So all that's really stored in your workshop item is a link to his workshop item, and then the settings you changed? What if I added a particle effect of sparks as a child to his and make it a prefab. Does that work for me to make that a workshop item then and my workshop item would have all the information needed to reproduce the prefab from his item?

This isn't use and reuse, it's use and modify and redistribute. So what you just said is a little confusing to people. I assume it means we can modify certain LE settings but not the source files. We can use it in another prefab and distribute that new prefab, but not modify the source files right?

If LE's Button1 is wrapped in the Leadwerks namespace then it shouldn't matter. That's the whole point of a namespace right? If it's not then I'd say that's a bug.

Thanks White, will give this a try when I get home. It looks pretty much what I was expecting. The slower it goes the more noticeable it is as to what is happening, but I bet if it's done fast enough it'll look smoother. In my case with walls I want the shadow to stick around so for me it's not an issue. It's a very neat trick and will work for what I need. Thanks! So pixels can't be made transparent in a shader? It's either there with a given color or it's discarded? I would think if you can discard it and have whatever is behind it still be there, that you could make the pixel semi-transparent too.