Road Kill Kenny

If the bodies are parented to the bones then the bones have control. Therefore, the character can be animated. If the bones are parented to the bodies then the bodies have control and it will be ragdoll. I would also play around with disabling gravity mode on the bodies when not in ragdoll and also changing their entity type so they don't collide with anything. However, because they are parented they should collide anyway.

position pre-made physics bodies in the same position and orientation as the animation bones. Then connect them with joints and set their constraints the. Apply physics to those bodies and whalla you have Ragdoll. That's the basic concept but it is very much a fiddly piece of work and a bit of a glossy thing that isn't necessary until you have gameplay.

Nice one! I've been staying away from cosmetic things so far in the development in my game and concentrating on mechanics and game play but the time is coming soon when I will be doing stuff like this so it's great to know.

If you mean scrolling and scaling textures on a mesh then there is no simple command for it. You either need to make a shader to do it (though I don't know how myself).. Or you need to change the texture every frame to make an animated textures. It is possible to change the UV's of an object to scroll and scale a texture on a mesh. However, this is incredibly slow... I think it's possibly the slowest thing that a graphics card can do so I wouldn't recommend it.

What kind of online game were you thinking of making? Also is this your first game or have you made some before? If it is your first I would recommend staying away from online until you have more experience. Also "It's very simple actually." is not actually true. It is actually relatively complex. Not necessarily difficult to send data over a network but making that data work nicely for you is another story. For online games take a single player game and multiply the difficulty by 10 and that will give you an idea..... if by online you mean mmo then multiply that difficulty by 100 instead.

I have finished the standard patrolling behavior for the mobile NPCs. I can now set up a mobile NPC in the editor and give it a pre-determined patrol pattern in the editor that utilizes the path finding grid that I made. That is all working well now. Now it is on to the attacking behavior. I want the units to pause for about 0.7secs or so and simply look at the target before sounding the alarm and then pursuing the target. It will change to a retreat state if it looses too much hp and a seek state if it loses sight of the target. To facilitate these movements I added two new functionalities to the Controller Module including: int TrackEntity(LE::TEntity tgt) int ChaseEntity(LE::TEntity tgt, float proximity) These functions will automatically track and chase the target entity from the character controller module without the behavior states having to do any more than just call these functions once to initiate the appropriate movements.

NPCs, whether they be ally or enemy, are a very important component for many games and a large portion of a game's game play is highly dependant on the things that NPCs do, they way they behave and, if they are enemies, the way that they try to kill you. Therefore, it is vital that your NPCs, their associated behaviours and AI are done well so as to compliment game play rather than detract from it. If these factors are not 'fit for purpose' then the player will see right through the NPCs and the game will become just another game rather than a world the player can immerse themselves into. This doesn't mean the NPCs have to be human perfect, as I said before, it simply has to be 'fit for purpose'. With this in mind I set out to firstly create my NPC classes. I had a few attempts before I got it right. Firstly I decided to make a fixed enemy NPC like a turret because I thought it would be easier than a mobile enemy for the first one. I had an idea that there would be two main types of enemies including both fixed and mobile enemies and I made base classes for each of them. The FixedEnemy class was then derived into a unique fixed enemy classes depending on the type of enemy. The FixedEnemy class also inherited from my standard Finite State Machine (FSM) class so that it could handle states of behaviour easily. Following this I created a whole bunch of behaviours that I thought would be necessary in different situations. Different behaviours could easily be slotted in to make many enemies that could behave differently if necessary. The system worked well for the fixed enemy and you can see my original blog on this part of the process here: http://www.leadwerks...a-new-frontier/ After this was completed I decided to leave NPCs an AI while I worked on my new level system and level editor. I have now completed most of the editor and am re-visiting the NPCs and began creating that MobileEnemy class that I had planned. However, when I finished writing the class declaration I found that it was almost exactly the same as the FixedEnemy class. By a force of habit I had made the FixedEnemy class so flexible to the point where there was no need for two separate base classes. This was a good thing but it got me thinking and after a good 10 minutes of pondering I found that my previous thinking was rather flawed. Why were my base classes just for 'enemies' and why did I think that splitting them into fixed and mobile variants was a good idea. Evidently I had already made the class flexible enough to handle any NPC. As a result of this pondering I went on to make a pure NPC base class that inherited from the FSM class and then was derived into any unique NPC that I wanted whether enemy, ally or neutral. It was mostly just the FixedEnemy class with a different name but there were a few minor changes. This was much cleaner and I liked it. However, there was a bit of a problem. The underlying difference between a mobile NPC and a fixed NPC is that mobile NPCs require a controller for movement. I didn't want to clog up fixed NPCs with controller code that they wouldn't use and I didn't want to create new controller code for every single unique derived NPC that needed one. To solve this I thought back to how my character animator class works where each character has an animator object within it and the animator object handles all animations automatically. In the same modular fashion I created a controller mod that could be attached to any AI driven NPC in the game that requires a character controller. This class would live within the unique derived NPC classes, if applicable, and would be able to handle all the annoying movement code necessary for a lot of things. It is almost like a wrapper for the LE character controller which makes it more automated. The major functionality that I gave the module includes: SetTurnToAngle(float angle) SetTurnToFace(LE::TVec3 facePos) SetMoveToPoint(LE::TVec3) SetPathToPoint(LE::TVec3) I was actually rather proud of this module as it is not only code that is re-used a lot it also re-uses a lot of code within itself very well. For example the SetPathToPoint() function simply works by managing the calling of SetMoveToPoint() and SetTurnToFace() functions in a structured manner so that the controller will move from one node to the next in a path. Even the SetMoveToPoint uses the SetTurnTo Face() function to first turn to face the direction that the controller is to move. With that out of the way I just had to continue to create behaviours for mobile NPCs. I found that my previous method of having slotted behaviours still worked very well and I made no changes there. The behaviours were given access to the NPC modules so that it could call the relevant functions to get the NPC to do what the behaviour decided it should do. Now that that is all out of the way I am working on the games Alert System. Basically it is like an alarm system where if the player gets seen then an alarm gets set and all NPC's in the immediate area will know your location. This of course means stealth and in terms of stealth the mechanics is 95% with the NPCs further compounding how important NPCs are. Hope you enjoyed my stories. Sorry no more video's for you guys until official announcment

Have you tried updating your graphics drivers?

Ah a glorified Dell

Not if its a laptop

I'm interested to know what people would even use soft bodies for in their game. I can't imagine it's benefit being worth more than the performance cost that I imagine it would induce.

Besides my biased opinion that C++ is better in almost every way.... It doesn't really matter what you use.

I wonder how much effort would be required to support this for LE if any. If you don't have to change anything about the rendering then you could probably implement it without official LE support as it comes with an API for the motion sensing and such. However, I’m not sure if the rendering would have to be different for peripheral vision. I’d be interested to see if you could just change the camera view angle or if it is more involved like having the camera clip plane be rounded rather than flat. However, I’m not sure if the rendering would have to be different for peripheral vision. I’d be interested to see if you could just change the camera view angle or if it is more involved.

What ever you do... Don't mention the war!

Maybe try something like this: Not sure if this is the exact code or what exactly GetChar() returns if nothing is hit cuz I'm at work and can't check. But it should give you enough information to figure it out. bool AnyKeyHit(){ int key = NULL; key = LE::GetChar(); LE::FlushKeys(); if(key != NULL) return true; else return false }

C# won't be supported initially in LE3. However, I think it will be supported later after release.

what are you calling TurnEntity on? Also forget the dummyObject... I don't see what purpose it has. The pivot is supposed to be the dummy object itself that is parented to the player and then the camera is parented to the pivot. From what you're showing there it looks like you are creating a pivot and not doing anything with it.

This is the general idea. Although there are ways to do it without a pivot... I'll still explain using one. Camera is parented to a pivot which is positioned (not parented) to the character. The reason you don't parent the pivot to the character is because if you do, you lose any possibility of smoothing. For a good smooth camera you need to position the pivot at the characters position each frame except using the Curve function. @Foomanshoo.. 1. Create you objects: (this is psuedo code so not correct syntax) LE::TCamera cam = CreateCamera(); LE::TPivot camPiv = CreatePivot(); LE::TController player = LE::CreateController(); 2. LE::EntityParent(cam, camPiv); //Parent the camera to the pivot 3. LE::MoveEntity(cam, LE::Vec3(0, 0, -followDistance)); // Move the camera back by a certain distance 4. In Main Loop Position campPiv to Position of player except using the Curve smoothing function. 5. Also in main loop use user input from mouse movement to rotate the Turn the pivot allowing orbit around the point. There are better ways to do this without a pivot but this should be easiest for you.

Regardless it is good practice

HAHAHA lulz always a funny one MG....

Nice one MG XD..... Though do you sleep with one eye open? Just in case something happens along the way and you have to make a quick decision XD

Yes. Power of 2 is very important. Read why here: http://www.katsbits.com/tutorials/textures/make-better-textures-correct-size-and-power-of-two.php

http://www.leadwerks...led/#entry48802 Evidently its not working too well Josh. Maybe you should go back to what you were doing before ::giggles::

Makes sense. As a pointer holds a physical address in memory using the ++ operator sounds like it would just increment the position in memory or do nothing... one of the two. The overloaded ++ operator you defined in the class is defined for an object and not a pointer to an object. Sounds right to me (*asset)++ is what you want but I'm sure you know that already by now

Its the exact same as the last one with changed DP and name