Advice on per-player files on a quest plugin?

Hi! I’m currently making a custom RPG quest plugin for my server, and I’m planning to use text files to store “Flags” on each player (short strings like “CompletedQuestX” or “TalkedToNPCBob”), with each player having their own file with as many as hundreds of flags in each one. However, I’m trying to decide on how specifically to implement the function for boolean hasFlag(Player p, String flag). Option 1 would be to load the flags from that player’s file to RAM every time, search for that flag and close it afterwards. Option 2 would be to load the files for each player whenever they log on onto the server to RAM and update their file whenever the server shuts down.

The way I see it each option has its own upsides, but I can’t decide.

Option 1:

  • Less taxing on RAM
  • Much safer if the server accidentally shuts down

Option 2:

  • Less CPU and storage intensive (less IOPS!)
  • Allows me to more easily edit flags in runtime for debugging.

What do y’all think?

How about loading a player’s data into memory once they join and if the data is written to, push those changes to disk; when a player logs off their data in memory can be released.

Most times you need a players data, it will only be read, so you’re saving IO and not compromising data integrity.

1 Like

That’s actually a great idea! tysm!

1 Like

How about this…
You make a enum class for all flags
and store as enum instead of string in ram, enum is not gonna eat up your ram plus. it’s easy to debug

hasFlag(Player p, RPGFlag.FIRST_QUEST_DONE)

when you write to file you just write full name of enum
RPGFlag flag = RPGFlag.FIRST_QUEST_DONE;
flag.name() <-- you get name of enum

To restore it back to enum
RPGFlag.valueOf(“FIRST_QUEST_DONE”);

And don’t forget to save flag after you change something fo flags file, in case of server crash. no data will be lost, saving config every x second is bad idea so don’t it :slight_smile:

1 Like

Using an enum (in java an enum is just a special class) or a strings both require a very similar amount of memory.

This stackoverflow answer explains how an enum looks to the JRE, as a normal class.

That this code (lifted from the answer):

public enum Constants {
  ONE,
  TWO,
  THREE;
}

is this, once it has been compiled (and that bytecode has been decompiled back to java):

public final class Constants extends java.lang.Enum{
  public static final Constants ONE;
  public static final Constants TWO;
  public static final Constants THREE;
  public static Constants[] values();
  public static Constants valueOf(java.lang.String);
  static {};
}

That said, an enum with members or a class with constant (static final) string fields for all of the flags, it’s just personal/team preference.

It may be nicer, for organization, to have a class for “missions”; “missions” would be groups of their objectives/flags. Players could have completed or in-progress missions saved to their file.