You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the first I really like the class based structure of this mod. But currently just the functionality is grouped to classes. I miss the Class-hierarchy of the Mob-Classes. Currently there is just one Mobs-Class named "ai_library" that is copied to all defined mobs and does have all the logic. I see you run into problems because there is no "universal" logic possible. The result are many not needed if's like "if jumper then, elseif aqua, then, elseif ridable then .... I tried to fix a issue with NPC after stop walking, because freezing of the walk-animation seems strange for NPC. Then I realized the freeze is fine for cows or horses, and allways enable the stay-animation will be seems strange for this npc types.
I'm not a OO-guru, but I imagine it as follows (some pseudo-code):
-- base-class that contains just the really universal minimum (framework and luaEntity related things)
ai_base = {}
Then the hierarchy
ai_animal = table.copy(ai_base)
ai_animal.animation = animal_specific_animation
ai_monster = table.copy(ai_animal)
--have same animation
ai_npc = table.copy(ai_animal)
ai_animal.animation = npc_specific_animation
Now there is no mix with the many ifs. Each method is assigned to the right class.
Of course we need a registration, like "register_ai("type", class)" that register the usable classes in a table.
ea_table["npc"] = ai_npc
The "register_mob" can get the mob_type = "npc" in interface to select the right implementation.
If the "register_ai" is available for other mods it is possible easy to add new mobs from other mods
A second advantage of multiple more specific classes is: the classes can contain usable defaults so the register_mob() parameters list can be reduced. A sample: the NPC does have allways the visual = "mesh" with mesh = "character.b3d" and allways the same collisionbox and radius...
The text was updated successfully, but these errors were encountered:
At the first I really like the class based structure of this mod. But currently just the functionality is grouped to classes. I miss the Class-hierarchy of the Mob-Classes. Currently there is just one Mobs-Class named "ai_library" that is copied to all defined mobs and does have all the logic. I see you run into problems because there is no "universal" logic possible. The result are many not needed if's like "if jumper then, elseif aqua, then, elseif ridable then .... I tried to fix a issue with NPC after stop walking, because freezing of the walk-animation seems strange for NPC. Then I realized the freeze is fine for cows or horses, and allways enable the stay-animation will be seems strange for this npc types.
I'm not a OO-guru, but I imagine it as follows (some pseudo-code):
Now there is no mix with the many ifs. Each method is assigned to the right class.
Of course we need a registration, like "register_ai("type", class)" that register the usable classes in a table.
ea_table["npc"] = ai_npc
The "register_mob" can get the mob_type = "npc" in interface to select the right implementation.
If the "register_ai" is available for other mods it is possible easy to add new mobs from other mods
A second advantage of multiple more specific classes is: the classes can contain usable defaults so the register_mob() parameters list can be reduced. A sample: the NPC does have allways the visual = "mesh" with mesh = "character.b3d" and allways the same collisionbox and radius...
The text was updated successfully, but these errors were encountered: