The code in this package was generated by an LLM, and exhibits unmistakable hallmarks of this in its exercise of the mob API.
Mobs should never overload on_step, for that circumvents the mob API entirely, and defeats the purpose of the mob API. The rest of the implementation comprises inferior substitutes for physics facilities which already exist in the mob API, but were disabled by this measure, and there are also numerous instances where fields defined by facilities in the mob API which are circumvented here are defined in the mob table, by a program which clearly does not understand why they exist. This practice is not supported by mcl_mobs; it is not guaranteed to continue functioning, and you would be far better served by either defining an ordinary entity with your code, or conforming your mob implementation to the AI and physics systems defined by mcl_mobs.
Thank you for this very helpful comment. The information you gave about the mob_API is what i'm currently trying to understand and solve.
I have marked the mod as WIP as i'm new to this and am trying to learn how the system works.
'The code in this package was generated by an LLM', yes. And that's why i indicated this in the description as well as the readme and lua files of the package.
If you can give me more feedback and maybe a few hints as to what needs to change with the highest priority i would be very thankful.
I've already told you what must be altered, but sure, I shall elaborate. The mob must cease to override "on_step," and the custom physics must be deleted, after which AI functions must be defined to perform the functions which these methods previously did.
I suggest referring to one of the existing mobs in mobs_mc, such as the Vex.
yes, that is true! thanks to you i found and read the mob api. on_step and the 100% ai made physics (i dont get) are gone.
'after which AI functions must be defined to perform the functions which these methods previously did'
that will be a whole new update eventually. kodama needs to become a mesh and an actual mob first i guess.
vex testing is happening! i used the parrot as base layer before.
I agree with the sentiment.
In the current state you will end up with permanent light nodes on the map and players complaing that blockes they placed disappeared.
yes. i agree as well and am working on a new update. there are a few funny things about the vex that don't work for kodama yet. i'm having real trouble to get 'check_travel_to_owner' to work and also found that the vex has custom ai and physics. this will take a bit of work with kodama. also he needs to become b3d mesh which im working on atm.
the issue with the light nodes will be solved by just removing the immumination for now until i get kodama to float like the little spirit he is.
It's not necessary that a mob's mesh should be a b3d (or indeed that its visual should be a mesh at all). You should be able simply to specify another visual type.
Thank you repetitivestrain,
Currently I'm trying to get upright sprite to work but the movement seems to be an issue. The Vex has custom movement and doesnt override the mob api from what i understand. This probaply is the main issue with Kodama as of right now.
The code in this package was generated by an LLM, and exhibits unmistakable hallmarks of this in its exercise of the mob API.
Mobs should never overload on_step, for that circumvents the mob API entirely, and defeats the purpose of the mob API. The rest of the implementation comprises inferior substitutes for physics facilities which already exist in the mob API, but were disabled by this measure, and there are also numerous instances where fields defined by facilities in the mob API which are circumvented here are defined in the mob table, by a program which clearly does not understand why they exist. This practice is not supported by mcl_mobs; it is not guaranteed to continue functioning, and you would be far better served by either defining an ordinary entity with your code, or conforming your mob implementation to the AI and physics systems defined by mcl_mobs.
Yours, &c.
Thank you for this very helpful comment. The information you gave about the mob_API is what i'm currently trying to understand and solve. I have marked the mod as WIP as i'm new to this and am trying to learn how the system works. 'The code in this package was generated by an LLM', yes. And that's why i indicated this in the description as well as the readme and lua files of the package. If you can give me more feedback and maybe a few hints as to what needs to change with the highest priority i would be very thankful.
Yours, PsyMops
I've already told you what must be altered, but sure, I shall elaborate. The mob must cease to override "on_step," and the custom physics must be deleted, after which AI functions must be defined to perform the functions which these methods previously did.
I suggest referring to one of the existing mobs in mobs_mc, such as the Vex.
yes, that is true! thanks to you i found and read the mob api. on_step and the 100% ai made physics (i dont get) are gone. 'after which AI functions must be defined to perform the functions which these methods previously did' that will be a whole new update eventually. kodama needs to become a mesh and an actual mob first i guess. vex testing is happening! i used the parrot as base layer before.
I agree with the sentiment. In the current state you will end up with permanent light nodes on the map and players complaing that blockes they placed disappeared.
yes. i agree as well and am working on a new update. there are a few funny things about the vex that don't work for kodama yet. i'm having real trouble to get 'check_travel_to_owner' to work and also found that the vex has custom ai and physics. this will take a bit of work with kodama. also he needs to become b3d mesh which im working on atm. the issue with the light nodes will be solved by just removing the immumination for now until i get kodama to float like the little spirit he is.
It's not necessary that a mob's mesh should be a b3d (or indeed that its visual should be a mesh at all). You should be able simply to specify another visual type.
Thank you repetitivestrain, Currently I'm trying to get upright sprite to work but the movement seems to be an issue. The Vex has custom movement and doesnt override the mob api from what i understand. This probaply is the main issue with Kodama as of right now.