Pixel Perfect

Thanks for the code. I'll have a play with this when I get a bit of spare time.

Yeah, apologies Aggror, I answered without reading it properly, fatal mistake lol. Glad you have it fixed anyway

Best of luck Chris. Looking forward to seeing how this progresses.

For something as controlled as that, where the movement is required to be exact, I would manipulate it directly. Physics engines are great but not really intended for fine control more for emulated physics behavior where the interaction of forces and momentum would otherwise make it difficult to control in a believable way.

Hmmm, isn't LE a library maintained by one person The one thing I don't understand though nakof, having bought Xors3D, why are you still frequenting these forums and posting instead of spending your time with your new game engine

The answer is in the error message: 'cannot compare a function with an integer'. You are trying to compare the function and not its value, you need the brackets after the function name: if MouseX() > 1

If the LE Builder one worked fine with 2010 I would stick with that and just wipe the example code and start with your own tutorial one. At least then you know you are starting with a good project configuration. I don't know what tutorial you are using but beware, not all the tutorials have been kept up to date. I've lost track of what works and what doesn't!

Are you using a project created using the LEBuilder Tool ? This should ensure everything is set up correctly in your project prior to attempting to compile, link and execute.

The EKI One AI engine is started from within your own game engine code and utilises the data from the EKI One project you test and deploy. It then uses a comms system to communicate between the AI engine and your game engine. That interface and the data items to be exchanged have to be defined both in EKI One and in your game engine. I am currently working on a simple example of this type of interface for Leadwerks and this will be released for people to work from. It will demo the fundamentals of the interface. But each individual using EKI One will need to adapt this into their own game engines and expand this to work as they need it to. I cannot preempt their requirements as there is no fixed game engine framework in Leadwerks to work with; as Leadwerks is just a game engine API and people are free to write their engines however they see fit.

Yes, but perhaps it's worth elaborating a bit here on how the EKI One - Leadwerks (or any other game engine for that matter) interface works so people who are unfamiliar with it get a better idea of what does what. Although EKI One generates a nav mesh for your Leadwerks level; it does so within the EKI One sandbox and deploys this data to the EKI One AI engine. All path finding is carried out within the AI engine and only the details of the movement passed to your Leadwerks engine in the form of velocity data (direction and speed) and animation data (what the current animation type should be) at each iteration of your game loop. So your Leadwerks engine never knows anything about the nav mesh as this is all handled for it by EKI One. Likewise, AI designed within the EKI One configurator and tested against your imported level in the Sandbox will be run and executed in real time within the EKI One AI engine, not your Leadwerks engine. So in order to get anything to happen in Leadwerks you need to develop the interface between the AI engine and your Leadwerks engine such that when the AI makes a decision, pertinent data is passed back to Leadwerks to enable the out come of that decision. So you could imagine a situation where your AI is running and your NPCs are in attack mode. Under this simulation they will attack the player on sight. The AI uses line of sight (perception) to determine when each enemy NPC can see you and under that circumstance informs your game engine that it wants NPC n to fire at the player. For this to happen you must have a command interface between EKI One's AI engine and Leadwerks, The actual sequence of the NPC attacking the player will be controlled by your NPC class and will drive all the necessary animation sequences, the AI will simply trigger this action. So to summarize, the decision to carry out events will be decided by the AI running in the EKI One engine whilst the mechanisms to actually make these events happen reside within code in your game engine. The AI engine passes instructions to the game engine whilst the game engine carries these out and provides feedback to the AI engine. So if your Player is hit, the player class could pass back the details of where it was hit back to the AI engine. It would then update your health and possibly decide you have died in which case, come the next iteration of the game loop the AI will send an instruction to enact the player death sequence. Another scenario might have the players health controlled by it's own game engine class and it would enact it's death itself, simply passing back the fact the player had died to EKI One. The exact balance between what is done on the EKI One side and what is handled on the Leadwerks side is for you to decide.

Glad you finally came to a decision. I wish you luck with your game development

Alpha test will give full transparency on anything set over a certain transparency but is cheaper to process, you need to use alpha blend if you want true graduated transparency

That's a good workaround as you can constrain the nav mesh to the immediate area around the tunnel complex and as it's a closed system paths will only ever exist within it anyway. Good luck with your development. It's really great to see people using EKI One.

Ah ok, there is no terrain on that map is there. Does the loader fail then, I can't remember off hand if I catered for that and I don't have the code on this PC. You will need to check (and possibly modify) the code or conversely add a small terrain as a workaround

I agree but otherwise looking good

Generating nav meshes for large areas can work out quite expensive memory wise. When you get errors like this you really need to alter your configuration settings or decide if you need to generate a nav mesh for the entire area. The nav mesh settings can be accessed for the Configuration setting button when editing the level in the Configurator and defaults to the following: Increasing the Cell Size should help reduce the memory footprint as will increasing the size of merged regions but this is at the expense of the resolution of the navigation area. You need to play around with the settings to get a feel for how they affect the outcome of the nav mesh and associated memory usage. You might also concider creating multiple nav meshes. Ones with small cell size but limited area for areas where this might be required such as built up areas and ones that cover large open areas with increased cell size. You can switch between nav meshes freely in your AI implementation. With regard to the tunnel map, if this has any private assets (i.e. locked in a password protected pak file) then you won't be able to export it to EKI One. You need to have full access to all assets referenced in the sbx file for this to work. Otherwise it should work ok, like any other level.

Ouch! That's worrying.

Well EKI One is effectively a path finding and advanced AI solution based around hierarchical Finite State Machine technology with all the tools to support that. So although it's effectively a separate engine it would still be scripted in the same way as you would script an FSM within your game engine. If it's not obvious what you need to do then you probably need to read up on designing AI with Finite State Machines as you need to have a good understanding of the fundamentals of State design. You will indeed require classes for your NPCs which your AI can interface with and because Eki One supports a perception system you can rely on the AI for being aware of when the enemy is in sight and take appropriate action. Your AI could chose the target for instance and pass that data to an NPC class 'targetEnemy' procedure passing the ident of the enemy. The function would then handle the raycast and subsequent shot if accurate targeting of the enemy is required, otherwise just run a random outcome as to whether the enemy is hit or not weighted perhaps by the distance between the two. If hit call the targets decrementHealth procedure and if that results in the enemy's death, its own class instance would handle that (play the death animation, update the AI so it can be removed from the simulation etc). There is a natural separation between the NPC AI and the game play logic. In theory the game play logic could be handled by EKI One too as it supports VirtualAgents which are not tied to a character as such and can be used for producing AI Directors which act at a higher level. Just remember that the more you do in EKI One the more info you will need to pass between your engine and EKI One and the subsequent configuration of suitable data items for this. Some things might be better handled in your own engine even though theoretically they can be done in EKI One. I guess its a fight between ease of design (EKI One has great tools to aid this) and the complexity of the interface between EKI One and your game. There are no definite answers, there are many ways of doing this. It helps to make a list of all the things that need to take place in order to aid the design of these types of systems and of course, unless you have a lot of previous experience of AI design, assume you will learn as you go and accept that you will probably redesign it many times with hindsight before arriving at a final solution. Maybe some of the other people using EKI One might have some further input/insight on this.

So any comments/feedback on any of this Chris ?

I have to agree, this was the correct place for such a question.

correct, well kind of, you can sequence lots of separate image files but most people store a series of images in a single file for convenience ... see this animated sprites link: animated sprites

I support these in my engine so could use these now. I have my own design source for these but I think there would be market for them.

I think he's referring to this: nextNode = LE.GetEntityTarget(currentNode); Console.WriteLine(LE.GetEntityKey(nextNode, "name").ToString()); you are using nextNode without checking that it's not NULL

@Raz. That should work ok so long as you have the specular embedded in the alpha channel of your normal map. Otherwise drop the specular on the frag shader as Metatron is suggesting above

You can either simply paint a series of textures on to a suitable plane as I have done in the past (very fast) or you could use a shader to do so (never tried but I think someone, possibly Aily, produced one in the past).