how you can spawn many lycanite mobs, what jas cannot read by default? ( such as zephyr)
I'm interested in this too. I love Lycanites mobs but Lycanite has changed his spawning system a lot so I'm not sure what works any more. From memory, Lycanites has it's own spawning system so this is not turned off by JAS. JAS can see or "read" the Lycanites entities (if they are set to spawn in the Lycanites config) but JAS cannot interfere with Lycanites spawning system. That's ok though, right? ..because it still leaves 2 options (?). One way is to tell JAS to not spawn any Lycanites mobs, then configure those mobs using the Lycanites configs. The other way is to turn off the separate Lycanites spawner. With the separate Lycanites spawner turned off, JAS is free to control spawns. The problem that I've had with this in the past, however, was that I accidentally "disabled" the Lycanites mobs individually without disabling the Lycanites spawner. That was easy to do when he kept changing his config system with each update :P. I had to get a fresh config and start again but in the end I got it working. That was a while ago, though.
Now I'm ready to set up again under 1.7.10 so if anyone has any corrections or additional advice, now would be handy. I should ask on the Lycanites topic as well because I think it's not just us who want to play with both.
Just set all Lycanite Mob Weights in the Lycanite config folder to zero, keep the chances to 100 and the global spawn enabled (otherwise, rock, lava etc. spawns wont work.
Disable the vanilla spawn control in every Lycanite config.
Now set the JAS SpawnListEntry Weights for Lycanite Mobs to whichever value you see fit. Done!
good solution
and we can use lycanite cfgs for ROCK STORM ... control
I've encounter issues with JAS not functioning for certain Biomes. For certain it appears that 'Extreme Hills+ M' is not spawning according to the config files, I know this because I disabled almost all mobs so naturally when I saw a hillside full of skeletons and creepers I went to investigate. I determined that the nighboring biome of 'Extreme Hills' was spawning as expected, but as soon as you cross over to 'Extreme Hills+ M' you could see the difference.
What would be nice for JAS is to have a MasterSpawning.cfg which simply lets you enable or disable mobs as a whole, regardless of biome since that would make it much easier to configure when you just want to turn a specific mob off entirely.
You can. Go to JustAnotherSpawner\WorldSettings\{settingsFolder}\EntityHandlers\<desiredModID>.cfg. And find the desired entity, then change the 'true' statement to 'false'. i.e. "Creeper": { "Type-Enabled": "MONSTER-true", to "Creeper": { "Type-Enabled": "MONSTER-false",
EDIT: Btw, is it normal that JAS replaces all "&" characters with "\u0026" ?
Its not normal (in the sense that I don't think it did previously) but should be fine. HTML Escaping must have accidently been enabled by the GSON parser.
I got another problem:
Is there a special trick to make Project Zulu and JAS work together flawlessly? My Gorillas wont spawn in most places due to the "living handler" not allowing to (/canspawnhere is telling me this), but I looked in all cfgs (PZ and JAS ones) and everything regarding the Gorilla and the specific biomes is enabled.
Gorillas don't spawn nicely in their biomes in vanilla. Sky LOS, Leaves on ground (Jungle). Its not an interaction issue, its just how it spawns. You'll need to play with tags to fix it.
Then there's an issue when 2 mods add the same entityname like Animals+ bird and Mo`s bird. When I try to use the /canspawnhere command on one of them like /jas canspawnhere MoCreatures.Bird, it says "entitiynotfound". Typing "/jas canspawnhere Bird" works, but I can't analyze the other entity. I tried editing the LivingGroups.cfg, but no matter which custom name I assign to the entities it has no impact on the JAS commands. The entity names listed by "/jas listspawns" arent always the ones expected by "/jas canspawnhere", which is confusing.
Yea, its bugged. Its currently using the FML mapping instead of the JAS one.
Are there hidden prequisites for gorilla spawning? Cause I cleared the ground of all leaves under clear sky and tried the /canspawnhere command for the gorilla and other mobs from the same category. Other mobs are allowed to spawn but for some reason the "Living Handler" of the gorillas is denying their spawning (in most places, there are some single and lonely spots /canspawnhere is returning all green). No idea where to fix this.
I can't help without asking another question, I'm afraid. I thought the short way to fix this would be to assign the gorilla some spawn tags in the EntityHandlers/ProjectZuluCore.cfg. This would override it's default spawn conditions instantly. This method can be handy with mobs like the Blizz (from Thermal Expansion) which is set to only spawn when it's snowing.
So, for your gorillas, I wanted to suggest something like
..but, as you can see, I ran into a problem. I don't know how to specify a grass block any more. Not since the 1.7.2 ID change thing. The ID for a block of grass used to be 2 and going by this, it still is but what format does JAS need for its tags?
Okay, I can't assign custom names in LivingGroups.cfg or I am doing something wrong. Every time I am changing the left name it is restored after server restart or /jas loadconfig...
I could be wrong here but shouldn't you be changing the name to the right of the ":"?
First of all, there are some strangeness going on in https://github.com/Crudedragos/JustAnotherSpawner/wiki/Tags about spawnRate. It has been mentioned two times and even after all the testing, I still have no clue what is the difference between spawnRate and despawnAge. Also, naming could be more intuitive: despawnAge is clearly tied to despawning while spawnRate and spawnRange sound something that one could believe are somehow tied to spawning instead of despawning. Please, educate me if there is a good reason for these names exactly.
Secondly, all tests considering spawnRange, spawnRate and despawnAge were fruitless. They seemed to have no effect at all. Test with sky tag was somewhat success: mobs who were able to see sky didn't despawn at all, while the others despawned after a while when the player was far away from the mob. However, I was expecting them to despawn immediately why it was a surprise.
Thirdly, spawnRange has description of ":spawnRange,range" but server crashes when I am trying to use only one value. When I use two values (eg. spawnRange,0,10) the server doesn't crash but as said previously: no impact on despawning.
Only thing that seems to work logically is maxSpawnRange (naming could be better though) where entity instantly despawns after the certain range.
My goal: To be able to define exactly if and when entities despawn, and how far the players have to be from it and how long. From the Wiki: DespawnAge marks the minimum age an entity (has to be before it) is eligible for despawning. Age is in ticks.
DespawnAge cannot instantly despawn an entity. In fact, I don't really know of any way to instantly despawn an entity at all. I wanted this for myself in the past with creepers. I wanted creepers to only spawn underground and for all creepers who wandered out of a cave to instantly die lol. After a bit of thought, though, I realised this was a silly idea. I would've occasionally seen a creeper come out of a cave, head towards me, then magically die for no reason.
From what I can gather, despawnAge means that creepers can essentially "die" of "old age" (or be eligible to despawn a certain number of ticks after their spawn) but they will despawn mostly out of sight of the player and never during a combat situation. I think the idea with the despawn age thing is that it helps keep the mobs in a game constantly refreshing and recycling, ensuring the player has a good chance to see every one of the mobs that are set to spawn in any given biome over time. There are some mobs I like to have on a short despawn age (like the Kobold from Lycanite's mobs) and the despawnAge tag helps with that.
I hope that helps with you.
EDIT- hrr.. seems you're right about there being some silliness on the wiki to do with spawnRate. It shouldn't have anything to do with despawnAge at all ..and it's tag parameters shouldn't be the same as spawnRange...
Okay, I can't assign custom names in LivingGroups.cfg or I am doing something wrong. Every time I am changing the left name it is restored after server restart or /jas loadconfig...
Change the right name i.e. "Bat": "Bat" to "Bat": "Bat2" as Dulciphi has noted.
..but, as you can see, I ran into a problem. I don't know how to specify a grass block any more. Not since the 1.7.2 ID change thing. The ID for a block of grass used to be 2 and going by this, it still is but what format does JAS need for its tags?
Anywhere that use to be a blockID is now the String name. So instead of 2 you'd put grass. Sadly it also automatically means anything that did the range i.e. 2-4 no longer works (grass-sand doesn't make sense).
First of all, there are some strangeness going on in https://github.com/Crudedragos/JustAnotherSpawner/wiki/Tags about spawnRate. It has been mentioned two times and even after all the testing, I still have no clue what is the difference between spawnRate and despawnAge. Also, naming could be more intuitive: despawnAge is clearly tied to despawning while spawnRate and spawnRange sound something that one could believe are somehow tied to spawning instead of despawning. Please, educate me if there is a good reason for these names exactly.
Secondly, all tests considering spawnRange, spawnRate and despawnAge were fruitless. They seemed to have no effect at all. Test with sky tag was somewhat success: mobs who were able to see sky didn't despawn at all, while the others despawned after a while when the player was far away from the mob. However, I was expecting them to despawn immediately why it was a surprise.
Thirdly, spawnRange has description of ":spawnRange,range" but server crashes when I am trying to use only one value. When I use two values (eg. spawnRange,0,10) the server doesn't crash but as said previously: no impact on despawning.
Only thing that seems to work logically is maxSpawnRange (naming could be better though) where entity instantly despawns after the certain range.
1a.
'despawnAge' is the minimum amount of time must pass before an entity is capable of despawning.
'spawnRange' is the minimum distance an entity can be considered valid for despawning. The player must be farther away than this distance for the entity to be able to being despawn. If inside this range, despawnAge is set to 0.
'spawnRate' is the rate at which the entity will despawn once it is elible for despawning. The check is run every 3 seconds and if rand(1 + spawnRate / 3) == 0 where rand(1 + spawnRate / 3) is a randomly a number between 0 and spawnRate / 3.
'maxSpawnRange' is the distance an entity must be before it will instantly despawn (assuming it is not cancelled via other tags i.e. sky).
1b. Poor variable names are poor.
3. Yes it seems to be bugged. Two values, however, does not work and the tag would be disregarded completely (thus avoiding the aforementioned crash). You should have a [SEVERE] message in your log saying 'Error Parsing spawnRange parameter. Invalid Argument Length'.
1a.
'despawnAge' is the minimum amount of time must pass before an entity is capable of despawning.
'spawnRange' is the minimum distance an entity can be considered valid for despawning. The player must be farther away than this distance for the entity to be able to being despawn. If inside this range, despawnAge is set to 0.
'spawnRate' is the rate at which the entity will despawn once it is elible for despawning. The check is run every 3 seconds and if rand(1 + spawnRate / 3) == 0 where rand(1 + spawnRate / 3) is a randomly a number between 0 and spawnRate / 3.
'maxSpawnRange' is the distance an entity must be before it will instantly despawn (assuming it is not cancelled via other tags i.e. sky).
Thank you for clearing that up. I was tempted to try and edit the Wiki using the info you just gave but I'm quite cowardly in the face of tables and ..other things that have names
Problem: Neither of the mobs despawn unless I go over maxSpawnRange (it's there to show that things are working otherwise). I can wait Minecraft day and nothing happens. I am way over spawnRange as you can see in the picture.
Please accept my apologies if I'm wrong here. I'm tired and I'm having a hard time figuring it out anyway.. but doesn't that mean despawn UNLESS you're between 5 and 50 blocks from the player?? So... ?
Hey there,
To the details: I tested it with only the three above mentioned mods installed and with three different forge versions, all with the same result. I had not yet changed any JAS settings.
I'm running Minecraft 1.7.10 on Forge 10.13.0.1208 (also tested on .1180 and .1150) via MultiMC 5 0.4.2, using Twilight Forest 2.2.3, JAS 0.14.8 and the JAS compatibility addon 1.0.0.
The "NoSuchFieldError" I get makes it seem to me like this is an issue of unfitting versions but then again the TF version I use is already over a month old and i can't really imagine me being the only one who has tried out that combination of mods and versions.
In any way, here is the pretty short crash log, hope you don't mind me putting it here instead of Pastebin or similar:
You'd be surprised how long it takes for certain bugs, even ones that should be common, to be brought up. This mod lends to the power user, someone with many mods installed: it takes awhile for them to update.
Please accept my apologies if I'm wrong here. I'm tired and I'm having a hard time figuring it out anyway.. but doesn't that mean despawn UNLESS you're between 5 and 50 blocks from the player?? So... ?
Problem: Neither of the mobs despawn unless I go over maxSpawnRange (it's there to show that things are working otherwise). I can wait Minecraft day and nothing happens. I am way over spawnRange as you can see in the picture.
You are correct. The issue is that I was simple calling those values from a hashmap using the wrong key.
@Crudedragos and @Dulciphi, I'm using JAS for 1.6.4 (but not Project Zulu), and I'm trying to wrap my head around the config files, but having trouble. I've taken to reading the Wiki on the GitHub page, but I'm still really confused and a little concerned that it might be because of the Wiki. Is it meant primarily for folks working with 1.7.x? It mentions set maths, but I can't see where it should be used.
Let's say that I have scorpions from Mo' Creatures and I only want them to spawn in hot, arid environments. I could easily create two AttributeBiomeLists (one for hot, one for arid). How do I get the scorpions to only spawn in "A|HOT&A|ARID" ?
Yo Crudedragos!
I was pretty excited when I saw you had updated the compatibility addon, because I thought you had already resolved the issue that I had reported.
When I went to downloading it though I saw that the file provided is still the 1.0.0 version and not the new 1.1.0 version indicated by the name of the link.
Both files are not only identical in name but also in hashes and the crash is still there.
Have you perhaps just uploaded or linked the wrong file?
I'm trying to wrap my head around the config files, but having trouble. I've taken to reading the Wiki on the GitHub page, but I'm still really confused and a little concerned that it might be because of the Wiki. Is it meant primarily for folks working with 1.7.x? It mentions set maths, but I can't see where it should be used.
It mentions set maths, but I can't see where it should be used.
Let's say that I have scorpions from Mo' Creatures and I only want them to spawn in hot, arid environments. I could easily create two AttributeBiomeLists (one for hot, one for arid). How do I get the scorpions to only spawn in "A|HOT&A|ARID" ?
I'm not as familiar with 1.6.4 notation as you'd expect. But if IIRC you'd want to add a biomegroup in the form of
biomelists {
S:CUSTOMHOT=A|HOT,&A|ARID
}
The comma is neccesary, people tend to forget it.
Then in /modEntitySettings/ find the entry (will require start /jas loadconfig to generate) and set to only spawn in that biomegroup (You'd likely want to disable them in other biomesgroups which they are enabled by default).
"CUSTOMHOT" {
S:<whatever the scorpion name is>=10-4-1-4
}
The idea of adding tags to the entity handler was brilliant and now all my Gorilla problems are solved Yay!
Are entity- and spawnlist tags OR-ed or AND-ed in the current version?
They are || as long as neither have a & in front of {spawn} i.e. {&spawn}.
Yes. The reason you get no feedback is that the entity-mapping exists but it has no groups which (mistakenly) exits silently but also means it cannot spawn anywhere.
Somewhere in your log there is likely (hopefully?) something complaining that ProjectZulu|Core.Gorilla doesn't exist.
Then in /modEntitySettings/ find the entry (will require start /jas loadconfig to generate) and set to only spawn in that biomegroup (You'd likely want to disable them in other biomesgroups which they are enabled by default).
"CUSTOMHOT" {
S:=10-4-1-4
}
Awesome. I use the option to sort creatures by mod, then by name. So if I wanted to, I could just put this in the scorpion section and it would only generate them in hot, arid biomes? Do I need to specify the other biomes at all? Will it use some default value if I don't?
Awesome. I use the option to sort creatures by mod, then by name. So if I wanted to, I could just put this in the scorpion section and it would only generate them in hot, arid biomes? Do I need to specify the other biomes at all? Will it use some default value if I don't?
scorpion {
S:ARIDHOT=6-4-1-1
}
If they are non-zero they'd spawn in the other biomes. It imports from vanilla, which may or may not be 0 for MOcreatures entities depending on the version you use. If you look at the values you will easily have your answer.
Thanks again! Works like a charm.
I see you updated JASCA. I always wondered if I really need it or not... Is it definitely a must have when running TF to make it work properly?
Commonly people just add TF to the Blacklist, at which point JASCA is useless. TF is standalone and tightly tuned so the need for a spawner is greatly diminished. Most people if they want to interact at all want the entities in TF spawning elsewhere. For them it is useless.
Otherwise. I cannot comment the quality of the experience with/without as I've little actual experience. The issue is TF relies so heavily on structures: Hills, towers, hedgeMaze, iceTower, questIsland/grove, ruins, lairs, strongholds, caves, and even underground ('below a certain height if nothing else is found') are all there own structures with independent spawnlists. The bosses aren't on the spawnlist, so no worry in missing them. Obviously absent the compatibility these areas just read from the biome spawnlist. Risking a homogenous experience. The areas may not be setup with appropriately atmospheric entities.
This mod looks pretty interesting, but I'm not sure why its installation is recommended along with project Zulu? From a brief reading of the config files, dropping this in without customizing the configs will break Zulu's customized per-biome spawning of creatures, isn't it? Even with the config pack linked on the wiki, I thought I only saw settings for creature/monster/etc groups as a whole, and nothing to assign creatures/mobs to specific biomes.
Also, I was wondering if this mod correctly overrides Mo' Creatures spawning correctly? Has someone extensively tested it or proven it? I seem to remember that mod overriding the vanilla spawn lists pretty late in the forge boot process, and messing up Mob Spawn Controls because of that, among other problems.
This mod looks pretty interesting, but I'm not sure why its installation is recommended along with project Zulu? From a brief reading of the config files, dropping this in without customizing the configs will break Zulu's customized per-biome spawning of creatures, isn't it? Even with the config pack linked on the wiki, I thought I only saw settings for creature/monster/etc groups as a whole, and nothing to assign creatures/mobs to specific biomes.
It'll import settings for each entity based on its vanilla settings. Thus it'll copy whatever your current settings for PZ are. Once copied, of course, changing PZ settings afterward will have no effect.
Each entity is assigned per biome. Biomes and entities can be grouped to ease bulk edits if desired.
Also, I was wondering if this mod correctly overrides Mo' Creatures spawning correctly? Has someone extensively tested it or proven it? I seem to remember that mod overriding the vanilla spawn lists pretty late in the forge boot process, and messing up Mob Spawn Controls because of that, among other problems.
JAS spawn system is completely independent of the vanilla spawn system. The only issue from any mods altering the vanilla spawn list is that the import would be messed up.
The only issue anyone has ever had with Mo'Creatures is either 1: MoC entities won't import (as they were not put in the vanilla spawnlist so import == 0) or 2: CMS won't shut itself off and both spawner function as normal.
1: Shouldn't be an issue anymore as MoC is independent of CMS (unless something changed in last 2-3 months). It is more work to set them up but functionality is maintained.
2: Same as 1 nowadays and previously its settings would just be set to 0. Though that would still have the issue of no imports.
Something is wrong when I am using the tag: random
Here is a piece of server log: http://oi57.tinypic.com/2hzle8j.jpg
Pay attention to the types RAREMOB and TEMPORARYMOB. They both keep spawning relatively often. One could say that almost every 5 seconds.
Here are bits of config file:
If I've understood correctly RAREMOB should spawn a lot less often. In case, I have misunderstood something then TEMPORARYMOB should spawn less often.
Question remains: Something is wrong but what it is?
1. It'll effect the spawnrate until the cap is reached. Typically spawnrate >>>> depspawnrate depending on circumstances.
2. At a rate of 100 ticks, that is a spawn loop every 5 seconds. During a loop that particular check will be performed once for each chunk eligible for spawning. Assuming a single player, the defualt is 257. (8 chunk radius, 16 * 2 + 1 == 257). Even at 5% there is practically a guarantee that a few are valid for each. For any time it does pass, there is the probability the spawn location is invalid. If it is valid its likely to spawn 2-4 entities depend on your settings.
I'm still having a lot of trouble figuring out these config files, so I've come back with questions.
Again, with Mo' Creatures, there is a mob called BigCat. This isn't one, but actually more like a variety of big cats packed into one mob, and I've found that you can select the type by changing an NBT tag . I want to differentiate between the two, setting up Lions and Cheetahs to spawn in, say, only one biome, and Tigers and Black Leopards to spawn only in another. Further, I want the Lions to spawn in packs comprised of one (rarely two) males, and 5-8 females. I've tried various approaches, but I'm not seeing how I can create two different variants of the same creature. Everything I've tried has caused my client to crash back to the main menu.
Also, can you explain the file structure dependencies? Which config files are dependent upon which? Obviously LivingGroups.cfg is dependent upon CreatureType.cfg, but then is, for example, MoCreatures.cfg dependent upon LivingGroups.cfg?
I'm interested in this too. I love Lycanites mobs but Lycanite has changed his spawning system a lot so I'm not sure what works any more. From memory, Lycanites has it's own spawning system so this is not turned off by JAS. JAS can see or "read" the Lycanites entities (if they are set to spawn in the Lycanites config) but JAS cannot interfere with Lycanites spawning system. That's ok though, right? ..because it still leaves 2 options (?). One way is to tell JAS to not spawn any Lycanites mobs, then configure those mobs using the Lycanites configs. The other way is to turn off the separate Lycanites spawner. With the separate Lycanites spawner turned off, JAS is free to control spawns. The problem that I've had with this in the past, however, was that I accidentally "disabled" the Lycanites mobs individually without disabling the Lycanites spawner. That was easy to do when he kept changing his config system with each update :P. I had to get a fresh config and start again but in the end I got it working. That was a while ago, though.
Now I'm ready to set up again under 1.7.10 so if anyone has any corrections or additional advice, now would be handy. I should ask on the Lycanites topic as well because I think it's not just us who want to play with both.
good solution
and we can use lycanite cfgs for ROCK STORM ... control
Make sure they are set not to sapwn by using /jas listspawns https://github.com/Crudedragos/JustAnotherSpawner/wiki/Commands#analytics-commands. You can also check your log and it will tell you if it JAS that is spawning the entities.
Create a scenario with a limited number of mods installed and directions to reproduce from a fresh install and I'll investigate.
You can. Go to JustAnotherSpawner\WorldSettings\{settingsFolder}\EntityHandlers\<desiredModID>.cfg. And find the desired entity, then change the 'true' statement to 'false'. i.e. "Creeper": { "Type-Enabled": "MONSTER-true", to "Creeper": { "Type-Enabled": "MONSTER-false",
Its not normal (in the sense that I don't think it did previously) but should be fine. HTML Escaping must have accidently been enabled by the GSON parser.
Gorillas don't spawn nicely in their biomes in vanilla. Sky LOS, Leaves on ground (Jungle). Its not an interaction issue, its just how it spawns. You'll need to play with tags to fix it.
Yea, its bugged. Its currently using the FML mapping instead of the JAS one.
Just Another Spawner v0.14.8
Changelog: https://github.com/Crudedragos/JustAnotherSpawner/wiki/Changelog#just-another-spawner-v014
Download: http://projectzulu.blogspot.ca/p/downloads.html
* Fix issue with CommandCanSpawnHere using FML instead of JAS mapping.
I can't help without asking another question, I'm afraid. I thought the short way to fix this would be to assign the gorilla some spawn tags in the EntityHandlers/ProjectZuluCore.cfg. This would override it's default spawn conditions instantly. This method can be handy with mobs like the Blizz (from Thermal Expansion) which is set to only spawn when it's snowing.
So, for your gorillas, I wanted to suggest something like
"ProjectZulu|Core.Gorilla": {
"Type-Enabled": "CREATURE-true"
"Tags": "{!spawn:sky:&block,**what goes here?**}"
..but, as you can see, I ran into a problem. I don't know how to specify a grass block any more. Not since the 1.7.2 ID change thing. The ID for a block of grass used to be 2 and going by this, it still is but what format does JAS need for its tags?
I could be wrong here but shouldn't you be changing the name to the right of the ":"?
DespawnAge cannot instantly despawn an entity. In fact, I don't really know of any way to instantly despawn an entity at all. I wanted this for myself in the past with creepers. I wanted creepers to only spawn underground and for all creepers who wandered out of a cave to instantly die
From what I can gather, despawnAge means that creepers can essentially "die" of "old age" (or be eligible to despawn a certain number of ticks after their spawn) but they will despawn mostly out of sight of the player and never during a combat situation. I think the idea with the despawn age thing is that it helps keep the mobs in a game constantly refreshing and recycling, ensuring the player has a good chance to see every one of the mobs that are set to spawn in any given biome over time. There are some mobs I like to have on a short despawn age (like the Kobold from Lycanite's mobs) and the despawnAge tag helps with that.
I hope that helps with you.
EDIT- hrr.. seems you're right about there being some silliness on the wiki to do with spawnRate. It shouldn't have anything to do with despawnAge at all ..and it's tag parameters shouldn't be the same as spawnRange...
umm... Crudedragos?
Change the right name i.e. "Bat": "Bat" to "Bat": "Bat2" as Dulciphi has noted.
Anywhere that use to be a blockID is now the String name. So instead of 2 you'd put grass. Sadly it also automatically means anything that did the range i.e. 2-4 no longer works (grass-sand doesn't make sense).
On the despawning process: https://github.com/Crudedragos/JustAnotherSpawner/wiki/Spawning-101#despawning
Also there is another distance farther away where the entity will instantly despawn.
1a.
'despawnAge' is the minimum amount of time must pass before an entity is capable of despawning.
'spawnRange' is the minimum distance an entity can be considered valid for despawning. The player must be farther away than this distance for the entity to be able to being despawn. If inside this range, despawnAge is set to 0.
'spawnRate' is the rate at which the entity will despawn once it is elible for despawning. The check is run every 3 seconds and if rand(1 + spawnRate / 3) == 0 where rand(1 + spawnRate / 3) is a randomly a number between 0 and spawnRate / 3.
'maxSpawnRange' is the distance an entity must be before it will instantly despawn (assuming it is not cancelled via other tags i.e. sky).
1b. Poor variable names are poor.
3. Yes it seems to be bugged. Two values, however, does not work and the tag would be disregarded completely (thus avoiding the aforementioned crash). You should have a [SEVERE] message in your log saying 'Error Parsing spawnRange parameter. Invalid Argument Length'.
Just Another Spawner v0.14.9
Changelog: https://github.com/Crudedragos/JustAnotherSpawner/wiki/Changelog#just-another-spawner-v014
Download: http://projectzulu.blogspot.ca/p/downloads.html
* Fix issue with SpawnRange tag crash caused to accessing objects before construction
Thank you for clearing that up. I was tempted to try and edit the Wiki using the info you just gave but I'm quite cowardly in the face of tables and ..other things that have names
You'd be surprised how long it takes for certain bugs, even ones that should be common, to be brought up. This mod lends to the power user, someone with many mods installed: it takes awhile for them to update.
JASCA v1.1.0
Changelog: https://github.com/Crudedragos/JAS-Compatability-Addon/wiki
Download: http://projectzulu.blogspot.ca/p/downloads.html
* Update TF support for newer version. Unknown TF version made the change.
Nope. Those are value tags.
You are correct. The issue is that I was simple calling those values from a hashmap using the wrong key.
Thank you for reporting these issues.
Just Another Spawner v0.14.10
Changelog: https://github.com/Crudedragos/JustAnotherSpawner/wiki/Changelog#just-another-spawner-v014
Download: http://projectzulu.blogspot.ca/p/downloads.html
* Fix issue with spawnrange and despawnage not being called properly
Let's say that I have scorpions from Mo' Creatures and I only want them to spawn in hot, arid environments. I could easily create two AttributeBiomeLists (one for hot, one for arid). How do I get the scorpions to only spawn in "A|HOT&A|ARID" ?
I have now actually uploaded the file, thank you.
Its an (un)healthy mix of both.
I'm not as familiar with 1.6.4 notation as you'd expect. But if IIRC you'd want to add a biomegroup in the form of
The comma is neccesary, people tend to forget it.
Then in /modEntitySettings/ find the entry (will require start /jas loadconfig to generate) and set to only spawn in that biomegroup (You'd likely want to disable them in other biomesgroups which they are enabled by default).
They are || as long as neither have a & in front of {spawn} i.e. {&spawn}.
Yes. The reason you get no feedback is that the entity-mapping exists but it has no groups which (mistakenly) exits silently but also means it cannot spawn anywhere.
Somewhere in your log there is likely (hopefully?) something complaining that ProjectZulu|Core.Gorilla doesn't exist.
Changing
to
Will fix your issue.
Awesome. I use the option to sort creatures by mod, then by name. So if I wanted to, I could just put this in the scorpion section and it would only generate them in hot, arid biomes? Do I need to specify the other biomes at all? Will it use some default value if I don't?
If they are non-zero they'd spawn in the other biomes. It imports from vanilla, which may or may not be 0 for MOcreatures entities depending on the version you use. If you look at the values you will easily have your answer.
Commonly people just add TF to the Blacklist, at which point JASCA is useless. TF is standalone and tightly tuned so the need for a spawner is greatly diminished. Most people if they want to interact at all want the entities in TF spawning elsewhere. For them it is useless.
Otherwise. I cannot comment the quality of the experience with/without as I've little actual experience. The issue is TF relies so heavily on structures: Hills, towers, hedgeMaze, iceTower, questIsland/grove, ruins, lairs, strongholds, caves, and even underground ('below a certain height if nothing else is found') are all there own structures with independent spawnlists. The bosses aren't on the spawnlist, so no worry in missing them. Obviously absent the compatibility these areas just read from the biome spawnlist. Risking a homogenous experience. The areas may not be setup with appropriately atmospheric entities.
To each their own.
Also, I was wondering if this mod correctly overrides Mo' Creatures spawning correctly? Has someone extensively tested it or proven it? I seem to remember that mod overriding the vanilla spawn lists pretty late in the forge boot process, and messing up Mob Spawn Controls because of that, among other problems.
It'll import settings for each entity based on its vanilla settings. Thus it'll copy whatever your current settings for PZ are. Once copied, of course, changing PZ settings afterward will have no effect.
Each entity is assigned per biome. Biomes and entities can be grouped to ease bulk edits if desired.
JAS spawn system is completely independent of the vanilla spawn system. The only issue from any mods altering the vanilla spawn list is that the import would be messed up.
The only issue anyone has ever had with Mo'Creatures is either 1: MoC entities won't import (as they were not put in the vanilla spawnlist so import == 0) or 2: CMS won't shut itself off and both spawner function as normal.
1: Shouldn't be an issue anymore as MoC is independent of CMS (unless something changed in last 2-3 months). It is more work to set them up but functionality is maintained.
2: Same as 1 nowadays and previously its settings would just be set to 0. Though that would still have the issue of no imports.
1. It'll effect the spawnrate until the cap is reached. Typically spawnrate >>>> depspawnrate depending on circumstances.
2. At a rate of 100 ticks, that is a spawn loop every 5 seconds. During a loop that particular check will be performed once for each chunk eligible for spawning. Assuming a single player, the defualt is 257. (8 chunk radius, 16 * 2 + 1 == 257). Even at 5% there is practically a guarantee that a few are valid for each. For any time it does pass, there is the probability the spawn location is invalid. If it is valid its likely to spawn 2-4 entities depend on your settings.
Again, with Mo' Creatures, there is a mob called BigCat. This isn't one, but actually more like a variety of big cats packed into one mob, and I've found that you can select the type by changing an NBT tag . I want to differentiate between the two, setting up Lions and Cheetahs to spawn in, say, only one biome, and Tigers and Black Leopards to spawn only in another. Further, I want the Lions to spawn in packs comprised of one (rarely two) males, and 5-8 females. I've tried various approaches, but I'm not seeing how I can create two different variants of the same creature. Everything I've tried has caused my client to crash back to the main menu.
Also, can you explain the file structure dependencies? Which config files are dependent upon which? Obviously LivingGroups.cfg is dependent upon CreatureType.cfg, but then is, for example, MoCreatures.cfg dependent upon LivingGroups.cfg?