JAS v0.9.0: SpawnListEntry Tags

There were two goals when designing v0.9. One was to improve the useability, reducing the certain unnecessarily complex parts of JAS to make them more plug-n-play. The second was spawnlist entries to allow unprecedented customization settings for users worlds.

Useability Improvements

A fair number of improvements were introduced into making JAS more user friendly. First and foremost was attempting to improve the ability to plug-n-play. The first improvement was settings the vanilla spawnlists to be cleared by default, rendering the vanilla system automatically disabled by installing JAS. The required the improvement of the importing and now vanilla settings are always imported properly, even with the vanilla spawnlist being cleared. Next was to make all entities set to spawn by default. They still need a spawnweight >0 and a type that is not NONE.

Also in the useability is the ability to combine all entities into a single universal CFG. The option is inside the SaveConfig.cfg, along with the SortByBiome option (this inherits its default setting from the global toggle but can be set world specific). The toggle of both options were improved such that it reads from the settings it was saved as. Such that saving as Universal then switching to mod specific will read the settings from Universal, delete itself, then create the mod specific files.

Spawn Lise Entry Tags

Tags can now be added to spawnlist entries identically to livinghandler. Tough a few tags are different. Valid tags are spawn, light, block, blockRange, blockFoot, spawnRange, sky, minSpawnHeight, maxSpawnHeight, liquid, opaque, normal, solidSide, difficulty, torchLight, ground, top, fill, modspawn, origin, players, entities, random, writenbt.

WriteNBT Tags

Another long promised feature. Valid for SpawnList and LivingHandler spawn parent tags. The format is fairly straightforward. After the usual ':writeNBT,' a comma separates each nbt operation. Each operation is int the format of 'targetTag/targetTagID/value'. See http://www.minecraftwiki.net/wiki/NBT_format for valid tag IDs. It helps to think of it as folders, telling the system to dig down until you find the tag you want to set and then providing a value. Container tags (TAG_Compound and TAG_List) do not have values, they merely move you along the hierarchy. The operations are get or set; meaning if a tag is called that does not exist, it is created.

The name of tags are case sensitive. To figure out what tags you need an NBT editor is recommended. The Project Zulu limited mob spawner allows you to explore the NBT tree graphically and test adding/removing tags to see their effects.

Value tags are typically just one value, setting a short would be done like 'id/2/30'. For arrays such as byte array, keep including values for as long as you want the array to be; i.e. 'myArray/7/20/30/40/2/254'. As you may have noticed already, all tags fetch using name (with one exception). Thus the first value is a string of the name. The exception is TAG_List, which uses an index instead.

Example, make an entity hold glass block in hand. ":writenbt,Equipment/9,0/10,id/2/20,Damage/2/0,Count/1/1".

Biome Attributes

Biome Attributes are an interesting addition to biome groups. Functionally, they are identical with the exception that they do not show up in your entity CFG reducing clutter. By default there is an attribute group for each entry in the biome dictionary and on representing all biomes. They can be added to biome groups in the same way biome mappings are, with the exception that they must be prefixed by an A|.

An additional feature introduced with attributes is the ability to add and subtract them and mappings by placing a '+' or '-' in front of their names. They are parsed left to right. Biomes cannot be added twice, and will simply 'overwrite' the other if tried.
Read more ...

JAS v0.8.0: BiomeGroups Revisited

This new version of JAS brings a Biomegroup cleanup. This makes them significantly more stable when adding/removing biome mods and hopefully makes them more use friendly. It was unfortunately not possible to make it backwards compatible with previous versions.

The World save configuration style was abandoned. Now instead of fighting between a world and master save folder there is only one user configurable save folder where changes need to be made.

Finally a few new tags were added; modSpawn, players, origin. ModSpawn calls the regular entity getCanSpawnHere method: allowing users to easily add additional considerations to how entities would regularly spawn. Players allows evaluating the number of players within a certain range. Origin is a range tag that evaluates based on the distance from the world spawn.


BiomeGroup files prior to v0.8.0 are no longer valid. The groups themselves can be with minor changes.

The referencebiomes list is gone, replaced with packagenamemappings. Allowing you to map the complex packages names to a shorter version. Instead of writing "net.minecraft.world.biome.BiomeGenBeach.Beach" you can write "Beach". The mapped name can be changed to any valid string, duplicated are ignored. They are case sensitive.

The allgroups property is gone and replaced with customgroups. The main change is that the default biomegroups (1 for each unique biome name) are always created. They can still be disabled by removing all biomes from the group; any group with no biomes will not be declared and will not show up in the entity CFGs.

World Save Configurations

The World-Master configuration pattern is abandoned. Instead the SaveConfig.cfg in WorldSettings contains a Save_Name property for each world which controls where it looks for and saves settings. Defaults to world name, allowing for backwards complete compatability. Multiple worlds can use one folder by setting the save nam eto the same.

There is also an import name option, which is used only when the Save_Name folder is missing. It will COPY the files from the import name to the Save_Name folder. This pattern should be more user friendly. Deleteing the Save_Name folder causing an import, deleting the contents allows them to be generated fresh.


There were a few new tags and tweaks to old ones. The ModSpawn tag which is only valid for the livinghandler spawn parent tag. It calls the default entity spawn method. It is, as is normal of new tags now, both chainable and invertable. Format is simply ':modspawn'.

The second tag added was the Players tag. Searchs for a number of players within a certain range. Both min and max search range and number of players are settable. Format is ':player,minSearch,maxSearch,min#,max#'.

Light and Torchlight tags are now invertable.

The last new tag is the Origin tag. This is a range tag in the same vein as light or torchlight.The difference is that it checks the distance from the entity to the spawn point instead of the light level. It is both invertible and chain-able. Format ':origin,minDistance,maxDistance'.

Along with the origin tag some improvements were added to the light and torchlight tags. They are now invertible. And an issue in the range colculation for cases where min was greater than max was fixed. The ranges are now as follows:
When max>min, range is min->max.
When min>max, range is max->+INF & -INF->min.


JAS now requests FML to load it after everything. This should resolve issues with JAS not clearing certain mods spawnlists.

The issue where the blockRange rag was not considered valid tag for spawning should be resolved.
Read more ...