Canardia

I so want to use this crowd AI in a mini game like Leeroy Jenkins You aggro one enemy, run away and because he has aggro on you, every other enemy who sees the enemy who has aggro to you will aggro you too. Soon you have all the enemies chasing your arse.

You have vertical sync forced ON in your nVidia control panel. It should be always set to force OFF, so that applications can run above 60 FPS.

Actually, when using Lua, you should avoid putting too much code in the main loop, because Lua is a bit slow in looping. Instead, try to put all the code into the model's lua file, because then you get not only more speed, but also your whole game will work with very little changes from C++ also. It will work from C++ and if you need more speed, then you can put the model lua code into the C++ main loop when needed.

Does it also support detours, so the enemy AI can not be predicted so easily? I saw in your code at the end of the video that you set an array on weights to 1.0f, so maybe one could set "wrong" weights to simulate a detour? For example when the shortest path is full of sentry guns and traps, a detour with smaller weights would make the enemy travel a safer path.

Can the thickness of the Ariadne's String be adjusted, so that it doesn't hug the walls so much?

Ah yes, AutoSmooth sounds good, because indeed on soft edges, like on a sphere they should be welded.

SetBloom(1) SetAntialias(1) etc... http://www.leadwerks.com/werkspace/page/Documentation/le2/_/command-reference/framework/

Looks like you are missing the mat files. Each seperate texture of the model needs an own mat file. For example if you use a texture called stone002.png, then your mat file would be in its simplest form: stone002.mat texture0="abstract::stone002.dds" Note that you also need to convert png to dds, because LE can only read dds textures.

No, logic is not computer based at all, it's all in your head. But you use your head to read the logic from one computer program, and then you implement the same logic to another computer program. As an example, if the CE script picks up an object when you press F, then you would know in you head that this happens when you press F, and then you can do the same in LE. Of course you need to know then also what commands you need for doing that logic in LE, but it's quite simple, basically just a EntityPick(player,3) (upto 3 meters away) when KeyHit(KEY_F) occurs, and then FreeEntity(object) and add it to your inventory as a simple text item.

Yeah, you can use any logic in LE. So just copy the logic, not the code, and it will work. Copying logic works so that you first read and understand what the original code does, then you just transfer your knowledge by coding it in another engine. Sounds logical, right?

I tested it again today, and it's now giving 1 FPS less. So it seems to be a bit random behaviour, and probably best to keep it turned off then.

Why not? At the moment, in LE 2.5, it gives an FPS increase, so there might be actually a bug in the engine, because it should not give an FPS increase when the whole occllusion culling is turned off.

Callbacks don't work in Lua.

You could just hide it before the raycast and the show it again.

Like I said, you should still put model->SetOcclusionMode(true); because it gives more FPS when OcclusionCulling(0); is set also.

You get the best FPS when you set OcclusionCulling(0), but still set it to 1 for each entity recursively. And EntityViewRange(0) works for me, and it increases FPS.

Try to set the camera far range also to the same distance as your model's view range is (default 50 for near).

ViewRange can not be 10, but only 0-3: const int VIEWRANGE_NEAR = 0; const int VIEWRANGE_MEDIUM = 1; const int VIEWRANGE_FAR = 2; const int VIEWRANGE_INFINITE = 3;

But isn't mp3 much worse quality than ogg, at least I can hear a clear difference with high quality songs which has high pitched percussion and other instruments. It's impossible to encode them with mp3, but no problem with ogg.

Maybe he was a visionary. Like Leonardo da Vinci, or Dr. Michio Kaku. In future we will have sunglasses with integrated computers and screens. It doesn't exist yet, but it's quite sure that it will, because we want it.

Wrist watches don't especially say tick tick tick, unless you put your ear right next to it. The first tick tick tick clocks were made already in the 13th century, so it is absolutely historically correct to say in the 17th century tick tick tick: http://en.wikipedia.org/wiki/Clock#Early_mechanical_clocks The word OK was also invented in the 17th century, so it is also historially correct: http://en.wikipedia.org/wiki/Okay#Earliest_documented_examples You should really Wiki all your info, because without doing that, you're hopelessly on ignorative grounds. Even if the Wiki is not 100% updated, it's still the best you can get.

You can make a custom tank vehicle with LE2. I've already demoed that you can even make 4 legged walker robots, so everything is possible. Setting up physics forces and torques is very delicate though, but with a few tests you will find the right balance, to make it stable and game ready.

The mess with the entitykeys: name, class, model, classname, has been always horrible, because they used to change from one engine version to another. I just hope it stays like it is now: 1) name = the name of the entity (can be anything you want, like Joe, John, Josh, Player1, Enemy1, Hummer, etc...) 2) class = the entitytype of the entity (mesh, light, corona, etc...) 3) collisiontype = the collisiontype (can be mistaken as entitytype, so I think using class and collisiontype is better, like it is now) GameLib used to use classname, because it was used first by the engine for additional type designation of entities, but then it got lost somewhere after LE 1.15 or so. GameLib has been still using it, hoping that it will come back some day, but it never did. Now I decided to rename it to type, because class is already taken by the engine, and looking at the Wikipedia for typology, the term type actually sounds logical. So with the next gamelib release, type will designate what kind/type an entity is, for example: weapon, player, enemy, car, etc.... It should be easy to remember. All models need the one additional line in their lua script which adds the type string input for Editor. This is easy to add, for example if you have a new model with no Lua script at all yet, the whole Lua script would look like this: require("scripts/class") local class=CreateClass(...) function class:InitDialog(grid) local group self.super:InitDialog(grid) group=grid:FindGroup("General") group:AddProperty("Type",PROPERTY_STRING) end

I think we have to wait and see how the plugin design in LE3 is, maybe it is like PAL, but for all libraries, like graphics, sound, and not only for physics. It would make little sense to have PAL for physics, and then no PAL for sound and graphics.

Too big terrains can lead also to bad gameplay, like we have seen in FarCry 2. The terrain is way too big, and the whole game is just useless driving around and killing respawns. Better have a smaller terrain which you can actually populate better, and not have huge distances with emptyness. Even a 128x128 terrain is quite big with a 10 times smaller scale, because you would have to populate a 1 square km area, and that would lead to lots of polygons too, if you want to keep it dense.