When messing around with the editor, I looked at the file format and started to wonder whether there aren't more options than what the editor provides. And there are, although a little hacky. Some of those were already mentioned by others (e.g. the few player-made missions where you fight Liv, who is not normally placeable). But I think I found more, although it makes the job of making levels much harder, as the editor doesn't preserve them when resaving. However, I've tested that it is still possible to upload these (both of the items I uploaded use these, at least on 2024-09-12-2-Barberry). The capabilities that are possible with this are:

• Enabling all perks of a character
  
• Changing unit allegiances
  
• Units starting with Unsteady, Sedated and more

Since we are venturing into undocumented and unsupported territory, we should acknowledge, that any use of these techniques might end up being broken by some future patch (possibly intentionally or even unintentionally). Anyone, that uses them, should expect that they might stop working (or it might cause the levels to be unloadable entirely). I would also recommend putting this similar warning to any mission where you would use these if having them function is required for the mission to be playable.

Also, everything I write here comes just from my exploration of the functionality and it is possible I missed some options or interactions. Imagine any absolute statements about how things are or aren't to be surrounded by plenty of "maybes", "seems" and "I thinks", which are excluded to streamline the text of this post (which is already taking me too long to compose).

And if any developer ends up reading this and not being happy about it, I understand that you might not like this and I will take it down (or just remove this post yourself, which I presume you can). Although it would be nice to have some of these (the ones that do not break the game too much) officially supported by the editor, since the game already supports some way to read them from level file.


Each level is a separate .lvl file in a folder named after the mission (= level pack) in:
Inside these .lvl files are several named "elements" with name-value properties on separate lines wrapped in opening and closing "tags" (the structure looks HTML/XML-like at first glance, so I use that terminology, even though it is not that format at all). For example, at the start of each level is an element that looks like this:
Later down the file are also "elements" for every floor tile, wall tile, unit or other objects. For example, this is the code for Rion:
Anything after # is just a comment and is ignored.
Some properties are "lists" that can hold multiple values and uses a syntax with square brackets, e.g. the list of objectives:

The campaing mission files are also accessible and are in:
We can already open these mission in the editor and clone them, but not everything survives and taking a look into the actual files is useful for figuring out how some things are done. Most of the objects that you can find only there however do not work in editor. There is already a post from DemoCorn that touches on some of these limitations.
(If you are feeling adventurous, it is possible to edit the campaign missions and then launch them from the campaing mission/dream select. You can even add levels and components that are prohibited in editor do work. You however cannot use the editor for that. Also, you won't be able to post these to Workshop, as the levels downloaded from it have the same restrictions as the editor. The only option would then be to instruct players to tamper with their game files as well... which seems like a bad idea.)

But the source for all the new capabilities I wish to describe here is from the following: When playing a level, specifically after making any action, the game creates a new file "Move state X.gsf" or "Turn state X.gsf" in:
Specifically, it looks like the serialization of the state of the game before the action happened. It might be how the rewind buffer is implemented or it is there for reporting purposes, not really sure. But the point is that these serialized game states use the same format as the levels, but there are a lot more properties for the different objects than what is exposed by editor or campaign levels. A lot of these properties don't work when used in the level directly (health, mana, actionPoints, stability), but there are others that do (perk, Condition, allegiance). The manipulation that this post describes is using these propeties on objects in the level file format. And these properties are the ones that editor removes on any save (most likely because when serializing the level, it is not allowed to output them).
(I didn't really try all the properties, so there might still be some room for exploration, although based on the names, there is a lot properties that affect campaign progression, achievement tracking or they encode some internal state, e.g. "artPrefabName". Even with the properties I did mess around with, I managed to get the game into some invalid states where the game half-loaded a level. I think I might have crashed the game too. So proceed with caution... and don't report such bugs/crashes to devs, they are your faults... and mine I guess, but mostly yours.)


Just for completeness, I will mention the few changes I found useful when taking inspiration from the mission files only. All of these are retained when saving the file from an editor:

• Tips - a list of lines that are shown as tips in the ESC menu; pretty much the only place where you can have a piece of custom text shown to the player besides the mission description, although it's pretty hidden
  
• LevelManager->disableAutoWall - can be used to make levels that are not surrounded by walls or when you want to mix a corridor floor tile in the middle of a level without a wall around it; you will however have to your own walls (or Anti-Walls) everywhere
  
• LevelManager->ignoreActionsDifficulty and LevelManager->ignoreReinforcementDifficulty - for puzzle-esque levels where you need to have a predictable setup; unfortunately, there is no way to counteract the bonus health option
  
• Enemy door can spawn units that are not allowed when placed directly (mostly just useful to spawn Liv)

Everything that we will be doing here is adding additional name-value properties to the objects in a level. Any manual change of this kind gets removed after opening and saving the file in the in-game editor. Just opening and launching the file works fine. You can also make a change in a level that is currently loaded and your changes will be loaded after pressing "Restart level".

The perks that are selected for a specific hero are serialized as a list of "perk[]" values on the unit itself. And when you include them in the level directly, they do apply to the unit. The game doesn't really expect that and if the player doesn't have the perk enabled, there are parts of the UI that do not correctly reflect, that the unit has the perk. You also do not get to reallocate the perk points if you have the perk already. And I found no way to disable a perk...
Because of that, I always ended up just enabling all perks for all the characters, since the player would most likely be able to do that anyway if I ended up enabling a bunch of them. And since the UI might already be confusing for the player, as they will almost certainly have no idea what is happening, it is beter to just do the optimal choice for them automatically.

The following are the complete perk lists for all 5 characters:
Also, in case you would want the final innate perk for Zan (+3 knockback), put this in the LevelManager element:
(Unfortunately, the singleLevelPerk property cannot be used to enable the other perks. This is also the only change out of these that is retained when re-saving in editor.)

Because the perk list is specified for the unit specifically, if you have multiples of the same wizard, you have to repeat the same list for both. Or not, if you would want to them to behave differently... I haven't found a use case for that.

Note that when you look at the perks, there are perks that use the naming convention "Unlock{ability}". That seems to be how the game implements that Zan and Jen do not start with all of their abilities unlocked in the first campaign levels. I was initially ignoring them, but it is necessary to include them for some of the other perks to work correctly. Specifically, in my case it was Banks's Spectral Skull damage upgrade (GhostSkullDamage) that was not being applied unless UnlockGhostShot was present earlier in the list. I am not really sure why. As mentioned, I just ended up unlocking all perks so I didn't explore this further...


There are three teams/allegiances in the game:

• NonCombatant - anything that is not meant to attack, most commonly seen with disabled turrets (and Rion in dog-form)
  
• Wizards - your team and any allies you may have (e.g. friendly Traffic Warlock)
  
• Enemies - any enemy

And it is possible to alter the allegiance of a unit in a file by specifying one of these values like this:
Changing enemies into allies works fairly well and should be the most common use-case. You can even make a friendly medic or a friendly Shepherd (he protects anyone that shares his allegiance).

Changing the allegiance of wizards kind of works (except for Rion for some reason), but the game is not expecting that -- even though a wizard is an enemy, they are still controlled by the player and abilities may or may not consider the altered teammates (or the new allies of those teammates) as allies or enemies. Enemy wizards are also not considered as enemies for the purpose of the "Knock out all Enemies" objective. Generally, it felt like it is necessary to test each interaction to see how it works, which is not really a good thing to use in a level.

The third neutral allegiance NonCombatant turns out to have some non-intuitive behaviour. The main property of this group is that any unit of that allegiance is not considered hostile by the other groups and is thus not targeted by AI. But it doesn't actually stop the unit from engaging in combat, so if you just take a unit that normally attacks you and change it to NonCombatant, it will look friendly but will still attack you... but it will attack units with allegiance=Enemies as well. You can also have wizards with allegiance=NonCombatant, which leads to less perceived inconsistencies than when using Enemies, although it might still be confusing (as there is no indication for the player to see the difference).

If you take a level and change all enemies to NonCombatant, they will still be hostile towards the team, but it gives wizards the ability to move arbitrarily within one turn, because (technically) there are no enemies.

Unfortunately, because the units that spawn from doors do not have a corresponding "element" and are mentioned only by name, it is not possible to adjust allegiance of spawning unit in a user-level (which is likely why official missions use something called Allegiance Switcher instead).

When messing around with different values, it turns out that it is possible to set the allegiance using numbers as well (0=NonCombatant, 1=Wizards, 2=Enemies), so I tried to use other numbers as well... and it does work, but only until you Rewind for the first time, at which point it reverts to the original allegiance. So I would advise against using that.

(Continued in next post...)