JAS Part 4 - ProjectZulu/JustAnotherSpawner GitHub Wiki
Entity Handlers
First, EntityHandler (EH for short) is not a file, its a folder full of files (cfg files of course). Each mod that has mobs gets to have space in the EH folder. BUT WAIT! in order for the mods to get space in the EH folder A WORLD MUST BE LOADED FIRST, before this there is no EH folder (makes sense yes?). As we have discussed already, there is a file called SaveConfigGson.cfg located in .minecraft>config>JustAnotherSpawner>WorldSettings>BASIC which defines whether or not there is a separate cfg file for each and every mob mod or just one cfg file with all the mobs in one place.
The line "Use_Universal_Entity_CFG": false....asks "should we use a single file for all mobs ?" false of course means no, use one for each mod (or in the case of Lycancites, use like 20). If set to true, it will create a file called Universal.cfg with all mobs in that single cfg. It will also create a Universal.cfg file in the SpawnListEntries Folder for the SLE's as well.
LH fields in JAS's configuration files are ways to complement, or override default mob spawning behavior and introduce your own behavior. Some mods give more controls than others.
While the folder is called EntityHandler, the files themselves and the data contained therein is referred to the entities LivingHandler's (or LH for short). An entity's default behavior (its LivingHandler) is basically: whatever the original author decided. Most of the vanilla Minecraft entity spawning behaviors are documented in the Minecraft wiki (check individual mob pages), but if you're dealing with mods you will need to refer to that mods forums/documentation to determine behaviors. You can also ask questions and use Google to figure out how the author intended their creatures to behave.
Trying to figure out a mobs behavior can be frustrating at times as the behavior doesn't always follow any obvious logical pattern; in some cases, no one really knows how a mob is supposed to spawn or behave. That information is no longer necessary as JAS lets us bypass existing LivingHandlers completely and make needed or desired adjustments.
Newly-generated configurations have no LivingHandler overrides, and each mob's definition will contain the following basic properties (albeit with different values):
"arcticmobs.reiver": {
"Type-Enabled": "MONSTER-true",
"Contents": [
"arcticmobs.reiver"
]
}
In addition to the "Type-Enabled" and "Contents", which must always be present, JAS lets us define additional properties for an entity's spawning behavior.
Each LivingHandler property is a string containing an MVEL expression. See examples further below, or check the MVEL reference for more info. By default, JAS operates on the principle that events are allowed to happen unless certain restrictions apply. Each condition can be negated by using the not operator: !
Well, our newest buddy Pistol Pete need not be too worried as he is the only type of Pigboy pig out there. The word Pig after "contents" is what actually calls the pig entity. The first one "Pigboy" which was simply "pig" before is what we decided it should be called. This is an easy way to create multiple instances of pig that can belong to other groups so JAS can treat multiple groups of pigs differently.
"Pigboy": {
"Type-Enabled": "EDIBLE-true",
"Spawn Operand": "OR",
"Spawn Tag": "obj.light<7",
"Despawn Tags": "block({'fence','nether_brick_fence'},{8,1,8},{0,0,0})",
"InstantDespawn Tags": "(obj.light>7)||(obj.torchlight>6)||(obj.playersInRange(1,6)>0)",
"Entity Cap": 20,
"Contents": [
"Pig"
]
}
- "Pigboy" we created a new pig entity called pigboy, which is one method of allowing an entity to belong to more than one group without causing conflicts with spawning. In most cases "pig" which is between the brackets following the "contents" would exist where we have typed "Pigboy". This line is actually what JAS is going to use to refer to the entity as long as we have the word "true" after "Type-Enabled". We could create more copies of "pig" and assign them to other groups by changing the line "Pigboy" to something else.
- Type-Enabled adds this entity to the EDIBLE group (the 'true' is necessary to let JAS control it).
- Using "OR" as a spawn operand means "Tell JAS to override all of Minecraft's default spawning behavior regarding pigs."
- Here, the Spawn Tag indicates pigs should spawn whenever they can, except when the light level is below 7 (vanilla Minecraft usually spawns pigs at level 9 or above).
- The Despawn Tags specify that all pigs should despawn whenever they're checked for it, unless a wooden fence/nether block fence is located within 8 blocks of their front/back/sides. Also checks if there's a fence 1 block above/below it: helps prevent pigs from despawning when they jump around or climb/descend a level.
- The InstantDespawn condition will only be checked if the pig is away from a fence, in the wild for example. It lets the pig despawn immediately when checked, unless the ambient light level (outdoors) is above 7, or unless torchlight is above 6 (useful for indoor farms), or unless there's a player within 1-6 blocks (useful when leading a pig back home at night).
- The EntityCap means no more than ~20 pigs total will be allowed within all chunks loaded in memory. (The actual number can be slightly more or less depending on other game variables.)
- Contents is actually referring to the actual mob. While it is at the end it really says that all the commands given between the {} belong to the entity within the [] which follows the CONTENTS keyword. so the title "Pigboy" we assigned in the front is saying take the "pig" entity and make a copy now called "pigboy", which we could use to make other copies and assign them to other groups if we desired. This would allow us to use "Pig" with other groups or custom groups. Every entity has a CONTENTS section that refers to the actual mob, they also have a name before the {} which the CONTENTS command will be referred to by JAS in spawning. This can be useful if we want to use an entity in different BIOMES but want to set special attributes for that mob but only in particular BIOMES. we could want them to spawn in different light conditions or possible in different quantities. We would do this by making a new "copy" of the mob. If you simply take a mob and assign it to multiple groups, JAS does not know which mob belongs to which group so if one group calls for 100 and it spawns 100 and the next group calls for 20, it will destroy 80.
##Spawn List Entries
Now we get our buddies together and we slide into the SpawnListEntries folder. Once again we either have a bunch of individual cfg files or one called Universal.cfg.
These files contain data on what biomes an entity can spawn in, the weighting and certain tags that can be added.
"BEACH": { <---the biome is BEACH
"EDIBLE": { <----our group called EDIBLE
"COW": { <-----mob cow
"Weight-PassivePackMax-ChunkPackMin-ChunkPackMax": "30-4-1-1"
},
"Pigboy": { <-----mob pigboy
"Weight-PassivePackMax-ChunkPackMin-ChunkPackMax": "70-4-1-1"
}
We should have no trouble identifying the biome, creaturetype, or the mobs. the long line might have a few odd things in it.
Weight - This corresponds to the first number set in each series. e.g. for cow it would be the 30, for pigboy it would be 70. This number is added for each and every member of the group, which is only two mobs and so convenient the total come to exactly 100. these numbers are added and each number is divided against the grand total to come up with a percent. For cow 30/100 =.3 or 30%, while pigboy would come out to 70%. this is a rough estimate that translates to. the cow will be ABOUT 30% of the spawns and pigboy ABOUT 70%. they are not exact but rough so cow could be 25 to 35 % for example.
PassivePackMax - Just like it sounds the Max a PACK can be under Passive spawning
ChunkPackMin - The Minimum Pack size during CHUNK spawning
ChunkPackMax - The Maximum Pack Size during CHUNK spawning
and now we can slide our buddies over to JAS Advanced and really start showing some command elements and how much they can do.
##Mob Spamming