Replies: 2 comments 1 reply
|
I also believe we need to make plugins immutable and treat them as a part of the RPGMV codebase, as in no replacement patches for them. Whatever we can do with a patch can also be done with a new plugin. I think we need to not think about the mod plugins as RPGMV plugins, but as they are, mod plugins. Use a separate "mod plugin loader." This could allow for some neat tricks like a |
|
I feel like the best way to do modding in general is make the vanilla game immutable; aka there isn't any support for modifying an existing model in Gomori, or you may have to make replacing existing models extremely explicit for things like maps. For everything else, I'm considering dropping model replacement in all to encourage immutable modding. If you really, really need to replace a model, you would need to do it programmatically. We might introduce mod compilation at runtime. Database mod files are stored as deltas. These deltas get read by Gomori and Gomori gives unallocated ids to each new database model. After those database models have been given ids, Gomori then has to replace each reference to the models in the mod's other databases, like event pages, with the new unallocated ids given to those models. With that, those things can be safely appended to the I'm pretty confident this solves almost every single issue we had with the current patch system for database objects and maps. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
We agreed that a new form of patching needs to be done to allow mods to be better compatible with each other, which also ushers in a new major bump. Ideas for patching (and further API changes) should be discussed below.
Me (and a couple other people of #modding-discussion) agreed that we should start using string IDs for models like items and enemies. String IDs will prevent conflicts while also being referable by code.
All reactions