Should notes be read-only and not for writing?

[Tsukihime]

Note-tags are a common way for users to provide input.


However, different scripters have different ways of treating notes. The two general ways are


1. parse the note once and cache the values in instance variables


2. parse the note everytime a value is needed


The first approach assumes that the note does not change and essentially treats it as initialization data.


The second approach does not assume this and assumes someone may be modifying your note whenever they want and expect you to pick up the new value. Which is of course more forgiving and better for compatibility because it's not hard to modify a note right? It's a string after all (well, by default anyways)


I think it can be difficult to accurately modify a note. There are several different operations


1: append a tag. This is easy, and it would be pretty easy to do it right


2. Modify a tag. This may be somewhat difficult depending on how many other tags the note is cluttered with. For the most part would require you to extract the correct tag and then subsitute or re-build it.


I say it's better to just never try to modify a specific "field" on the note, and instead modify the instance attribute directly if it needs to be changed.

 

[Funplayer]

Notes are usually for importing data into some sort of object structure, by the notetags contained in whatever item/monster/skill/whatever.  Generally speaking, you should not be modifying the notes directly.

Good practice would be, import notes once into objects, modify objects, save any instanced objects for custom modifications into its own objects (either attached to the file, or a into a sub external save based around the global environment).  Add more notes later, and a note check to sync the instanced items with the main item database.

The database itself reloads every time you load the game into memory, because the global variables are populated by caching the database itself into a series of $objects. 

An altered vanilla database is not going to save notes, and thus the notes are already read-only.  This is the case with VX, but with Ace i'm not completely sure, but I'm fairly certain.

 

[TheoAllen]

I never saw any scripters modifying notes on the fly. I believe that we all indirectly agreed that anything related to the database objects should not be changed no matter what.

 

[Shaz]

Yeah, I load all of mine on startup and don't change them. If you allow them to be changed, you've got to save them with your save data and then load them again on a new game.


If I want to change data, I'll set up an array or hash in Game_System or somewhere to store the details, and it'll be saved & loaded automatically. Then I'll add methods to make the engine check for the changed data and override any default values with it, if necessary.

 

[Engr. Adiktuzmiko]

IMHO, I prefer the second option so that note changes to the database (like if I update a game) would be read... We all know that not doing that causes some problem especially with scripts that are added after a save file was made...

As for modifying them on the fly, especially if by the user thru some sort of input, I don't think that is a good idea...

 

[Funplayer]

IMHO, I prefer the second option so that note changes to the database (like if I update a game) would be read... We all know that not doing that causes some problem especially with scripts that are added after a save file was made...

As for modifying them on the fly, especially if by the user thru some sort of input, I don't think that is a good idea...

I'd suggest establishing a versioning system, to cater to any database changes you'd have.  It wouldn't be more than a couple hundred lines of code, and would greatly improve compatibility with a changed database.  Saved files being loaded from older database versions, would simply have their item lists brought up to snuff, otherwise the script would end and the game would immediately begin.

 

[Galenmereth]

I'd suggest establishing a versioning system, to cater to any database changes you'd have.  It wouldn't be more than a couple hundred lines of code, and would greatly improve compatibility with a changed database.  Saved files being loaded from older database versions, would simply have their item lists brought up to snuff.

I'm doing this with The Vendor, because it's inevitable that there'll be some post-launch patches, and I really don't want to tell players that "sorry, you'll have to start a new game to get the latest version". So I'll be writing an auto-updater for save files so that everything that's non-database read (like crafted items with custom stats) will be brought up to workable conditions.

 

[Funplayer]

I'm doing this with The Vendor, because it's inevitable that there'll be some post-launch patches, and I really don't want to tell players that "sorry, you'll have to start a new game to get the latest version". So I'll be writing an auto-updater for save files so that everything that's non-database read (like crafted items with custom stats) will be brought up to workable conditions.

Smart thinking.  Nobody wants to restart their game, to get the newest content.

 

[tyler.kendrick]

Even though I'm just reiterating previous sentiments...

Notetags shouldn't have write access; they are default database data - just like actor and class names.

Just like actor and class names, if you want to augment the values, changes are made and persisted through intermediary instance objects (i.e. Game_Actor).  Otherwise, changes to the notetag would be persisted across all new save files - which would likely be undesirable.

For example, if you store the class an enemy uses in a notetag, the following scenario would be a problem:

- Enemy "Rival" is assigned class "Fighter" in notetag.

- New Game is started and saved.

- Game progresses and Enemy "Rival" class notetag is set to "Master Fighter".

- New Game is started.

- Enemy notetag is read: setting "Rival" to "Master Fighter" instead of "Fighter".