-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Namespace custom game object fields by the mod that adds them #15
Comments
I think we've decided on the data:add {
_type = "base.chara",
_id = "spiral_putit",
_ext = {
moar_putits = {
putit_class = "deadly"
}
}
} And have some way of adding to Data.add_mod_extension("moar_putits", "elona.putit", { putit_class = "benign" }) The edits must be wrapped in callbacks to be compatible with hotloading, else you'd have to restart the engine to get the data mutated in the correct order. This would use an API similar to that of If we don't do this, data definitions won't be compatible with hotloading, so we have to implement it before stability is reached. |
NB: Read up on Forge's capability system. Could have some good ideas, as opposed to just shoving all the mod extended data into an unstructured table. |
I think the capabilities should be interfaces, just like the base engine's. They could get passed their own private table somehow for the local visual_ai_plan = chara:get_capability(IVisualAICapable)
if visual_ai_plan then
visual_ai_plan:run(chara)
end And we'd have a |
I think it would be very convenient to specify items as acting like an armor/weapon by merely defining a capability. The way armor and weapons are defined currently is a bit hackish. The capability would store the DV/PV or dice rolls of the object. |
Maybe it would also be best to just replace the |
Many games like Minecraft have systems where mods can attach custom data to game objects. In that game specifically, groups of custom fields are placed in tagged bundles, and mods check if the object has a specific bundle if they want to use fields from other mods.
This is in contrast to how OpenNefia currently handles custom fields added by mods, in which... it doesn't. Mods simply add whatever data they want directly on the object. This can cause numerous issues:
There could be multiple ways of handling these issues:
object.m.my_mod.field
. This increases verbosity, but makes it completely unambiguous which mod the field is concerned with and eliminates concerns about naming conflicts. After this is done,__newindex
on the game object can be overridden to make it impossible to add new fields directly on the object's table.The text was updated successfully, but these errors were encountered: