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 - Core Bits

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

Required field.

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.

sidebar_text

Required field. Rich text is supported.

This is the text that appears in the sidebar, on the journals tab, so that you can tell one entry from the next. The timestamp and everything like that is automated, but you have a bit of space where you might write something brief but intelligible like "Hive Golem" or "Hive Golem Discovered" or whatever fits and makes the most sense. Being brief is probably better if you are going for consistency, since some unit names can be incredibly lengthy.

This is just text that we use for display -- it isn't stored in the savegame, so it can be as long as comfortably fits in the sidebar.

full_text

Required field. Rich text is supported.

This is the text that appears in the popup window after you click the sidebar entry. This can be pages and pages long, if you want. From a practical sense it is probably good idea if you keep it to something like a few thousand words, but you won't hurt game performance or savegame size or anything like that if it is very long. You'll just potentially wear out your reader. None of this gets stored in the savegame or transmitted over the network, so that's helpful.

chat_text

Optional field -- but frequently recommended. Rich text is supported.

This is text that appears on the right-hand side of the screen (and chat log) when the journal entry appears. Essentially it is working like this -- Custom Text Messages To The Player -- but without you having to do any custom code.

A little text entry saying you've found a new journal entry or what it is can be a great thing to go through chat, no question. So using this is often a good idea. But the length here DOES matter. For one thing, it gets saved into savegames until the chat log is long enough to push it out, and so that makes savegames larger if it is silly-long. Also, since this pops up on the screen during gameplay, if it is too long then it is very invasive and screen-blocking anyhow.

Please save most of your length for the actual full text! This is just a chat note, thematic or otherwise, to let people know a new journal entry has been logged. They may well not otherwise notice it, so it really is a very good idea to do.

Creating New Journal Entries - Extended Bits

You really don't have to use any of these, and in some respects it may even be better if you don't! But they provide flexibility for mods in particular to have very different styles of journals from what we envision with the main game.

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.