Palin

Veteran
Veteran
Joined
Mar 17, 2016
Messages
80
Reaction score
36
First Language
English
Primarily Uses
N/A
Hi everyone,

I've been fiddling with JS/RPG MV for years, but I'm by no means a professional coder so please pardon if my terms below are off.

One thing I noticed that confused me is that some plugin makers pre-load monster/item, etc... notetags into a new property of the associated monster/item object (I see this a lot in Yanfly plugins). However, can't the same information be used by just referring to the meta of what you're working with? For instance, in the EnemyBook plugin by Yoji Ojima (which came with MV), when they need a notetag they just refer to the meta of an object without moving it to another property.

Is there an advantage of pre-loading the notetags like Yanfly does vs what Yoji Ojima did? Or is it simply coder preference / cleaner in larger projects?

Thanks for any tips about this. I appreciate it!
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,817
Reaction score
969
First Language
Chinese
Primarily Uses
N/A
Hi everyone,

I've been fiddling with JS/RPG MV for years, but I'm by no means a professional coder so please pardon if my terms below are off.

One thing I noticed that confused me is that some plugin makers pre-load monster/item, etc... notetags into a new property of the associated monster/item object (I see this a lot in Yanfly plugins). However, can't the same information be used by just referring to the meta of what you're working with? For instance, in the EnemyBook plugin by Yoji Ojima (which came with MV), when they need a notetag they just refer to the meta of an object without moving it to another property.

Is there an advantage of pre-loading the notetags like Yanfly does vs what Yoji Ojima did? Or is it simply coder preference / cleaner in larger projects?

Thanks for any tips about this. I appreciate it!
Right now the only 2 advantages I can think of are:
1. Reduced chance of notetag property name collision - As many plugins use the meta property and Yanfly has tons of plugins using notetags, the chance of property name collision would be likely noticeably higher if Yanfly put everything into meta instead. Of course, the Yanfly way can still have name collisions, but I think it's reasonable to expect that more plugins will put things into the meta property than those which didn't, as putting things into the meta's the default RM way.
2. Simpler notetag property access - While the difference between data.meta.noteProperty and data.noteProperty is small on their own when it comes to property access simplicity, the accumulated difference on access simplicity when there are so many notetag properties that are accessed in so many difference places can still be noticeable.

However, I do think that using different ways of pre-loading notetags is mainly coder preference, because the situations of different plugins can be different, and different coder weight the same pros against the same cons differently.
For instance, some of my plugins will even go so far as using data.meta.pluginIdentifier.noteProperty, to further reduce the chance of name collision and make it more clear that which note property is from which plugin.
 

Trihan

Speedy Scripter
Veteran
Joined
Apr 12, 2012
Messages
3,050
Reaction score
2,308
First Language
English
Primarily Uses
RMMV
I think the main thing is that meta only supports notetags in the format <property: value>. Some plugins have multi-line tags with an opener/closer, which meta doesn't cover.
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,817
Reaction score
969
First Language
Chinese
Primarily Uses
N/A
I think the main thing is that meta only supports notetags in the format <property: value>. Some plugins have multi-line tags with an opener/closer, which meta doesn't cover.
I don't know if the op thinks using meta includes something like this as well(edited from notetag reading codes of a plugin):
Code:
_SATB._loadNote = function(notes, datumType, datum_) {
    if (!datum_) return;
    var satb = datum_.meta.satb = { datumType: datumType };
    _SATB._readNote.call(this, notes, datum_.id, satb, datum_.note.split(/[\r\n]+/));
};
_SATB._readNote = function(notes, id, satb, lines) {
    var isEvalLine = false, noteType = "", funcLines = [];
    lines.forEach(function(line) {
        if (line.match(_SATB._REG_EXPS.evalStart)) {
            isEvalLine = true, noteType = RegExp.$1;
        } else if (isEvalLine) {
            if (!line.match(_SATB._REG_EXPS.evalEnd)) return funcLines.push(line);
            _SATB._loadEvalNote.call(this, notes, id, satb, line, noteType, funcLines);
            isEvalLine = false, noteType = "", funcLines = [];
        }
    }, this);
};
_SATB._loadEvalNote = function(notes, id, satb, line, noteType, funcLines) {
    if (noteType !== RegExp.$1) return;
    var funcContent = funcLines.join("\n");
    _SATB._loadNotePairs.call(this, satb, noteType, ["eval"], [funcContent]);
};
_SATB._loadNotePairs = function(satb, noteType, suffixes, entries) {
    satb[noteType] = satb[noteType] || [];
    satb[noteType].push(_SATB._notePairs.call(this, satb.datumType, noteType, suffixes, entries));
};
 
Last edited:

Palin

Veteran
Veteran
Joined
Mar 17, 2016
Messages
80
Reaction score
36
First Language
English
Primarily Uses
N/A
Thanks for the responses.

I was mostly considering the single line tags. I can def see the advantage of preloading when it comes to the multi-line tags like action sequences and the like.
 

Solar_Flare

Veteran
Veteran
Joined
Jun 6, 2020
Messages
551
Reaction score
238
First Language
English
Primarily Uses
RMMV
Expanding on #2 in DoubleX's explanation, in some cases preloading makes sense in order to leverage existing features in the engine. For example, if the note tag adds something that looks like a trait, you can preload it to actually be a trait, allowing you to use all the features that the RMMV code offers for working with traits, such as taking the sum or product of all values affecting a battler. In other words, rather than writing something along the lines of this.something = this.meta.something, you would write something along the lines of this.traits.push({code:500, dataId: this.meta.something, value: 0}).

I would note that the Kadokawa plugins that come with RMMV (by Yoji Ojima and others) are in my opinion probably not the best reference for how to read note tags and plugin parameters. Specifically, text values that are shown to the user should never be private to the plugin's IIFE, because localization plugins (maybe others, but that's the main one) may need to access those strings. There are other problems with those plugins, too - for example, EnemyBook is not extensible because its windows and scene are private to the IIFE.

As many plugins use the meta property and Yanfly has tons of plugins using notetags, the chance of property name collision would be likely noticeably higher if Yanfly put everything into meta instead.
I'll note that Yanfly notetags will appear in meta too. You can't find them via simple lookup, since they're whitespace tolerant and case insensitive, but they're there; you can loop over the meta property and find them by running a regex on the key (this is sort of how I maintained the flexibility of Moogle_X's notetags despite reading from meta, though I used split rather than regex since his tags weren't too complex). Even multiline note tags would be there, I believe, though they would only have the value true which is obviously not very useful.
 

Tsukihime

Veteran
Veteran
Joined
Jun 30, 2012
Messages
8,564
Reaction score
3,875
First Language
English
Lot of points have been addressed above.

Speaking of note-tags, historically I've offered these formats

Code:
<some_tag: value [value2 value3]>
<some_tag: id1>
  opt1: value1
  opt2: value2
</some_tag>

I don't know if meta supports multiple values.

In Ace, I didn't want to have to import a JSON library so I never bothered with it, but maybe for MZ I might switch to using JSON instead of having to deal with parsing.

Pre-loading is generally for performance reasons. If you loading an object involves fetching files, it might be nice to pre-fetch everything inside your "loading" screen at the beginning of the game.
 

Solar_Flare

Veteran
Veteran
Joined
Jun 6, 2020
Messages
551
Reaction score
238
First Language
English
Primarily Uses
RMMV
Speaking of note-tags, historically I've offered these formats

Code:
<some_tag: value [value2 value3]>
<some_tag: id1>
  opt1: value1
  opt2: value2
</some_tag>

I don't know if meta supports multiple values.
Both of those would be gathered by meta, but the second one would only have the value " id1", so it's probably not useful to look it up in meta. (I think meta would also have "/some_tag" set to true, so if you allow both formats for the same tag, maybe you could at least use the meta to test if it exists. Not sure it that's useful, mind you.)

The other downside of meta is that it won't support multiple of the same tag. I guess the last one would be added and the rest would be missed.
 

Tsukihime

Veteran
Veteran
Joined
Jun 30, 2012
Messages
8,564
Reaction score
3,875
First Language
English
Both of those would be gathered by meta, but the second one would only have the value " id1", so it's probably not useful to look it up in meta. (I think meta would also have "/some_tag" set to true, so if you allow both formats for the same tag, maybe you could at least use the meta to test if it exists. Not sure it that's useful, mind you.)

The other downside of meta is that it won't support multiple of the same tag. I guess the last one would be added and the rest would be missed.

Oh ya multiple tags is something I've done before as well.
Simple example you want to specify multi elemental damage (element ATK used in calculation, separate calculation for each element resistance on target)

Code:
<element: fire 0.5> // 50% fire damage
<element: water 0.5> // 50% water damage

Alternatively I suppose we could do

Code:
<element: "fire 0.5 water 0.5">

And then you would just parse the value. But of course if I wanted to add additional arguments, would just break all existing tags.
 

Solar_Flare

Veteran
Veteran
Joined
Jun 6, 2020
Messages
551
Reaction score
238
First Language
English
Primarily Uses
RMMV
Yeah, the way I would have done that (having only gotten RMMV in the last year or so) is to make the element part of the tag key, so...

<element fire:0.5>
<element water:0.5>

Or something like that.

So, at least in simple cases, not supporting duplicates is something you can work around.
 

Latest Threads

Latest Posts

Latest Profile Posts

Mike running through an area that's influenced by his thoughts, thus his drawings are infused into the land.
We're playing Omori by OMOCAT starting at 2pm est :D
Hi there! Do you actively use your Itch.io account? How do you use it?
When you have your friend over and you try to have a good time and let him try your game but he legit finds 10+ bugs that you now have to add to your already big workload for the day lol.

Forum statistics

Threads
111,338
Messages
1,060,262
Members
144,657
Latest member
expiredmilkandcherries
Top