AI War 2:Journal Entries

Hey!

The content that used to be on this page has moved to " Custom Text Messages To The Player", as that's really a less-formal and chat-embedded type of journal entry. It also requires some custom coding. That was the only way to do things prior to us adding in the actual codified journal entries with their dedicated sidebar, etc.

Thew New Style Of Journal Entries

These were introduced in version 2.03x of the game.

Creating New Journal Entries

So, you want to write journal entry or five? Depending on your goals and how you want these to appear, there are various ways you can call them. But no matter what, the basics of how you create one is always the same. That's what we will cover here, field by field:

unique_id

This is a series of ASCII characters (a string), and it's the one thing stored in savegames. This entry is longer than most, but please read it.

• Uniqueness:
  • This really does need to be unique!
  • If you give your entry an obvious ID like unique_id="GolemFound", then it's a pretty good bet that somebody else will do that also at some point.
  • If you're a modder, then generic IDs are a really great way to wind up with lots of errors when people try to load your mod and someone else's at the same time.
  • Putting your initials or handle is certainly a good way to make it truly unique: CMP_x4000_FirstTime_HiveGolemName would be an example of something that someone else is unlikely to EVER accidentally reuse.

• Brevity:
  • "CMP_x4000_FirstTime_HiveGolem" is fine from a uniqueness standpoint, but at 29 characters it's awful from a brevity standpoint.
  • Each character in the name is saved into the savegame, raw, at a rate of 1 byte per character.
  • How many journal entries will we really be saving? Probably not that many, compared to something like ships. But let's be reasonable everywhere we can.
  • Adopting something much more brief like "CMP4_1st_HiveGol" is 16 characters, but just as readable to me, and just as likely to be unique.

Striking a balance is a good idea. "CP4FirHivGo" is even more brief, and still likely unique, but incomprehensible.

optional_group_id

You don't have to include this at all.

• Purpose: Sometimes you will want to have "one at random out of a group of possible entries" logged to the game, and this lets you do that.
  • All of the entries that are in the group need to have a matching ID, so for instance putting four entries into "HiveGolemAppears" would work just fine.

• Mitigating Factors: These are NOT saved in savegames, so don't need to be particularly brief.
  • These do need to be somewhat unique, in the sense that if your mod has a really generic event name in it like "FighterDiscovered" may or may not clash with someone else's mod who has an event they name the same thing.
  • If you and another mod both come up with the same name, it won't be a problem per-se, no errors will be thrown, but when you say "show one of the FighterDiscovered entries," you'd potentially get one from the other mod and not yours.

unique_id_of_alternate_if_id_already_recorded

You don't have to include this at all.

• Purpose: If you are NOT using group_ids, this is another way to have something progressive happen when normally it would try to log the same entry multiple times.
  • Each journal entry will only be entered once per campaign, normally.
    • So if for instance there was a nice big entry that you had for when you first find Hive Golems, and you find three hive golems... only the first one would log anything at all.
    • This might be absolutely A-OK and something you are happy with, especially if it is written in a bestiary-style fashion.
  • However, if you've already found (for instance) the first hive golem, but you still want it to say something else for each further one you find, you could use unique_id_of_alternate_if_id_already_recorded="AnotherHiveGolemFound" to point it to an entry that is just something like "hey, there's another one!"

can_record_another_copy_if_already_recorded_in_this_campaign =

You don't have to include this at all. It defaults to false.

• Purpose: If you want something to happen EVERY time some event happens, then this is how you'd set that up.
  • Most commonly you would pair this with unique_id_of_alternate_if_id_already_recorded and have the first one be longer, and then the second one (for example "AnotherHiveGolemFound") be a lot more brief.

It's really worth stating that the Journal is supposed to be interesting, and not a full list of capturables (that's what Intel is for! And Intel is far more informative and actually links to specific planets and entities when you click on them, etc). Intel also lets you control the priority of things you remember, and link over to the map, etc. It's the planner's tool. The journal is... flavor and background.

Filling up the journal with a bunch of entries like "we found another hive golem" sounds incredibly banal and cluttered, so we'd heartily suggest avoiding it. There's a good chance that there's no reason to use unique_id_of_alternate_if_id_already_recorded or can_record_another_copy_if_already_recorded_in_this_campaign, but we prefer to make flexible systems especially since you never know how a modder might use things.

But a general rule of thumb is that if you give the player 1000 journal entries in a campaign, and dozens of them are basic duplicates, that journal tab is going to be laggy, irritating to thumb through, and generally something people find overwhelming to even open. Fewer entries that are more substantial is by far preferred.