Thanks for clearing that up for me, I may have to try out the origin tag sometime. Sounds handy for keeping the truly nasties away from the new players!
If JAS is now working to run MineFantasy spawns, you could also use it to run MoC spawns. Here's my MoCGlobal.cfg that from what I can tell disables CMS completely. You may want to change some of the other settings - I left ogres and big golems on defaults, for example. How you need it to run the spawning of other mobs is up to you, but since the origin tag works according to players' spawn, you could set all mobs to obey a spawn radius restriction if you wanted.
Well, that gave me a couple crashes, a lot of pigs, and something to fix. I don't need Mo'Creatures; I'll miss the added challege of evading the cats and bears early in the game, but in the end had first installed it to get tendons, which I no longer need. Thanks though.
OP updated with information for servers having the "invisible/mixed-up Mo' Creatures mobs" issue and how to resolve it.
Update to the 5.2.4 (currently DEV) version, and move/rename/delete configs to let new configs generate. Open MoCGlobal.cfg and set useGlobalEntityRegistration to false. Do this for both server/client configs. (source)
I have confirmed that the setting worldGenCreatureSpawning prevents Buildcraft oil generation when set to true. This is with Mo Creatures 5.23 and CustomMobSpawner 2.2.2
Changing this setting to false allows Buildcraft oil gen, and creatures are still spawning. I'm guessing they just won't spawn during initial chunk creation, but they do shortly after. Does anyone know if there are other consequences for this option?
I already answered the question in the other thread. TL;DR - for the most part, all should be fine.
I went a step further and fixed the long time annoyance with CMS and that is with Vanilla Spawner not obeying limits while CMS is being used. An example of this bug is as follows:
Assume you have MoCreatures installed with Thaumcraft. If CMS is used, by default Thaumcraft's mob AngryZombie will get added to vanilla's spawner. We do this to guarantee other modded entities are spawned as "intended" by the author. The bug that occurs is, whatever is added to Vanilla's Spawner would essentially use vanilla's spawn limits and not CMS limits. So if AngryZombie is the only mob on vanilla's spawnlist, it would use the entire vanilla spawn limit for itself causing you to see many of them. This would also affect CMS spawn counts when checking the number of existing entities since it would be counting angryzombies as part of the count. The current workaround was to just add the mob to CMS but that would require the user to go figure out every entity that was being used by vanilla's spawner then change the configs to use CMS instead. To avoid this, I now monitor LivingSpawnEvent.CheckSpawn and deny vanilla spawner spawns if we are passed our count.
Other bugs I have fixed :
1. /moc maxMonsters, /moc maxAmbients, /moc maxCreatures, /moc maxWaterCreatures will now work properly. Currently they update the config but don't actually take affect.
2. /moc debugCMS true/false not working for same reason as above.
3. canSpawn in GUI now works properly if set to false.
Currently working on
1. Saving tamed pet data for players to locate and teleport missing pets(WIP)
2. Improve /moc command colors and messages(Done).
3. Add /moc killall command that supports all custom entities(Done)
4. Add per-world spawn limits for CMS
When the above is done, I plan to release 5.2.5 followed by 1.6.2 update. I believe this functionality will make for a much better release and hope everyone agrees =).
Rollback Post to RevisionRollBack
The config files are your friends! Get to know them, and shape your world!
a tiny problem we/i have, my friend and i play on a hexxit server...COWS DON'T SPAWN !!!!
Looking at the Hexxit mod list, I see no additional spawner systems (CMS, MSC, JAS, etc.) which means vanilla is running the spawns (unless your particular server added something extra). I also don't see anything on that list that has ever been noted of interfering with creature spawns. Are there other mods beyond the Hexxit list added to that server?
I have a feeling that would probably wreck my methods of getting MoC to play as well as it does with everything else. If CMS starts placing that limit on vanilla spawns, it's going to get trickier to stop MoC from overwhelming everything else.
The root of the angry zombie problem is that CMS's default behaviour is to take all vanilla creatures into its own spawn table, leaving the vanilla one only holding mobs from other mods. Reducing vanilla spawn table spawns may well help people suffering from that problem, but is going to open up a whole new can of worms for people trying to achieve a sensible balance.
The real solution to the angry zombie issue is to not allow CMS to take control of vanilla creatures. There's a setting for that in the configs.
Certainly, the solution to a problem caused by CMS interfering with vanilla spawns ought not to be even more interfering with the vanilla spawner.
In the long run, I think you're right. We all know how certain mods like to meddle where they really don't need to though.
Rollback Post to RevisionRollBack
The config files are your friends! Get to know them, and shape your world!
I have a feeling that would probably wreck my methods of getting MoC to play as well as it does with everything else. If CMS starts placing that limit on vanilla spawns, it's going to get trickier to stop MoC from overwhelming everything else.
The root of the angry zombie problem is that CMS's default behaviour is to take all vanilla creatures into its own spawn table, leaving the vanilla one only holding mobs from other mods. Reducing vanilla spawn table spawns may well help people suffering from that problem, but is going to open up a whole new can of worms for people trying to achieve a sensible balance.
The real solution to the angry zombie issue is to not allow CMS to take control of vanilla creatures. There's a setting for that in the configs.
That limit is no longer being done. Instead, next update of CMS will copy all biome spawn list entries from vanilla into its own lists before world loads.
Certainly, the solution to a problem caused by CMS interfering with vanilla spawns ought not to be even more interfering with the vanilla spawner.
Yes which is why we are now putting full control of spawns into CMS by default(excluding structure spawns). This is being done due to vanilla/CMS spawners not running identical code, limits being seperate, spawn ticks being seperate, and other factors that you cannot predict. This change will not break vanilla since we are copying the exact settings placed by mods into our own biome spawn lists. Hope this helps =). I have already made the changes on our official MoCreatures server and everyone loves it. We are running quite a few entity mods along with BoP and XL with excellent balance.
All despawning mobs can spawn in already loaded chunks as long as the requirements are met they never spawn with the chunk.
Non despawning mobs spawn with th chunk and won't spawn again unless the requirements are met
Yes which is why we are now putting full control of spawns into CMS by default(excluding structure spawns). This is being done due to vanilla/CMS spawners not running identical code, limits being seperate, spawn ticks being seperate, and other factors that you cannot predict. This change will not break vanilla since we are copying the exact settings placed by mods into our own biome spawn lists. Hope this helps =). I have already made the changes on our official MoCreatures server and everyone loves it. We are running quite a few entity mods along with BoP and XL with excellent balance.
This sounds like a step in the right direction - auto-import of modded entity settings should help tremendously. I am curious as to how structure spawning will work then? My best guess is that when an entity is to spawn at a structure, vanilla handles it as normal.
All despawning mobs can spawn in already loaded chunks as long as the requirements are met they never spawn with the chunk.
Non despawning mobs spawn with th chunk and won't spawn again unless the requirements are met
That's simple
I'm not entirely sure what you're referencing or replying to, but it if was that simple this thread wouldn't be 22 pages long and include the likes of Dr. Zhark, Bloodshot, Crudedragos, Father Toast, and some of the other long-time mod authors.
Things get messy when 1) modded entities do not spawn/despawn in a usual manner; 2) mods use global entity IDs that conflict; 3) two or more spawning systems are all trying to operate at the same time. There's a few other corner-cases, but those are the main ones.
Rollback Post to RevisionRollBack
The config files are your friends! Get to know them, and shape your world!
OK, heres a good one. For the past week or so my minecraft games have been falling apart due to crashes referencing Mo Creatures, CSM and Project Zulu. A few minutes after starting a world Memory allocation would suddenly skyrocket from around 50% up to 99% and then 100% and then game freeze and crash. The crash reports citing one of three consistently repeated messages. I got rid of one of these by reverting from the current PZ version to the previous one.
The other two remained so yesterday I disabled CSM and installed JAS, a build I've been experimenting with in parallel to get used to the system. The difference is huge. With the same Forge, Mods and set up, the only difference being CSM disabled and JAS implemented, I no longer have memory allocation spikes, it hovers between 50% to 72% and actually falls down to 40% now and again. (Which is a massive difference on whats been happening lately) No game freezes, no crashes, smooth play even on 6 player LAN. And, i'm seeing and confirming everything I set to spawn in the biomes I intend them too, in a good mix with no problems, including Mo Creatures.
I haven't got to grips with all of JAS yet, there are still parts i'm unsure of, but these first results are very encouraging. But its back breaking labour setting up all these configs though, but I have the working in a nearly gameplay acceptable form now.
That sounds like you are using all your RAM allotted to the JVM. How much RAM does your machine have? Give your JVM 2GB and set the following java params :
-XX:PermSize=128M
With the above settings, you should have no issues. I'm running a modpack with 50+ mods and have 0 issues with memory spikes.
You should also adjust the spawnTickRates or max limits in MoCGlobal.cfg to your liking. Try lowering all the max limits and raising the spawnTickRates for less memory usage.
Rollback Post to RevisionRollBack
Help me support Mo Creatures SMP by donating for my time and effort=)
In light of people discussing mods using more memory than they'd like for the functionality they provide I though I would share a post I did up a while back talking about using VisualVM profiling JAS (technically profiling anything your currently running, I just happened to be discussing JAS for obvious reasons). http://www.minecraft...0#entry23120215
JAS Memory consumption will doesn't really scale with the number of entities in the world; it will scale with each additional entity type and biome combination. That said, it should be a trivial amount, at least compared to the anything else going, drop in the bucket so to speak. Also, it should be essentially constant after world start.
Played with JAS + hexxit for a little over an hour and noticed no noticeable increase in memory consumption over time:
Here is a guide to create to do the analysis your self using VisualVM, assuming you are not already familiar with it.
Step 1: Install VisualVM
Google VisualVM, it should take you to http://visualvm.java.net/download.html . I downloaded VisualVM 1.3.5. Extract visualVM anywhere on your system. I created a VisualVM folder at C:\VisualVM\ and extracted the visualvm_135.zip into it. The path to start visualVM is then C:\VisualVM\bin\visualvm.exe . It doesn't matter where, so long as you know where visualvm.exe is.
Step 2: Setup Minecraft
I'm using MultiMC with a maximum memory allocation of 3GB (3072 MB). For this text, I'm using Hexxit from Technic. But anything will obviously do. The important step is the java option -Dcom.sun.management.jmxremote on startup. Without this you will not be able to do a heap dump from VisualVM. This is essentially opening a door to allow VisualVM to inspect whats going on inside our minecraft java instance. Relevent javadoc http://docs.oracle.c...ment/agent.html which is admittedly long winded. Also some relevent stackoverflows http://stackoverflow...s-with-jconsole and http://stackoverflow...ote-connections .
Continuing on, in MultiMC to add -Dcom.sun.management.jmxremote you right click on the instance you want to start and from the menu click settings.
A window pops open with two tabs (Minecraft and Java). On the java tab, set the JVM argument to -Dcom.sun.management.jmxremote.
Step 3: Start VisualVM
Go to whereever you have VisualVM installed and double click it to start. See this for more comprehensive details http://visualvm.java...ingstarted.html .
You should now see
Step 4: Start Minecraft
After minecraft is started the instance should appear inside VisualVM
Step 5: Gather and Interpret Data
Once it appears you open it by clicking. There are useful global stats under Monitor. The show everything summed togther which is not overfly useful for debuggin purposes. IN the monitor tab (or by right clicking as in the image above) you can create a heap dump, which will allow to see the consumption per class. Which is very useful.
At this point, play the game for a short while to let the game stabilize. In order to gather meaningful data we'll more often than not need to compare dumps. We want to compare the dump to a supposedly steady state, not to initial world creation or idle main menu.
If we click HeapDump we get. It needs to be noted that, obviously, some things consume more resources than others. http://en.wikipedia....as_a_free_lunch
After playing for a sufficient time. Take another heap dump. You'll notice a "compare with another heap dump" text in blue. By clicking you can select the previous heap dump. This will change the view to increases +/- instead of absolute values. Hopefully something is obviously wrong and will increase incredibly ahead of other things. Things are not always so simple.
Opened up my JAS World Master folder to continue editing this morning to discover that EVERY bloody ModEntitySettings config for EVERY bloody mod had rewritten itself back to ZERO - to whatever the mod set up had been originally. It wasn't however a full rewrite - where I had changed the Living Handlers to true, which all remained as I set them in every config:
If I didn't have back-ups that would be two weeks work up in smoke. Now it hasn't rewritten the individual world folders, but even so, this shouldn't be happening. The last time I experienced this problem was with Daveydees MSC when anytime you updated a mod the whole thing rewrote itself. I had to resort to locking his configs in read-only until he eventually solved the problem. Since then I've always kept a full up to date config backup.
Nothing changed in my set up before this happened except that I updated Project Zulu to the latest 1.0.4.12 version. It worked fine, and I don't have the previous PZ problem, but it seems to have caused JAS configs to reset? I'm now wondering if any mod updating will also cause a config reset? Has anyone else experienced JAS configs resetting like this?
An update shouldn't matter unless the entity/biome name/classes change.
That is not good. What version are you using? There was a bug fixed v0.9.6 caused by the tempSaveSettings "Sort Creature By Biome" and/or "Universal Entity CFG" being set wrong. The mismatch between how JAS thought they were saved and how they were saved would cause the reading to not find the correct setting. It could be manually fixed by ensureing the tempSaveSettings.cfg were set to the same as the SaveConfig.cfg (for all worlds with the relevent 'Save_Name').
Ahhha! Thanks for that, yes my version of JAS was well out of date - pre-your bug fix, I've updated to the latest available 1.5.2 JAS and I hope that cures the problem. I had also entirely missed the JAS thread, so I've bookmarked that and reading through, there's lots of useful info there. I have the configs presently set to read-only - should I unlock them again?
You should be able to. You'll want to open tempSaveSettings in the entity folder and make sure "Sort Creature By Biome" and "Universal Entity CFG" are set to how it to how the entityCFGs are currently saved. (i.e. if sorting by biome make sure "Sort Creature By Biome" is false)
I did a completely fresh install. Hmmm, the Master folder has vanished?
How do you create a master folder/setting from which all new worlds will draw their original config info? At the moment every new world starts again from scratch?
"Sort creature by biome" has to be "false" to sort them by biome? Is that right?
Also,
"vanilla controls" {
B:"Empty Vanilla SpawnLists on Start"=true
B:"Gamerule doSpawning Off on Start"=false
What do these two controls actually do? In my previous version Empty vanilla was set to false by default. Now its true.
I'm fairly certain he meant sort by biome=true to actually sort by biome. At least, that's how it seems to work for me (and makes the most sense).
Empty vanilla spawnlists will do just that - it clears the vanilla spawn tables entirely. I set this to false myself, so that in the event there's a spawning issue I can see if it's only a JAS problem or if vanilla is being affected as well. I'm not certain of the reason behind clearing vanilla's spawnlists unless you're trying to failsafe anything but JAS spawning, period.
This sets the vanilla spawning gamerule as if you typed in '/gamerule doMobSpawning false' yourself.
I haven't messed with master folders yet, so I've no idea atm. There are some interesting options in the SaveConfig.cfg such as:
# Folder name to Copy Missing Files From. Case Sensitive if OS allows. Beware invalid OS characters.
S:Import_Name=
which seems to imply a "master set" could be referenced, though.
I'm at a bit of a loss actually. The first version I had of JAS generated a "Master" folder that I had been working in and had set up all the configs for each of the mods - Mo Creatures, LOTR, Primitive Mobs, DungeonMobs, Lava Monsters, Fossils, Goblins, Grimoire of Gaia, Witches and More, Twilight Forest, Weeping Angels and vanilla.
I had spawning working pretty damn well. And apart from this sudden config rewrite problem I just experienced, JAS was working out pretty perfectly. I don't understand what this updated version is doing or why. But I don't understand why it seems to have taken a step backward and every world has to be set up individually. This is probably not the case, i'm doing something wrong.
Had a good look through the JAS wiki but it seems hopelessly out of date. In the meantime I've reverted back to the previous build with read only configs and its working fine.
It is more of a moving sideways endeavour. A little cleaner to the client, though a little more effort to initially setup. Significanty easier on my end to find bugs and add features: the ability to toggle sortByBiome (and later the universalCFG) while retaining the previous toggles settings was possible due to this.
As you said, its working for you. Locking the configs is trivial with no real cost as JAS doesn't have an ingame GUI to edit them. Hard to argue with the opportunity cost there.
I had not realized how far back you were. There were some significant changes between then and now. Relevent was the rewriting of how the cofigs were saved as of v0.8. THe issue I spoke of before I'm pretty sure was introduced as of that version and thus don't believe it is the one you encountered. On the other hand as all the save code was rewritten probably doesn't exist.
The World-Master configuration pattern was abandoned. Instead the SaveConfig.cfg in WorldSettings contains a Save_Name propertry for each world which controls where it looks for and saves settings. The "Default Save_Name" controls the default save name a world will get on startup, defaulting to created worlds name, but can changed to anything. You can change the save name after creation and multiple worlds can use one folder by setting the save name to the same name.
There is also an import name option, which is used only when the Save_Name folder is missing. It will COPY the files from the import save_name to the Save_Name folder. This pattern should be more user friendly. Useful when you want to start with specific settings but are going to deviate.
Jasv0.8 changelog, released June 4th. Noteable as it broke biomegroup compatability (in a trivial was, to be fair, but very important to mention).
JAS v0.8.0 Changelog
============== BiomeGroups ==============
BiomeGroup files prior to v0.8.0 are no longer valid. The groups themselves can be with minor changes.
The referencebiomes list is gone, replaced with packagenamemappings. Allowing you to map the complex packages names to a shorter version. Instead of writing "net.minecraft.world.biome.BiomeGenBeach.Beach" you can write "Beach". The mapped name can be changed to any valid string, duplicated are ignored. They are case sensitive.
The allgroups property is gone and replaced with customgroups. The main change is that the default biomegroups (1 for each unique biome name) are always created. They can still be disabled by removing all biomes from the group; any group with no biomes will not be declared and will not show up in the entity CFGs.
============== World Save Configurations ==============
The World-Master configuration pattern is abandoned. Instead the SaveConfig.cfg in WorldSettings contains a Save_Name propertry for each world which controls where it looks for and saves settings. Defaults to world name. Multiple worlds can use one folder by setting the save nam eto the same. There is also an import name option, which is used only when the Save_Name folder is missing. It will COPY the files from the import name to the Save_Name folder. This pattern should be more user friendly.
============== Tags ==============
* ModSpawn Tag. Valid only got livinghandler {spawn} parent tag. Calls default entity spawn method. Chainable and invertable.
* Light and Torchlight tags are now invertable.
* Fixed issue in range Calculation for cases where min>max. When max>min, range is min->max. When min>max, range is max->+INF & -INF->min.
* Add Origin Range Tag. Invertable and chainable. Checks if distance to spawn is within range. Format identical to light or torchlight. Limited to integers.
* Add nearby player tag. Format :player,minSearch,maxSearch,min#,max#. Chainable, invertible.
============== Miscellaneous ==============
* JAS should alwasy now load last. This should resolve issues with JAS not clearing certain mods spawnlists.
* Fix issue where blockRange was not considered valid tag for spawning.
"The World-Master configuration pattern was abandoned. Instead the SaveConfig.cfg in WorldSettings contains a Save_Name propertry for each world which controls where it looks for and saves settings. The "Default Save_Name" controls the default save name a world will get on startup, defaulting to created worlds name, but can changed to anything. You can change the save name after creation and multiple worlds can use one folder by setting the save name to the same name."
Previously, the 'world-master' style, we would take the default settings and filter them through the MASTER config files then take thse settings and filter them through world-specific config files. This works well with a few quirks. Testing can be tricky, particularly when you want to create a new world. If working with master, one has to constantly delete the world-specific folder but if work is done in world specific it must be copied to master before making a new world. It also had a penchant for world specific spam to appear in the Master config. Nothing that would cause a bug since master didn't know to look for it but it could cause an appreciable amount of noise nontheless.
With the change, we essentially removed the middle man, the default settings are filtered through only one set of world specified config files. The improvement is that the world-specific folder does not have to be the same as the world name (the name of the folder is referred to as the Save_Name).
The SaveConfig.cfg allows controlling of the save settings, such as the Save_Name (the folder name the world settings are saved/loaded from) of a world. It is located at \JustAnotherSpawner\WorldSettings\SaveConfig.cfg. Relevent to out conversation, it contains a few important fields: 'Default Save_Name', 'Import_Name', and 'Save_Name'.
Default Save Name and import name are global properties that apply to all worlds.
Save_Name is a world specfic property that sets the name of the folder in \JustAnotherSpawner\WorldSettings\ that the settings will fall under. Multiple worlds are allows to have the same folder name. The typical use case for this is to have most/all worlds have the same name, i.e. MASTER, then you only have one folder of settings to save/backup. That can be tedious to do by hand which brings us to 'Default Save_Name'.
Default Save_Name is the default name for the Save_Name fields above. its default is {$world} which replaced by the currently loaded world name when running. replacing {$world} with MASTER would result in the Save_Name field in SaveConfig.cfg for a new worlds to be MASTER.
Import_Name is less useful and more niche. Instead of working in a common directory this will copy the target Save_Name folder to the folder that is being created. It will not copy individual missing/deleted files. Only if the entire folder is missing/deleted. As an example, say we have a world with save_name FunPieTime and we have import set to import from save_name MASTER. On JAS start if folder FunPieTime is not present, it will copy the MASTER folder and rename the copt to FunPieTime and settings will be read from there. If on JAS start the FunPieTime existed, even if empty, nothing would be done. Settings would then be loaded normally.
Just an FYI:
If you notice a sudden loss of monsters and you're using the Dimensional Doors mod, you likely have a large rift spread somewhere in your world. After about a week of frustration trying to understand why monsters weren't spawning (no, I wasn't in Peaceful - keep reading), I finally discovered a large spread of rifts that were continually spawning Endermen... over 500m from my home.
A recent reply from stevenrs11 confirmed that the rifts (they are tileEntities) seem to be staying loaded even when players aren't around. It's unintentional and recently discovered, and has gone on the "things to fix" list. For now, you can configure the rift settings (or even disable them IIRC) to help prevent this issue. I'd suggest stocking up on rift removers and pumpkins as well.
Rollback Post to RevisionRollBack
The config files are your friends! Get to know them, and shape your world!
Alright when asking about my spesific issue in another thread i was directed here so i will try my best to explain the problem in detail and perhaps you wonderfully intelligent people may be able to give a few suggestions on how to fix it.
I just spent the last week building an ender farm based losely around this concept:
The concept of this farm is based around the endermen spawning around the area where you are. And by building a platform well away from the ender island, you would essentially pull the spawn of the endermen to a more condensed area forcing them to spawn on the top of the farm and then be pushed down through the mechanism and fall into the collection chamber. This was extremely effective and would give roughly 30 levels every 3-4 min.
After many of my members asking for more creatures i have been on the hunt for a mod that gave just that. Noticing today that mo creatures was finally updated to 1.6.2 forge i went through hell to get it installed (the jar file was not actually a jar file but a zip file and i couldnt see the zip ect ect ect.) so i get it installed and now with the Custom Mob Spawner mod, the endermen are spawning differently.
It appears (from my observation) that they are no longer interested in only spawning where i am standing, but all over the entire ender island causing the farm to be empty. It was suggested by a few members maybe we could put half slabs all over the top of the island to stop them from spawning there lol. but thats a whole lot of work and im not sure it would really work anyway (and i wont use world edit or cheat on my server).
Im mostly trying to figure out, with the config files, if there is a way to revert the spawning of endermen in the end back to vanilla style, while still leaving the overworld and nether with the configuration of Mo Creatures spawning so we can have all the new cool animals and baddies without breaking the ender farm.
There does not seem to be a config file spesifically for the end. Changing the spawn entity configs in the Creatures folder in the config folder seems to be only affecting the rate at which endermen spawn in the overworld. Turning off custom mob spawner only makes it so that mo creatures cant spawn anymore.
Alright when asking about my spesific issue in another thread i was directed here so i will try my best to explain the problem in detail and perhaps you wonderfully intelligent people may be able to give a few suggestions on how to fix it.
I just spent the last week building an ender farm based losely around this concept:
The concept of this farm is based around the endermen spawning around the area where you are. And by building a platform well away from the ender island, you would essentially pull the spawn of the endermen to a more condensed area forcing them to spawn on the top of the farm and then be pushed down through the mechanism and fall into the collection chamber. This was extremely effective and would give roughly 30 levels every 3-4 min.
After many of my members asking for more creatures i have been on the hunt for a mod that gave just that. Noticing today that mo creatures was finally updated to 1.6.2 forge i went through hell to get it installed (the jar file was not actually a jar file but a zip file and i couldnt see the zip ect ect ect.) so i get it installed and now with the Custom Mob Spawner mod, the endermen are spawning differently.
It appears (from my observation) that they are no longer interested in only spawning where i am standing, but all over the entire ender island causing the farm to be empty. It was suggested by a few members maybe we could put half slabs all over the top of the island to stop them from spawning there lol. but thats a whole lot of work and im not sure it would really work anyway (and i wont use world edit or cheat on my server).
Im mostly trying to figure out, with the config files, if there is a way to revert the spawning of endermen in the end back to vanilla style, while still leaving the overworld and nether with the configuration of Mo Creatures spawning so we can have all the new cool animals and baddies without breaking the ender farm.
There does not seem to be a config file spesifically for the end. Changing the spawn entity configs in the Creatures folder in the config folder seems to be only affecting the rate at which endermen spawn in the overworld. Turning off custom mob spawner only makes it so that mo creatures cant spawn anymore.
Any ideas?
I'm not entirely familiar with CMS for 1.6.2, and there may have been new settings added. I've not heard of this issue (mobs spawning all over instead of around players) before with CMS, so perhaps there's a setting that can be changed.
Assuming that is not the case, you could try setting the following section in MoCGlobal.cfg to false:
# Forces Custom Spawner to handle vanilla spawns otherwise the default vanilla spawner is used.
B:ModifyVanillaSpawns=true
What that should do is let vanilla spawn its own entities as normal while still letting CMS spawn Mo' Creatures. This should make The End spawn as it used to, but you'll likely have way more total entities spawning in the Overworld because vanilla and CMS are spawning things at the same time. You can lower the spawn caps and other settings for Mo Creatures if that's the case.
I personally do not recommend running two spawn systems at the same time (which is essentially what you'd be doing here), as it becomes more likely you'll run into spawn issues while having a harder time figuring out what the cause is. Your other options at this point would be A ) slabs all over The End to prevent spawning anywhere else; or B ) disabling CMS entirely and using a different spawning mod (Mob Spawn Controls 1 or 2, or Just Another Spawner).
If anyone else is running 1.6.2 with CMS enabled, I'd like to hear your experiences with it - particularly if you've noticed mobs spawning far out of range. That just doesn't sound normal to me for any spawn system, including previous versions of CMS.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWell, that gave me a couple crashes, a lot of pigs, and something to fix. I don't need Mo'Creatures; I'll miss the added challege of evading the cats and bears early in the game, but in the end had first installed it to get tendons, which I no longer need. Thanks though.
Update to the 5.2.4 (currently DEV) version, and move/rename/delete configs to let new configs generate. Open MoCGlobal.cfg and set useGlobalEntityRegistration to false. Do this for both server/client configs. (source)
[EDIT] Just found this:
I already answered the question in the other thread. TL;DR - for the most part, all should be fine.
Looking at the Hexxit mod list, I see no additional spawner systems (CMS, MSC, JAS, etc.) which means vanilla is running the spawns (unless your particular server added something extra). I also don't see anything on that list that has ever been noted of interfering with creature spawns. Are there other mods beyond the Hexxit list added to that server?
In the long run, I think you're right. We all know how certain mods
That limit is no longer being done. Instead, next update of CMS will copy all biome spawn list entries from vanilla into its own lists before world loads.
Yes which is why we are now putting full control of spawns into CMS by default(excluding structure spawns). This is being done due to vanilla/CMS spawners not running identical code, limits being seperate, spawn ticks being seperate, and other factors that you cannot predict. This change will not break vanilla since we are copying the exact settings placed by mods into our own biome spawn lists. Hope this helps =). I have already made the changes on our official MoCreatures server and everyone loves it. We are running quite a few entity mods along with BoP and XL with excellent balance.
Help me support Mo Creatures SMP by donating for my time and effort=)
Non despawning mobs spawn with th chunk and won't spawn again unless the requirements are met
That's simple
This sounds like a step in the right direction - auto-import of modded entity settings should help tremendously. I am curious as to how structure spawning will work then? My best guess is that when an entity is to spawn at a structure, vanilla handles it as normal.
I'm not entirely sure what you're referencing or replying to, but it if was that simple this thread wouldn't be 22 pages long and include the likes of Dr. Zhark, Bloodshot, Crudedragos, Father Toast, and some of the other long-time mod authors.
Things get messy when 1) modded entities do not spawn/despawn in a usual manner; 2) mods use global entity IDs that conflict; 3) two or more spawning systems are all trying to operate at the same time. There's a few other corner-cases, but those are the main ones.
That sounds like you are using all your RAM allotted to the JVM. How much RAM does your machine have? Give your JVM 2GB and set the following java params :
With the above settings, you should have no issues. I'm running a modpack with 50+ mods and have 0 issues with memory spikes.
You should also adjust the spawnTickRates or max limits in MoCGlobal.cfg to your liking. Try lowering all the max limits and raising the spawnTickRates for less memory usage.
Help me support Mo Creatures SMP by donating for my time and effort=)
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttp://www.minecraft...0#entry23120215
JAS Memory consumption will doesn't really scale with the number of entities in the world; it will scale with each additional entity type and biome combination. That said, it should be a trivial amount, at least compared to the anything else going, drop in the bucket so to speak. Also, it should be essentially constant after world start.
Played with JAS + hexxit for a little over an hour and noticed no noticeable increase in memory consumption over time:
Here is a guide to create to do the analysis your self using VisualVM, assuming you are not already familiar with it.
Step 1: Install VisualVM
Google VisualVM, it should take you to http://visualvm.java.net/download.html . I downloaded VisualVM 1.3.5. Extract visualVM anywhere on your system. I created a VisualVM folder at C:\VisualVM\ and extracted the visualvm_135.zip into it. The path to start visualVM is then C:\VisualVM\bin\visualvm.exe . It doesn't matter where, so long as you know where visualvm.exe is.
Step 2: Setup Minecraft
I'm using MultiMC with a maximum memory allocation of 3GB (3072 MB). For this text, I'm using Hexxit from Technic. But anything will obviously do. The important step is the java option -Dcom.sun.management.jmxremote on startup. Without this you will not be able to do a heap dump from VisualVM. This is essentially opening a door to allow VisualVM to inspect whats going on inside our minecraft java instance. Relevent javadoc http://docs.oracle.c...ment/agent.html which is admittedly long winded. Also some relevent stackoverflows http://stackoverflow...s-with-jconsole and http://stackoverflow...ote-connections .
Continuing on, in MultiMC to add -Dcom.sun.management.jmxremote you right click on the instance you want to start and from the menu click settings.
A window pops open with two tabs (Minecraft and Java). On the java tab, set the JVM argument to -Dcom.sun.management.jmxremote.
Step 3: Start VisualVM
Go to whereever you have VisualVM installed and double click it to start. See this for more comprehensive details http://visualvm.java...ingstarted.html .
You should now see
Step 4: Start Minecraft
After minecraft is started the instance should appear inside VisualVM
Step 5: Gather and Interpret Data
Once it appears you open it by clicking. There are useful global stats under Monitor. The show everything summed togther which is not overfly useful for debuggin purposes. IN the monitor tab (or by right clicking as in the image above) you can create a heap dump, which will allow to see the consumption per class. Which is very useful.
At this point, play the game for a short while to let the game stabilize. In order to gather meaningful data we'll more often than not need to compare dumps. We want to compare the dump to a supposedly steady state, not to initial world creation or idle main menu.
If we click HeapDump we get. It needs to be noted that, obviously, some things consume more resources than others. http://en.wikipedia....as_a_free_lunch
After playing for a sufficient time. Take another heap dump. You'll notice a "compare with another heap dump" text in blue. By clicking you can select the previous heap dump. This will change the view to increases +/- instead of absolute values. Hopefully something is obviously wrong and will increase incredibly ahead of other things. Things are not always so simple.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAn update shouldn't matter unless the entity/biome name/classes change.
That is not good. What version are you using? There was a bug fixed v0.9.6 caused by the tempSaveSettings "Sort Creature By Biome" and/or "Universal Entity CFG" being set wrong. The mismatch between how JAS thought they were saved and how they were saved would cause the reading to not find the correct setting. It could be manually fixed by ensureing the tempSaveSettings.cfg were set to the same as the SaveConfig.cfg (for all worlds with the relevent 'Save_Name').
I honestly don't remember the details of the issue all that well but I did find the relevent bug report http://www.minecraftforum.net/topic/1753435-1471516-just-another-spawner-jas-v0100/page__st__420#entry23452083 with past-me's thoughts/solution to the issue below issue it. This sounds eerily similar.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou should be able to. You'll want to open tempSaveSettings in the entity folder and make sure "Sort Creature By Biome" and "Universal Entity CFG" are set to how it to how the entityCFGs are currently saved. (i.e. if sorting by biome make sure "Sort Creature By Biome" is false)
I'm fairly certain he meant sort by biome=true to actually sort by biome. At least, that's how it seems to work for me (and makes the most sense).
Empty vanilla spawnlists will do just that - it clears the vanilla spawn tables entirely. I set this to false myself, so that in the event there's a spawning issue I can see if it's only a JAS problem or if vanilla is being affected as well. I'm not certain of the reason behind clearing vanilla's spawnlists unless you're trying to failsafe anything but JAS spawning, period.
This sets the vanilla spawning gamerule as if you typed in '/gamerule doMobSpawning false' yourself.
I haven't messed with master folders yet, so I've no idea atm. There are some interesting options in the SaveConfig.cfg such as:
which seems to imply a "master set" could be referenced, though.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt is more of a moving sideways endeavour. A little cleaner to the client, though a little more effort to initially setup. Significanty easier on my end to find bugs and add features: the ability to toggle sortByBiome (and later the universalCFG) while retaining the previous toggles settings was possible due to this.
As you said, its working for you. Locking the configs is trivial with no real cost as JAS doesn't have an ingame GUI to edit them. Hard to argue with the opportunity cost there.
I had not realized how far back you were. There were some significant changes between then and now. Relevent was the rewriting of how the cofigs were saved as of v0.8. THe issue I spoke of before I'm pretty sure was introduced as of that version and thus don't believe it is the one you encountered. On the other hand as all the save code was rewritten probably doesn't exist.
The World-Master configuration pattern was abandoned. Instead the SaveConfig.cfg in WorldSettings contains a Save_Name propertry for each world which controls where it looks for and saves settings. The "Default Save_Name" controls the default save name a world will get on startup, defaulting to created worlds name, but can changed to anything. You can change the save name after creation and multiple worlds can use one folder by setting the save name to the same name.
There is also an import name option, which is used only when the Save_Name folder is missing. It will COPY the files from the import save_name to the Save_Name folder. This pattern should be more user friendly. Useful when you want to start with specific settings but are going to deviate.
Jasv0.8 changelog, released June 4th. Noteable as it broke biomegroup compatability (in a trivial was, to be fair, but very important to mention).
JAS v0.8.0 Changelog
============== BiomeGroups ==============
BiomeGroup files prior to v0.8.0 are no longer valid. The groups themselves can be with minor changes.
The referencebiomes list is gone, replaced with packagenamemappings. Allowing you to map the complex packages names to a shorter version. Instead of writing "net.minecraft.world.biome.BiomeGenBeach.Beach" you can write "Beach". The mapped name can be changed to any valid string, duplicated are ignored. They are case sensitive.
The allgroups property is gone and replaced with customgroups. The main change is that the default biomegroups (1 for each unique biome name) are always created. They can still be disabled by removing all biomes from the group; any group with no biomes will not be declared and will not show up in the entity CFGs.
============== World Save Configurations ==============
The World-Master configuration pattern is abandoned. Instead the SaveConfig.cfg in WorldSettings contains a Save_Name propertry for each world which controls where it looks for and saves settings. Defaults to world name. Multiple worlds can use one folder by setting the save nam eto the same. There is also an import name option, which is used only when the Save_Name folder is missing. It will COPY the files from the import name to the Save_Name folder. This pattern should be more user friendly.
============== Tags ==============
* ModSpawn Tag. Valid only got livinghandler {spawn} parent tag. Calls default entity spawn method. Chainable and invertable.
* Light and Torchlight tags are now invertable.
* Fixed issue in range Calculation for cases where min>max. When max>min, range is min->max. When min>max, range is max->+INF & -INF->min.
* Add Origin Range Tag. Invertable and chainable. Checks if distance to spawn is within range. Format identical to light or torchlight. Limited to integers.
* Add nearby player tag. Format :player,minSearch,maxSearch,min#,max#. Chainable, invertible.
============== Miscellaneous ==============
* JAS should alwasy now load last. This should resolve issues with JAS not clearing certain mods spawnlists.
* Fix issue where blockRange was not considered valid tag for spawning.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumPreviously, the 'world-master' style, we would take the default settings and filter them through the MASTER config files then take thse settings and filter them through world-specific config files. This works well with a few quirks. Testing can be tricky, particularly when you want to create a new world. If working with master, one has to constantly delete the world-specific folder but if work is done in world specific it must be copied to master before making a new world. It also had a penchant for world specific spam to appear in the Master config. Nothing that would cause a bug since master didn't know to look for it but it could cause an appreciable amount of noise nontheless.
With the change, we essentially removed the middle man, the default settings are filtered through only one set of world specified config files. The improvement is that the world-specific folder does not have to be the same as the world name (the name of the folder is referred to as the Save_Name).
The SaveConfig.cfg allows controlling of the save settings, such as the Save_Name (the folder name the world settings are saved/loaded from) of a world. It is located at \JustAnotherSpawner\WorldSettings\SaveConfig.cfg. Relevent to out conversation, it contains a few important fields: 'Default Save_Name', 'Import_Name', and 'Save_Name'.
Default Save Name and import name are global properties that apply to all worlds.
Save_Name is a world specfic property that sets the name of the folder in \JustAnotherSpawner\WorldSettings\ that the settings will fall under. Multiple worlds are allows to have the same folder name. The typical use case for this is to have most/all worlds have the same name, i.e. MASTER, then you only have one folder of settings to save/backup. That can be tedious to do by hand which brings us to 'Default Save_Name'.
Default Save_Name is the default name for the Save_Name fields above. its default is {$world} which replaced by the currently loaded world name when running. replacing {$world} with MASTER would result in the Save_Name field in SaveConfig.cfg for a new worlds to be MASTER.
Import_Name is less useful and more niche. Instead of working in a common directory this will copy the target Save_Name folder to the folder that is being created. It will not copy individual missing/deleted files. Only if the entire folder is missing/deleted. As an example, say we have a world with save_name FunPieTime and we have import set to import from save_name MASTER. On JAS start if folder FunPieTime is not present, it will copy the MASTER folder and rename the copt to FunPieTime and settings will be read from there. If on JAS start the FunPieTime existed, even if empty, nothing would be done. Settings would then be loaded normally.
Hope that helps.
If you notice a sudden loss of monsters and you're using the Dimensional Doors mod, you likely have a large rift spread somewhere in your world. After about a week of frustration trying to understand why monsters weren't spawning (no, I wasn't in Peaceful - keep reading), I finally discovered a large spread of rifts that were continually spawning Endermen... over 500m from my home.
A recent reply from stevenrs11 confirmed that the rifts (they are tileEntities) seem to be staying loaded even when players aren't around. It's unintentional and recently discovered, and has gone on the "things to fix" list. For now, you can configure the rift settings (or even disable them IIRC) to help prevent this issue. I'd suggest stocking up on rift removers and pumpkins as well.
I just spent the last week building an ender farm based losely around this concept:
The concept of this farm is based around the endermen spawning around the area where you are. And by building a platform well away from the ender island, you would essentially pull the spawn of the endermen to a more condensed area forcing them to spawn on the top of the farm and then be pushed down through the mechanism and fall into the collection chamber. This was extremely effective and would give roughly 30 levels every 3-4 min.
After many of my members asking for more creatures i have been on the hunt for a mod that gave just that. Noticing today that mo creatures was finally updated to 1.6.2 forge i went through hell to get it installed (the jar file was not actually a jar file but a zip file and i couldnt see the zip ect ect ect.) so i get it installed and now with the Custom Mob Spawner mod, the endermen are spawning differently.
It appears (from my observation) that they are no longer interested in only spawning where i am standing, but all over the entire ender island causing the farm to be empty. It was suggested by a few members maybe we could put half slabs all over the top of the island to stop them from spawning there lol. but thats a whole lot of work and im not sure it would really work anyway (and i wont use world edit or cheat on my server).
Im mostly trying to figure out, with the config files, if there is a way to revert the spawning of endermen in the end back to vanilla style, while still leaving the overworld and nether with the configuration of Mo Creatures spawning so we can have all the new cool animals and baddies without breaking the ender farm.
There does not seem to be a config file spesifically for the end. Changing the spawn entity configs in the Creatures folder in the config folder seems to be only affecting the rate at which endermen spawn in the overworld. Turning off custom mob spawner only makes it so that mo creatures cant spawn anymore.
Any ideas?
I'm not entirely familiar with CMS for 1.6.2, and there may have been new settings added. I've not heard of this issue (mobs spawning all over instead of around players) before with CMS, so perhaps there's a setting that can be changed.
Assuming that is not the case, you could try setting the following section in MoCGlobal.cfg to false:
What that should do is let vanilla spawn its own entities as normal while still letting CMS spawn Mo' Creatures. This should make The End spawn as it used to, but you'll likely have way more total entities spawning in the Overworld because vanilla and CMS are spawning things at the same time. You can lower the spawn caps and other settings for Mo Creatures if that's the case.
I personally do not recommend running two spawn systems at the same time (which is essentially what you'd be doing here), as it becomes more likely you'll run into spawn issues while having a harder time figuring out what the cause is. Your other options at this point would be A ) slabs all over The End to prevent spawning anywhere else; or B ) disabling CMS entirely and using a different spawning mod (Mob Spawn Controls 1 or 2, or Just Another Spawner).
If anyone else is running 1.6.2 with CMS enabled, I'd like to hear your experiences with it - particularly if you've noticed mobs spawning far out of range. That just doesn't sound normal to me for any spawn system, including previous versions of CMS.
How exactly would Mob Spawn Controls or Just Another Spawner work in conjunction with Mo Creatures? And are they compatible with forge and 1.6.2