New AI for Mobs

[tonibm19]

I'd like to help but I still need to learn much more C++, Im still a noob.
What's the major problem with AI now? With the changes tigerw did now mobs aren't too stupid. I think if we add brewing(I think is the only inportant thing missing,), we'll have a decent mob AI.

[Taugeshtu]

What's the major problem with AI now?

I think it's a FakeTruth Well, put it that way: FakeTruth (I belive it was him, amirite?) linked a paper to modular component-driven design in programming somewhere in AI thread, and we all gone mad (probably, I went mad more than others apart from Sam, who's mad enugh to plan attempt it BTW, cheers, mate I belive in you!), and we discussed this neat component-based mobs system, where you can make skeletons behave like cows simply by config... So, yeah, FakeThruth is wrong with the current AI

But seriously, I suppose (haven't done much testing with mobs myself) AI was slow, stupid, in other words - Artificial Idiot. Haven't looked up recent changes to it but there's always room for improvement. Besides, there're lots of ways vanilla AI can be improved, and since MCS tends to go over "like minecraft, but harder, better, faster, stronger" (and wi[L]dely configurable!) and some people feel like improoving it - why the heck not? After all, it's not a job project, it's a hobby project, we do what we feel like doing.

[SamJBarney]

Plus, the way that we are going to implement it will allow hooking into the Lua side of things. People will finally be able to customize mobs however they like from within a plugin.

---

STR_Warrior, I think you don't give yourself enough credit. Besides, because of the module way that Entities will be built now, you wouldn't have to write a humongous amount of code, or figure out exactly how everything will work.

The first bit of the new layout is that I will be working on is the cModelComponents, and then integrating this into the entity code. I figured this would be the simplest one to work on initially, mainly because it handles what shows up on the client side, and then later on it will handle collision.

Here is a list of the Model Components that I think will need to be implemented:

• cModelComponent
  • cMinecartModel
    
  • cBoatModel
    
  • cExpModel
    
  • cProjectileModel
    
  • cItemModel
    
  • cMobModel
    
  • cPlayerModel
    

Maybe if I posted a specific list of things that need to be implemented, y'all would be more interested in helping?

Xoft, if we're going to go incrementally, I think that implementing the component system first would be the more logical choice. That way we can still keep all of the AI code that has been written so far until we are ready to fully switch to a task based system.

[tonibm19]

Yes, I knew abou that, but I don't think it should be the highest priorty now. I think first AI needs to be like vanilla, and then start with the component rewrite and customizable mobs we thought about.

[xoft]

The problem with switching to component system is that none of us really know what kinds of components we'll be needing, what those components should do and what interfaces they should declare. There's just too much to cover everything. So it would be better to start doing one component at a time, while keeping the rest of the entities in the current format. That's what I meant by the "smaller steps": First make a Behavior component, and convert the current AI behavior into that component. Then perhaps the Movement component. The point is, this can be done incrementally and with much fewer decisions to make, rather than "let's delete all the code and write it new from scratch, using components".

Tonibm19, it's a much better way to rewrite into components first, and then make it like vanilla - because the components will make it much easier to implement the vanilla-like behavior; if we did it the other way around, we'd end up writing code (for vanilla behavior) that won't be convertible to components, so we'd throw it out when we rewrite for components.

[SamJBarney]

I agree, Xoft. I was actually planning on doing it like you suggested: one piece at a time. I won't be moving on to the next part until I one part done.

[tonibm19]

Hmm MoveToPosition does not seem to work in Lua. I think it's because Player:GetPosition() returns a vector3d, any way to convert it to a vector3f?
[17:33:21] LUA: Plugins/Debuggers/Debuggers.lua:525: attempt to call method 'Mov
eToPosition' (a nil value)
[17:33:21] Stack trace:
[17:33:21] [C](-1): MoveToPosition
[17:33:21] Plugins/Debuggers/Debuggers.lua(525): (no name)
[17:33:21] Stack trace end
[17:33:21] Error in plugin Debuggers calling function <callback>()

---

Now I try changing MoveToPosition function in C++ to use Vector3d

---

Nope it doesn't work.

[NiLSPACE]

In lua do:

Monster:MoveToPosition(Vector3f(Player:GetPosition()))

[xoft]

The error message says that the function doesn't exist. Did you re-generate the bindings after marking the function as "// tolua_export"?

You could make two MoveToPosition() functions, one taking Vector3d, the other taking Vector3f, and export both. Both C++ and tolua know how to handle that.

[NiLSPACE]

Maybe if I posted a specific list of things that need to be implemented, y'all would be more interested in helping?

Sure. I'll see what I can do