ZioRed

I don't know, it's you the admin lol, I cannot edit my Rank in Edit Profile ?

Once you know what entity is the hand bone, I would use SetParent to make the weapon as child (and set offset local position) to set its position only once instead of repositioning it in each UpdateWorld call. If you're using LUA then I would suggest to have a public string property to store the name of the hand bone (you could even think to store names as hierarchy tree, for example "Spine/Chest/Right Arm/Hand" and then splitting by "/" to get it if your model has two entities "Hand" instead of "Hand R/Hand L") and one vector3 property to store the offset local position for the weapon (since these values could easily be different for each model).

@Einlander: if it's the Steam system that prevents it then I agree (though you cannot compare a game DLC with an asset for engine, because their use is completely different), but the following sentence doesn't seem to be the case: Anyway it's not an issue for me, I just won't use it and I can still live (anyway I can still use LE with models bought elsewhere, so no problem at all). I only wanted to be sure how it would work before discover myself wasting money, I don't want to take control of how LE (and tools) works at all.

Thanks for clarifying it, I see that I unluckily understood well, so I can only be glad to stay out of Steam and Workshop. Honestly I think you're considering piracy something that really isn't when you're in a team, you're just protecting authors at the expense of customers (there are lawyers and lawsuits for something like that). I will likely purchase nothing from Workshop with such restrictions. PS: the asset's price is completely countless, even if it's at 10$ I should pay it 100$ if my team has 10 members... would you really pay 100$ for a crate? I doubt. And things go even worst when you want to buy an asset that costs 100$, it's just unfeasible. This kind of rule may be good only for one-member teams

I don't fully understand the point, does it mean that if my level designer subscribe (that is purchase, when it'll be possible to sell and not only share for free) an item from Workshop and use it in our scene then every team member must purchase it? I hope to have misunderstood on this, cause it would mean the cost of each asset is multiplied by team members count (that is just unfeasible and also illogic in my opinion).

I'm not a Lua developer (I use C++ only, in LE) but I see you have the property "script" for each entity and in GoblinAI I see that self.target is assigned from the target entity.script, so I think you should be able to access the player health in your GoblinAI using self.target.health @MilitaryG: I see you used/use also the "unnameable", so if you like component system and are using C++ then I could have something that you may find interesting, that is my craft-made complete component system built with the "unnameable" usage pattern (including AddComponent<>, GetComponent<>, GetComponents<>, Awake/Update/LateUpdate/OnGUI/Destroy).

What has this to do with LOS? LOS means "is there anything between me and my target" (to check for example if there's a wall between us), while yours is to check if it's in front of me that is completely different question. Agree, I think this should be the way to go, though I'm not sure it will skip also its children (in which case you'd need to call it on every child that you know having a collider). Do you know if it skips children too?

lol I think Sony will most likely fail (in terms of sold units), as they already did with their current head-mounted display: http://www.sony.co.uk/electronics/head-mounted-display/t/head-mounted-display At least unless they completely change their point of view on the price, cause I doubt there's really a consumer user (but also an indie/hobby developer) who is willing to pay 1000£ or more for something like this, when Oculus costs less than half of it and is more supported by indie community. By the way, I WANT the Oculus DK2, will see if I can get it in the next few months, I have already DK1 but DK2 with 1080p and above all positional tracking is very much better (besides the fact I read that sickness is now no more in DK2, or at least very few compared to DK1).

Josh said that crouching was still not supported but would be implemented in SetInput sooner, here is, but it was about 1 month ago so I don't know if it has already been implemented/supported in this early version of 3.1

Here is a code to rotate towards an entity that you can port to Lua too: Vec3 cur = myEntity->GetRotation(true); myEntity->Point(targetEntity); myEntity->Turn(0, 180, 0); myEntity->SetRotation(Vec3(cur.x, myEntity->GetRotation(true).y, cur.z)); btw I tried the code posted above that uses ATan2 in C++ but it seems my header hasn't the operator "-" for Vec2, it's only defined in Vec3.

This would be the only reason for me to upgrade to 3.1, since I don't care neither OGL4 nor Linux support (decals implementation is another big stuff required, using a plane is simply awful)

Oh finally, I had speed lag issues with Copy for my bullets, now with Instance it works smoothly! Thanks

In your first post you said that you want your "main character to slowly push back the enemy character", so you need to apply the force (or Move if you're not using forces) to your enemy character.

@NA: Trust me, I understand your thoughts and I know the issues in relying on physics, but I have many ideas of games where physics plays a very important role in the gameplay and of course I don't like to reinvent the wheel and definitely don't like to use raycast on each update to only understand if a rigidbody collides with something, this is the role of a physics engine else it would be completely unuseful. For example my latest game Domino Rally (http://itunes.apple.com/us/app/domino-run/id663200322) is almost completely relying on physics and it works pretty well without any "hack", it just works with forces and physics, so this is an example where you can perfectly rely on physics if it works as expected. I'm almost disappointed that I cannot rely on physics, I'm not the best math or physician in the world, neither I want to achieve a degree in Math or Physics Engineering to make a game (also consider that as already told I'm having very high FPS and unless the physics engine is completely broken then I should have collisions detected as expected because I'm not using very high velocity or very thin objects, I mean the bullet is thin BUT the avatar model is deep enough that it's really impossible that the engine won't intercept the collisions). I'm almost sure that my setup is wrong somewhere, because LE engine should hopefully implement physics correctly. Besides the fact that I'm not interested in porting a game to other engines, in which case I'm perfectly aware that it could lead to some changes to your code (well I implemented a component system and game engine, so if I had to change engine it would require changes to only 1 function, this is "API agnostic" too even if it relies on physics instead of math distance/collision detection). So to not being forced to hold on, I opted to switch to continuous raycast along the movement of bullet, this is working of course, even if it's not what I was trying to test. So for now I'm following this path and hopefully will release sooner a game demo, just some weeks to build few levels.

Note the link path, it has "le2" so I suppose this documentation is for LE 2.x not for 3.x (and yes LE2 was C, or better it was BlitzMax compiled DLL if I remember well, while the C++ version was just a wrapper around the C functions). We haven't the old T* types, like TMesh in the example posted on that page. I don't find anything about decals and surfaces for Leadwerks 3.