New AI for Mobs

[SamJBarney]

Ok, I've blocked out the first set of tasks that need to happen with the ComponentRewrite. Here is a list of things that need to happen. Please post in this thread which task you plan on doing before you do it. Also, push your code to the ComponentRewrite branch of MCServer.

Initial Tasks:

• cModelComponent
  • REALLY EASY - Create subclass 'cBoatModel'
    
  • REALLY EASY - Create subclass 'cFloaterModel'
    
  • EASY - Create subclass 'cMinecartModel'
    
  • EASY - Create subclass 'cPlayerModel'
    
  • EASY - Create subclass 'cPickupModel'
    
  • EASY - Create subclass 'cProjectileModel'
    
  • MEDIUM - Move SpawnOn calls from the different entities into the new classes. Have them pass the entity to the spawning code instead.
    
  • HARD - Rework cClientHandle and the Protocol classes to use the new entity system. This will require some temporary code to be in place while the rest of the system is written.
    

Completed Tasks:

• cModelComponent
  • REALLY EASY - Create subclass 'cExpModel'
    
  • EASY - Create subclass 'cMobModel'
    
  • EASY - Create subclass 'cBlockModel'
    

Remember, the cModelComponent and its descendants only handle what the client sees on their end, currently. The tasks marked REALLY EASY will just require the creation of the class. EASY tasks will require a bit more put into them (e.g. Mobs have different varieties).

Also, don't worry if your code doesn't compile; the task you choose may just be dependant on a task not completed yet.

Thank you to all of those who are willing to help out.

---

Once we get these done I will make sure we have a compiling version of MCServer that works as expected before we move onto the next set of components.

[xoft]

I still don't quite understand what the cModelComponent is supposed to do.

[SamJBarney]

Currently each Entity, whether Vehicle, EXP Orb, Mob, Falling Block or Item Drop has a SpawnOn function which is used to interface with the cClientHandle. These SpawnOn functions call their respective spawning function within the cClientHandle class. We'll be moving that functionality directly into the cModelComponent.

Along with that, the cModelComponent will eventually handle collision with blocks and other entities. And possibly physics simulation, if entities were handling that before.

Sorry if I haven't been clear about its purpose. Does that help a bit?

There are a couple of other things that I want it to handle, but I am still uncertain about whether they should be a part of it.

[xoft]

Not sure if this is the right way to go at this. Why not have a cProtocol:SpawnEntity() function that would take any cEntity and spawn it on the client using whatever protocol packet it requires? Historically there were some changes to some entities being spawned by one packet, but later in new protocol by another packet; this way the protocol can handle everything and we don't need the cModelComponent to do this at all.

[SamJBarney]

But how does it know what to spawn? Where is that information stored? Unless we have something that encapsulates that, we're just sticking with what we already have. Besides, doesn't cClientHandle know which version of the protocol to use already?

[SamJBarney]

You know what, I'm not going to bother explaining it anymore. I'll just get rid of it and get started on one of the other bits.

[SamJBarney]

Let me know when people are done poking at the old Entity and Mob code, and then I will continue on the rewrite. I don't want to have to deal with reverse merging to get this working.

[tonibm19]

I think old Mob AI is now good enough to stay some time with it, so...

[NiLSPACE]

The current AI is much better then the previous one, but it still has massive flaws that can be improved.

[SamJBarney]

Well, if anyone wants to do the entity and mob rewrite, I'll give them a hand. But I suppose I'll just let it go for now.