Is it possible to change the "Spawner-Settings"? For now, Spawner will only start spawning when a Player is 16 blocks near the Spawner. Can i somehow increase the number of blocks or decrease the amount of players to 0? Im playing on my Forge SMP Server
I'm not sure what you are talking about, could you clarify? Are you in the right thread?
The short and sweet version is that if you have the mobs disabled in the Mo' Creatures config file by setting their frequencies to <0:0:0> then it is blocking JAS from spawning them as well if you try to spawn them using their default settings. By applying custom spawn settings using the {spawn} tag, you overwrite this behavior and they are capable of spawning once again; but this removes their in-built functionality to determine how and when to spawn.
Disclaimer: ANy information I have about CMS/Mo'Creatures is second hand knowleadge and should be taken with a grain of salt.
I think someone said setting the spawn rate in mo'Creatures to 0 causes the entity to not be declared / registered in game. Which is the only way to prevent JAS from spawning something.
The workaround I have found is to set the creatures' spawn frequencies to <1:0:0> in the configuration file and remove them from all CMS biome groups. This accomplishes two things: first it effectively disables CMS from running at all because while the mobs have frequencies set they have no biomes in which to spawn; this takes care of CMS interfering with JAS. Secondly, by having their spawn rates set to 1 JAS is capable of spawning the mobs using their default spawn restrictions.
My main concern with keeping CMS enabled is that doens't CMS have some kind of custom despawner? I don't know how it works, but here are many ways they may not work well together. Technically, this should only result in entities despawning sooner than anticipated, not longer.
I've read the entities not in the CMS spawnlists (such as those from other mods) are not controlled by CMS but by the vanilla system. Couldn't you remove MoC in a identical way? As an FYI, JAS will print all spawnlist entries that it adds to biome groups at on world joining / startup: if it says [entity] in [biome group] there then it should spawn, otherwise it won't.
Currently there is a bug where attempting to disable Custom Mob Spawner will cause the game to crash. Therefore I was trying to find a workaround to prevent CMS from spawning anything while avoiding said crash.
After this I removed Project Zulu and went back to messing around with Mo' Creatures. I decided that maybe setting the frequency of spawns to 0 was effectively disabling the mob both for CMS and JAS. To test I set the frequency of horses to <1:0:0> and tested in-game. After this JAS appeared to be successfully spawning both vanilla creatures (I was testing with pigs) and horses. This introduced a new problem: with a frequency set and CMS unable to be truly disabled it was now spawning mobs as well.
I admire your persistence in figuring these things out via experimentation.
One random thought I had while doing this testing that I would like to hear your thoughts on Crudedragos would be the addition of another custom CreatureType (like the opensky and underground types) that would allow mobs in said group to ONLY spawn during chunk-loading. As in somehow prevent any passive spawning of the members of this group. My thinking was that if you could do this you could set things such as the vanilla pigs/cows/chickens/sheep to this group in order to sort of get a finite population of these creatures. This would give them their own cap so they wouldn't interfere with others, allow them to still be spawned naturally so they could be collected and farmed without needing to worry about trying to get them to despawn as their numbers would be limited due to only ever spawning with a new chunk and with proper use of hunter creatures they would eventually be culled without being replaced.
That way if you need these animals, you can find them by exploring new chunks where they may spawn but don't need to set them to passively spawn where they could overpopulate and take over.
I haven't thought of a way to do this using currently existing functionality in JAS so thought I would see what you thought (of course I could be overlooking something simple; all this time messing with config files has kind of fried my brain). Oh and sorry for the long post, I can be quite talkative (type-ative?) at times.
Chunk spawning does not count towards caps, which is not something I feel should change.
Thus,
1. Chunk-only categories can be attained by setting cap to zero and enabling chunk spawns.
2. Ability to add user-defined Categories will be added in a future update, complete with spawning tag support to customize how things spawn.
Edit: Corrected Several instances of typing MSC where I meant CMS.
Disclaimer: ANy information I have about MSC/Mo'Creatures is second hand knowleadge and should be taken with a grain of salt.
I think someone said setting the spawn rate in mo'Creatures to 0 causes the entity to not be declared / registered in game. Which is the only way to prevent JAS from spawning something.
This is interesting if true because during my tests, as mentioned before, JAS was occasionally attempting to chunk-spawn mobs that had their spawn-rate set to 0 (in the MoC config) but it seemed to be failing. I was getting the messages in the console but when arriving at the given coordinates there was never anything there (also never seemed to show up on Rei's Minimap with EntityRadar on). Also, they are showing up in the console as being added to the BiomeGroup so it seems they are still being declared/registered. They just aren't being spawned passively (I get no messages that they are being spawned aside from occasionally via chunks) and chunk-spawning seems to be attempting but failing.
My main concern with keeping MSC enabled is that doens't MSC have some kind of custom despawner? I don't know how it works, but here are many ways they may not work well together. Technically, this should only result in entities despawning sooner than anticipated, not longer.
Hmm. This is where I am getting a bit confused. Firstly, I am not using MSC (Mob Spawn Controls) at all. So I am going to just assume that you meant to type CMS instead (quite possible because they are so similar) and go off that assumption. I apologize if I was unclear about this in my original posts.
I haven't done any testing with despawning yet and have no ideas how the internals of CMS would handle such a thing but it is something to consider. I will maybe see if I can figure out some reasonable way of testing to see if CMS is still despawning entities; maybe by setting an entity to have a custom {despawn} tag in JAS with a very unlikely criteria that should keep them spawned. If they do disappear without meeting said criteria (for example maybe something like don't despawn unless on diamond blocks or some such nonsense) then it would point to CMS interfering.
I've read the entities not in the MSC spawnlists (such as those from other mods) are not controlled by MSC but by the vanilla system. Couldn't you remove MoC in a identical way? As an FYI, JAS will print all spawnlist entries that it adds to biome groups at on world joining / startup: if it says [entity] in [biome group] there then it should spawn, otherwise it won't.
This is the method I am using to prevent CMS from spawning anything. It is technically enabled and has frequencies set to spawn; it just doesn't have any valid biomes to spawn them in, effectively rendering it useless as I intended. As for whether they are added to the vanilla system I haven't checked as I have been running all these tests with the vanilla spawn system disabled via emptying the spawnlist at start and setting doMobSpawning to false.
If I continue to run into any more trouble this may be what I have to end up doing, but for now with the little bit of testing of my workaround I have done it seems to be doing alright. Just need to see if it (CMS) is still attempting to control the despawn of entities.
Chunk spawning does not count towards caps, which is not something I feel should change.
Thus,
1. Chunk-only categories can be attained by setting cap to zero and enabling chunk spawns.
2. Ability to add user-defined Categories will be added in a future update, complete with spawning tag support to customize how things spawn.
Awesome, sounds good. Didn't think about setting the cap to zero to prevent passive spawning, might have to take over opensky or underground until user-defined categories are implemented.
This is interesting if true because during my tests, as mentioned before, JAS was occasionally attempting to chunk-spawn mobs that had their spawn-rate set to 0 (in the MoC config) but it seemed to be failing. I was getting the messages in the console but when arriving at the given coordinates there was never anything there (also never seemed to show up on Rei's Minimap with EntityRadar on). Also, they are showing up in the console as being added to the BiomeGroup so it seems they are still being declared/registered. They just aren't being spawned passively (I get no messages that they are being spawned aside from occasionally via chunks) and chunk-spawning seems to be attempting but failing.
If JAS was attempting to spawn them then it would evidently not be true. That they are not spawning passively, I don't know. Maybe cap was already hit. Ensure non-zero wight in applicable biomes. Many small thing which could cause odd occurances. As you've had success apparently with horses and pigs this may be a moot point.
Hmm. This is where I am getting a bit confused. Firstly, I am not using MSC (Mob Spawn Controls) at all. So I am going to just assume that you meant to type CMS instead (quite possible because they are so similar) and go off that assumption. I apologize if I was unclear about this in my original posts.
I meant CMS. Acronyms are so similar I often mix them in my head.
I haven't done any testing with despawning yet and have no ideas how the internals of CMS would handle such a thing but it is something to consider. I will maybe see if I can figure out some reasonable way of testing to see if CMS is still despawning entities; maybe by setting an entity to have a custom {despawn} tag in JAS with a very unlikely criteria that should keep them spawned. If they do disappear without meeting said criteria (for example maybe something like don't despawn unless on diamond blocks or some such nonsense) then it would point to CMS interfering.
It's essentially a race. Whoever decides to despawn the entity first despawns it. So that test should work. I can only assume that is what is happening with your failed chunk spawns. As "failing" isn't really possible. The only other thing that comes to mind is being on peaceful / below difficulty such that the entity insta-despawns.
This is the method I am using to prevent CMS from spawning anything. It is technically enabled and has frequencies set to spawn; it just doesn't have any valid biomes to spawn them in, effectively rendering it useless as I intended. As for whether they are added to the vanilla system I haven't checked as I have been running all these tests with the vanilla spawn system disabled via emptying the spawnlist at start and setting doMobSpawning to false.
Right, but the despawner would / may be still trying to control said entities.
It would be nice if you could state in each change if it's necessary to delete the config files to recreate them.
It has never been necessary. The one time I did change the living handler format, I included an auto-converter, I did mention it and urged users to backup there stuff.
If JAS was attempting to spawn them then it would evidently not be true. That they are not spawning passively, I don't know. Maybe cap was already hit. Ensure non-zero wight in applicable biomes. Many small thing which could cause odd occurances. As you've had success apparently with horses and pigs this may be a moot point.
I can confirm that I had weights properly set for the biome I was testing as well as the cap had not been hit. Not sure what the issue is there.
It's essentially a race. Whoever decides to despawn the entity first despawns it. So that test should work. I can only assume that is what is happening with your failed chunk spawns. As "failing" isn't really possible. The only other thing that comes to mind is being on peaceful / below difficulty such that the entity insta-despawns.
I was testing on Hard so I don't think it was difficulty level causing instant despawning. Maybe CMS will insta-despawn any entity it controls that has its rate set to 0 if it should accidentally get spawned? Maybe this is deliberate workaround intended to counteract chunk-spawning (which it does). Lots of possibilities, who knows.
Right, but the despawner would / may be still trying to control said entities.
Good luck.
After a little bit of testing it doesn't seem like CMS is interfering with JAS in terms of despawning either vanilla or it's own creatures, which is good news. Of course I cannot say that for certain; just the result of a few little experiments I performed.
There is one thing weird I noticed during all of this. I haven't heard of this before, but is there a range around the block where entities are allowed to spawn / despawn? Kind of hard to put in to words so in the spoiler below are some pictures. In all the pictures zombies were spawned on top of ALL the sandstone / diamond blocks with the following settings used in the JAS config:
After spawning all the zombies, I moved far enough away for them to start despawning and waited. You can see from the pictures the results; it appears like there is a bit of a radius effect the diamond block (the only block on which zombies won't despawn) has on the surrounding area. Not sure if this is vanilla or related to your mod, nor if it is a bug or intended. Just thought I would share. Oh, and the fences in the second picture were just to prevent the zombies from trying to jump between platforms.
There is one thing weird I noticed during all of this. I haven't heard of this before, but is there a range around the block where entities are allowed to spawn / despawn? Kind of hard to put in to words so in the spoiler below are some pictures. In all the pictures zombies were spawned on top of ALL the sandstone / diamond blocks with the following settings used in the JAS config:
After spawning all the zombies, I moved far enough away for them to start despawning and waited. You can see from the pictures the results; it appears like there is a bit of a radius effect the diamond block (the only block on which zombies won't despawn) has on the surrounding area. Not sure if this is vanilla or related to your mod, nor if it is a bug or intended. Just thought I would share. Oh, and the fences in the second picture were just to prevent the zombies from trying to jump between platforms.
For {spawn], the block is the at the entities feet. For {despawn} it is by default a range of 3. The {:blockRange,} tag can set the isometric distance in any direction or each specific direction by providing additional arguments.
i.e. {:blockRange, isometricDistance} OR {:blockRange, xDistance, yDistance, zDistance}
For {spawn], the block is the at the entities feet. For {despawn} it is by default a range of 3. The {:blockRange,} tag can set the isometric distance in any direction or each specific direction by providing additional arguments.
i.e. {:blockRange, isometricDistance} OR {:blockRange, xDistance, yDistance, zDistance}
Interesting. Is this vanilla behavior? Also, can you think of any benefits or disadvantages of setting this to 1?
Seems a little weird to me. I guess don't seem to really understand why it would be this way; what it is trying to accomplish or prevent. Of course you aren't usually going to have such an obvious case where this has an actual effect in a real game so it is mostly a moot point. I guess my interest in the matter is purely academic at this point since it is intended behavior that I doubt I will be altering.
On the subject of academic questions, could you explain how your {sky} check works? I haven't yet had time to play around with it much, but one of the things that irks me about the vanilla spawning system is getting mobs spawning beneath tress in forests during the daytime. If an entity is beneath, say, a single log block would this count as not being able to see the sky? If so, is there any possibility of a feature to perhaps configure blocks to be ignored during this check? So that if set - from the point of view of the sky check - all configured blocks would be counted as air instead?
Meh, maybe I am just babbling; it is early-ish. I need to go eat something.
Thanks again for putting up with all my nonsense!
EDIT:: After a few donuts, the idea of blacklisting certain blocks for the sky check probably isn't a good idea. Maybe an option configurable range to ignore above the entity? So for example the first 3 blocks wouldn't be checked.
Oh and maybe I shouldn't be cluttering up your thread with my general spawning questions and discussions, might be better suited to the mob spawning observations thread; let me know.
Interesting. Is this vanilla behavior? Also, can you think of any benefits or disadvantages of setting this to 1?
Seems a little weird to me. I guess don't seem to really understand why it would be this way; what it is trying to accomplish or prevent. Of course you aren't usually going to have such an obvious case where this has an actual effect in a real game so it is mostly a moot point. I guess my interest in the matter is purely academic at this point since it is intended behavior that I doubt I will be altering.
All these options are equivalent to the modder getCanSpawnHere method. There is no "vanilla" equivalent. The obvious use case is farms, you can set the animals to despawn unless near some block. Imagine using fence blocks, sheep in the wild would despawn, but those in your farm would never despawn, unless you left the door open and they wandered away. The idea behind these tags is allow end-users to write equivalent spawn methods that mod authors can write. Which is obviously non-trivial.
On the subject of academic questions, could you explain how your {sky} check works?
It relies on utilizing methods in world. I used to use canBlockSeeTheSky, which consulted the heightMap. This had the problem of being below leaves would count as being below ground. I now use (as of 0.6.0? I think) getTopSolidOrLiquidBlock, which consults an internal storage array (which I don't know what they are) to get the top block and then iterates downwards till it find a solid block that is solid and not air, leaves or foliage. Solidity is determined by material.
I haven't yet had time to play around with it much, but one of the things that irks me about the vanilla spawning system is getting mobs spawning beneath tress in forests during the daytime. If an entity is beneath, say, a single log block would this count as not being able to see the sky?
If so, is there any possibility of a feature to perhaps configure blocks to be ignored during this check? So that if set - from the point of view of the sky check - all configured blocks would be counted as air instead?
It would be possible to create a sky method that allowed ignoring additional blocks. Though I think the sky method fulfills your needs. It would obviously be a seperate tag. Suggested name?
EDIT:: After a few donuts, the idea of blacklisting certain blocks for the sky check probably isn't a good idea. Maybe an option configurable range to ignore above the entity? So for example the first 3 blocks wouldn't be checked.
Oh and maybe I shouldn't be cluttering up your thread with my general spawning questions and discussions, might be better suited to the mob spawning observations thread; let me know.
It doesn't bother me either way. Understanding of how vanilla works is unfortunately critical to doing anything of value. Even discussion of other mods is relevant, though in that case your chances of getting assistance would be better elsewhere.
All these options are equivalent to the modder getCanSpawnHere method. There is no "vanilla" equivalent. The obvious use case is farms, you can set the animals to despawn unless near some block. Imagine using fence blocks, sheep in the wild would despawn, but those in your farm would never despawn, unless you left the door open and they wandered away. The idea behind these tags is allow end-users to write equivalent spawn methods that mod authors can write. Which is obviously non-trivial.
Very interesting. Didn't think of it that way. I heard that Mo' Creatures was (at least at one point in time) using the whole vanilla animals don't despawn around fences thing. I had no idea it was possible to recreate that in JAS. Definitely opened my mind to some neat new possibilities!
It relies on utilizing methods in world. I used to use canBlockSeeTheSky, which consulted the heightMap. This had the problem of being below leaves would count as being below ground. I now use (as of 0.6.0? I think) getTopSolidOrLiquidBlock, which consults an internal storage array (which I don't know what they are) to get the top block and then iterates downwards till it find a solid block that is solid and not air, leaves or foliage. Solidity is determined by material.
A bit of an annoyance when using mods that add big trees to the game where there are often large branches of logs to block the sky check. If I thought there was the possibility of adding an 'above-ground' check I would request it, but with even my little knowledge of Minecraft modding and programming in general I highly doubt there is any way to reliably determine this.
It would be possible to create a sky method that allowed ignoring additional blocks. Though I think the sky method fulfills your needs. It would obviously be a seperate tag. Suggested name?
After a bit of pondering it would seem that ignoring a block outright would likely just lead to weirdness. If I were to for example prevent logs from being used in the sky check and then build my house out of them we would have trouble.
It might potentially be able to remove some of the annoyances with spawning. Then again, it could also introduce more. If I say ignore the 5 blocks above your head when checking for sky, while it might help with some of the large tree checks it could also again mess with interiors of structures or near-surface caves. Would probably require more thought (which I will try to put in to any future ideas before I post them ).
It doesn't bother me either way. Understanding of how vanilla works is unfortunately critical to doing anything of value. Even discussion of other mods is relevant, though in that case your chances of getting assistance would be better elsewhere.
Well then I guess I will stick around. Anyways, you seem to be one of the gifted few that actually has a grasp on how all this spawning stuff works; might as well consult an expert!
Now to an on-topic question regarding the BiomeGroups.cfg file. If I make an entry into a biomegroup and that entry is invalid will it simply be stripped away or will it throw an error? I am trying to make things easier on myself by setting up a master config which groups all available biomes from my selected biome mods, but the thing is I don't actually -use- every biome; some I set to not generate. Depending on the mod this may or may not remove the biome from the reference list. Also, it seems that the reference list is occasionally missing some biomes; would adding in a biome that is technically correct and valid yet not in the reference list be functional?
With a bit of testing the above seems to be working, so nevermind.
I know you are still working on the mod and you want it left in for debugging... but can you please add the "hide server spam" thing for those of us who aren't doing any debugging?
I know you are still working on the mod and you want it left in for debugging... but can you please add the "hide server spam" thing for those of us who aren't doing any debugging?
I think that if you are going to disable / allow for the disabling of the spawning messages that they should be added as a separate option to the full debug text. It is nice for troubleshooting and not having to have the full debug text on (which seems to lag me something fierce at times).
Also, now that I have confirmed that JAS is functioning as I wanted I have actually started to begin setting up the config files for a real game. This has given me more ideas and I am sure you just can't wait to hear them (by the way, please feel free to tell me to leave you alone)!
One would be the ability to ban the spawning of entities on certain blocks on a global scale. Not sure if this can be implemented as I believe it would effectively require you to customize all remaining spawn parameters yourself, since defining a custom spawn setting overwrites the default built-in mod settings as far as I know. Though if you are going to be editing most entities' spawn settings anyway then being able to specify "no entities can spawn on block 18" instead of having to specify it for each individual entity could save a lot of work. Ideally this functionality could be overwritten by explicitly defining that an entity could spawn on a banned block.
Another would be the ability to define spawn/despawn parameters for entities on a per-biome basis; maybe adding them to the spawnlist entry instead of the livinghandler entry. Again, ideally this would allow you to set a default for all entities of a particular type in the livinghandler and then override those settings with the ones in the spawnlist entry (say I want Zombies to be able to spawn above ground in most biomes but not in tundra, etc.).
I know that you do this in your free time and am very grateful for what you have done so far; I don't want to give the impression I am not appreciative (as far as I am concerned this is the best spawning mod out there). Just thought it would suggest some things and see what you thought.
I'm very glad I'm not running into any problems with MoCreatures and CMS. Though I'm still on the 1.4.7 version (& that may be entirely why), I remembered from setting up MSC that, to avoid problems, set the spawn rates inside CMS to 1. Speaking of MSC, though, that was how I ended up with only Ocelots spawning in the Ice Plains. They'd been put into the monster category by MSC by default and, while I did change some entity categories with MSC - to stop certain fish spawning and !drowning on land, etc, I didn't see the Ocelot As for how I ended up with snowmen/golems spawning.. that must have been a leftover from misclick/science experiment in CMS ages ago. I love how JAS imports settings, making the whole config setup much easier, but it also copied my errors across. Not sure if deleting any configs before first running JAS would have helped.
So, I put my head down recently to work on the spawns in JAS and think I learned a bit more but wanted to check a few things if I may. Sort of a sanity check question. I've noticed some creepers interested in blowing up my library so I was wondering if adding spawn tags removed their usual light check. It's only creepers spawning there and they're the only ones with spawn tags on so ..do I need to add light levels to their tag?
I say "sanity check" because it could actually be that they found a dark enough spot to spawn. Although, if that were the case, I'd expect other monsters to be spawning there too. The other monsters are spawning outside and underground as they should. I looked into light levels and, from my understanding, the block light level is displayed on the F3 screen as "bl"? I might add a screencap if you don't mind. Or I might try to. Not really sure how
.. dropbox links will have to do. Creeper's tags at the moment are {spawn:sky:|block,2}
Next (absurd amounts of wishful thinking here).. when it comes to spawning seagulls on water.. is that at all possible? I'd love to have them out over my oceans. PZ pelicans too - cause they're awesome. so.. would it work by setting the water block in the spawn tags? What about an air block? Can 0 be input? Apologies if this has already been asked or addressed somewhere else. I'm generally very bleary after hours in configs by the time I come to the forum.
And {!spawn:sky:&block,12:block,87} - that's actually handy for quite a few mobs but I was wondering if I can, or how I go about adding "or redrock" & "or cracked sand" to it? (They're terrain gen blocks from XBXL Mountain Ridge and Wasteland biomes respectively) So, don't spawn unless under clear sky and on sand, redrock or cracked sand ...or on Netherack? Is this possible?
Despite those questions, everything's working really well with JAS. Loving the new features. I had been having a problem with the atmos mobs worm ignoring his config settings and continuing to eat through rock and dirt but, now that I can set his y level with height tags, it's not a problem any more. He can eat as much as he likes down there.
The new logging setup is a great time saver too. Many thanks.
A bit of an annoyance when using mods that add big trees to the game where there are often large branches of logs to block the sky check. If I thought there was the possibility of adding an 'above-ground' check I would request it, but with even my little knowledge of Minecraft modding and programming in general I highly doubt there is any way to reliably determine this.
Just wondering about that. Would using the :blockRange tag for logs and leaves in your spawn tags help there? {!spawn:sky:blockRange, 17,18,etc} ..actually that's wrong because it doesn't indicate what the block range is - only which blocks. Could you please show us how to use the blockrange tag please?
Edit- second thoughts.. that would result in opensky animals spawning inside a log house.. yeah I don't know. I can say that, in my experience at least, I still get lots of opensky creatures spawning in heavily forested biomes like Redwood forests, etc. If it is a problem ...maybe there's another way around it like an NPC logger or maybe a beaver.
It's only creepers spawning there and they're the only ones with spawn tags on so ..do I need to add light levels to their tag?
<snip>
Creeper's tags at the moment are {spawn:sky:|block,2}
I believe that once you declare a custom spawn parameter the defaults are completely wiped out. As far as I know it will only do what you specify plus a basic bounding-box check. So by setting the sky and block properties you have overridden their default behavior; but you haven't re-added their check on light. I believe that is how it works.
You would probably want something like {spawn:sky:block,2:light,8,15}.
As far as I know that reads as "always spawn unless you see the sky OR you are on a grass block OR the light level is between 8 and 15."
Next (absurd amounts of wishful thinking here).. when it comes to spawning seagulls on water.. is that at all possible? I'd love to have them out over my oceans. PZ pelicans too - cause they're awesome. so.. would it work by setting the water block in the spawn tags? What about an air block? Can 0 be input? Apologies if this has already been asked or addressed somewhere else. I'm generally very bleary after hours in configs by the time I come to the forum.
I haven't tried this before so cannot give any input there.
And {!spawn:sky:&block,12:block,87} - that's actually handy for quite a few mobs but I was wondering if I can, or how I go about adding "or redrock" & "or cracked sand" to it? (They're terrain gen blocks from XBXL Mountain Ridge and Wasteland biomes respectively) So, don't spawn unless under clear sky and on sand, redrock or cracked sand ...or on Netherack? Is this possible?
I am assuming you are trying to get the following: "never spawn unless you can see the sky and are on sand or redrock or cracked sand OR you are on netherrack." I am pretty sure you can specify multiple blocks under a block tag, using commas between them
I believe this would be: {!spawn:sky:&block,12,*id1*,*id2*:block,87}
Replace *id1* and *id2* with the block ids of redrock and cracked sand.
Just wondering about that. Would using the :blockRange tag for logs and leaves in your spawn tags help there? {!spawn:sky:blockRange, 17,18,etc} ..actually that's wrong because it doesn't indicate what the block range is - only which blocks. Could you please show us how to use the blockrange tag please?
This is interesting. It may work with the despawning tags to automatically despawn an entity within a certain distance of a log. Might have to test that out and see how it fares. Of course having it automatically despawn an entity that gets near a log could have very wide-spead consequences; would definitely need to find a balance if it worked.
As far as block range works, to my understanding it is only used for despawning and there are two different formats available for the tags as listed below:
:blockRange,range (only needs one input; isotropic)
:blockRange,rangeX,rangeY,rangeZ (can explicitly specify the distance in each direction)
Hopefully I am not leading you astray on anything here. I apologize if any of the above is incorrect, I am sure Crudedragos will be able to shed light on anything I missed or messed up.
Time to go play with blockRange despawn settings on logs!
A bit of an annoyance when using mods that add big trees to the game where there are often large branches of logs to block the sky check. If I thought there was the possibility of adding an 'above-ground' check I would request it, but with even my little knowledge of Minecraft modding and programming in general I highly doubt there is any way to reliably determine this.
Now to an on-topic question regarding the BiomeGroups.cfg file. If I make an entry into a biomegroup and that entry is invalid will it simply be stripped away or will it throw an error? I am trying to make things easier on myself by setting up a master config which groups all available biomes from my selected biome mods, but the thing is I don't actually -use- every biome; some I set to not generate. Depending on the mod this may or may not remove the biome from the reference list. Also, it seems that the reference list is occasionally missing some biomes; would adding in a biome that is technically correct and valid yet not in the reference list be functional?
With a bit of testing the above seems to be working, so nevermind.
Glad you fiqured it out. Invalid biome names are simply ignored. Succesful named biomes are printed to log on startup.
I know you are still working on the mod and you want it left in for debugging... but can you please add the "hide server spam" thing for those of us who aren't doing any debugging?
I think that if you are going to disable / allow for the disabling of the spawning messages that they should be added as a separate option to the full debug text. It is nice for troubleshooting and not having to have the full debug text on (which seems to lag me something fierce at times).
One would be the ability to ban the spawning of entities on certain blocks on a global scale. Not sure if this can be implemented as I believe it would effectively require you to customize all remaining spawn parameters yourself, since defining a custom spawn setting overwrites the default built-in mod settings as far as I know. Though if you are going to be editing most entities' spawn settings anyway then being able to specify "no entities can spawn on block 18" instead of having to specify it for each individual entity could save a lot of work. Ideally this functionality could be overwritten by explicitly defining that an entity could spawn on a banned block.
Unlikely, though you should eventually be able to do this on the category level.
Another would be the ability to define spawn/despawn parameters for entities on a per-biome basis; maybe adding them to the spawnlist entry instead of the livinghandler entry. Again, ideally this would allow you to set a default for all entities of a particular type in the livinghandler and then override those settings with the ones in the spawnlist entry (say I want Zombies to be able to spawn above ground in most biomes but not in tundra, etc.).
I'd like to do it on the spawn list entry level. I hadn't considered doing it per biome group.
So, I put my head down recently to work on the spawns in JAS and think I learned a bit more but wanted to check a few things if I may. Sort of a sanity check question. I've noticed some creepers interested in blowing up my library so I was wondering if adding spawn tags removed their usual light check. It's only creepers spawning there and they're the only ones with spawn tags on so ..do I need to add light levels to their tag?
I say "sanity check" because it could actually be that they found a dark enough spot to spawn. Although, if that were the case, I'd expect other monsters to be spawning there too. The other monsters are spawning outside and underground as they should. I looked into light levels and, from my understanding, the block light level is displayed on the F3 screen as "bl"? I might add a screencap if you don't mind. Or I might try to. Not really sure how
Posted ImagePosted ImagePosted Image
..Posted Image dropbox links will have to do. Creeper's tags at the moment are {spawn:sky:|block,2}
Next (absurd amounts of wishful thinking here).. when it comes to spawning seagulls on water.. is that at all possible? I'd love to have them out over my oceans. PZ pelicans too - cause they're awesome. so.. would it work by setting the water block in the spawn tags? What about an air block?
Not really. The category iirc effectively forbids or allows the entity to spawn in water.
Can 0 be input? Apologies if this has already been asked or addressed somewhere else. I'm generally very bleary after hours in configs by the time I come to the forum.
And {!spawn:sky:&block,12:block,87} - that's actually handy for quite a few mobs but I was wondering if I can, or how I go about adding "or redrock" & "or cracked sand" to it? (They're terrain gen blocks from XBXL Mountain Ridge and Wasteland biomes respectively) So, don't spawn unless under clear sky and on sand, redrock or cracked sand ...or on Netherack? Is this possible?
Generally speaking, there is no complicated ordering, so doing something like A & (B | C) would require A & B | A & C. The Block tag does support internally adding several block-meta combinations that are effectively ORed. So you could just do {!spawn:sky:&block,12,87,112,211,201}. You can any number of block-meta combinations.
Just wondering about that. Would using the :blockRange tag for logs and leaves in your spawn tags help there? {!spawn:sky:blockRange, 17,18,etc} ..actually that's wrong because it doesn't indicate what the block range is - only which blocks. Could you please show us how to use the blockrange tag please?
Edit- second thoughts.. that would result in opensky animals spawning inside a log house.. yeah I don't know. I can say that, in my experience at least, I still get lots of opensky creatures spawning in heavily forested biomes like Redwood forests, etc. If it is a problem ...maybe there's another way around it like an NPC logger or maybe a beaver.
blockRange doesn't do anything for spawning. It should, and it will eventually be changed, such that block functions identically for both. The spawning tag will eventually be renamed something like blockFoot to better represent what it does.
SageEthereal outlined its use perfectly.
ah thank you. Some great info there. {!spawn:sky:&block,12,*id1*,*id2*:block,87} That's brilliant. Such power just from a comma. And let us know how you go with the despawn settings on logs please. That would be a good one to try due to the way monsters hide under trees at sun up now.
I'm off to go put a light range on those creepers.
Thank you
Edit- Hey Crudedraogs, didn't see your post before I sent mine.
Generally speaking, there is no complicated ordering, so doing something like A & (B | C) would require A & B | A & C. The Block tag does support internally adding several block-meta combinations that are effectively ORed. So you could just do {!spawn:sky:&block,12,87,112,211,201}. You can any number of block-meta combinations.
I'm going to re-read that a few more times to make sure I understand it, then see how I go implementing it.
Great to hear about the block 0 spawning too. That would be perfect for my oceans.
I believe that is what I am meaning. If I could use spawn tags in the spawnlistentry section where I am specifying the weight and pack size of a entity for a particular biome-group and have those tags override those specified in the livinghandler section that would be awesome.
Would really allow for crazy-complex set-ups; as if things can't be complex enough already.
lol sorry. starting to boggle myself here. I love JAS for the brilliant simple compatibility - getting many mob adding mods to just simply work together - and I don't want people new to JAS to get the impression that it's only good for this convoluted, complicated stuff. It works really well for that, too but, if all someone wants is to avoid problems with many mods spawning, JAS is ideal.
Back to my tag question then, I threw in "OR standing on end stone" at the end of the tag there because I'm entirely unsure what would happen to endermen spawning in The End otherwise. Is The End classed as an endless open sky for spawning purposes?
The tag also rules out building with end stone in the overworld ..unless I deliberately wanted to troll my Mum... but, otherwise, it's ok?
I'm reading that as, "Do not spawn an Enderman unless no sky is visible and light level is 0-5 and spawn height is below 50, OR on block 121."
But I could be wrong.
I myself find the OR tags a bit confusing. Are you saying you only want them to spawn on 121, and if not 121 then to follow the other rule? Or should you have it as an AND?
Also, from this, you only want them spawning underground from depth 0-50?
I'm reading that as, "Do not spawn an Enderman unless no sky is visible and light level is 0-5 and spawn height is below 50, OR on block 121."
But I could be wrong.
I myself find the OR tags a bit confusing. Are you saying you only want them to spawn on 121, and if not 121 then to follow the other rule? Or should you have it as an AND?
Also, from this, you only want them spawning underground from depth 0-50?
Essentially, yes. In the overworld I want Enders only spawning underground (ie. !sky) & below y level 50 & in low light. In The End, I want them to be able to spawn as they normally would, which wouldn't be possible without adding the OR block 121 to the tag.
Edit: Sorry Blue. Just re-read ^there and had a go at myself for forgetting my manners. That's unlike me and totally unintentional. Hope you didn't mind.
About those Enderman tags, I just tested it out and it's working perfectly. They're spawning as normal in the End - above ground and all over the place. And, in the overworld, they're spawning only underground below level 50 in low light
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm not sure what you are talking about, could you clarify? Are you in the right thread?
Disclaimer: ANy information I have about CMS/Mo'Creatures is second hand knowleadge and should be taken with a grain of salt.
I think someone said setting the spawn rate in mo'Creatures to 0 causes the entity to not be declared / registered in game. Which is the only way to prevent JAS from spawning something.
My main concern with keeping CMS enabled is that doens't CMS have some kind of custom despawner? I don't know how it works, but here are many ways they may not work well together. Technically, this should only result in entities despawning sooner than anticipated, not longer.
I've read the entities not in the CMS spawnlists (such as those from other mods) are not controlled by CMS but by the vanilla system. Couldn't you remove MoC in a identical way? As an FYI, JAS will print all spawnlist entries that it adds to biome groups at on world joining / startup: if it says [entity] in [biome group] there then it should spawn, otherwise it won't.
You could always downgrade until its fixed.
I admire your persistence in figuring these things out via experimentation.
Chunk spawning does not count towards caps, which is not something I feel should change.
Thus,
1. Chunk-only categories can be attained by setting cap to zero and enabling chunk spawns.
2. Ability to add user-defined Categories will be added in a future update, complete with spawning tag support to customize how things spawn.
Edit: Corrected Several instances of typing MSC where I meant CMS.
This is interesting if true because during my tests, as mentioned before, JAS was occasionally attempting to chunk-spawn mobs that had their spawn-rate set to 0 (in the MoC config) but it seemed to be failing. I was getting the messages in the console but when arriving at the given coordinates there was never anything there (also never seemed to show up on Rei's Minimap with EntityRadar on). Also, they are showing up in the console as being added to the BiomeGroup so it seems they are still being declared/registered. They just aren't being spawned passively (I get no messages that they are being spawned aside from occasionally via chunks) and chunk-spawning seems to be attempting but failing.
Hmm. This is where I am getting a bit confused. Firstly, I am not using MSC (Mob Spawn Controls) at all. So I am going to just assume that you meant to type CMS instead (quite possible because they are so similar) and go off that assumption. I apologize if I was unclear about this in my original posts.
I haven't done any testing with despawning yet and have no ideas how the internals of CMS would handle such a thing but it is something to consider. I will maybe see if I can figure out some reasonable way of testing to see if CMS is still despawning entities; maybe by setting an entity to have a custom {despawn} tag in JAS with a very unlikely criteria that should keep them spawned. If they do disappear without meeting said criteria (for example maybe something like don't despawn unless on diamond blocks or some such nonsense) then it would point to CMS interfering.
This is the method I am using to prevent CMS from spawning anything. It is technically enabled and has frequencies set to spawn; it just doesn't have any valid biomes to spawn them in, effectively rendering it useless as I intended. As for whether they are added to the vanilla system I haven't checked as I have been running all these tests with the vanilla spawn system disabled via emptying the spawnlist at start and setting doMobSpawning to false.
If I continue to run into any more trouble this may be what I have to end up doing, but for now with the little bit of testing of my workaround I have done it seems to be doing alright. Just need to see if it (CMS) is still attempting to control the despawn of entities.
Awesome, sounds good. Didn't think about setting the cap to zero to prevent passive spawning, might have to take over opensky or underground until user-defined categories are implemented.
Thanks for everything so far!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf JAS was attempting to spawn them then it would evidently not be true. That they are not spawning passively, I don't know. Maybe cap was already hit. Ensure non-zero wight in applicable biomes. Many small thing which could cause odd occurances. As you've had success apparently with horses and pigs this may be a moot point.
I meant CMS. Acronyms are so similar I often mix them in my head.
It's essentially a race. Whoever decides to despawn the entity first despawns it. So that test should work. I can only assume that is what is happening with your failed chunk spawns. As "failing" isn't really possible. The only other thing that comes to mind is being on peaceful / below difficulty such that the entity insta-despawns.
Right, but the despawner would / may be still trying to control said entities.
Good luck.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt has never been necessary. The one time I did change the living handler format, I included an auto-converter, I did mention it and urged users to backup there stuff.
I can confirm that I had weights properly set for the biome I was testing as well as the cap had not been hit. Not sure what the issue is there.
I was testing on Hard so I don't think it was difficulty level causing instant despawning. Maybe CMS will insta-despawn any entity it controls that has its rate set to 0 if it should accidentally get spawned? Maybe this is deliberate workaround intended to counteract chunk-spawning (which it does). Lots of possibilities, who knows.
After a little bit of testing it doesn't seem like CMS is interfering with JAS in terms of despawning either vanilla or it's own creatures, which is good news. Of course I cannot say that for certain; just the result of a few little experiments I performed.
There is one thing weird I noticed during all of this. I haven't heard of this before, but is there a range around the block where entities are allowed to spawn / despawn? Kind of hard to put in to words so in the spoiler below are some pictures. In all the pictures zombies were spawned on top of ALL the sandstone / diamond blocks with the following settings used in the JAS config:
After spawning all the zombies, I moved far enough away for them to start despawning and waited. You can see from the pictures the results; it appears like there is a bit of a radius effect the diamond block (the only block on which zombies won't despawn) has on the surrounding area. Not sure if this is vanilla or related to your mod, nor if it is a bug or intended. Just thought I would share. Oh, and the fences in the second picture were just to prevent the zombies from trying to jump between platforms.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFor {spawn], the block is the at the entities feet. For {despawn} it is by default a range of 3. The {:blockRange,} tag can set the isometric distance in any direction or each specific direction by providing additional arguments.
i.e. {:blockRange, isometricDistance} OR {:blockRange, xDistance, yDistance, zDistance}
Interesting. Is this vanilla behavior? Also, can you think of any benefits or disadvantages of setting this to 1?
Seems a little weird to me. I guess don't seem to really understand why it would be this way; what it is trying to accomplish or prevent. Of course you aren't usually going to have such an obvious case where this has an actual effect in a real game so it is mostly a moot point. I guess my interest in the matter is purely academic at this point since it is intended behavior that I doubt I will be altering.
On the subject of academic questions, could you explain how your {sky} check works? I haven't yet had time to play around with it much, but one of the things that irks me about the vanilla spawning system is getting mobs spawning beneath tress in forests during the daytime. If an entity is beneath, say, a single log block would this count as not being able to see the sky? If so, is there any possibility of a feature to perhaps configure blocks to be ignored during this check? So that if set - from the point of view of the sky check - all configured blocks would be counted as air instead?
Meh, maybe I am just babbling; it is early-ish. I need to go eat something.
Thanks again for putting up with all my nonsense!
EDIT:: After a few donuts, the idea of blacklisting certain blocks for the sky check probably isn't a good idea. Maybe an option configurable range to ignore above the entity? So for example the first 3 blocks wouldn't be checked.
Oh and maybe I shouldn't be cluttering up your thread with my general spawning questions and discussions, might be better suited to the mob spawning observations thread; let me know.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAll these options are equivalent to the modder getCanSpawnHere method. There is no "vanilla" equivalent. The obvious use case is farms, you can set the animals to despawn unless near some block. Imagine using fence blocks, sheep in the wild would despawn, but those in your farm would never despawn, unless you left the door open and they wandered away. The idea behind these tags is allow end-users to write equivalent spawn methods that mod authors can write. Which is obviously non-trivial.
It relies on utilizing methods in world. I used to use canBlockSeeTheSky, which consulted the heightMap. This had the problem of being below leaves would count as being below ground. I now use (as of 0.6.0? I think) getTopSolidOrLiquidBlock, which consults an internal storage array (which I don't know what they are) to get the top block and then iterates downwards till it find a solid block that is solid and not air, leaves or foliage. Solidity is determined by material.
Yes,
It would be possible to create a sky method that allowed ignoring additional blocks. Though I think the sky method fulfills your needs. It would obviously be a seperate tag. Suggested name?
That is an interesting and useful approach.
It doesn't bother me either way. Understanding of how vanilla works is unfortunately critical to doing anything of value. Even discussion of other mods is relevant, though in that case your chances of getting assistance would be better elsewhere.
Very interesting. Didn't think of it that way. I heard that Mo' Creatures was (at least at one point in time) using the whole vanilla animals don't despawn around fences thing. I had no idea it was possible to recreate that in JAS. Definitely opened my mind to some neat new possibilities!
Understood.
A bit of an annoyance when using mods that add big trees to the game where there are often large branches of logs to block the sky check. If I thought there was the possibility of adding an 'above-ground' check I would request it, but with even my little knowledge of Minecraft modding and programming in general I highly doubt there is any way to reliably determine this.
After a bit of pondering it would seem that ignoring a block outright would likely just lead to weirdness. If I were to for example prevent logs from being used in the sky check and then build my house out of them we would have trouble.
It might potentially be able to remove some of the annoyances with spawning. Then again, it could also introduce more. If I say ignore the 5 blocks above your head when checking for sky, while it might help with some of the large tree checks it could also again mess with interiors of structures or near-surface caves. Would probably require more thought (which I will try to put in to any future ideas before I post them
Well then I guess I will stick around.
Now to an on-topic question regarding the BiomeGroups.cfg file. If I make an entry into a biomegroup and that entry is invalid will it simply be stripped away or will it throw an error? I am trying to make things easier on myself by setting up a master config which groups all available biomes from my selected biome mods, but the thing is I don't actually -use- every biome; some I set to not generate. Depending on the mod this may or may not remove the biome from the reference list. Also, it seems that the reference list is occasionally missing some biomes; would adding in a biome that is technically correct and valid yet not in the reference list be functional?With a bit of testing the above seems to be working, so nevermind.
I think that if you are going to disable / allow for the disabling of the spawning messages that they should be added as a separate option to the full debug text. It is nice for troubleshooting and not having to have the full debug text on (which seems to lag me something fierce at times).
Also, now that I have confirmed that JAS is functioning as I wanted I have actually started to begin setting up the config files for a real game. This has given me more ideas and I am sure you just can't wait to hear them (by the way, please feel free to tell me to leave you alone)!
One would be the ability to ban the spawning of entities on certain blocks on a global scale. Not sure if this can be implemented as I believe it would effectively require you to customize all remaining spawn parameters yourself, since defining a custom spawn setting overwrites the default built-in mod settings as far as I know. Though if you are going to be editing most entities' spawn settings anyway then being able to specify "no entities can spawn on block 18" instead of having to specify it for each individual entity could save a lot of work. Ideally this functionality could be overwritten by explicitly defining that an entity could spawn on a banned block.
Another would be the ability to define spawn/despawn parameters for entities on a per-biome basis; maybe adding them to the spawnlist entry instead of the livinghandler entry. Again, ideally this would allow you to set a default for all entities of a particular type in the livinghandler and then override those settings with the ones in the spawnlist entry (say I want Zombies to be able to spawn above ground in most biomes but not in tundra, etc.).
I know that you do this in your free time and am very grateful for what you have done so far; I don't want to give the impression I am not appreciative (as far as I am concerned this is the best spawning mod out there). Just thought it would suggest some things and see what you thought.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSo, I put my head down recently to work on the spawns in JAS and think I learned a bit more but wanted to check a few things if I may. Sort of a sanity check question. I've noticed some creepers interested in blowing up my library so I was wondering if adding spawn tags removed their usual light check. It's only creepers spawning there and they're the only ones with spawn tags on so ..do I need to add light levels to their tag?
I say "sanity check" because it could actually be that they found a dark enough spot to spawn. Although, if that were the case, I'd expect other monsters to be spawning there too. The other monsters are spawning outside and underground as they should. I looked into light levels and, from my understanding, the block light level is displayed on the F3 screen as "bl"? I might add a screencap if you don't mind. Or I might try to. Not really sure how
..
Next (absurd amounts of wishful thinking here).. when it comes to spawning seagulls on water.. is that at all possible? I'd love to have them out over my oceans. PZ pelicans too - cause they're awesome. so.. would it work by setting the water block in the spawn tags? What about an air block? Can 0 be input? Apologies if this has already been asked or addressed somewhere else. I'm generally very bleary after hours in configs by the time I come to the forum.
And {!spawn:sky:&block,12:block,87} - that's actually handy for quite a few mobs but I was wondering if I can, or how I go about adding "or redrock" & "or cracked sand" to it? (They're terrain gen blocks from XBXL Mountain Ridge and Wasteland biomes respectively) So, don't spawn unless under clear sky and on sand, redrock or cracked sand ...or on Netherack? Is this possible?
Despite those questions, everything's working really well with JAS. Loving the new features. I had been having a problem with the atmos mobs worm ignoring his config settings and continuing to eat through rock and dirt but, now that I can set his y level with height tags, it's not a problem any more. He can eat as much as he likes down there.
The new logging setup is a great time saver too. Many thanks.
Regards
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumJust wondering about that. Would using the :blockRange tag for logs and leaves in your spawn tags help there? {!spawn:sky:blockRange, 17,18,etc} ..actually that's wrong because it doesn't indicate what the block range is - only which blocks. Could you please show us how to use the blockrange tag please?
Edit- second thoughts.. that would result in opensky animals spawning inside a log house.. yeah I don't know. I can say that, in my experience at least, I still get lots of opensky creatures spawning in heavily forested biomes like Redwood forests, etc. If it is a problem ...maybe there's another way around it like an NPC logger or maybe a beaver.
I believe that once you declare a custom spawn parameter the defaults are completely wiped out. As far as I know it will only do what you specify plus a basic bounding-box check. So by setting the sky and block properties you have overridden their default behavior; but you haven't re-added their check on light. I believe that is how it works.
You would probably want something like {spawn:sky:block,2:light,8,15}.
As far as I know that reads as "always spawn unless you see the sky OR you are on a grass block OR the light level is between 8 and 15."
I haven't tried this before so cannot give any input there.
I am assuming you are trying to get the following: "never spawn unless you can see the sky and are on sand or redrock or cracked sand OR you are on netherrack." I am pretty sure you can specify multiple blocks under a block tag, using commas between them
I believe this would be: {!spawn:sky:&block,12,*id1*,*id2*:block,87}
Replace *id1* and *id2* with the block ids of redrock and cracked sand.
This is interesting. It may work with the despawning tags to automatically despawn an entity within a certain distance of a log. Might have to test that out and see how it fares. Of course having it automatically despawn an entity that gets near a log could have very wide-spead consequences; would definitely need to find a balance if it worked.
As far as block range works, to my understanding it is only used for despawning and there are two different formats available for the tags as listed below:
Hopefully I am not leading you astray on anything here. I apologize if any of the above is incorrect, I am sure Crudedragos will be able to shed light on anything I missed or messed up.
Time to go play with blockRange despawn settings on logs!
Edit: Mispellings.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumTrue, I hadn't considered that.
Glad you fiqured it out. Invalid biome names are simply ignored. Succesful named biomes are printed to log on startup.
I will consider it. Probably.
Unlikely, though you should eventually be able to do this on the category level.
I'd like to do it on the spawn list entry level. I hadn't considered doing it per biome group.
You would need to add light tags.
Not really. The category iirc effectively forbids or allows the entity to spawn in water.
0 should be a valid input.
Generally speaking, there is no complicated ordering, so doing something like A & (B | C) would require A & B | A & C. The Block tag does support internally adding several block-meta combinations that are effectively ORed. So you could just do {!spawn:sky:&block,12,87,112,211,201}. You can any number of block-meta combinations.
blockRange doesn't do anything for spawning. It should, and it will eventually be changed, such that block functions identically for both. The spawning tag will eventually be renamed something like blockFoot to better represent what it does.
SageEthereal outlined its use perfectly.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm off to go put a light range on those creepers.
Thank you
Edit- Hey Crudedraogs, didn't see your post before I sent mine.
I'm going to re-read that a few more times to make sure I understand it, then see how I go implementing it.
Great to hear about the block 0 spawning too. That would be perfect for my oceans.
Thanks again
I believe that is what I am meaning. If I could use spawn tags in the spawnlistentry section where I am specifying the weight and pack size of a entity for a particular biome-group and have those tags override those specified in the livinghandler section that would be awesome.
Would really allow for crazy-complex set-ups; as if things can't be complex enough already.
So much awesomeness in one single line and it will probably get even awesome-er. This is just the start! Weee, spawning is actually fun-ish!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumS:Enderman=MONSTER-true{!spawn:!sky:&light,0,5:&maxSpawnHeight,50:|block,121}
lol sorry. starting to boggle myself here. I love JAS for the brilliant simple compatibility - getting many mob adding mods to just simply work together - and I don't want people new to JAS to get the impression that it's only good for this convoluted, complicated stuff. It works really well for that, too but, if all someone wants is to avoid problems with many mods spawning, JAS is ideal.
Back to my tag question then, I threw in "OR standing on end stone" at the end of the tag there because I'm entirely unsure what would happen to endermen spawning in The End otherwise. Is The End classed as an endless open sky for spawning purposes?
The tag also rules out building with end stone in the overworld ..unless I deliberately wanted to troll my Mum... but, otherwise, it's ok?
I'm reading that as, "Do not spawn an Enderman unless no sky is visible and light level is 0-5 and spawn height is below 50, OR on block 121."
But I could be wrong.
I myself find the OR tags a bit confusing. Are you saying you only want them to spawn on 121, and if not 121 then to follow the other rule? Or should you have it as an AND?
Also, from this, you only want them spawning underground from depth 0-50?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEssentially, yes. In the overworld I want Enders only spawning underground (ie. !sky) & below y level 50 & in low light. In The End, I want them to be able to spawn as they normally would, which wouldn't be possible without adding the OR block 121 to the tag.
Edit: Sorry Blue. Just re-read ^there and had a go at myself for forgetting my manners. That's unlike me and totally unintentional. Hope you didn't mind.
About those Enderman tags, I just tested it out and it's working
Yay!