In the Chinese mod community, it is a common practice to use items as judgment criteria. For example, in 月影 mod, the panel is opened by smashing specific items, and the item is re-added when the panel is closed, which actually turns the item into a button to open the panel (its improved version is to open the panel by canceling the quest in Scourge). In 智械觉醒 mod, several specific items are used to represent the relations of different factions.

Based on our understanding of the characteristics of the game, we can easily realize that the relation of characters is a better data storage method than items. Compared with items, its main advantage is that it can store negative numbers (in fact, items can also, you need two different items to store positive and negative numbers respectively, and use a cyclic Quest to offset them when both exist at the same time, but it’s still very troublesome), directly set to a specific value, and most importantly, it is hidden enough.

Based on the relations of characters, you can design comparators, adders and subtractors between two characters. Of course, this is quite troublesome as you may not necessarily do so, and a major drawback is that the character's relation ranges from -100 to 100, while using items to store data is almost unlimited.

In fact, the biggest function of this trick is to pass data between two different quests.

Here are some examples:

In Scourge, the "sector management" function is implemented through factional quests. You may think this is impossible because when you click a button to obtain a quest, a new quest is always generated. But through a data system based on character relations, this can be achieved.

Firstly, we will call the initial faction quest Quest A. When Quest A is triggered, if the player chooses to "build a zone", it will generate Quest B (which is not a single, but a range of Quests). We know that a sector can build many zones, each corresponding to a type of Quest B. Let's call them Quest B1, Quest B2,...... Next, we assume that the player has built a commercial zone in the first zone, and Quest A will modify the character relations corresponding to the "first zone"(let's call it X), while Quest B1 reads X and jumps to a node corresponding to the commercial zone. Then the player left the galaxy.

When the player returns to this galaxy, Quest B1 will be activated and another character relations Y will be modified. When the player opens another Quest A, it will read Y and know that the player has built a commercial zone in the first zone of this sector. This completes the function we want.

Another example is the trade function, which is implemented through several sets of different relation data. The first group is the global data, each of which records the amount of a resource sold or purchased. A quest generated once a day allows players to deduct or obtain corresponding resources by reading these data. Another set of data is temporary data. When the player opens the panel to modify the trade plan, the global data is read into the temporary data, and the player's modification will only change the temporary data. Temporary data is only read into global data when trade is passed.