Jas Part 3 - ProjectZulu/JustAnotherSpawner GitHub Wiki

Welcome to Creature types. Here we will delve into the Creaturetype CFG file. How it does what it does and why, which will help us understand some common issues that arise and how to resolve them easily.

• Creature Type
• Creature Sample
• Entity Handler
• Spawn List Entries
• What is Mob Spamming?
• Goto Walkthrough Part 3

Lets begin by going over the parts of syntax.

NOTE: When in doubt use Json Checker.

The comma in JAS lists is to say that there is "more coming". So, in a list of attributes as we will see, each attribute is followed by a comma to signify that there is another attribute coming. The last item will NOT have a comma to signify that it is the last attribute in the list.

The following is for the group "AMBIENT". The lines that follow it are attributes for the group. Every entity in that groups may be different (a bat is not slug), but if they belong to the group "AMBIENT" they would all share whatever attributes are listed.

• "AMBIENT": { <---open bracket signifies the beginning so no comma after it is needed
• "Spawn Rate": 1, <---There is a comma here because there is another element after it
• "Spawn Cap": 10, <---the same is true here
• "Chunk Spawn Chance": 0.0, <-----and here
• "Spawn Medium": "air", <----yup more to come
• "Iterations Per Chunk": 0, <------no end in sight
• "Iterations Per Pack": 0, <-----and more
• "Default Biome Cap": -1, <-----and more
• "Biome Caps": {} <---and none here

}, <----this is the closing bracket which means the code is done, the coma means there should be another creature group in this case coming. if this were real it would give an error because there isn't one. the comma in this case would be wrong. If another creature group followed, then it would be good.

NOTE: The group AMBIENT can only have 10 entities spawned into the world, so if the bat and slug are in that group there can only be a total of 10, not 10 each.

NOTE: I am a fan of total control and when working with multiple mods you never know exactly how the mod author works out mob spawning. Like Lycancites, there is normal spawning which JAS can readily resolve, but also some special spawning that MUST be turned off or controlled throw Lycancites. Total control means to remove obstacles that could cause problems now or later. Chunk Spawning is one such problem for me. It ignores all spawning rules and uses its own, this results in spiked mob numbers that can in turn result in mob spamming, etc.

FDLFCS

The opening bracket tells JAS that everything that follows are properties (or rules) about our group and any creature part of this group will have to obey all the rules for this group.

So here is a fully loaded creature type called EDIBLE.

 "EDIBLE": {
      "Spawn Rate": 60,
      "Spawn Cap": 45,
      "Chunk Spawn Chance": 0.01,
      "Spawn Medium": "water",
      "Iterations Per Chunk": 3,
      "Iterations Per Pack": 3,
      "Spawn Tag": "!liquid({0,0,0},{0,0,0})||!liquid({0,0,0},{0,-1,0})||normal({0,0,0},{0,1,0})",
      "Default Biome Cap": -1,
      "Biome Caps": {}
    },

Jump to

• Spawn Rate
• Spawn Cap
• Chunk Spawn Chance
• Spawn Medium
• Iterations per Chunk
• Iterations per Pack
• Spawn Tag
• Default Biome Cap

Simply put, its the rate (or speed) at which entities (or mobs as they are also called) spawn into the world. There are other parameters and requirements but this element only cares about how quickly we want an entity to be considered for spawning. Note we use the word "considered", based on certain factors an entity might not be able to spawn in the random location selected. For example, there might be water and they need land, or deeper water. Maybe they cannot see to sky and need to. All this and many more possible factors into whether an entity actually spawns.

Keep in mind we are using what is called Game Ticks or simply Ticks. These are 1/20th of a second or .05 seconds long. so 100 would be 5 seconds, 600 would be 30 seconds. There are many reasons you would want to set a particular timing for a group which we will get into later, for now we need only know that this will affect all mobs in the group.

NOTE: when you are working with LOTS of mobs (and maybe lots o mobs), you will soon discover wanting to spawn and fill caps and replace caps every game tick could easily cause lag. 100 ticks is only 5 seconds, so it might be worth it to realize for 200 mobs and 10 groups, a 5 second delay in all your groups would go unnoticed. maybe. maybe 200 ticks is better. Don't be afraid to experiment as in this case that is a LOT of ticks for 200 mobs and it could be a significant saving on the server.

How many of this group are we allowing to exist at one time ? simple, yet this is very different in setting a spawn cap to a specific entity. Here, the spawn cap is not shall we say "aggressive" like one for a specific entity. Here it has two pointed features

1. Its a "roughly this much" cap, so our cap of 45 here might yield 50 or 40 or somewhere in between but still close
2. Because it is more like and estimate, it does not force extras to be despawned. something a specific entity cap would do

Remember the despawn cycle runs separate from the spawn cycle. We are trying to control the world but since we don't run into every mob at once, 5 extra will go unnoticed. Of course, if you add that to chunk spawning which worries about the pack size, you could easily be invaded. (one possible cause of squid spamming)

Chunk Spawning is once again, the spawning that takes place when a chunk first comes into existence. When you move away and it unloads from memory and then you return and it reloads into memory that does not constitute coming into existence again. you can only do that once. It can be a big deal as we adventure and are spawning new chunks constantly, but when we move away and return, we can't confuse the pack spawning and other regular spawning with chunk spawning.

A value of one means the EDIBLE group has a 100% chance of chunk spawning. 0 of course would be a "don't ever chunk spawn" value. we have .01, which would be a 1% chance. Depending on your caps and the entities that make up that cap, chunk spawning can be a hindrance or just a plain waste of spawning as chunk spawning straight ignores caps.

NOTE :Yeah, chunk spawning is a separate list of spawns than passive spawning and if your spawning timers are set right it makes chunk spawning pointless as much as a hindrance.

This one might be the easiest. what medium (type of block) should the mobs that belong to this group spawn IN.

Don't confuse this with ON...you are not checking to see what they are on, etc. a small little factoid is that Minecraft is 100% blocks. Meaning AIR IS A BLOCK. One issue some mods have when it comes to spawning too little, too much or not at all is spawning in water. Water biomes like ocean have so much space to spawn in with no obstacles and not the same conditions. for example, while we check to see if the blocks above the ground are air so a cow can spawn IN them, we are using the ground as a point of reference because that is what he is spawning on. We might be making sure he can also see sky so he doesn't spawn underground, or buried in the leaves of a tree, etc. With water creature there is a simple requirement of needing a water block to spawn IN.

First we notice this has to do with the infamous "CHUNK" spawning, so it only occurs when a chunk comes into existence. While this word vaguely translates into "attempts", it is important enough in its purpose to warrant an actual definition.

• Iteration is defined as :repetition of a mathematical or computational procedure applied to the result of a previous application, typically as a means of obtaining successively closer approximations to the solution of a problem.

Putting that right back into simple terms, it says that while a cow would glad to know there is a system to ensure more cows are spawned. As we mentioned in an earlier section, when spawning occurs; both chunk and passive spawning. The mobs needs are placed along with the groups requirements to find a suitable and acceptable spawn location.

1. According to the EDIBLE group there can only be 45 and I'm number 22 so the group is giving me permission to join
2. According to the rules of Minecraft's Spawning Conditions I have the right spawn medium, players are far enough away, etc. So I get a green light there.
3. According to the SpawnListEntry I'm in the right biome and the weights here are set to let me spawn as well.
4. I got all green lights, time to make an attempt to come into existence.

Now an ATTEMPT is made to spawn. What all those steps really amount to is in meeting the right conditions so our soon-to-be food does not spawn 50 blocks in the air and fall to its death, spawn inside a wall and die, spawn in Lava and still die, or even under water and possible die before he gets to the surface. We also don't want him to spawn inside a bunch of leaf blocks if possible, in a cave, and a bunch of other places that would kill him before we could find him and eat him :)

A "pass" is made to spawn the food, using you as the center starting point. If it doesn't find a suitable location it makes another attempt. This is where the meaning of iteration would hit home. It isn't just another attempt to spawn, its about making mathematical adjustments in computations to SUCCEED. So whatever it did the first time in trying to select a suitable spawn location, it makes adjustments the second time, and if that fails it recomputes again and with each iteration after that based on the number of iterations it is allowed to have.

Personally I think this is how a cow can actually spawn trapped in a bunch of leaf blocks. somewhere buried in Minecraft's code is a "need" formula, so an entity needs to spawn bad enough that after enough iterations it starts to compute spawning in a bunch of leaf blocks. It is as sound a theory as any of the theories Hawking's has on black holes. Or not.

Ok, given we understand Iterations per chunk, this might be easier to get than Spawn Medium.

Pack spawning involves the number of an entity that spawns in a cluster, or group. According to Minecraft Pack Spawning the requirements are the same as a chunk pack. The difference is of course a Pack can occur at regular intervals. Also, because JAS gives us control over properties and methods found in Minecraft, the "one Attempt" stated in the Minecraft wiki is only accurate if you have your iterations per pack set to one. In our example we are making 3.

As you grow in your understanding of how JAS really puts you in control of mobs, the Spawn Tag will be one of those tools in your arsenal you call upon frequently. As a result, we will break it down over and over again from different vantage points to hopefully get everyone using JAS on the same page.

For our purposes here, we are defining what Spawn Tag is not the myriad of commands that can be used within it.

That being said, Spawn Tag is a command that tells Minecraft the Mobs belonging to the group EDIBLE will have conditions to them spawning. So "Spawn Tag": is the command we care about here and all the stuff between the " " are the elements we will discuss in a later section, but they are the "modifications" we would make to the mobs spawning under the EDIBLE group. This is one of the ways JAS allows us to really get under the "hood" of Minecraft when it comes to mobs and making it behave in a way we find fun/or useful.

This allows us to set caps for or EDIBLE group based on Biomes. Of course the line after it "Biome Caps": {} would be the list of biomes with cap amounts were any set.

As you will read in our spawn tag section later, there are 3 primary uses for the spawn tag that: 1)set conditions for all entities in a group 2)set conditions for a specific entity 3)set conditions for a specific entity per biome default biome cap is essentially in the same place as 1 above but this allows you to select biomes to set making it 4)set biome caps for entities in #1. this does not change conditions for groups based on biome that would simply be you needing to make another group :)