Make the Database Editor configurable like the new Plugin Manager

[xDGameStudios]

Description of the Feature:

• This feature would make it possible to add new fields to the database editor using plugins!
• In the plugin you could name the field, give it a default value, a type...
• The fields could go somewhere in the same place where the notes are!
• Field would then be added to the database structure, like the meta that is automatically processed when running!
• Variables from different plugins would stack (concat) with plugins (ie.: plugin 1 defines variable "top", plugin 2 defines variable "bottom", database item would have both top and bottom variables).
  
  (PART2, another ideia not necessary!!)
• Adding to the ideia it could even enable some customization, like creating your own tabs in the editor!! (See second mockup)

Mockups:
Here is something that will show just what I mean (in the image I called it "variables" but I think "fields" is a more suited name):

From the plugin point of view for example (the tag "editor" refers to the editor tab you are trying to add a new field):

/*:
 * @editor Items
 * @param enable
 * @text Enable the Quest System
 * @default true
 */

Another mockup of something even more dynamic:

for the second mockup idea just using a "tab" tag.

[CODE]/*:
 * @tab Quest
 * @param Name
 * @type text
 * @default Something
 *
 * @param Icon
 * @type icon
 * @default 1
 *
 * @param Description
 * @type multiline
 * @default Other thing
 *
 * ..... (you get the idea)
 */

Why is this feature good?
This feature is great because of the following:

• Puppies of course!!
• It will be much more convenient than adding a lot of messy tags.
• Notes could still stay there for compatibility purposes.
• The fields could be used to override default ones... for example for breaking editor limits.
• THE MOST IMPORTANT: it could tackle many features that were asked for, like limit caps, custom traits (we could build our own custom trait/effects struct and let the player add them right in the database editor), ...

Possible issues with this feature?
Issues that might arise from this feature:

• Don't really know what issues could come from that!!
• I would say using duplicated variable names... but that could already happen with tags.
• I don't know how complex it would be to do this since we already have this feature working for the plugin manager it should be straight forward

 

[Kaliya]

I actually like this suggestion, and would push for it if it gets enough "Yes" votes. Shame that currently no one is voting on this stuff.

- Liquidize

 

[Shaz]

I like this - it gives a spot for all the stuff we put in notes, and makes notes free for ... well ... notes!

My only request would be to allow multiples of the same value. Right now, when building the metadata, if the game finds the same item defined twice, it overwrites the original with the newer one. I would like it to turn it into an array. Or for the plugin to specify that it's an array, so even if there's only one instance, it's still put into an array.

 

[peq42_]

Nice idea, it would make a lot easier to configure things when dealing with many plugins

Also the engine would like more flexible and professional with it. People could create something like "MV Upgrader Pack" with plugins that improve and add new things to the engine, and it would be integrated in the Editor.

 

[Frogboy]

I like it. Anything that would clean up the Notes box would be nice.

 

[xDGameStudios]

I actually like this suggestion, and would push for it if it gets enough "Yes" votes. Shame that currently no one is voting on this stuff.

- Liquidize

Well at least now... this seems to have gain some visibility thank you for the votes.

I like this - it gives a spot for all the stuff we put in notes, and makes notes free for ... well ... notes!

My only request would be to allow multiples of the same value. Right now, when building the metadata, if the game finds the same item defined twice, it overwrites the original with the newer one. I would like it to turn it into an array. Or for the plugin to specify that it's an array, so even if there's only one instance, it's still put into an array.

that array thing is important also!! It would be a good addition!

The main reason I see this as a good feature is it make the editor much more professional.. and places RPG Maker in the same step of configuration as a lot of other high end engines It could be a standard from now on, even in new RPG Makers iterations.

Adding to the idea, imagine... metadata to allow to add new object tabs to the editor.
For example creating a:

@tab Quests

would allow to add this new "Quest" data type and then adding fields to it dynamically... wow.. It would be really great
then one could even decide if it is a tab with a list of objects like "Actors", "Items" using:

@tab Quests[]

or a tab with just a bunch of fields, like the System tab! for example (the more complex thing I see with this tab idea is "How would the properties arrange themselves in the GUI layout?"... they could just stack one below another).

 

[Dungeonmind]

I love this idea to. I’m gonna vote yes. There could be endless possibilities. It would make some plugins Actually feel like they are installed and people with less plugin-use knowledge it would be easier for and potentionally make more advanced plugins easier to understand and change options/fields for.

I really hope this feature gets approved!

 

[ICF-Soft]

I had a similar idea to bind plugin parameters to database and I think that is better to post here than opening a new thread. You can see that is different, but is more plugin developer friendly.

To add fields to a table inside database you use tags like these inside main block:

 * @databaseKey ICF
 * @databaseText ICF-Soft
 * @databaseTable Items struct<something>
 * @databaseTable Skills struct<something>

databaseKey: A name given to a group of fields. If more than one plugin uses the same all fields will be merged.
databaseName: A name to show in a tab for it's key.
databaseTable: The table to bind parameters and a struct where parameters are taken from. Can be any table from database, maps, events and eventpages.

Spoiler: Mockup

Unlike normal plugin parameters these should be stored as the right data types instead of a text that needs to be parsed.
To access a field you use an identifier to show that it comes from a plugin, the database key you've defined and the name of the field.
Example:

$dataItems[1].pluginKey.ICF.weigth

This will help plugin developers a better framework for his/her plugins and avoid notetag intromisions. Plus a better interface for game developers.

 

[xDGameStudios]

I had a similar idea to bind plugin parameters to database and I think that is better to post here than opening a new thread. You can see that is different, but is more plugin developer friendly.

To add fields to a table inside database you use tags like these inside main block:

 * @databaseKey ICF
 * @databaseText ICF-Soft
 * @databaseTable Items struct<something>
 * @databaseTable Skills struct<something>

databaseKey: A name given to a group of fields. If more than one plugin uses the same all fields will be merged.
databaseName: A name to show in a tab for it's key.
databaseTable: The table to bind parameters and a struct where parameters are taken from. Can be any table from database, maps, events and eventpages.

Spoiler: Mockup

View attachment 78691

Unlike normal plugin parameters these should be stored as the right data types instead of a text that needs to be parsed.
To access a field you use an identifier to show that it comes from a plugin, the database key you've defined and the name of the field.
Example:

$dataItems[1].pluginKey.ICF.weigth

This will help plugin developers a better framework for his/her plugins and avoid notetag intromisions. Plus a better interface for game developers.

I like this idea, for note tags, too!!

But as @Liquidize said.. not a lot of people are taking these major advantages into consideration.

 

[ICF-Soft]

Maybe we need more patience. This is a good suggestion but it needs to be viewed by more people. I think is a matter of time.

Anyway we can still dream that programers have a lack of ideas and someone propose this.