Hostile Worlds - Invasions - Customizing
This page is for customizing the existing invasion wave templates or creating your own.
Contents
- 1 Getting setup
- 2 Resetting files or updating CoroUtil
- 3 JSON Structure
- 4 Dynamic Local Difficulty
- 5 Workflow of making and testing invasions
- 6 Testing Tips
- 6.1 Enable helpfull debug output to diagnose potential problems in json
- 6.2 Live edit normal config options
- 6.3 Live reload data from the json files ingame
- 6.4 See difficulty of area
- 6.5 Print out a list of usable entities for invasions
- 6.6 Test spawn a random mob from a specific mob spawn template
- 6.7 Test how your mob spawn template looks parsed ingame
- 6.8 Simulate the choosing of a mob spawn template and print out the results
- 6.9 Force specific mob spawn template for invasion to be used
- 6.10 Reset dps calculations for 50 chunk area around you
- 7 Mob Grinders
Getting setup
You'll need a good text editor, for windows, notepad++ should do, but something that can do syntax checking would help make sure things are formatted correctly, and editor like IntelliJ IDEA can do this. If you just use notepad++ you can find out if anything went wrong reading your json file later.
- TIP: use https://jsonlint.com/ to make sure your json syntax is correct.
The first thing you'll need to do is run the game with coroutil and hw-invasions installed, this will generate the needed files in your minecraft config folder, you can leave the game open or close it at this point, doesn't matter. If you leave it open you can live edit and reload json files, to save from having to reload large modpacks.
The main file you will be working in is mob_spawns.json, once you have run the game, you can find it in config/CoroUtil/data/templates/actions/
Resetting files or updating CoroUtil
CoroUtil will overwrite the contents of config/CoroUtil/data/ every game run if:
- The folder is empty, or
- It detects zero file changes by comparing file contents against the info in filehashes.txt (leave this file alone or you might lose data)
If you make changes to the json files, you should be safe from having files overwritten.
This is to make sure any new mod updates has the latest json on the filesystem unless files have been manually edited.
For updating the mods when you have custom files I would recommend backing up your json files, deleting the data folder, then let the mod generate the new files, you could then paste your files back in and see if things work out ok ingame, if not, decide on how to merge in your changes.
JSON Structure
The default invasion setup is making use of 3 files: templates/action/mob_spawns.json, templates/cmods/invasions_cmods.json, and templates/conditions/invasions_stages.json.
Only mob_spawns.json is truely required, you can get away with using only it if you don't use templates at all, the default setup uses templates though, the other 2 files contain pre-made templates referenced in mob_spawns.json to keep down on the copying and pasting.
I would recommend copying bits from these files to create and customize your invasions.
mob_spawns.json
- Contains a list of potential spawn templates, defined in the "templates" list object
- Each spawn template can have a list of conditions required to use the spawn profile, defined in the "conditions" list object, this list is optional
- Each spawn template has a list of spawn profiles, defined in the "spawns" list object
- The spawn profile defines a lot of things
- What to spawn
- How it spawns
- How many spawn
- What cmods to give them
Have a look at mob_spawns_example_commented.json to see every piece explained.
Cmods
A Cmod is just short for the more corny term: Coro Modifier. They modify an entity in various ways, from things as simple as health to more complex things like preset AI routines.
To see an up to date list on every cmod possible, the file all_cmods.json will always be where to look for every single thing the cmod system supports, there is also lots of comments in the file to explain them as much as possible.
Conditions
A Condition is used to decide if a mob spawns profile can be used at the moment an invasion starts. You can define things like what wave number it should be used, what what difficulty, or for randomizing between various mob spawn profiles like the default spawn templates do.
To see an up to date list on every condition possible, look at all_conditions.json
Dynamic Local Difficulty
CoroUtil has a local dynamic difficulty systems that tries its best to figure out what stage of the game the player is at, so it can ramp up difficulty along with them.
Use of this system isn't actually required for invasions, but the default invasion setup uses it for scaling up inventory equipment, health, attack damage, speed, xp of mobs and also how many spawn in an invasion.
If you want to tweak the default way the difficulty is setup, pop open config/CoroUtil/DynamicDifficulty.cfg
Play with the configs prefixed with "difficulty_" or "weight" to change how much influence each type has on the average difficulty.
To test this live in game, you can instead use the /config command to change the values, then run /coroutil difficulty to see the reflected result for your player.
Workflow of making and testing invasions
First, do the "Enable helpfull debug" step in Testing Tips section below
If you want to find a new mob to use from a mod:
- /coroutil printEntities
Lets use minecraft:husk for a simple example.
Test a mob you found from the entities list:
- /summon minecraft:husk
- OR /coroutil spawn minecraft:husk
Didn't crash? great! If it did crash, its probably a modded mob and you can't use that mob :(
- TIP: open config/forge.cfg and set removeErroringEntities to true to save yourself from having to restart every entity crash while testing for ones that will work, be sure to read forges warning about using that setting in their config
- If you use this setting, the entity should just dissapear if it has an issue, which also means you can't use it in an invasion.
You can keep the game open and paused, we should never need to close it.
Open up mob_spawns.json in text editor. I will edit the first mob spawn template to use this mob The first spawn profile is the zombie miner, I will leave that one alone and go down to the second mob spawn profile, that one is the zombie soldier. In the "entities" list there should be 1 entry, "minecraft:zombie", lets change that to "minecraft:husk"
Save the file, then in minecraft, run:
- /coroutil reloadData
- Make sure everything went ok in the console, check for json parse errors and fix anything needed.
If you want, you can run:
- /coroutil testProfile invasion_stage_1
to see it print out the data for that template, you should see minecraft:husk used in there somewhere if it loaded in correctly.
To see if your mob spawns with the setup ok, you can run:
- /coroutil testSpawn invasion_stage_1
you might have to run it a few times, as it will randomly choose a mob, so it will either spawn a zombie miner or a husk soldier.
It should eventually spawn the husk soldier for you.
Everything should work at this point for a real invasion if all the above worked correctly.
To test an invasion, we can just set the time to when one should start.
- Make sure you are in the overworld, on the surface for best results (caves will work but will be harder to find them)
- /hw_invasions setPlayerTime 62000
- Need to fake a players playtime so an invasion will actually trigger now
- /time set 62000
- default config has first invasion on the 3rd night, that time sets it to the 3rd night, adjust the time value as needed for your own config
- Since we modified the first invasion that is designed to be the only one run as the first invasion, your mob should be in this one.
- If you want to test a specific invasion mob spawn template see section "Force specific mob spawn template" in Testing Tips then do the time command above.
You should get the invasion start message, look around for your husks, they should be there somewhere.
Switch to survival mode to make sure they are targetting you and pathfinding to you, they wont in creative.
If everything went well and you are satisfied, you can stop the invasion with:
- /time set 0
And kill off everything spawned with
- /kill @e[type=!Player]
And you're set! Start playing around and copying and pasting bits around and changing them up and retesting.
I tend to use this workflow for fastest testing:
- /hw_invasions setPlayerTime 62000
- Only need to run once per world
- Edit json and save
- /coroutil reloadData
- /time set 0
- /time set 62000
- Find mobs, make sure setup how you want
- Repeat all steps
Testing Tips
Enable helpfull debug output to diagnose potential problems in json
- in CoroUtil/General.cfg, set useLoggingDebug to true
You will be able to see if there were any syntax errors with your json file, and where the error was, if everything went ok it should look like this:
processing, detected as DifficultyData: ./config/CoroUtil/data/templates/actions/mob_spawns.json
[19:53:05] [main/INFO]: detected mob spawns to deserialize by detecting: mob_spawns
Live edit normal config options
- /config
Live reload data from the json files ingame
- /coroutil reloadData
See difficulty of area
- /coroutil difficulty
Print out a list of usable entities for invasions
- /coroutil printEntities
The printed entities SHOULD work, especially vanilla ones, but any modded entities you should always test, they could either not work, or worse, crash the game. A surprising amount of modded mobs like to crash the game if they aren't spawned in their own special way, that I cannot support without specifically accounting for them.
Entities that work best are ones that walk on the ground, flying entities still need better support, and may never work because vanilla minecraft doesn't have a good standard for flying entities that modded entities could use, so every mod out there probably implemented their own way.
Test spawn a random mob from a specific mob spawn template
- /coroutil testSpawn <TEMPLATENAME>
- eg: /coroutil testSpawn invasion_stage_1
Test how your mob spawn template looks parsed ingame
- /coroutil testProfile <TEMPLATENAME> <DIFFICULTY>
- eg: /coroutil testProfile invasion_stage_1
- test with difficulty in current position for player
- eg: /coroutil testProfile invasion_stage_1 0.5
- test with specific difficulty
Will print out everything the game knows about your json setup, good for making sure everything loaded in as you expect.
Simulate the choosing of a mob spawn template and print out the results
- /hw_invasions testInvasion <DIFFICULTY> <WAVE NUMBER>
- both <> are optional, but if you want to specify <WAVE NUMBER> you must specify <DIFFICULTY> so it knows which is which
- eg: /hw_invasions testInvasion 0.5 11
- Choose an invasion for difficulty 0.5 and wave count of 11
Will print out the invasion mob spawn profile it chose.
Force specific mob spawn template for invasion to be used
- in config/CoroUtil/General.cfg, set mobSpawnsWaveToForceUse to the name of your mob spawn template
- eg: invasion_stage_1 or invasion_stage_3_opt_10_illagers
Reset dps calculations for 50 chunk area around you
- /coroutil resetDPS
Probably not needed, but I've had issues with some situations causing super high DPS resulting in the difficulty being too high, mainly from mods. If you run into issues, use this, or disable DPS in the difficulty calculation, see Dynamic Local Difficulty wiki section for that.
Mob Grinders
Mob grinder blocks or features from other mods have the potential to cause very high dps values which will throw the difficulty of an area off. A way to blacklist specific damage sources is in the works, but for now, if you think you might have this issue, you can limit the dps rating to a reasonable max:
- In config/CoroUtil/General.cfg, Set enableAdvancedDeveloperConfigFiles to true
- Restart game
- In config/CoroUtil/Advanced.cfg, set difficulty_MaxDPSRatingAllowed to something lower than its default of 5, 1 is the theoretical vanilla max, so something like 2 might do.