Q: "Text ID# Shift Mechanics" *SOLVED*

[Shademp]

I had long assumed that removing or adding new text entries into the FFVII fields would cause text to be triggered at the wrong instances, as I figured that the game's scenes will not adjust which Text ID# it calls for. I thought this was at the very heart as to why so many unused text entries exist; because deleting them would require fixing up all the text calls.

However some experimentation in Makou Reactor 1.4.1 has made me confused. The program only claims that problems will arise if I delete a text entry that is USED. Adding new text entries or deleting unused ones led to no objections, neither when I did it in Makou Reactor or tried out the effects in a modded game.

I can ask Myst6re if this "Text Call Adjustment" for scenes is something he added himself or not, but I'm also looking for general info and knowledge regarding Text ID# mechanics. Is the problem of shifted text identification numbers an underlying cause for the high amount of unused text found in video games...or is it not? =/

[luksy]

All the id is is an offset into a table of 2 byte offsets, and the table itself is pointed to by an offset at the start of the field file.

The game has no way of knowing in advance what the id points to, or if it's even valid at all. Case in point, life and life2 set the field name to a bunch of gibberish (which is actually the start of an akao block) because somebody either forgot to remove the field name function (you can't access the menu anyway), or forgot to add a text entry for it.

Most of the unused text (like that in the various blin* fields) looks like either a debugging artifact given the repetition, or simple laziness.

[Shademp]

The game has no way of knowing in advance what the id points to, or if it's even valid at all.

I guess it all boils down to one simple question that I need answered:
Could the developers of FFVII have deleted all the unused text entries without having to adjust the Text ID# called for in the scenes of those fields?

On one hand it sounds to me like they did not delete the text entries so to avoid the Text ID# shift problem, on the other hand deleting unused text entries in Makou Reactor causes no trouble.
The answer to this question is important for the commentary in the next Unused Text article that I am about to publish.

[luksy]

Could the developers of FFVII have deleted all the unused text entries without having to adjust the Text ID# called for in the scenes of those fields?

As long as the offsets that are actually used in the text table are adjusted accordingly, it's safe to delete the unused text without modifying the ids in the script because they cannot possibly be called by the script.

Makou avoids the issue when deleting by adjusting the text IDs.

[Shademp]

Do we have any way to know if the developers used software that adjusted the Text IDs accordingly, when text entries were deleted?

Or is it all speculation if they avoided deleting text entries (even unused ones) so to avoid having to adjust the called text entries manually, one by one?

[luksy]

Do we have any way to know if the developers used software that adjusted the Text IDs accordingly, when text entries were deleted?

Although I seriously doubt the script and text editing was done by hand, it's possible that there was no link made in software between the text IDs and the actual table, which may have encouraged the developers to just leave stuff in instead of wading through and changing a bunch of IDs.

Then again it's also possible that the text left in is a combination of debugging text, and events that were disabled at the last minute / unfinished with the intention of eventually reinserting them at some point, who knows.

[Shademp]

Ok, that confirms to me at least that we don't know for certain either way if the called text entries were adjusted etc.

But there are two other items of interest. We already know from the messed up kanji in the fields ONNA_1, ONNA_6, BLACKBGA, WHITEBG1 (and JUNBIN21 in the original JP release) that when additional kanji were added to the kanji table, this shifted the symbol identification numbers which led to the aforementioned fields displaying the wrong text. That much we are on the clear.

The second item, which causes me some wonder though, are the Field IDs. As most of us here know (I think), the fields are generally ordered in a way that represents the progression through the game from beginning to end. However, after Field ID#768 (LASTMAP), random fields are added.

769 - fallp
770 - m_endo
771 - hill2
772 - bonevil2
773 - junone22
774 - rckt32
775 - jtemplc
776 - fship_26
777 - las4_42
778 - tunnel_6
779 - md8_52
780 - sininb34
781 - md7st33
782 - midgal
783 - sininb35
784 - nivgate4
785 - sininb36
786 - ztruck

Fields from throughout the game, with the ID numbers 780-786 representing the scenes that were added after the original Japanese release. I have always figured that these fields were given high numbers, rather than being placed in the "group" where they belong, so to not shift the Field IDs and thus avoid erroneous map jump commands.

Do we have anything to support this notion that an added Field in the middle of the list would cause faulty map jumps, due to these (presumably) not being automatically adjusted in the script?

[luksy]

It absolutely would cause problems if the IDs weren't updated, because when map jumps in the script and exit points are used in the field, the ID is used.