RPG Maker Forums

The biggest problem for creating a general purpose journal/encyclopedia script or plugin has always been the question of how to enter and organise independent data.
It is easy to make an encyclopedia based on an existing database tab like items or enemies, but encyclopedias for independent world lore like town- or NPC lists have been difficult to enter without programming knowledge to place the data into the code itself.
And for that reason even the existing journal scripts for the makers (MV, Ace and olders) are rarely used.

This plugin is to change this by using a pseudo-map and events as a way to enter that data by the editor, details on that will follow. I'll describe the entire logic structure as I think it should be possible, but lack the time and RMMV-knowledge to implement it myself.


List of needed plugin commands and script functions
All parts described below needs to be able to do by plugin commands (for easy eventing) and by script function (for connecting with other plugins) both

1) set title description
A command to change a plugin property that holds a sentence to describe the active journal.
This sentence will be displayed in the title window of the journal screen.
The game developer needs to be able to change it before calling the screen to allow for different journals to be used

Example:
Plugincommand setjournaltitle "The Library of Skytown - which book do you want to read?"
Script setjournaltitle("The Library of Skytown - which book do you want to read?");


2) Open Journal with single map ID
A command to open a three-element screen based on the data of a single map.
The three elements are a title element (on top, static, contains the journal title and optional the map title), a list element (left side, one line per event on the map) and a content element (main part right, to display details and texts of the entry).
The function to open this needs to be written in a way that allows inclusion in for example a menu manager to call this screen from the main menu.

Example
Plugincommand opensinglejournal 127
Script opensinglejournal(127);



3) Open Journal with multiple map IDs for categories
A command to open a four-element screen based on the data of multiple maps.
Three of the elements are identical to the description above. The fourth element is a category list below the title element but above the list/main elements.
The category list will display the map names as categories from left to right to be able to be selected before the list element is displayed.

Example
Plugincommand opencatjournal 128 129 135 141
Script opencatjournal([128,129,135,141]);

4) set "unknown" default text
The plugin needs an default text that is used when an entry is still inactive and the player cannot know what it is.
Default should be set as plugin property to something like "?????", but the developer should be able to change that based on what kind of journal he wants.

Example
Plugincommand setinactivetext "unreadable booktitle"
Script setinactivetext("unreadable booktitle");

5) choose to display IDs
Some encyclopedias are better to read with an ID-Number for the entry, and in other cases a journal would work better without, for example with a diary where the text of each entry is its date.
So the developer needs a way to activate or deactivate the ID display based on the journal called

Example
Plugincommand displayjournalID false
Script displayjournalID(false);

6)?
Whatever the plugin writer thinks might be good to add



Controls on the journal screen

For the single journal screen, ESC should leave the screen and up-down should scroll the curser through the list element. On each up/down, the main element should update to the content of that specific entry (requiring an enter for updating would be suboptimal but might be neccessary to prevent lag - programmers choice, or give option as plugin property).

For the screen with multiple categories there should be a two-level control.
First level should be category selection - left and right for selecting a category, action button to confirm selection, ESC to close menu.
Second level should be entry selection - after the category is confirmed, the list element will be filled with those entries and the regular up-down selection will be working like the single screen. ESC will bring the player back to cat selection instead of closing.



How to store and read the journal entries
The plugin needs a modified copy of the regular mapload function. This modified function must NOT replace the current gamemap, but instead place the data loaded into the journal data structure.
I don't know if that should be done at the moment of the journal opening (which would have the advantage of versality and less memory use at the price of delay while loading) or if all journals should be loaded at "new game" (which would mean only startup lag and no delays on opening, but require a way to tell the plugin which maps are journals and requires more RAM).

And here is how the data of that map should be converted (which also explains how the developer will enter the data):
The display name of the map will become the category name to be used on the multicat-screen or (optional) the journal title to be used on the single journal screen
The tiles of the map will be completely ignored (although some developers might use that for themselves to help sorting).
Each event will become a single entry in the list element, with the eventID being identical to the entry ID if those IDs will be displayed.

If the event has no active page (no conditions fulfilled) then the element will use the "unkown" default and not count the event.
If the event has an active page (no matter if that is because of no conditions or because the conditions have been fulfilled), then the element will use the event name as the displayed text in the element list and count the event for itself.
At the bottom of the list element, it will display the counter as "active event count/total event count" (this might become an optional display).


When any of the entries in the list element are selected, the plugin will update the main content element using the data from the corresponding map event.
If that map event is inactive, the main element will be emptied (or perhaps display the unknown default again).
If that map event has an active page, the content and event commands on the active page will be used to create the contents of the main journal element.


This last part has to be done by a modified copy of the game interpreter. Most event commands here would be useless and should be ignored, but a few need to be available, especially:
show picture to place a picture into the background of the main element
show scrolling text to place the text inside the main element (it doesn't need to scroll, but the texts here are usually longer and would not fit into a single show text

In case of logical event commands (conditional branch, control variable, jump to label) this would need to be tested - these options would help, but if they create too much lag then they can be ignored)
Event commands for map or battle should be removed or ignored as they don't have a purpose here - although sometimes game developers might have ideas for them like an arena list that asks to fight against the displayed enemy or a magic teleport list to the town listed and so on.


---------------------------
That is basically the structure I thought of. I don't have the time or javascript knowledge to implement it myself (at my university time, Pascal and C/C++ were the current languages and I even programmed in assembler, but javascript was developed later when I no longer programmed things).

This structure should work however and allow the developer to use regular methods like "control switch NPC XY met ON" or "control variable herb knowledge = 7" to show the different entries into the journal by controlling which pages of the events on the pseudo-maps are active. Up to using hidden items to trigger those conditions if you don't want to use up variales.
This would also allow changing entries by multipage events, like an NPC getting a nice description until the story variable is high enough to reveal that he was the traitor.

And as I wrote in another topic https://forums.rpgmakerweb.com/index.php?threads/rmmv-codex.105082/
this plugin is not intended for myself at the moment, but for the community.
I only ask whatever plugin writer makes this to include in the comments something like "idea by Andar" with a link to my profile here or something like that.