My undersanding is that creature type NONE means that it will never spawn in a biome, cannot be referenced in StructureSpawns.cfg, and will not exists unless a mob spawner block creates it.
True. There is a spawnlist (for every biome) for each creature type. Technically, in vanilla, the EntityType and its spawnlist are seperate: meaning you can have a creature with no type or the wrong type in a spawnlist (which is very bad, as it won't count towards caps). JAS won't allow it, for obvious reason, so if the creature has no actual types but in vanilla was in a monster spawnlist, JAS will list it as type NONE. Typically not an issue, but it has come up on rare occasions.
I think your write about StructureSpawns, spawnlistentries will not persist for creature type == NONE. This is pretty much just for keeping configs a little cleaner for entries that are never used (NOTE: if shouldspawn is false or weight is 0, spawnlistentries should still persist).
... creature type NONE means ... will not exists unless a mob spawner block creates it.
All that gaurantees is that JAS won't spawn it. Anything else could; eggs, items, other spawners. I think that was your point, but thought it might be worth clarifying. JAS settings can only affect itself (ignoring the options like clearVanillaSpawnLists) and everything else continues as intended.
1) Do I need to contact the WandM author and ask him which of these are allowed to spawn in biomes (and what kind of biomes he had in mind), which are allowed to spawn only in structures (and which structures he had in mind), and which are allowed to be spawned only by spawner blocks?
If the above scenario occured where it should be spawning but doens't in JAS because it didn't have a type then you could just give it a type and make the spawnlist entries regenerate (delete them).
Otherwise you'll need to talk to the author. Outside of MoCreatures and maybe one of the Pokemobs mod (it has a custom spawner IIRC) the above should work fine.
2) StructureSpawns.cfg contains no entries for the many world gen structures added by WandM. Is this an import error, or are there no structure-specific spawn tables, or does WandM have it's own spawner (sigh) which I will need to somehow circumvent after deciphering the authors intent for the parameters of each mob?
There is only structure support for Twilight Forest and vanilla structures. There is no global structure list-registry, so support must be added manually for each.
Importantly, Most structures do not actually have their own spawnlists. In the vanilla overworld only the witchhut does. Other overworld structures, such as the mineshaft, would normally draw from the biome spawnlist. JAS does have support to specify a custom spawnlist for mineshafts.
3) I notice that vanilla villagers are set to NONE as a CreatureType, but Villages do not appear in StructureSpawns.cfg.
How is villager spawning managed under JAS, and do I need to investigate/configure villagers added by other mods (Thaumcraft/Mystcraft/Ars Magica 2/etc)?
Villages generate villagers as the structure itself generates.
I can't speak to other mods villagers. I know forge has hooks to customize the villager entity.
All of these make sense to me except MobDryad and MobLightMage. Thought they should be in biome-specific tables. MobMageVillager is a question that goes to my previous post about villager spawning, JAS, and mods.
Feel free to put them there. Just because the original author didn't have need doesn't mean you don't. I can't really comment on most of these.
Right to the source for this one. These seem like legitimate mobs, how are they spawned?
Not through the spawner. Follower is spawned the centipede head-master piece to represent its 'tail'. Haunted armor are in spawners or just spawned by the cemetary when it generates. Horse Black is probably a PZ bug. Mimic spawned when various PZ structures are doing there generation. Minotaur is in spawners. Pharoad is summoned by the jasper block summoning ritual.
There are many ways to spawn mobs. These do not typically have a need for types. They are legitimate, you can give them types if you want and spawn them. The PZ mobs are configurable in the PZ mod's own config files even.
This isn't a bug, its very much intended. If the mod author indicates that these entities should be passive spawning through the vanilla spawn system you should ask them to properly set the type of their entity: if not properly set, it will not count towards caps anyway which has been a major problem for users in the past.
The largest single source of NONEs is the witchesandmore.cfg that I referenced in the post just before this one. Some of those seem right... I'm guessing that the fish eggs are drop items that somehow ended up in the mob lists, but the fish themselves should be WATERCREATURES or maybe AMBIENT, to my thinking. And the various Knights and the Hill Giant, not sure what's up there. As WandM has its own config file that references spawn properties, I'm getting the sinking feeling that I'm going to need to deal with YAS (yet another spawner) and decide either to remove them from JAS spawning and hope for the best, or disable the WandM spawner and try to get the relevant mob attributes into JAS config files.
Trying to find out, left a message in the WandM thread. But there are some suggestive entries in the mods own config file. Perhaps these are just hooked into the vanilla spawn system, if such a thing is done.
This comment:
# Entity spawn values limited to integers from 0 thru 8.
And these example entries for the Angelfish:
I:"Angelfish Maximum number per spawn"=4
I:"Angelfish Minimum number per spawn"=2
B:"Angelfish Spawn enabled?"=true
I:"Angelfish Spawn frequency"=1
True. There is a spawnlist (for every biome) for each creature type. Technically, in vanilla, the EntityType and its spawnlist are seperate: meaning you can have a creature with no type or the wrong type in a spawnlist (which is very bad, as it won't count towards caps). JAS won't allow it, for obvious reason, so if the creature has no actual types but in vanilla was in a monster spawnlist, JAS will list it as type NONE. Typically not an issue, but it has come up on rare occasions.
I think your write about StructureSpawns, spawnlistentries will not persist for creature type == NONE. This is pretty much just for keeping configs a little cleaner for entries that are never used (NOTE: if shouldspawn is false or weight is 0, spawnlistentries should still persist).
All that gaurantees is that JAS won't spawn it. Anything else could; eggs, items, other spawners. I think that was your point, but thought it might be worth clarifying. JAS settings can only affect itself (ignoring the options like clearVanillaSpawnLists) and everything else continues as intended.
If the above scenario occured where it should be spawning but doens't in JAS because it didn't have a type then you could just give it a type and make the spawnlist entries regenerate (delete them).
Otherwise you'll need to talk to the author. Outside of MoCreatures and maybe one of the Pokemobs mod (it has a custom spawner IIRC) the above should work fine.
There is only structure support for Twilight Forest and vanilla structures. There is no global structure list-registry, so support must be added manually for each.
Importantly, Most structures do not actually have their own spawnlists. In the vanilla overworld only the witchhut does. Other overworld structures, such as the mineshaft, would normally draw from the biome spawnlist. JAS does have support to specify a custom spawnlist for mineshafts.
Villages generate villagers as the structure itself generates.
I can't speak to other mods villagers. I know forge has hooks to customize the villager entity.
Feel free to put them there. Just because the original author didn't have need doesn't mean you don't. I can't really comment on most of these.
Not through the spawner. Follower is spawned the centipede head-master piece to represent its 'tail'. Haunted armor are in spawners or just spawned by the cemetary when it generates. Horse Black is probably a PZ bug. Mimic spawned when various PZ structures are doing there generation. Minotaur is in spawners. Pharoad is summoned by the jasper block summoning ritual.
There are many ways to spawn mobs. These do not typically have a need for types. They are legitimate, you can give them types if you want and spawn them. The PZ mobs are configurable in the PZ mod's own config files even.
This isn't a bug, its very much intended. If the mod author indicates that these entities should be passive spawning through the vanilla spawn system you should ask them to properly set the type of their entity: if not properly set, it will not count towards caps anyway which has been a major problem for users in the past.
W&M has its own spawner?
I have some custom and one general purpose mob spawner blocks, but I do not have an in-game GUI entity spawner system such as this. All my entities are assigned an EnumCreatureType. I am heavily in the middle of developement builds and do not have the time to look into what information your mod is expecting to see but I am doing nothing out of the ordinary when it comes to registering my entities. I use only the registerModEntity method to register my entities which may or may not be what you are expecting. Mod authors should only be using this method though as there are only a limited number of entity IDs for the vanilla method.
Trying to find out, left a message in the WandM thread. But there are some suggestive entries in the mods own config file. Perhaps these are just hooked into the vanilla spawn system, if such a thing is done.
This comment:
# Entity spawn values limited to integers from 0 thru 8.
And these example entries for the Angelfish:
I:"Angelfish Maximum number per spawn"=4
I:"Angelfish Minimum number per spawn"=2
B:"Angelfish Spawn enabled?"=true
I:"Angelfish Spawn frequency"=1
These config settings are applied to the registerModEntity method at the time of registering the entity which is nothing out of the ordinary. For this mod (JAS) to work it makes adjustments to methods used after registering the entity which would ignore these settings as it would for vanilla mobs or any other normally registered entities.
These config settings are applied to the registerModEntity method at the time of registering the entity which is nothing out of the ordinary. For this mod (JAS) to work it makes adjustments to methods used after registering the entity which would ignore these settings as it would for vanilla mobs or any other normally registered entities.
If I'm following this correctly, the WandM mobs cited are supposed to spawn passively through the vanilla spawn system, they have an EnumCreatureType set for the call to registerModEntity, but when imported into JAS that EnumCreatureType is unrecognized or unavailable, or something else has gone amiss in the process or chain of assumptions.
But since I have almost no idea what I'm talking about, I have no idea what to do next.
Can I use NBTEdit to read the values for the entity type and reflect those values in the JAS configs for WandM? I don't mind some work, I just want everything to spawn (and despawn) the way the mod author intended it to and still have the option to configure it differently using the granularity of control available through JAS.
I have some custom and one general purpose mob spawner blocks, but I do not have an in-game GUI entity spawner system such as this. All my entities are assigned an EnumCreatureType. I am heavily in the middle of developement builds and do not have the time to look into what information your mod is expecting to see but I am doing nothing out of the ordinary when it comes to registering my entities. I use only the registerModEntity method to register my entities which may or may not be what you are expecting. Mod authors should only be using this method though as there are only a limited number of entity IDs for the vanilla method.
Worth noting is that with respect to registering methods the EnumCreatureType passed in when using EntityRegistry.addSpawn doesn't set the type of the entity; only the entity spawnlist it is in.
JAS looks for the EnumCreatureType(s) an entity counts towards via the Entity.isCreatureType method (used by SpawnerAnimals when counting). Which unless overidden in the entity class follows the following: implements IMob == MONSTER, extends EntityAnimal == CREATURE, extends EntityAmbientCreature == Ambient, extends EntityWaterMob == AMBIENT, otherwise doesn't count towards caps.
public boolean isCreatureType(EnumCreatureType type, boolean forSpawnCount)
{
return type.getCreatureClass().isAssignableFrom(this.getClass());
}
Worth noting is that with respect to registering methods the EnumCreatureType passed in when using EntityRegistry.addSpawn doesn't set the type of the entity; only the entity spawnlist it is in.
JAS looks for the EnumCreatureType(s) an entity counts towards via the Entity.isCreatureType method (used by SpawnerAnimals when counting). Which unless overidden in the entity class follows the following: implements IMob == MONSTER, extends EntityAnimal == CREATURE, extends EntityAmbientCreature == Ambient, extends EntityWaterMob == AMBIENT, otherwise doesn't count towards caps.
public boolean isCreatureType(EnumCreatureType type, boolean forSpawnCount)
{
return type.getCreatureClass().isAssignableFrom(this.getClass());
}
When I finally get to the planned improvements and updates to my existing entities I will add the method in each class where relevant. As I stated before I am in the middle of a great deal of change and additions to the mod that I have to complete first but it has been on my to-do list for some time.
I suggest you add a TO MOD AUTHORS section in the OP with what and where your mod expects to find the information it needs to function. Folks can then quote these requirements to the authors of mods they would like to ensure compatibility for. I for one do not have the time nor do I care to look through your code on Github.
Is there any way to control the crazyness that is chunk spawning? I want to use chunk spawning for creatures only, like cows and sheep, so they are present in the world as you explore, but spawn very slowly passively. but if I set S:Cow=25-1-1-1 on my cow... I get 1 cow every 10 steps or so, its like a massive overload of crazyness. XD
I tried to use the entity check to make it so it only spawns if no other cows are nearby but I think I formatted it wrong... (unless chunk spawns ignore that tag as well as cap?)
Could you give me an example of proper formatting of the entity tag for cows, adding it to my current tag set up for them??
Was there still a plan on adding a GUI for JAS someday? The /jas loadconfig is great, but I wish I could set some of the tags to a mob with a click. Like what block they can spawn on, etc. I get confused by the formatting of some of the tags when the spawn params get 5-6 tags long. XD
When I finally get to the planned improvements and updates to my existing entities I will add the method in each class where relevant. As I stated before I am in the middle of a great deal of change and additions to the mod that I have to complete first but it has been on my to-do list for some time.
I suggest you add a TO MOD AUTHORS section in the OP with what and where your mod expects to find the information it needs to function. Folks can then quote these requirements to the authors of mods they would like to ensure compatibility for. I for one do not have the time nor do I care to look through your code on Github.
I wasn't trying to suggest that you need to take action immediately or anything. There just didn't seem any point in waiting to have a conversation. Paths are best plotted knowing the terrain.
This isn't strictly compatability with my mod, its compatability with vanilla. If you are not overriding that method your entities that are spawning (though the passive spawning system only of course) will not count towards their appropriately caps and will lead to an unstable number of entities. This was (is?) a major problem people were having with MSC (also without it, which is why is a reason to install mob spawner mod). The first post of the spawning thread (http://www.minecraftforum.net/topic/1721480-mob-spawning-observations-and-tests-updated-82813/ ) at the bottom has an issue where my Finch entity was switched to being ambient and exploded into the spawn cap because it didn't count towards its cap. Obviously, that is the worst case scenario. If only one entity doesn't count towards a cap of creatures, for example, which spawn rarely its hardly going to cause overrage of thousands (which again, was an issue I had). Nearly all the PZ entities did not follow the standard type hierarchy which neccesitated the forge hook method isCreatureType to be added.
Thats a little long winded. I just wanted to be clear with the 'why' JAS expected assumes this information presnt. I was getting the impression that the thinking was this was something I arbitrarily patched via coremod for JAS as opposed to a forge patch for a vanilla problem (the first repo I linked to was Forge - I should have provided more context with those links than just dumping 300 lines of code).
Is there any way to control the crazyness that is chunk spawning? I want to use chunk spawning for creatures only, like cows and sheep, so they are present in the world as you explore, but spawn very slowly passively. but if I set S:Cow=25-1-1-1 on my cow... I get 1 cow every 10 steps or so, its like a massive overload of crazyness. XD
Increase the S:"Chunk Spawn Chance"=0.0 under CreatureType? (Note 1.0 would be always).
I tried to use the entity check to make it so it only spawns if no other cows are nearby but I think I formatted it wrong... (unless chunk spawns ignore that tag as well as cap?)
Could you give me an example of proper formatting of the entity tag for cows, adding it to my current tag set up for them??
:entities,Cow,minIsoSearchRange,maxIsoRange,MinCows,MaxCows so :&entities,Cow,0,6,0,3 ?
S:Cow=CREATURE-true{!spawn:ground:cap,35:&torchlight,0,6:&entities,Cow,0,6,0,3}
Was there still a plan on adding a GUI for JAS someday? The /jas loadconfig is great, but I wish I could set some of the tags to a mob with a click. Like what block they can spawn on, etc. I get confused by the formatting of some of the tags when the spawn params get 5-6 tags long. XD
Both Biomes O plenty and BiomesXL have a Redwood forest.
This for some reason prevents anything from JAS spawning into the redwood forest from one of them (not sure which one)... as there is only one redwood forest listed in the config file and you can't set the 'other' to have spawns.
Any way to have it notices that there are two biomes with the same name so it generates a config section for it?
Both Biomes O plenty and BiomesXL have a Redwood forest.
This for some reason prevents anything from JAS spawning into the redwood forest from one of them (not sure which one)... as there is only one redwood forest listed in the config file and you can't set the 'other' to have spawns.
Any way to have it notices that there are two biomes with the same name so it generates a config section for it?
Look at your biome mappings. There should be two redwood entries. extrabiomes.something.redwood= and bop.something.redwood=. Make sure the mappings are different.
How are the vanilla properties of de/spawning reflected in the default cfg files generated by JAS?
What I mean is, there is no {spawn:light, 8,15} (or {!spawn:light, 0, 7}) in any of
MONSTER in creatureType.cfg
skeleton in ModEntitySettings\Vanilla.cfg livinghandler
or the biome-specific spawnlist entries for skeleton.
What prevents skeletons from spawning in bright light?
Likewise, there is no {!despawn} for CREATURES in creatureType.cfg. What prevents CREATURES from despawning?
Also, is it the case that the 'torchlight' is the value that 'light' has when the sun is down, but 'torchlight' has that value even during daylight hours?
How are the vanilla properties of de/spawning reflected in the default cfg files generated by JAS?
What I mean is, there is no {spawn:light, 8,15} (or {!spawn:light, 0, 7}) in any of
MONSTER in creatureType.cfg
skeleton in ModEntitySettings\Vanilla.cfg livinghandler
or the biome-specific spawnlist entries for skeleton.
What prevents skeletons from spawning in bright light?
In the absence of a {despawn} or {spawn} tag despawning is done the same way as the vanilla spawn system does it.
For spawning, there is a modspawn tag such that you can get default behviour by {!spawn:modspawn} which you can further customize. The only implicit condition of {spawn} is that the bounding box is clear.
For despawning, a few values are implicit even with a blank {despawn}. Distance to player to start aging, instant despawn distance, age to actually have chance of despawning, and change of despawning. Most of these have 'global' config toggles (in either WorldProperties or GlobalProperties).
Also, is it the case that the 'torchlight' is the value that 'light' has when the sun is down, but 'torchlight' has that value even during daylight hours?
In the absence of a {despawn} or {spawn} tag despawning is done the same way as the vanilla spawn system does it.
But there is a spawn tag associated with skeletons, which seems to model some of the vanilla restrictions, but not all of them. It's from the optional tags of MONSTER in CreatureType.cfg:
{spawn:!solidside,1,0,[0/-1/0]:liquid,0:normal,0:normal,0,[0/1/0]:!opaque,0,[0/-1/0]}
If I read these correctly (probably not), this means spawn a MONSTER unless one or more of the following are true:
The top of the block beneath the candidate block is not solid (there is no mapping of integers to block sides in the wiki, I assume that 1 is the top face) e.g., no mob spawning on top of water, or air, or a partial block. (If I took this out, would monsters rain down from the heavens? AWESOME Note to self: Contact Mithion with an idea for an Ars Magica 2 spell!)
The candidate block is a liquid
The candidate block is a 'NormalCube' (no definition of NormalCube in the wiki)
The block above the candidate block is a 'NormalCube' (no definition of NormalCube in the wiki)
(I assume that the previous 2 restrictions prevent MONSTER spawning inside solid blocks, although if that's the case I wonder what prevents tall mobs from spawning with their heads in solid cubes)
The block beneath the candidate block is not opaque e.g., no spawning on top of glass.
Aren't these all part of the vanilla behavior for MONSTER type spawning? If so, why do they appear but the light level restriction does not?
But there is a spawn tag associated with skeletons, which seems to model some of the vanilla restrictions, but not all of them. It's from the optional tags of MONSTER in CreatureType.cfg:
{spawn:!solidside,1,0,[0/-1/0]:liquid,0:normal,0:normal,0,[0/1/0]:!opaque,0,[0/-1/0]}
If I read these correctly (probably not), this means spawn a MONSTER unless one or more of the following are true:
The top of the block beneath the candidate block is not solid (there is no mapping of integers to block sides in the wiki, I assume that 1 is the top face) e.g., the mob would be spawned standing on a non-solid block or a partial block.
The candidate block is a liquid
The candidate block is a 'NormalCube' (no definition of NormalCube in the wiki)
The block above the candidate block is a 'NormalCube' (no definition of NormalCube in the wiki)
(I assume that the previous 2 restrictions prevent MONSTER spawning inside solid blocks, although if that's the case I wonder what prevents tall mobs from spawning with their heads in solid cubes)
The block beneath the candidate block is not opaque e.g., no spawning on top of glass.
Aren't these all part of the vanilla behavior for MONSTER type spawning? If so, why do they appear but the light level restriction does not?
Thanks again.
Light restriction are actually done on the entity level (vanilla equivalent to 'living handler'), not by the creature type.
Light restriction are actually done on the entity level (vanilla equivalent to 'living handler'), not by the creature type.
But there are no light level spawn restrictions expressed at the skeleton level through JAS, so I need to know that skeleton spawning is light-level restricted intrinsic to the definition of a skeleton, and I get the desired behavior without needing to express it in JAS. When I import a mob from a mod, how do I find out what it's 'intrinsic' spawning properties are so that I know what needs to be changed, given that the entity-intrinsic properties are not expressed explicitly as tags for that entity when it is defined by JAS?
I can't really have control over this process until I know what happens if I do nothing. Looking at the JAS config for skeletons, I would think that they will spawn in any light condition, and if that's what I wanted I wouldn't bother to add a tag specifying it. The overall system behavior becomes the interaction of explicit behaviors defined through JAS, and hidden behaviors expressed at the entity level. What, in your opinion, is a good tool to glean custom mobs intrinsic spawn restrictions, so that I know the actual set of rules used to determine the result?
So I need to know that skeleton spawning is light-level restricted intrinsic to the definition of a skeleton, and I get the desired behavior without needing to express it in JAS. When I import a mob from a mod, how do I find out what it's 'intrinsic' entity properties are so that I know what needs to be changed, given that the entity-intrinsic properties are not expressed explicitly as tags for that entity when it is defined by JAS?
You don't need to make any changes to have it spawn as normal. Tags are optional. Creature type have tags by default, but I can get away with because that behavior is hard-coded in vanilla so I can replace them with equivalent tags.
To further elaborate on 'defaults'. Type, LivingHandler, and spawn-list defaults are all separate. Attaching {spawn} to creature type doesn't mean you must apply tags to living handler or spawn-list as well (Note: spawnlist has no default, doesn't do anything in vanilla). I think this might be a source of confusion? If you don't put {spawn} on the living handler: it has it using the 'default' methods. For skeleton that would include a light restriction.
Once you want to make changes you can either, as I mentioned earlier, use modspawn tag or instead approach from a 'how do I want it spawn'.
given that the entity-intrinsic properties are not expressed explicitly as tags for that entity when it is defined by JAS?
Just a quick comment that this would be impossible to do automagically. I can't reduce a full features programming language into a simple list of restriction. As mentioned before, creature type is only doable because they are static in vanilla.
I can't really have control over this process until I know what happens if I do nothing. The overall system behavior becomes the interaction of explicit behaviors defined through JAS, and hidden behaviors expressed nowhere visible.
The 'hidden aspects' are the mod java entity classes. They are written in java. In vanilla, each entity has a 'getCanSpawnhere()' method which determines if the entity can spawn at its location. By default, this is what done.
I'm not sure where you are getting the impression you need to add something (if you want to do nothing?). At most you might need to correct the imported settings. Type might be wrong/not what you want, or spawn-list weights/packsize are absent. Most times, this happens with mods with their spawner. There are exceptions, of course. But still, nothing to do with tags.
What, in your opinion, is a good tool to glean custom mobs intrinsic spawn restrictions, so that I know the actual set of rules used to determine the result?
To look at the code you would need to decompile it. Example: http://jd.benow.ca/ . This is probably one of those things that if you have to ask, you shouldn't do.
Obviously asking the author could work. But may be difficult to translate from java to 'layman' to tags when neither know each end of the system.
You don't need to make any changes to have it spawn as normal. Tags are optional. Creature type have tags by default, but I can get away with because that behavior is hard-coded in vanilla so I can replace them with equivalent tags.
What I mean is, from the perspective of a user trying to control the spawning of skeletons in a world, looking at the JAS config for skeletons, I would think that they will spawn in any light condition, and if that's what I wanted I wouldn't bother to add a tag specifying it. Only by trial and error would I discover something was amiss, and I would still have no recourse in determining why skeletons were not spawning where I want them. I was hoping for a way to look at the hidden filters that control the results... someway to know the actual set of rules that determine if a mob spawns.
Just a quick comment that this would be impossible to do automagically. I can't reduce a full features programming language into a simple list of restriction. As mentioned before, creature type is only doable because they are static in vanilla.
Here I was hoping that the MC code had by now evolved a more strongly typed data construct for spawn control than a block of free-form Java code that returns a boolean. SpawnControl.MaxYLevel and SpawnControl.MaxLight, etc, with the possibility of inheriting the class to extend it for special cases. As opposed to if (candidateBlock.coords.y > 90) return false; Given the latter, yes, clearly there is no way to parse the entity-hidden spawn restrictions into tags without some kind of AI process which would soon become self-aware. And nobody wants that.
Which means that if I ever want a mob to spawn with less restrictions than the mob author provided, I better somehow find out the restriction exists so that I know they need to be overriden.
Conversely, the moment I do apply a {spawn} tag, the entity's entire canSpawnHere method is obviated, and I just threw away an unknown number of spawn restrictions that maybe make sense for the mob.
Which sours me on this entire effort.
No complaints about JAS, it does what I now see to be an extraordinary job in the context of what Minecraft feebly modeled as a method that returns a boolean.
Now he's having a go at the squirrels! What don't you like about bunnies and squirrels??
Just shedding light on what I know of the mods in question (that hasn't been answered already).
The only NONE from Grimoire of Gaia 2 that sticks out is the Cyan Flower, as the others are merchants you summon via magic scrolls. The flower is an entity with very low HP and if it's killed can rarely drop an item but usually spawns a Mandragora mob to attack what killed the flower. I've seen MoCreatures BigCats eat them only to be brought down by the avenging Mandragora (pretty funny). If something like lava kills the flower, aggro seems to default to the nearby player but I'm not 100% sure on that. If you intend to let Mandragoras spawn passively (via JAS for example), the flowers aren't necessary. I've had success placing the flowers in OPENSKY alongside mod-added animals that despawn.
I'm not sure why Twilight Forest bunnies and squirrels would be classified as NONE. Depending on your setup, either CREATURE, OPENSKY, or AMBIENT would likely work though. I'm relatively sure that they both despawn by default, as opposed to deer or boars from TF. Hydra heads are NONE for reasons similar to PZ's Follower (they're not standalone mobs per se, but "attachments" to other mobs).
Rollback Post to RevisionRollBack
The config files are your friends! Get to know them, and shape your world!
True. There is a spawnlist (for every biome) for each creature type. Technically, in vanilla, the EntityType and its spawnlist are seperate: meaning you can have a creature with no type or the wrong type in a spawnlist (which is very bad, as it won't count towards caps). JAS won't allow it, for obvious reason, so if the creature has no actual types but in vanilla was in a monster spawnlist, JAS will list it as type NONE. Typically not an issue, but it has come up on rare occasions.
I think your write about StructureSpawns, spawnlistentries will not persist for creature type == NONE. This is pretty much just for keeping configs a little cleaner for entries that are never used (NOTE: if shouldspawn is false or weight is 0, spawnlistentries should still persist).
All that gaurantees is that JAS won't spawn it. Anything else could; eggs, items, other spawners. I think that was your point, but thought it might be worth clarifying. JAS settings can only affect itself (ignoring the options like clearVanillaSpawnLists) and everything else continues as intended.
If the above scenario occured where it should be spawning but doens't in JAS because it didn't have a type then you could just give it a type and make the spawnlist entries regenerate (delete them).
Otherwise you'll need to talk to the author. Outside of MoCreatures and maybe one of the Pokemobs mod (it has a custom spawner IIRC) the above should work fine.
There is only structure support for Twilight Forest and vanilla structures. There is no global structure list-registry, so support must be added manually for each.
Importantly, Most structures do not actually have their own spawnlists. In the vanilla overworld only the witchhut does. Other overworld structures, such as the mineshaft, would normally draw from the biome spawnlist. JAS does have support to specify a custom spawnlist for mineshafts.
Villages generate villagers as the structure itself generates.
I can't speak to other mods villagers. I know forge has hooks to customize the villager entity.
Feel free to put them there. Just because the original author didn't have need doesn't mean you don't. I can't really comment on most of these.
Not through the spawner. Follower is spawned the centipede head-master piece to represent its 'tail'. Haunted armor are in spawners or just spawned by the cemetary when it generates. Horse Black is probably a PZ bug. Mimic spawned when various PZ structures are doing there generation. Minotaur is in spawners. Pharoad is summoned by the jasper block summoning ritual.
There are many ways to spawn mobs. These do not typically have a need for types. They are legitimate, you can give them types if you want and spawn them. The PZ mobs are configurable in the PZ mod's own config files even.
This isn't a bug, its very much intended. If the mod author indicates that these entities should be passive spawning through the vanilla spawn system you should ask them to properly set the type of their entity: if not properly set, it will not count towards caps anyway which has been a major problem for users in the past.
W&M has its own spawner?
Trying to find out, left a message in the WandM thread. But there are some suggestive entries in the mods own config file. Perhaps these are just hooked into the vanilla spawn system, if such a thing is done.
This comment:
# Entity spawn values limited to integers from 0 thru 8.
And these example entries for the Angelfish:
I:"Angelfish Maximum number per spawn"=4
I:"Angelfish Minimum number per spawn"=2
B:"Angelfish Spawn enabled?"=true
I:"Angelfish Spawn frequency"=1
I have some custom and one general purpose mob spawner blocks, but I do not have an in-game GUI entity spawner system such as this. All my entities are assigned an EnumCreatureType. I am heavily in the middle of developement builds and do not have the time to look into what information your mod is expecting to see but I am doing nothing out of the ordinary when it comes to registering my entities. I use only the registerModEntity method to register my entities which may or may not be what you are expecting. Mod authors should only be using this method though as there are only a limited number of entity IDs for the vanilla method.
These config settings are applied to the registerModEntity method at the time of registering the entity which is nothing out of the ordinary. For this mod (JAS) to work it makes adjustments to methods used after registering the entity which would ignore these settings as it would for vanilla mobs or any other normally registered entities.
If I'm following this correctly, the WandM mobs cited are supposed to spawn passively through the vanilla spawn system, they have an EnumCreatureType set for the call to registerModEntity, but when imported into JAS that EnumCreatureType is unrecognized or unavailable, or something else has gone amiss in the process or chain of assumptions.
But since I have almost no idea what I'm talking about, I have no idea what to do next.
Can I use NBTEdit to read the values for the entity type and reflect those values in the JAS configs for WandM? I don't mind some work, I just want everything to spawn (and despawn) the way the mod author intended it to and still have the option to configure it differently using the granularity of control available through JAS.
Worth noting is that with respect to registering methods the EnumCreatureType passed in when using EntityRegistry.addSpawn doesn't set the type of the entity; only the entity spawnlist it is in.
JAS looks for the EnumCreatureType(s) an entity counts towards via the Entity.isCreatureType method (used by SpawnerAnimals when counting). Which unless overidden in the entity class follows the following: implements IMob == MONSTER, extends EntityAnimal == CREATURE, extends EntityAmbientCreature == Ambient, extends EntityWaterMob == AMBIENT, otherwise doesn't count towards caps.
public boolean isCreatureType(EnumCreatureType type, boolean forSpawnCount);
https://github.com/MinecraftForge/MinecraftForge/blob/master/patches/minecraft/net/minecraft/entity/Entity.java.patch
Project Zulu Example
https://github.com/ProjectZulu/Project-Zulu/blob/master/src/projectzulu/common/mobs/entity/EntityGenericAnimal.java
When I finally get to the planned improvements and updates to my existing entities I will add the method in each class where relevant. As I stated before I am in the middle of a great deal of change and additions to the mod that I have to complete first but it has been on my to-do list for some time.
I suggest you add a TO MOD AUTHORS section in the OP with what and where your mod expects to find the information it needs to function. Folks can then quote these requirements to the authors of mods they would like to ensure compatibility for. I for one do not have the time nor do I care to look through your code on Github.
I tried to use the entity check to make it so it only spawns if no other cows are nearby but I think I formatted it wrong... (unless chunk spawns ignore that tag as well as cap?)
Could you give me an example of proper formatting of the entity tag for cows, adding it to my current tag set up for them??
S:Cow=CREATURE-true{!spawn:ground:cap,35:&torchlight,0,6}
Was there still a plan on adding a GUI for JAS someday? The /jas loadconfig is great, but I wish I could set some of the tags to a mob with a click. Like what block they can spawn on, etc. I get confused by the formatting of some of the tags when the spawn params get 5-6 tags long. XD
I wasn't trying to suggest that you need to take action immediately or anything. There just didn't seem any point in waiting to have a conversation. Paths are best plotted knowing the terrain.
This isn't strictly compatability with my mod, its compatability with vanilla. If you are not overriding that method your entities that are spawning (though the passive spawning system only of course) will not count towards their appropriately caps and will lead to an unstable number of entities. This was (is?) a major problem people were having with MSC (also without it, which is why is a reason to install mob spawner mod). The first post of the spawning thread (http://www.minecraftforum.net/topic/1721480-mob-spawning-observations-and-tests-updated-82813/ ) at the bottom has an issue where my Finch entity was switched to being ambient and exploded into the spawn cap because it didn't count towards its cap. Obviously, that is the worst case scenario. If only one entity doesn't count towards a cap of creatures, for example, which spawn rarely its hardly going to cause overrage of thousands (which again, was an issue I had). Nearly all the PZ entities did not follow the standard type hierarchy which neccesitated the forge hook method isCreatureType to be added.
Thats a little long winded. I just wanted to be clear with the 'why' JAS expected assumes this information presnt. I was getting the impression that the thinking was this was something I arbitrarily patched via coremod for JAS as opposed to a forge patch for a vanilla problem (the first repo I linked to was Forge - I should have provided more context with those links than just dumping 300 lines of code).
Increase the S:"Chunk Spawn Chance"=0.0 under CreatureType? (Note 1.0 would be always).
Chunk spawns also ignore entity cap tag.
:entities,Cow,minIsoSearchRange,maxIsoRange,MinCows,MaxCows so :&entities,Cow,0,6,0,3 ?
S:Cow=CREATURE-true{!spawn:ground:cap,35:&torchlight,0,6:&entities,Cow,0,6,0,3}
There is.
Both Biomes O plenty and BiomesXL have a Redwood forest.
This for some reason prevents anything from JAS spawning into the redwood forest from one of them (not sure which one)... as there is only one redwood forest listed in the config file and you can't set the 'other' to have spawns.
Any way to have it notices that there are two biomes with the same name so it generates a config section for it?
Look at your biome mappings. There should be two redwood entries. extrabiomes.something.redwood= and bop.something.redwood=. Make sure the mappings are different.
What I mean is, there is no {spawn:light, 8,15} (or {!spawn:light, 0, 7}) in any of
MONSTER in creatureType.cfg
skeleton in ModEntitySettings\Vanilla.cfg livinghandler
or the biome-specific spawnlist entries for skeleton.
What prevents skeletons from spawning in bright light?
Likewise, there is no {!despawn} for CREATURES in creatureType.cfg. What prevents CREATURES from despawning?
Also, is it the case that the 'torchlight' is the value that 'light' has when the sun is down, but 'torchlight' has that value even during daylight hours?
In the absence of a {despawn} or {spawn} tag despawning is done the same way as the vanilla spawn system does it.
For spawning, there is a modspawn tag such that you can get default behviour by {!spawn:modspawn} which you can further customize. The only implicit condition of {spawn} is that the bounding box is clear.
For despawning, a few values are implicit even with a blank {despawn}. Distance to player to start aging, instant despawn distance, age to actually have chance of despawning, and change of despawning. Most of these have 'global' config toggles (in either WorldProperties or GlobalProperties).
Despawning is only done at the entity level. i.e. 'living handlers' as per the wiki. https://github.com/Crudedragos/JustAnotherSpawner/wiki/Tags#living-handler . SpawnListEntries and EntityTypes do not accept despawn tags.
Yes.
For comlex tag combinations remember you can check if its working as you expect using /jas canspawnhere https://github.com/Crudedragos/JustAnotherSpawner/wiki/Commands#analytics-commands .
But there is a spawn tag associated with skeletons, which seems to model some of the vanilla restrictions, but not all of them. It's from the optional tags of MONSTER in CreatureType.cfg:
{spawn:!solidside,1,0,[0/-1/0]:liquid,0:normal,0:normal,0,[0/1/0]:!opaque,0,[0/-1/0]}
If I read these correctly (probably not), this means spawn a MONSTER unless one or more of the following are true:
Aren't these all part of the vanilla behavior for MONSTER type spawning? If so, why do they appear but the light level restriction does not?
Thanks again.
Light restriction are actually done on the entity level (vanilla equivalent to 'living handler'), not by the creature type.
But there are no light level spawn restrictions expressed at the skeleton level through JAS, so I need to know that skeleton spawning is light-level restricted intrinsic to the definition of a skeleton, and I get the desired behavior without needing to express it in JAS. When I import a mob from a mod, how do I find out what it's 'intrinsic' spawning properties are so that I know what needs to be changed, given that the entity-intrinsic properties are not expressed explicitly as tags for that entity when it is defined by JAS?
I can't really have control over this process until I know what happens if I do nothing. Looking at the JAS config for skeletons, I would think that they will spawn in any light condition, and if that's what I wanted I wouldn't bother to add a tag specifying it. The overall system behavior becomes the interaction of explicit behaviors defined through JAS, and hidden behaviors expressed at the entity level. What, in your opinion, is a good tool to glean custom mobs intrinsic spawn restrictions, so that I know the actual set of rules used to determine the result?
You don't need to make any changes to have it spawn as normal. Tags are optional. Creature type have tags by default, but I can get away with because that behavior is hard-coded in vanilla so I can replace them with equivalent tags.
To further elaborate on 'defaults'. Type, LivingHandler, and spawn-list defaults are all separate. Attaching {spawn} to creature type doesn't mean you must apply tags to living handler or spawn-list as well (Note: spawnlist has no default, doesn't do anything in vanilla). I think this might be a source of confusion? If you don't put {spawn} on the living handler: it has it using the 'default' methods. For skeleton that would include a light restriction.
Once you want to make changes you can either, as I mentioned earlier, use modspawn tag or instead approach from a 'how do I want it spawn'.
Just a quick comment that this would be impossible to do automagically. I can't reduce a full features programming language into a simple list of restriction. As mentioned before, creature type is only doable because they are static in vanilla.
The 'hidden aspects' are the mod java entity classes. They are written in java. In vanilla, each entity has a 'getCanSpawnhere()' method which determines if the entity can spawn at its location. By default, this is what done.
I'm not sure where you are getting the impression you need to add something (if you want to do nothing?). At most you might need to correct the imported settings. Type might be wrong/not what you want, or spawn-list weights/packsize are absent. Most times, this happens with mods with their spawner. There are exceptions, of course. But still, nothing to do with tags.
To look at the code you would need to decompile it. Example: http://jd.benow.ca/ . This is probably one of those things that if you have to ask, you shouldn't do.
Obviously asking the author could work. But may be difficult to translate from java to 'layman' to tags when neither know each end of the system.
What I mean is, from the perspective of a user trying to control the spawning of skeletons in a world, looking at the JAS config for skeletons, I would think that they will spawn in any light condition, and if that's what I wanted I wouldn't bother to add a tag specifying it. Only by trial and error would I discover something was amiss, and I would still have no recourse in determining why skeletons were not spawning where I want them. I was hoping for a way to look at the hidden filters that control the results... someway to know the actual set of rules that determine if a mob spawns.
Here I was hoping that the MC code had by now evolved a more strongly typed data construct for spawn control than a block of free-form Java code that returns a boolean. SpawnControl.MaxYLevel and SpawnControl.MaxLight, etc, with the possibility of inheriting the class to extend it for special cases. As opposed to if (candidateBlock.coords.y > 90) return false; Given the latter, yes, clearly there is no way to parse the entity-hidden spawn restrictions into tags without some kind of AI process which would soon become self-aware. And nobody wants that.
Which means that if I ever want a mob to spawn with less restrictions than the mob author provided, I better somehow find out the restriction exists so that I know they need to be overriden.
Conversely, the moment I do apply a {spawn} tag, the entity's entire canSpawnHere method is obviated, and I just threw away an unknown number of spawn restrictions that maybe make sense for the mob.
Which sours me on this entire effort.
No complaints about JAS, it does what I now see to be an extraordinary job in the context of what Minecraft feebly modeled as a method that returns a boolean.
Just shedding light on what I know of the mods in question (that hasn't been answered already).
The only NONE from Grimoire of Gaia 2 that sticks out is the Cyan Flower, as the others are merchants you summon via magic scrolls. The flower is an entity with very low HP and if it's killed can rarely drop an item but usually spawns a Mandragora mob to attack what killed the flower. I've seen MoCreatures BigCats eat them only to be brought down by the avenging Mandragora (pretty funny). If something like lava kills the flower, aggro seems to default to the nearby player but I'm not 100% sure on that. If you intend to let Mandragoras spawn passively (via JAS for example), the flowers aren't necessary. I've had success placing the flowers in OPENSKY alongside mod-added animals that despawn.
I'm not sure why Twilight Forest bunnies and squirrels would be classified as NONE. Depending on your setup, either CREATURE, OPENSKY, or AMBIENT would likely work though. I'm relatively sure that they both despawn by default, as opposed to deer or boars from TF. Hydra heads are NONE for reasons similar to PZ's Follower (they're not standalone mobs per se, but "attachments" to other mobs).