Rick

I don't think this would be the way to go. A helmet could fit multiple character models that are at different heights. I'm thinking RPG's where you could have a dwarf, night elf, human, orc etc. They would most likely be at all different heights and you would want to use the same helmet model for each to wear (less resources for us to use, reusable for you). I think having bone(s) on the accessory models would be the way to go. They would just be used for information instead of animation but that seems valid and then you wouldn't have to worry about lining them up correctly. Also if I scale your character model it might cause confusion, where if I have to do it via bones it's all good. Given that an orc head would probably be bigger than a human head we can scale in code to fit the character it's on. Think about who is going to buy your models. It'll be non-artists most which will probably be programmers.

Moving something with Move() or SetMatrix() is still moving it which is adjusting it's location. I don't want to get into a technicality fight with you but you get the idea of what I was talking about. If the bones on the character models are meant to match up with bones on the accessory models so that you can set the bone of the accessory to the correct done of the character and everything looks perfect, that's what I was talking about. I've never seen anyone make models this way but it seems it would be the ideal situation for both the buyer and seller. If he does this we here at LE can make a program that visually allows assembling the accessories in that it makes a config file and then support it with a lua script to read the config file to automatically assemble the final model. This would help those who don't want to dynamically create a character in code but just want a static character look.

I'm very interested in buying these models so that's why I'm asking questions and giving suggestions. I'm still confused given your statement above. I mean I'd still have to attach them via code (even if lua, that's still code), or I mean I would want the ability to.

Just saying if you plan on taking this path to have certain bones to handle the parenting of the accessory models. Like a bone at the head to be matched up with a bone in a hat/helmet accessory model. So that in code I find the head bone in your character model then find the matching bone in the hat model, and I place the hat model bone at the head bone and make the head bone it's parent. Then the hat will move correctly with the head! Repeat for things like weapons for the hands, boots for the feet, shoulder pads for the shoulders, gloves for the hands belts for the waist, etc. Doing this you could sell smaller priced "accessory packs" that dress up your character model. German soldier accessory pack, or swat team accessory pack that comes with textures and accessory models for us to "dress up" our base character model. Again, having a program that would allow us to do this visually and save the "dressed up" final model would be handy too for those who want a swat guy but don't want to assemble via code.

You mean blending? They don't have to be next to each other in the file for that. If you mean split animation then they won't need to be next to each other for that either. I'm still confused as to why the order matters I guess.

?? Why is this? I wouldn't think it matters.

I think making a basic human character (male and female) and then making different clothes textures and other models to attach (hats, boots, gloves, shoulder pads etc) would be the best bet for someone. setup the bones correctly so these other models can be attached via code, then someone here could create an editor that allows us to attach all these and save the result as 1 model if we wanted to go that route or we do it ourselves in code in the game. This would probably be the most efficient use of your time and your time would be spent on the accessories. You could get lots of different looks with different accessories from space marine, to medieval warrior, to cowboy and would allow you to turn out these accessories much faster than an entirely new model each time.

I think another option would be to animate this one only. It looks like you have some bones and if not you can make bones around where you want the damage to be. Then in code get the bones as entities and then you can animate each bone by itself to deform that part of the model. Then if you needed it you could pretty easily just deform the parts that were hit by having bodies around the areas of your major bones. Giving some similar naming conventions of your bodies and bones would make it pretty simple to code "when this body is collided with, then get the bone with the similar name and animate it to show the dmg". Would probably be easier and more dynamic than making new models for damaged car.

Making video games is an interesting thing because the reality is there are many common tasks that the majority of them have. Who plays a video game and thinks that the pathfinding in this game is amazing and really makes this game stand out from others? These tasks just have to not suck instead of being revolutionary. People aren't redesigning entire car engines for each new car because there are parts that are tried and true. The same should be for game engines. It shouldn't be just about making drawing and physics easier, but to provide the tried and true parts of a game. I wouldn't even consider pathfinding a gameplay feature honestly. It's as essential as physics in modern 3D games and generally physics isn't considered gameplay. Bullet time, combat systems, weapons and things of that nature is what I would classify as gameplay and those are the things that make games stand out from each other. Those are the things that I don't think you want to get into the business of making and those are the things that dreaming game designers think of first when they think of a new game. When you dream of your amazing game that you want to make you aren't dreaming about pathfinding or networking code, you are dreaming about the unique gameplay features like the cool kinds of guns you want or the different abilities you want your character to have access too 30 years ago maybe pathfinding would be considered a gameplay feature, but I think it's graduated to essential core engine feature.

Thx

What Lua Version does LE2 use? 5.1 I'm hoping.

Thanks Laurens. The last week or so has been hard to find time to work on it but I pick away a little at a time. Will probably have another video update in 2 weeks or so. I'm still kind of looking for a good Lua networking library so I can get multiplayer in this thing as that's where the real value is with a game like this. Having ladder tournaments and stuff like that to create a sense of community and competition I think is key to this games success.

I vote a mix of 1 and 2. Hire someone to do it, but make sure they knowledge transfer to you so you can maintain it. I view pathfinding as a critical piece in any game engine. I'm using a grid based Lua library, you and Marley have libraries, Pixel wrote his own editor even, but think of the time you put into those. Would be so much easier (and cheaper if your time is worth money) if Josh has it in the new LE. If people did all that for learning purposes then that's cool, but I'd prefer to just use a library built into the engine myself.

Just curious, but why do you want to do that? You should be able to get the same type thing using the callback.

I can't see the video, I assume the white space is a youtube video, here at work, but does this works across entities also? If I have Actor B attached to entity1 and Actor C attached to entity2, I can link them in this editor or is it just actors on the same entity? If it's cross entity linking, is there a way that I can get information of the actor which called the output method from within the output method? --ActorA.lua function MyOutputFunction() --output -- I want to access some property of the actor that called me! -- Let's say a timer Actor called me from a link I made via the flowgraph, and here I keep track of how many times I've been called and if it's > x I want to disable that timer actor script. end I think it would be cool if the output functions would be defined to take a parameter which would be the actor that called it. If that's not the case already.

I think CameraPick should give you what you want. You use it to select your unit, then you use it to get a point (x,y,z) selected on terrain or model and that is where you move your unit to.

I'm confused as to what you are asking? Maybe look at CameraPick?

I think just shooting paint off a wall, concreted off of pillars, and tiles off of floor is pretty cool in itself and could be done all via code, pending the breakout and texturing in real-time is fast enough.

What's up with the camcorder video?

[in my justin timberlake voice] Drop "the". Just Leadwerks. Hey it worked for Facebook.

If Josh does the coding framework for it and all I have to do is set some values on the csg model, then it could be done in about 5 seconds by all us users. The settings would basically be tolerances of forces. When x forces is applied to a given point on the CSG model look at the tolerance of CSG model (what kind of material is it, how deep can the blast go, etc) then based on those values the code to break the CSG model runs. In the game if you shoot the CSG model you apply a force at the point of contact the relates to the type of blast you want. Smaller force for a bullet and a big force for dynamite for example. I think outside apps make things more realistic, but not easier than having it all integrated into the engine directly via code. Converting all these models to gmf and textures to DDS and making these mat files is a big pain and time consuming enough. Not when I'm at work killing time before my football game

Honestly I'd rather the engine creator waste his time on trying that stuff out than mine If he thinks it can be done reasonably well and fast I say give it a shot!

I don't know if I'd agree with that. From a programmers perspective I'd prefer to have this all done for me in code with maybe a setting on the CSG model. If at all possible I'd prefer not to have external dependencies to accomplish this. If possible.

I like the term Game Studio. Gives you the feeling there are many tools to help you in making your game.

Yet beginners who come across the work UDK have no idea what it even means so I think the messed up there. I think adding something to Leadwerks is required and if Josh thinks Engine is scary for beginners, then 3D seems the next logical choice I guess. I don't think I'd ever refer to it as anything but LE3 though.