Rick

There used to be a gmf to mdl but Josh took it away. Probably because it's the exact same format and you can just rename your model to .mdl and it'll work

After you scale it, you could position the laser at your gun's barrel position (which will be the center point of your laser right?), and then Move() it forward (z value only in Move()) by 1/2 of it's z scale value. So scale it Position it Move it forward

Yeah, what we have right now is a more traditional approach. What you describe is pretty much how you'd do it in C++ as well. Break out common functionality into it's own class. I feel like we had something very powerful in the multi-script feature combine with flowgraphs for non coders (hell, even for coders). We could have written very generic scripts that are pieced together using the flowgraph by people who don't know how to code (or want to reuse things and get something unique up and running quickly by combining different scripts). I guess one way to test this is to use the pivot method Aggror mentioned above with the FPSPlayer script to see how different it is. Sounds like a fun challenge

I get where you are coming from but "classes straddling different files" isn't a burden, it's organization for maintainable and reusable code. You did this yourself with the AnimationManager class. You did it because that's the way it's supposed to be done. Nobody is going to copy/paste animation code into all scripts that need it. Programmers know this, and so this isn't for the ease of use for programmers, it's for the ease of use for non programmers. I get that, but the non programmers will graduate into seeing why this is important when their codebase becomes unmanageable. The training I've been giving to a few people I advise them to make classes that hold common functionality so it can be added easily into other scripts. This is required because we don't have multi-script functionality so it's the next best thing. If we had mult-script functionality these classes would be scripts. Need a timer on your object? Attach a timer scripts that does the functionality of a timer and hook up it's logic with the flowgraph. This is easier for a non-programmer and programmer than copy & pasting the timer functionality into each script that needs it because if the player object is the thing that needs said timer, they're out of luck because it has the FPSPlayer script already attached. The multi-script feature worked great because of the flowgraph feature. They compliment each other. I get where you are coming from, I just don't agree with it.

But swapping out FPSPlayer scripts that function differently and have the same interface works without any changes to the other scripts. I think this is more about separation of duties than anything else. Having all the code that handles what a player is inside 1 entity script gets complex and hard to follow. The FPSPlayer script that comes with LE is pretty messy and not even close to a final game's needs. This means it's only going to grow in complexity and be harder to follow and maintain. The way around that currently is to make our own classes (like AnimationManager) that help separate out some of the functionality and make reusable objects. The point with something like HealthManager is that I don't have to retype or copy/paste (because copy/paste is often a clue of bad design) health managing code into all the potential scripts that need it. My player needs health, enemy type A needs health, enemy type B needs health, a door needs health if you can break it/kill it. By simply adding the HealthManager script, that functionality is given to these entities and no need to code health data/logic into each script yourself.

Steam crashed.

You can't as the navmesh is built with the size of the controller in mind. In order for the navmesh to know how you can navigate around it needs to know the size of the controller. I think a nice feature could be to define a max controller size (width/height) and have the navmesh build based on that instead of a hardcoded value like it does today. This would give more flexibility.

Yes, instancing happens not only on prefabs but on everything by default. Copy/paste in editor does instancing. You have to load in code with the CreateNew or Unmanaged value to not get instancing. A nice feature would be to ask if you want instancing when you copy/paste in the editor. Just remember the less instancing the more memory it takes up. The only way to get a ton of models on the screen all at the same time with minimal impact is via instancing.

Yes, this is instancing at work. All instances of the same model share the same Material. This is the downside to instancing where the good side is that it saves memory and loading is instant because it just uses the already loaded mesh/material/texture. When you load a model you see that there is a parameter that accepts values defined here: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/asset/ CreateNew will load new mesh and material (this will cause a delay) Unmanaged I think will use the same mesh but load a new material (this is what you want, but it might cause a noticeable delay as well) The other way around this is something I did in 3.0 (with shadmars help) that uses a mega texture idea where this texture has sub textures inside of it in a grid like fashion. You then control, per model instance, what sub-texture should be displayed on it by using the SetColor() function since that information gets to the shader and is instance specific and this was all controlled at the shader level. I'll have to look for this and see if it works without modification in 3.1 but it makes it the fastest possible way but has limitations on texture size and how much sub textures you'd need. What you are experiencing with this is NOT a bug though. It's how LE was designed.

Path returns the string path to the material NOT the material object itself. You have to first load the material from the path and then use the loaded material variable in SetMaterial(). local mat = Material:Load(self.matKo) self.entity:SetMateria:(mat)

entity:SetKeyValue("key", "value) I want to be able to do that in the editor for any entity for any amount of keys. You can query these with entity:GetKeyValue("key") to tell what certain things are. This is a way to set variables inside the entity itself as opposed to doing it via a script. Some things may need to be tagged with keys but don't require a full script.

Yeah, the hard part is what should we be consistent with? Josh does it (via AnimationManager) the way I have above and I was consistent with what he's doing. Shadmar's method works as well but it's not consistent with how Josh does it with the scripts that comes with LE. So I had to pick

Sorry, step 2 means copy the first code block below. That's the class template.

In LE 2 I believe there was a copy command that you could use on LE primitives to make instances of them. There is this but it's crossed out so not sure if it'll work or if there is another way to do it. http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entityinstance-r173 You're a modeler why use LE primitives? Create your own model, add 1 to your scene and hide it under the ground, then load that model in your game when you need the bullet. Because 1 already exists in your game the engine is smart enough to know that even though you called Load() again, it'll just create an instance o the existing one in your scene. I do call :Release() on the bombs and it's fixed now. Before this last update it would crash the engine but Josh took care of that. If you use :Release() on your bullets when they collide or get to their destination, then you control the max number of bullets possible on the screen by your fire rate. This won't always be an exact number as sometimes bullets might travel farther before being released than other times, but it'll always be within 1-4 of a constant value probably. Just think, if you allow your gun to fire 3 bullets a second, and each bullet lasts for about 2 seconds, you can see that this creates a max bullet range without having to worry about limiting with some max number somewhere.

I understand that, but there is no freezing happening in my game when I load the bombs at run-time, so you might have been doing something wrong if you were getting freezes when you were doing it. I just want to make sure you understand how instancing works. Was that bullet a model that you brought into the editor or were you using one of LE's primitive model creation functions? Considering that it shares the exact same instance and everything else about the already loaded model, that's like saying no point in calling a function that makes a variable, which happens hundreds of times already in your game. Creating another instance of an already loaded model doesn't take any time at all. It's literally as instant as you can get, so I fear you've made this harder on yourself than it needed to be. Also, this method of pooling doesn't scale very well to games that require a ton of something on the screen at the same time. Any RTS for example wouldn't load hundreds of models at startup just in case, because that's a waste of resources. So the trade off is CPU vs memory and in both cases they are very minimal from what I can see, so why make your life harder by having to manage a pool of anything? I just think it's meaningless code and the only bug free code is no code. Meaning the less code you can write to do your task the better the chances of not having bugs. There is no advantage with that. You could have just as easily done the same thing and have the BulletPool:Fire() create the bullet at run-time and to the player object it still doesn't care about the bullet.

Were you actually getting lag when making a prefab at run-time if you had 1 instance of that model always loaded? I don't get any lag when I load the bombs at run-time which are all prefabs.

I've been doing some Lua training with TeamViewer, but I'm not sure if the language issue will be a big obstacle or not between you and myself. If you're having to use google translator I fear it will be an issue.

Once you get this working let me know if you want to know how to do split animations (playing 1 animation on upper 1/2 of body and another on the lower 1/2). I can show you how if you can't figure it out. This comes in handy since it can save you from making more animations in your model. Why make a run and shoot animation when you already have a run animation and you already have a stand and shoot animation (as an example), when you can play the shoot animation on the upper 1/2 and the run animation on the lower 1/2 via code!

Sometimes I find I just need to assign entity keys to entities in the editor so I can flag them as something. I know right now I have to attach a script and do it that way, but it would be nice to be able to do this from the editor. Maybe have a Keys tab when you select the entity that allows us to add a dynamic amount of key/value pairs to it. For csg this should flag it to not get collapsed.

Did you update your projects? Go to File->Project Manger and if you see ! by your projects it means they need to be updated. 1 left click the project, then click the update button.

Are you using the AnimationManager to do this or are you just thinking about the problem first? Leadwerks uses a blend value when playing animations. The idea behind this is that the blend value is 0 - 1. 0 meaning that animation's weighting has no effect on the model and 1 being it has full effect. With AnimationManager when you change animations you can provide this blend value. What ends up happening is while the transitioning to the new animation both animations are played on top of each other, but over a small period of time the old animation has it's blend value reduced from 1 to 0 (once it reaches 0 it's removed from the active animation playing list), while at the same time the new animation has it's blend value increased from 0 to 1. This creates a smooth transition between different animations.

You can just use SetPosition() at start. SetPosition() breaks physics for that frame but since it's at start it doesn't matter. Are you sure pos is a vec3 when it returns from your calculation? Did you put a breakpoint in and see what it contains?

Try making it a Vec3() object you pass instead of x, y, z self.bullet:PhysicsSetPosition(Vec3(pos.x, pos.y, pos.z), 1) I think I remember someone saying the doc was wrong or something.

Added to wiki also: http://leadwerks.wikidot.com/wiki:snippets-lua

I'm adding this because as people newer start getting more into programming, they start to see that putting everything inside entity scripts can get complicated and hard to follow. You can end up having a ton of unrelated variables and even run into variable naming issues. Below is a template that can be used to create "classes" in lua. Classes are a nice way to group an "object" or common functionality. Examples of what makes a good class would be: UI controls like a button, or dropdown A timer Inventory Create a new lua file and name it the name of your class. Copy and paste this code into it Do a find/replace all on ClassName and change it to the name you want your class to be (generally the name of your lua file) Add whatever variables you want to obj in the Create() function Add whatever functions. Generally you'll have an Update() that you'll call yourself each frame from an entity script and PostRender() if you need 2D drawing In the entity script (or App.lua) import this script and use it -- if this lua file gets included in multiple lua scripts this revents it from being recreated over and over again if ClassName ~= nil then return end -- define your class name ClassName = {} -- this is where you init things about the class function ClassName:Create() -- create a table that we'll return from this class so the user can work with it local obj = {} -- example of how to define class/table variables obj.test = 5 -- this assigns all the functions defined below to this table object above local k,v for k,v in pairs(ClassName) do obj[k] = v end -- return the table so the player can call the functions and access variables return obj end -- example of how to define a "class"/table function function ClassName:Update() end -- another example of a table/class function function ClassName:PostRender(context) end Usage example from an entity script: -- be sure you have the right path to where you saved it import "Scripts/MyClassScriptNameHere.lua" function Script:Start() -- create an instance of this class self.test = MyClassNameHere:Create() -- get a variable that was defined in this class local what = self.test.classVariableName end function Script:UpdateWorld() -- call a function that was defined in this class self.test:Update() end