Rick

Does anyone know if LE3 still uses model instancing? Also, if it does, which I think is good, is there yet a way to switch materials on a given instance and not have it switch all other instances? For mobile games I think this will be a big boost for us. Is there maybe some shader for LE3 that allows us to make a big texture and use certain parts of it per model?

As far as I know LE officially supports VS 2010. You'd be better off having VS 2010 on your machine for LE projects to avoid any issues.

I use it for volume triggers...

The invisible material doesn't seem to work on mobile (for my Samsung Galaxy 1 7 " anyway). I made volume triggers (CSG shapes), that have the invisible material on it, but when playing on my mobile device I see the CSG shape as gray color.

Creating objects isn't slow when they are instanced, which I believe LE does. So as long as creating 1 object of each prefab creating other objects of the same prefab should be fast because of instancing. Creating and deleting objects at run-time happens all the time in games.

Correct. Think of it being used in a wave manager for a tower defense game. Let's say every 2 seconds I want to create a new Goblin to rush the tower! You would use this that creates that goblin prefab isntance and all scripts attached. Prefabs are great for making manually in the editor, but it's more powerful if I can make instances of these prefabs via code. [EDIT] To give an example, in the tweaks I was doing to DA, when you got into the room with the switch, after you hit the switch I created a prefab instance of a goblin as a surprise attack. The goblin, however just sat there not even doing the idle animation. It was there frozen.

Exciting!

I believe all that is done for you when you go through LE's new project wizard. The VS solution is created for you with all that already defined in it.

I think this depends on what the main gameplay of your game is. Is having very real and accurate structures a main driving factor of the gameplay or not? I personally think looking at scematics is a little over the top for, say, a normal FPS game. You are an indi dev, which means it's probably just going to be you, maybe 1-2 others, so focus on the things that really matter to your game.

You have to pick the last option which is delete node I believe to delete the flowgraph node but not the entity.

I'm really getting tired of the, flowgraphs are for non programmers, idea (this isn't just you saying this). Flowgraphs speed up development and make it easier for you to get/test interactions in your level and reuse these components for multiple levels and games. Programmer or not, the "negatives" I hear are often from people who haven't even used them, which is just insane. I'm a programmer and I'm making these nodes for anyone who wants to get complex interactions that would otherwise just be silly to sit and code all together. You'd end up copying and pasting all sorts of different code together to get the same thing you can do with a flowgraph much faster. If at any point you find yourself copying and pasting code all over the place, you're doing it wrong Josh's switch script is a perfect (but small) example of why generic flowgraph components are ideal. He hardcoded sound files into that script, making that switch require manual changing to be reusable. That's a waste or time and resources to do for every game you have. Multiply that by every script/functionality you need for an entire game and all the different level interactions you will need and you've just wasted a bunch of dev time. A switch in itself shouldn't have sound files hardcoded in it at all. A switch should just be a switch. It should turn something on or toggle something. That doesn't always require a sound, but if it does, then just insert a sound node and you're good to go in seconds. Insert a toolbox of flowgraph components and you can get all these interactions up and running and combine things in an easy way and get complex behavior in seconds. You can easily mix and match these components to get really cool effects and functionality in much faster than coding each interaction specifically. The only thing I want to know is how far can we push it with flowgraphs. I think we can push it pretty far myself, but we'll see in time. I'm pretty certain I can create a fairly basic FPS game 100% with flowgraphs. I plan on making GUI elements to be exposed via the flowgraph. Some AI commands via flowgraphs. You name it. I'm not seeing anything at this point yet that suggests this can't be done.

Would be cool if you fired an output so it could be used in flowgraph

We could probably make this ourselves, however in LE it seems the names can be duplicated, so you'd get a table back with all the names that match and would have to sort through them to find the one you want, IF, you didn't stick to a strict naming convention.

Why do you always make double posts?

You basically need the same free look that the 3D part in the editor gives right? Why do you need that in game instead of just the editor? Just wondering.

I'm thinking that won't work. I don't have time right now but I'd try self.entity.bonename.bonename like that instead, but yes if you have dots in your bone names you'd have to change that.

I found that if I'm editing a property of an entity, say it has a textbox, and I press the delete key, it deletes my entity instead of just the textbox text!

YouGroove ,you don't know that yet. I'm sure there is a way to get the bones.

bones are just entities like any other. In LE2 they were children of the main entity if I recall correctly and you would call GetChild(entity, number). Once you had the bone you could do anything you could to a normal entity. Rotate it, move it, etc. That's why I'm thinking you can just access the bones directly. You notice that when you put a model into your scene it gives you a tree view of the bone hierarchy.

I would use picking myself to keep it simple.

I think you can access the bones in your model hierarchy, perhaps directly by name. Try something like: self.entity.bone1.bone2.etc and it would be treated like any other entity where you can :GetPosition(), etc. Note bone1, bone2 is whatever you named your bones in your model hierarchy.

This would only get entities in a range around the entity. http://www.leadwerks...eference/world/ Shows a list called entities. Try looping through: App.world.entities maybe? Not sure if this holds true for Lua or not. http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/world/worldforeachvisibleentitydo-r506 This would loop through all entities but might not be what you want because it calls another function for each one which but would be out of the scope of where you are calling. You could pass self as the extra parameter though to get access from within this callback.

I think it's App.context. If you look at PostRender on the player.lua file I believe it uses it there.

I'm not sure how this would work behind the scenes, but would be nice to get dynamic outputs, and public table parameters. They sort of go together as if I was to make a switch node I would define I want 4 entries in the properties of the table (every public table would need to ask how many elements), then after doing that the properties would dynamically change to show entries for each element. Once that's done, then inside the script I would be able to expose those as outputs. This would work for random nodes I made, switch statements, and possibly some animation sequence stuff.

You'll need to modify the AnimationManager.lua file. If you look at the Draw() method in there you'll see a frame variable that will tell you what you want. Just have to think of an elegant way to inform your character. Look at SetAnimationSequence at line starting 33. Notice how when you call this to play an animation and the animation doesn't exist, it creates an object and adds it to the self.animations table. What you can do here is copy how they are doing end hook, and add a specialFrame & specialFrameHook parameter. Then you'll have to handle it yourself in Draw(). This is something I require as well, so I'll try to make a modified AnimationManager sometime tonight with this functionality. I'm not a huge fan of the way he's doing it. He adds animations to the list the first time you try to call them. I prefer to setup the animations first before calling them so I'll be adding some kind of DefineAnimationSequence() function that you should call in the actors Script:Start().