i found some issues on nether with mo creatures
first the wolf not spawn on nether
and the werewolf too only the fire werewolf spawn on nether
and the silver skeleton only spawn at surface at night or in caves and not on the nether
and these issues only occurs with jas
but i noticied that werewolfs dont spawn at all in the nether
did you fixed the mo creatures mobs wrong placed in the nether ?
what you actually meant was
did you fixed the mo creatures mobs not placed in the nether.
Firstly wolves have never spawned there as far as im aware. I would think they have a default hard coded spawn condition of spawn on dirt/sand/stone/wood and so they may not spawn on netherrack (without using JAS tags/MVEL expression). Since I dont think mo creatures naturally assigns wolves to the nether youd also need to set it to spawn there.
You say only fire werewolves spawn in nether (normal as far as I know) but then say werewolves dont spawn at all. So do you get fire werewolves or none ? Id guess that you are getting them and that you saying they are not is just not having seen one for ages.
With the silver skeleton again this mob has never spawned in the nether as far as I know. Issues with that not spawning there (if you have set it too) will be similar to the wolf above I imagine.
"and these issues only occurs with jas"
Its not clear to me that there are issues with JAS not placing mobs in the nether. You are saying if you use CMS instead of JAS you get wolves and silver skeletons in the nether ?
the default mo creatures dont spawn these mobs in the nether if you look on the wiki you will see
As far as I can tell the vanilla spawnlist when BoP and MoC are present includes Werewolves in BoP nether biomes. I've adjusted the most recent version to print the imported list for reference. This looks like a MoC-BoP issue.
I have noticed all my mobs moving a litle bit derpyish/teleportish/lagish. I hadnt even started trying to work out what was responsible. Ive seen dodgy mods (witches and more) do that to a game environment before. Maybe if im lucky the new version of JAS will remove that slight effect.
Tick lag. JAS is heavier than v0.14.13. The costs come from two fronts. First, MVEL provides more rubust parsing, but at a evaluation cost. Second, the spawn loop was altered to expose the chosen entity sooner. Thus results in the entity selection running more often than previously, increasing cost. There have been, including the latest, updates with some optimizations to bring it down for maxxed out set-ups.
Some things that can be done in JAS; make sure any creature types that aren't be used are deleted (if they never fill, JAS has to keep trying to 'fill' their cap), increase creaturetype spawnrate from 1 to ~20.
Progress is moving slowly towards support for alternative spawners i.e. a light weight minimal feature spawner. Just not sure if it should be MVEL or TAG based. Optimization is slow business.
from globalproperties.cfg. I dont remember that setting having the word vanilla present before. Does that mean JAS will chunk spawn entities using its own settings when the above line is true ? Or will that prevent all chunk spawning. (which if I remember rightly was how it worked before).
It cancels the ChunkSpawn forge event, which will prevent all chunk spawning that uses it. JAS chunk spawning is unaffected by that settings and would continue as normal.
Am i missing something? I'm getting the following spammed in my server console.
No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:06 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:06 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:06 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:12 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
I'm using the config files listed earlier in this thread. I'm also having terrible problems on my server using JAS/Mocreatures if i get more than 2 people on my TPS tanks. I can disable JAS and my tps is constant with 3+ people. Do i have something configured wrong? Any suggestions?
So I'm still playing around with balancing and I did a clean generation of spawn lists using the latest Jas 16.11 and with Lycanite mobs I noticed something I hadn't seen before. Lycanites apparently defines a couple of other spawn types: SKY, FROSTFIRE, WATER (not WATERCREATURE), etc. and when I run JaS on a cleaned configuration directory it ends up listing mobs with those other tags as type "NONE" and shows no details in the spawn lists for them.
I'm going to adjust those manually to the recognized groups to capture their spawn details, but I curious about the various recognized groups like MONSTER and CREATURE. Are those "built in" to the game and others are not recognized?
I believe you can define your own entitiy categories. AMBIENT MONSTER CREATURE and WATERCREATURE are built into MC yes (or possibly just JAS constructs that simulate the conditions for all mobs in vanilla, still effectively yes to built in). OPENSKY and UNDERGROUND were almost examples of creating an entity class that became part of the mod as it developed.
Ive heard tell of Lycanites mobs spawning by events, hence some of them may be set to NONE so that they dont spawn through the regular JAS spawner only by lycanites desired spawn conditions.
Because JAS can define other entity groups I guess it has imported FROSTFIRE SKY and WATER though I have no idea what any of that means.
Actually JAS is not importing those others. I know that I can define my own in JAS but what I'm seeing is since these mobs in Lyncanites are using these other types, on initial startup JAS does not recognize them so it treats them as "NONE" and does not import their settings. Adding a "MONSTER" or "CREATURE" tag in the Lycanites configurations will allow JAS to see them and pull them in their base spawn details.
But these types are interesting for another reason. SKY and MC OPENSKY appear to be similar enough to use, but there are mobs like the Afrit that are listed as a LAVA type that should only spawn in lava. I'm looking into how to define spawn tags to support that, I think that one should be doable.
But a couple of others, namely ROCK and CROP, only spawn on player actions. ROCK types spawn when a player is mining stone, CROP on things like cutting down trees. With JAS is it possible to define spawn tags that are based on the player actions like these in Lycanites?
Dulciphi can probably help you more than me. I have no experience of lycanites. I was wondering how/why JAS was importing an entity class seemed a bit weird. makes more sense now.
Lycanites has been discussed on here but I cant remember any solutions to getting JAS to spawn on events. (not saying there isnt a way).
This isn't for the events (I actually turn those off), this is for spawning the mobs in general like the Roc or the Raiko that are flying mobs, or the Zephyr that spawns only during storms. One thing I noticed is that unless you set each mob's enabled flag to false in the Lycanite configs it will be spawned by Lycanites even if JAS is loaded. I had set the global flags to do not spawn but it didn't seem to stop the spawns, it was only after I set their individual spawn flags each to false that stopped them. I think maybe this is why because those that were spawning were type NONE to JAS meaning it ignored them, but Lycanite's built in custom spawner did not ignore them.
Actually JAS is not importing those others. I know that I can define my own in JAS but what I'm seeing is since these mobs in Lyncanites are using these other types, on initial startup JAS does not recognize them so it treats them as "NONE" and does not import their settings. Adding a "MONSTER" or "CREATURE" tag in the Lycanites configurations will allow JAS to see them and pull them in their base spawn details.
But these types are interesting for another reason. SKY and MC OPENSKY appear to be similar enough to use, but there are mobs like the Afrit that are listed as a LAVA type that should only spawn in lava. I'm looking into how to define spawn tags to support that, I think that one should be doable.
But a couple of others, namely ROCK and CROP, only spawn on player actions. ROCK types spawn when a player is mining stone, CROP on things like cutting down trees. With JAS is it possible to define spawn tags that are based on the player actions like these in Lycanites?
It's good to see I'm not the only one who's very interested in get those event type spawns into JAS. JAS has traditionally focused on passive spawn conditions - so that where a certain condition exists (has spawnlist entry for that biome, is dark, cannot see sky, etc) the entity *may* spawn.
On the contrary, Lycanite's event spawns (SLEEP, DEATH, CROP, ROCK) use an active type of spawning system. Ie it's triggered by a weighted chance *as soon as the triggering event takes place*.
Crudedragos is (I believe) working on a system that would enable JAS to replicate that active spawning system of Lycanite's event spawns. This is something I'd absolutely love - and from reading requests on the Lycanite's thread, a lot of others would love it too. I'll give a quick example of the Lycanite's Phantom. It spawns when a player kills an entity. The Phantom's DEATH spawn condition has no restrictions other than a weighted chance - so new players who have just spawned can trigger a Phantom spawn the very first time they kill a sheep. This is why people have been asking for a way to limit the event spawns.
By combining the powerful spawn restriction tags of JAS with the active event spawns that Lycanite uses, we'd be able to tell the Phantom to only spawn 2000 blocks or more from spawn. That would ensure that new players weren't being kept in perpetual early game by impossibly hard event spawns. Additionally, we'd be able to use the event spawns to spawn whatever entity we wanted from the on-player-kill-entity event.
I had been trying to limit the DEATH events to 2000 blocks from spawn using the existing JAS methods but it wasn't working. See this JAS github issue for more info. It was only after I'd started really looking into the event spawns that I discovered Father Toast (of Special Mobs fame) has devised such a system with his Mob Properties mod. I've been busy with Ancient Warfare recently but the moment I'm able to write up some working tags for the Phantom using that, I'll share them.
Reading through the code for both Lycanites and JAS, I don't think it is going to be possible with the current JAS code to duplicate some of the Lycanite spawning conditions. For the LAVA types, if in a JAS spawn tag you can access the util functions (TagsUtility) and add a check for a material() of type "lava", that might work for the LAVA type creatures. SKY can use OPENSKY for the most part so that should be fine.
But for the ones that spawn based on specific conditions such as players harvesting crops (CROP type) or stone (ROCK type) I'm guessing the best to do there is simply set basic spawn setting values to use for them.
Regarding the use of the TagUtility.material() check, since the Material is a class and not an enumerated type, in the MVEL how would I go about providing the Material.lava? Do I just write the MVEL as
util.material(Material.lava)
and it will pull in the static instance correctly for the check?
It's good to see I'm not the only one who's very interested in get those event type spawns into JAS. JAS has traditionally focused on passive spawn conditions - so that where a certain condition exists (has spawnlist entry for that biome, is dark, cannot see sky, etc) the entity *may* spawn.
On the contrary, Lycanite's event spawns (SLEEP, DEATH, CROP, ROCK) use an active type of spawning system. Ie it's triggered by a weighted chance *as soon as the triggering event takes place*.
Crudedragos is (I believe) working on a system that would enable JAS to replicate that active spawning system of Lycanite's event spawns. This is something I'd absolutely love - and from reading requests on the Lycanite's thread, a lot of others would love it too. I'll give a quick example of the Lycanite's Phantom. It spawns when a player kills an entity. The Phantom's DEATH spawn condition has no restrictions other than a weighted chance - so new players who have just spawned can trigger a Phantom spawn the very first time they kill a sheep. This is why people have been asking for a way to limit the event spawns.
By combining the powerful spawn restriction tags of JAS with the active event spawns that Lycanite uses, we'd be able to tell the Phantom to only spawn 2000 blocks or more from spawn. That would ensure that new players weren't being kept in perpetual early game by impossibly hard event spawns. Additionally, we'd be able to use the event spawns to spawn whatever entity we wanted from the on-player-kill-entity event.
I had been trying to limit the DEATH events to 2000 blocks from spawn using the existing JAS methods but it wasn't working. See this JAS github issue for more info. It was only after I'd started really looking into the event spawns that I discovered Father Toast (of Special Mobs fame) has devised such a system with his Mob Properties mod. I've been busy with Ancient Warfare recently but the moment I'm able to write up some working tags for the Phantom using that, I'll share them.
Thanks for the write up, looks like we're both digging into the depths of this for the same reasons. Perhaps with the new scripting language in use, it might give Crudedragos more flexibility to add supporting library functions that would make some of this possible.
And also thanks for the hint on the Mob Properties. I already use a couple of Father Toasts's mods (Natural Absorption, Utility Mobs, and Special Mobs), I'll have to see what I can do with this one.
Am i missing something? I'm getting the following spammed in my server console.
No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:06 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:06 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:06 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:12 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
That would be due to you not using all the mods used in the configs. That message is during chunk spawning when a spawnlistentry doesn't map to a valid entity to spawn.
If you go to \JustAnotherSpawner\WorldSettings\DEFAULT\SpawnListEntries\ and delete all the modIDs not in your mod setup the error should subside. You can also do this to the LivingHandlers under \JustAnotherSpawner\WorldSettings\DEFAULT\EntityHandlers\.
I'm using the config files listed earlier in this thread. I'm also having terrible problems on my server using JAS/Mocreatures if i get more than 2 people on my TPS tanks. I can disable JAS and my tps is constant with 3+ people. Do i have something configured wrong? Any suggestions?
Under CreatureType increase the "Spawn Rate": 1. Each type is processed when remainder of time / 'Spawn Rate' == 0. You could make sure each is not divisible so that they happen on their own 'tick'. i.e. MONSTER == 11, AMBIENT == 17, WATERCREATURE == 19, UNDERGROUND == 23, OPENSKY == 29, CREATURE == 401.
Otherwise, general things such as reduce type caps (CreatureType.cfg) or chunk count/spawn distance (under GeneralProperties).
Regarding the use of the TagUtility.material() check, since the Material is a class and not an enumerated type, in the MVEL how would I go about providing the Material.lava? Do I just write the MVEL as
util.material(Material.lava)
and it will pull in the static instance correctly for the check?
wrld.materialAt(int coordX, int coordY, int coordZ) returns a Material instance. So util.material(wrld.materialAt(int coordX, int coordY, int coordZ)) returns the String name of the material. Also of note obj.material() returns the Material String name at the current spawn position.
So the expression trying to match lava would be 'lava'.equals(util.material(wrld.materialAt(posX + 0, posY - 0, posZ + 0))) or 'lava'.equals(obj.material()).
Perhaps with the new scripting language in use, it might give Crudedragos more flexibility to add supporting library functions that would make some of this possible.
Progress is moving slowly towards support for alternative spawners i.e. a light weight minimal feature spawner. Just not sure if it should be MVEL or TAG based. Optimization is slow business.
My opinion - make the light version TAG based. Essentially what you had with v0.14.13. Perhaps tweak a few of the default settings. If players wish to upgrade to the MVEL system, they can do so easily.
Do you think it might work to use both Lycanite's custom spawner and JAS? What I'm thinking is, for the traditional Monster/Creature types set them inside of Lycanite settings as spawn=false and let JAS manage those. But for the non-traditional like the Grue or Afrit or other's that spawn on event, set their type in JAS to NONE (which is what happens by JAS by default), leave thir Lycanite settings to spawn=true.
I have only surface reviewed the Lycanite spawning code but do you think that would work?
Do you think it might work to use both Lycanite's custom spawner and JAS? What I'm thinking is, for the traditional Monster/Creature types set them inside of Lycanite settings as spawn=false and let JAS manage those. But for the non-traditional like the Grue or Afrit or other's that spawn on event, set their type in JAS to NONE (which is what happens by JAS by default), leave thir Lycanite settings to spawn=true.
I have only surface reviewed the Lycanite spawning code but do you think that would work?
Definitely. It's pretty much exactly what I do. So in the main lycanitesmobs-spawning.cfg file, I have
"global spawning" {
B:"Disable Spawning"=true
B:"Enforce Block Costs"=true
D:"Mob Limit Search Range"=32.0
D:"Weight Scale"=1.0
}
That *does not* disable the individual event spawners though. Just the passive spawns, which I then set up through JAS. It's a system I've been using to good effect for a while now.
Then for the event spawns, further down in the same config file there's
Still having issues spawning. But it turns out it wasn't water creatures. It is MoCreatures EVERYTHING (I just happened to only have the fish from mocreatures trying to spawn and never gave a thought to anything else from that mod). they are all stating "livinghandler cannot spawn".
Since they are showing up in my spawnlistentries but not actually spawning, and they all have the default spawning settings put on by jas when it generates, does this mean that JAS is detecting the mobs are installed, but something from that mod are preventing them from being spawned???
Still having issues spawning. But it turns out it wasn't water creatures. It is MoCreatures EVERYTHING (I just happened to only have the fish from mocreatures trying to spawn and never gave a thought to anything else from that mod). they are all stating "livinghandler cannot spawn".
Since they are showing up in my spawnlistentries but not actually spawning, and they all have the default spawning settings put on by jas when it generates, does this mean that JAS is detecting the mobs are installed, but something from that mod are preventing them from being spawned???
I've been really confused about this because I have MoCreatures watercreatures spawning. Jellyfish, sharks, dolphins.. all sizes of fish.. everything except for Piranha cause I dislike them. Or did I set them to spawn in jungles and just haven't checked the jungle waters yet? ..could be the latter. I'd like to know what I'm doing different though.
Still having issues spawning. But it turns out it wasn't water creatures. It is MoCreatures EVERYTHING (I just happened to only have the fish from mocreatures trying to spawn and never gave a thought to anything else from that mod). they are all stating "livinghandler cannot spawn".
Since they are showing up in my spawnlistentries but not actually spawning, and they all have the default spawning settings put on by jas when it generates, does this mean that JAS is detecting the mobs are installed, but something from that mod are preventing them from being spawned???
Yes, every entity has a mod specified spawn condition that must be met.
Let me know some of the specific entities you've tested and where you've tested them (preferably vanilla biomes, even better if flatland) and I'll give it a try.
When building biomegroups, how important is it to be able to include biomegroups in biomegroups.
Currently we have BiomeGroup/AttributeGrous of composed of other groups and only other groups. i..e "BiomGroup": { "Beach": "A|All-G|Desert-A|Hot"
I'm looking at moving to a more flexible methodology, where a biomegroup can be defined by other groups as well as other properties biomegen class (i.e. temperature, heightvariation, rainfall, enablesnow, enablerain, etc.) (on loading, not based on conditions that may change in the biome over time in game).
This would be of the form "BiomeGroup": { "Beach": "(A.All).rem('A.Hot').rainfall(0.85,-1).snowenabled()" or possibly "BiomeGroup": { "Beach": "($.enablesnow || $.isHighHumidity()) in ((A.All).rem('A.Hot'))"
The 'issue' with the alternative formatting is resolving dependencies becomes impossible. Requiring removal of the ability to remove BiomeGroups in Biomegroups / Attributes in Attributes OR guaranteeing the order read is always the same as written (which gets tricky later if editing at runtime is added, i.e a gui / in game commands are supported)
but i noticied that werewolfs dont spawn at all in the nether
NO I AM SAYING THAT THESE CREATURES SHOULD NOT SPAWN IN THE NETHER
http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1288431-just-another-spawner-jas-v0-14?comment=1670
ops forgot to mention that this happened with biomes o plenty
* Export ImportedSpawnlist to "ImportedSpawnlists.cfg"
Changelog: https://github.com/ProjectZulu/JustAnotherSpawner/wiki/Changelog
Download: http://projectzulu.blogspot.ca/p/downloads.html
No. As I haven't had time to look where the problem may be, if there is one at all.
As far as I can tell the vanilla spawnlist when BoP and MoC are present includes Werewolves in BoP nether biomes. I've adjusted the most recent version to print the imported list for reference. This looks like a MoC-BoP issue.
Tick lag. JAS is heavier than v0.14.13. The costs come from two fronts. First, MVEL provides more rubust parsing, but at a evaluation cost. Second, the spawn loop was altered to expose the chosen entity sooner. Thus results in the entity selection running more often than previously, increasing cost. There have been, including the latest, updates with some optimizations to bring it down for maxxed out set-ups.
Some things that can be done in JAS; make sure any creature types that aren't be used are deleted (if they never fill, JAS has to keep trying to 'fill' their cap), increase creaturetype spawnrate from 1 to ~20.
For anyone who hasn't/ is interseted in optimizing their setup they should link into using a profiler (the idea is the same for serve or client). The following is a decent explanation http://www.sk89q.com/2013/03/improving-your-minecraft-servers-performance/
or http://bukkit.org/threads/wip-analysis-of-your-server-jvm-using-visualvm.66536/
Progress is moving slowly towards support for alternative spawners i.e. a light weight minimal feature spawner. Just not sure if it should be MVEL or TAG based. Optimization is slow business.
It cancels the ChunkSpawn forge event, which will prevent all chunk spawning that uses it. JAS chunk spawning is unaffected by that settings and would continue as normal.
Yes.
No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:06 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:06 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:06 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
[23:56:12 ERROR]: No EntityClasses appear to exist in jas.spawner.modern.spawner.creature.entry.SpawnListEntry@7d8c2529
I'm using the config files listed earlier in this thread. I'm also having terrible problems on my server using JAS/Mocreatures if i get more than 2 people on my TPS tanks. I can disable JAS and my tps is constant with 3+ people. Do i have something configured wrong? Any suggestions?
I'm going to adjust those manually to the recognized groups to capture their spawn details, but I curious about the various recognized groups like MONSTER and CREATURE. Are those "built in" to the game and others are not recognized?
Actually JAS is not importing those others. I know that I can define my own in JAS but what I'm seeing is since these mobs in Lyncanites are using these other types, on initial startup JAS does not recognize them so it treats them as "NONE" and does not import their settings. Adding a "MONSTER" or "CREATURE" tag in the Lycanites configurations will allow JAS to see them and pull them in their base spawn details.
But these types are interesting for another reason. SKY and MC OPENSKY appear to be similar enough to use, but there are mobs like the Afrit that are listed as a LAVA type that should only spawn in lava. I'm looking into how to define spawn tags to support that, I think that one should be doable.
But a couple of others, namely ROCK and CROP, only spawn on player actions. ROCK types spawn when a player is mining stone, CROP on things like cutting down trees. With JAS is it possible to define spawn tags that are based on the player actions like these in Lycanites?
This isn't for the events (I actually turn those off), this is for spawning the mobs in general like the Roc or the Raiko that are flying mobs, or the Zephyr that spawns only during storms. One thing I noticed is that unless you set each mob's enabled flag to false in the Lycanite configs it will be spawned by Lycanites even if JAS is loaded. I had set the global flags to do not spawn but it didn't seem to stop the spawns, it was only after I set their individual spawn flags each to false that stopped them. I think maybe this is why because those that were spawning were type NONE to JAS meaning it ignored them, but Lycanite's built in custom spawner did not ignore them.
It's good to see I'm not the only one who's very interested in get those event type spawns into JAS. JAS has traditionally focused on passive spawn conditions - so that where a certain condition exists (has spawnlist entry for that biome, is dark, cannot see sky, etc) the entity *may* spawn.
On the contrary, Lycanite's event spawns (SLEEP, DEATH, CROP, ROCK) use an active type of spawning system. Ie it's triggered by a weighted chance *as soon as the triggering event takes place*.
Crudedragos is (I believe) working on a system that would enable JAS to replicate that active spawning system of Lycanite's event spawns. This is something I'd absolutely love - and from reading requests on the Lycanite's thread, a lot of others would love it too. I'll give a quick example of the Lycanite's Phantom. It spawns when a player kills an entity. The Phantom's DEATH spawn condition has no restrictions other than a weighted chance - so new players who have just spawned can trigger a Phantom spawn the very first time they kill a sheep. This is why people have been asking for a way to limit the event spawns.
By combining the powerful spawn restriction tags of JAS with the active event spawns that Lycanite uses, we'd be able to tell the Phantom to only spawn 2000 blocks or more from spawn. That would ensure that new players weren't being kept in perpetual early game by impossibly hard event spawns. Additionally, we'd be able to use the event spawns to spawn whatever entity we wanted from the on-player-kill-entity event.
I had been trying to limit the DEATH events to 2000 blocks from spawn using the existing JAS methods but it wasn't working. See this JAS github issue for more info. It was only after I'd started really looking into the event spawns that I discovered Father Toast (of Special Mobs fame) has devised such a system with his Mob Properties mod. I've been busy with Ancient Warfare recently but the moment I'm able to write up some working tags for the Phantom using that, I'll share them.
But for the ones that spawn based on specific conditions such as players harvesting crops (CROP type) or stone (ROCK type) I'm guessing the best to do there is simply set basic spawn setting values to use for them.
Regarding the use of the TagUtility.material() check, since the Material is a class and not an enumerated type, in the MVEL how would I go about providing the Material.lava? Do I just write the MVEL as
util.material(Material.lava)
and it will pull in the static instance correctly for the check?
Thanks for the write up, looks like we're both digging into the depths of this for the same reasons. Perhaps with the new scripting language in use, it might give Crudedragos more flexibility to add supporting library functions that would make some of this possible.
And also thanks for the hint on the Mob Properties. I already use a couple of Father Toasts's mods (Natural Absorption, Utility Mobs, and Special Mobs), I'll have to see what I can do with this one.
That would be due to you not using all the mods used in the configs. That message is during chunk spawning when a spawnlistentry doesn't map to a valid entity to spawn.
If you go to \JustAnotherSpawner\WorldSettings\DEFAULT\SpawnListEntries\ and delete all the modIDs not in your mod setup the error should subside. You can also do this to the LivingHandlers under \JustAnotherSpawner\WorldSettings\DEFAULT\EntityHandlers\.
Under CreatureType increase the "Spawn Rate": 1. Each type is processed when remainder of time / 'Spawn Rate' == 0. You could make sure each is not divisible so that they happen on their own 'tick'. i.e. MONSTER == 11, AMBIENT == 17, WATERCREATURE == 19, UNDERGROUND == 23, OPENSKY == 29, CREATURE == 401.
Otherwise, general things such as reduce type caps (CreatureType.cfg) or chunk count/spawn distance (under GeneralProperties).
wrld.materialAt(int coordX, int coordY, int coordZ) returns a Material instance. So util.material(wrld.materialAt(int coordX, int coordY, int coordZ)) returns the String name of the material. Also of note obj.material() returns the Material String name at the current spawn position.
So the expression trying to match lava would be 'lava'.equals(util.material(wrld.materialAt(posX + 0, posY - 0, posZ + 0))) or 'lava'.equals(obj.material()).
It does. Feel free to create an issue(s) on the Github page with any functions / helpers you feel deserve helpers / could be made easier.
https://github.com/ProjectZulu/JustAnotherSpawner/issues
My opinion - make the light version TAG based. Essentially what you had with v0.14.13. Perhaps tweak a few of the default settings. If players wish to upgrade to the MVEL system, they can do so easily.
I have only surface reviewed the Lycanite spawning code but do you think that would work?
Definitely. It's pretty much exactly what I do. So in the main lycanitesmobs-spawning.cfg file, I have
"global spawning" {
B:"Disable Spawning"=true
B:"Enforce Block Costs"=true
D:"Mob Limit Search Range"=32.0
D:"Weight Scale"=1.0
}
That *does not* disable the individual event spawners though. Just the passive spawns, which I then set up through JAS. It's a system I've been using to good effect for a while now.
Then for the event spawns, further down in the same config file there's
"spawners enabled" {
B:"CROP Spawn Enabled"=false
B:"DARKNESS Spawn Enabled"=true
B:"DEATH Spawn Enabled"=true
B:"FIRE Spawn Enabled"=true
B:"FROSTFIRE Spawn Enabled"=false
B:"LAVA Spawn Enabled"=true
B:"LUNAR Spawn Enabled"=true
B:"PORTAL Spawn Enabled"=true
B:"ROCK Spawn Enabled"=true
B:"SKY Spawn Enabled"=true
B:"SLEEP Spawn Enabled"=false
B:"STORM Spawn Enabled"=false
B:"TREE Spawn Enabled"=false
B:"WATER Spawn Enabled"=true
}
That's just how I have mine set up but you could customise it however you like really.
Since they are showing up in my spawnlistentries but not actually spawning, and they all have the default spawning settings put on by jas when it generates, does this mean that JAS is detecting the mobs are installed, but something from that mod are preventing them from being spawned???
This is my entityhandler listing for fishy...
"MoCreatures.Fishy": {
"Type-Enabled": "WATERCREATURE-true",
"Contents": [
"MoCreatures.Fishy"
]
},
Its all default still.
I've been really confused about this because I have MoCreatures watercreatures spawning. Jellyfish, sharks, dolphins.. all sizes of fish.. everything except for Piranha cause I dislike them. Or did I set them to spawn in jungles and just haven't checked the jungle waters yet? ..could be the latter. I'd like to know what I'm doing different though.
Yes, every entity has a mod specified spawn condition that must be met.
Let me know some of the specific entities you've tested and where you've tested them (preferably vanilla biomes, even better if flatland) and I'll give it a try.
* Optimize entity count / valid chunk determination to scale better with number of players
Changelog: https://github.com/ProjectZulu/JustAnotherSpawner/wiki/Changelog#just-another-spawner-v016
Download: http://projectzulu.blogspot.ca/p/downloads.html
Currently we have BiomeGroup/AttributeGrous of composed of other groups and only other groups. i..e "BiomGroup": { "Beach": "A|All-G|Desert-A|Hot"
I'm looking at moving to a more flexible methodology, where a biomegroup can be defined by other groups as well as other properties biomegen class (i.e. temperature, heightvariation, rainfall, enablesnow, enablerain, etc.) (on loading, not based on conditions that may change in the biome over time in game).
This would be of the form "BiomeGroup": { "Beach": "(A.All).rem('A.Hot').rainfall(0.85,-1).snowenabled()" or possibly "BiomeGroup": { "Beach": "($.enablesnow || $.isHighHumidity()) in ((A.All).rem('A.Hot'))"
The 'issue' with the alternative formatting is resolving dependencies becomes impossible. Requiring removal of the ability to remove BiomeGroups in Biomegroups / Attributes in Attributes OR guaranteeing the order read is always the same as written (which gets tricky later if editing at runtime is added, i.e a gui / in game commands are supported)