I see what you mean but I was actually talking about grouping multiple entities into one entity class, like Mo'Creatures big cats and bears. This means when using a different spawner mod you can only choose to spawn a bear rather than define the bear type (polar bear, panda, etc).
With regard to your comment, I don't use MSC to spawn but I believe that what you want can be achieved with JAS.
Yes, I do believe the HorseMob entity from Mo Creatures is one that doesn't let you separate .. the diseased horse, bone horse, black Pegasus horses are all in the one... which I agree,. is very annoying. I would love to spawn bone horses in dead lands, and black Pegasus in the ominous woods... but cant set them separately. So I agree.
@Mohawky - Idk what's causing your zombie issues, but it's not vanilla.
My server admin made a goof during a restart and caused a mess with no backup... so we all started over. Anyway, in the new world we noticed some spawn issues, namely 400+ entities at load and around 230 as things settled down - much more than we should've had. There were tons of MoC insects, snails, etc. about, and I told him that they were defaulting to Ambient now and I left them there to see how it would go.
We agreed to go back into JAS and set them to Opensky, and they returned to managable numbers. However, there was another issue that we still haven't seemed to fix. MoC insects set to false for spawn (and even in category None) were still spawning...
Wait, I think I may know what's going on. I'll have to check JAS documentation, but with configs already set with a new world loaded, I wonder if 0.5.1 auto-sets the doMobSpawning rules? I don't recall us entering those commands when we started the new world. I'll try them and report back.
After doing the commands to disable vanilla and enable JAS, the server seems to be functioning correctly.
However, this brings up something else I'd like to mention. I'm using a slightly older CMS/MoC (1.12.2 and 5.0.7) and have CMS disabled. With JAS also disabled prior to the commands, it means we had to have been running on vanilla spawning only.
That has me wondering now... what determined the MoC ambients' spawn settings? I'd assume the MoC configs, right?
Rollback Post to RevisionRollBack
The config files are your friends! Get to know them, and shape your world!
After several mind-numbing months of experiments, and testing. Creating new worlds, destroying others... its finally fixed.
I have found the source of the passive mobs not spawning bug.
Our server world was to large. Spanning over 20,000 x 17,000 blocks (world files 700+MB). It somehow caused the creatures to cease making new spawns. Perhaps because it still counted the offloaded ones? Perhaps the world just gets buggy when its to big? Who can say for sure; all I know, is that its finally... finally fixed.
The convo continues in that thread, basically that he/she's watching the world to see if things are still working. They used MCEdit to trim chunks and remove unwanted mobs.
It was mentioned by another user that while a great fix, it sounds like the problem will only occur again once more exploring takes place. I wanted to bring this to everyone's attention, as it was something I experienced in 1.4.7 under MSC/MoC/CMS. Others said exploring a little restarted the spawns, but if what the poster reports is the case, once your world is "too big", exploring more of it only makes the issue worse.
Interesting indeed, and will definitely require more information.
Rollback Post to RevisionRollBack
The config files are your friends! Get to know them, and shape your world!
Oh no! SirDave has become SirHumphrey - I've read that three times and still dont understand it
I believe the point was about how non-despawning creatures can take over the cap preventing creatures that do despawn from appearing. Of course I could be misinterpreting.
What I actually meant was, lets say i had PZ armdillos (non de spawning by default at the time) set to 4/1/1 and 5 other mobs all set to 10/1/1, what I actually saw was that armdillos seemed to spawn as expected but they semmed to prevent non despawning mobs from spawning and yes eventually taking over the cap as nothing else was spawning, but with all other mobs set to mroe than double the weight I would expect to see large numbers of other but actually did not see this.
When they were changed to despawn this effect went away.
The same was also true with chunk generation for vanilla. When they were set to anything other than 1/1/1 they seemed to prevent other mobs spawning.
Actually it might be non-despawning only and nothing to do with chunk gen because as I recall vanilla animals spawn "normally" under MSC continuing to spawn after chunk gen.
I also bserved this phenomenon with atmosmobs bison, all 3 examples being non despawning and in my experience prevented despawners from spawning in the first place.
Hmm. Lets see if I got this straight. You think that maybe non-despawning entities might have been getting preference over despawning entities regardless of weighting the despawners higher?
Given how crazy entity spawning is I have no idea if this is possible or not. Maybe it was just the fact that you saw less of the despawning entities, even with a higher weight, due to their despawning? If you have 3 of 'mob a' spawn and 2 of 'mob b,' and then one or two of 'mob a' despawned while 'mob b' was persistent it could give the appearance of a preference to the non-despawner even before the cap was reached; as far as I know despawning happens regardless of what the respective entity cap is at.
Meh, who knows (I sure don't, I am not a programmer or anything). All this spawning stuff is so hard to keep straight; makes my head spin at times.
Now off to try and see if I can determine if/how CMS despawning is interacting with JAS. Yay...
Has anyone had better luck getting the monsters to behave, and spawn in a more balanced fashion?
Not yet, but I have just recently started messing with my mob mods and spawn settings. Of course I am using JAS instead of CMS, which I have been able to effectively disable by setting the spawn-rates of all monsters to 1 and removing them from all biome-groups giving CMS no where to spawn them. In my few tests it also seems that CMS isn't altering the despawn behavior of JAS which is good.
Of course once the bug with simply disabling the use CMS is fixed so the game doesn't crash things should be much easier and not need a hackish workaround.
Now I am working on figuring out how I am going to divide and group all the biomes.
At the moment, i'm waiting to see and test the changes in CMS next version, and if it still doesnt work, will bite the bullet and have a go at the complexity that is JAS.
JAS isn't that bad once you get your head around the differences between {spawn} and {!spawn}. Once I started to understand that most of the rest seemed pretty natural in terms of configuring the spawning/despawning of entities.
Oho! The Dev versions of the new MoC and CMS are upon us. Let the testing begin!
Edit: MoC Monster spawns still take priority over ones on the vanilla spawning table, regardless of what you set their weight at. Hmm. Let's see what happens when you use the option to turn CMS off.
CMS/Vanilla spawning tables are completely seperate. Setting weight on CMS side has no affect on vanilla. Any custom entities defined with no biomegroups will be left untouched on vanilla spawning tables by default unless you explicity set the frequency to 0 on CMS side. It is up to the user to configure it correctly for CMS. I'm sure many users will start to share their configs once they figure out the best balance.
With CMS turned off, no MoC entities of any sort spawn. I'd hoped that they would insert themselves into the vanilla table using the biomes and weights described in their config, but that's OK. I guess they can be added via the spawn manager of your choice. Which would have been perfect for me until I learned MSC kills your spawning. (Does anyone know if MSC2 has the same problem?)
Then there's the other option. Inserting everything from everywhere else into CMS. It does have cfg files for some of the mods I have installed, though not all (No sign of Rencraft penguins, or Farlanders. And the Project Zulu cfg is blank.), which is a bit worrying. Still, it's clear a lot of work has been done on making it easier to get mods to work.
Edit: Aha, Project Zulu's creatures seem to have ended up in com.cfg. Com.cfg also duplicated entries from other config files such as the Thaumcraft mobs, so that's probably not quite right either.
I'm probably going to stick with just using not using MoC's monsters for now. (Though I could change the wolves and rats into animals. Hmm. Might try that. ) Handily, there's a new setting for that so we don't need to fiddle with their individual settings.
I don't understand how ProjectZulu is being created as "com.cfg". The way it *should* work is you setup the mod-mappings in MoCGlobal.cfg with the file it should go to. So for example, since ProjectZulu uses "projectzulu" in its package name, that is what i use to map to ProjectZulu.cfg as shown here :
As each entity is read, I check the class name to see if it contains one of my mappings and if so place it in the mapped cfg. The tags are mainly used for handling duplicate biome names. When you define a biomegroup, you must use the correct tag and name like so "TAG|Biomename".
Can you verify that your project zulu mod zip/jar contains "projectzulu" in its package name? And if so, turn on debuglogging and paste me the output.
As for Farlanders, the package name they use is "net.minecraft". I was originally setting this name to vanilla for use in eclipse but i have no switched it to "net.minecraft.entity". I'm currently testing Rancraft and Farlanders and will let you know when it is working.
I also added the ability for MoCreatures to automatically generate new mods that are not currently in mod-mappings. Any mapping that gets generated like this will have a comment "automatically generated" above its comment in MoCGlobal.cfg. However there is a bug with this in current release and has been fixed. I will update the file shortly.
When we have Vanilla and CMS both spawning monsters, the overwhelming majority of them will be MoC ones. That's the problem I was trying to sort out. My flailing around with weights was born of desperation. It's a problem many people on this thread can confirm. For whatever reason, it does not appear to be an issue with animals.
RE: Project Zulu, I'm using ProjectZuluCompletev1.0.3.2.zip
There's Project Zulu in there, Thaumcraft, and some Lion King. The Flying Book from Enhanced Books. Possibly other stuff. All except Zulu also have their own files which have entires for the same creatures that are in com.cfg. It seemed to me that some of the files were written when launching Minecraft, and then some were written when actually creating the world.
I'll go get you those log files you asked for.
Every creature type(CREATURE, AMBIENT, WATERCREATURE, MONSTER) have its own spawn tick rate. So if MoC monsters are overwhelming vanilla's, you will have to raise monsterSpawnTickRate so CMS spawns that type less frequently. In previous CMS versions, all types were using the same tick rate but this has been fixed by seperating them all. You can also adjust CMS monster limits by lowering maxMonsters value. I may have set it a bit too high. I didn't really have time to find the best balance so if you find better numbers, please share.
As for the "com.cfg", I meant the package name but I'll grab that version of zulu and test it myself. Also can you tell me your exact setup? Forge Build, MC version etc.
Here is what generated for me using ProjectZuluComplete1.0.3.3.zip on a fresh new client :
In case you missed it, I appended the logs you wanted to my last post.
ProjectZuluComplete1.0.3.3.zip is a version up from what I'm using. I'll see if that makes the difference. I hadn't noticed there'd been an update.
I'll need a log with 'debugLogging' turned on in MoCGlobal.cfg. Setting this option to true will generate a ton of output in the FML log. Same goes with 'debugCMS' if you are having issues with spawning. 'debugCMS' will show the entity class, spawned coord, type:freq:min:max:chunk, and the biome it spawned in. It also shows some debug for light levels if you noticed a type of creature/monster that shouldn't of spawned.
Rollback Post to RevisionRollBack
Help me support Mo Creatures SMP by donating for my time and effort=)
Just started testing CMS. And I can confirm the problems Arkenor originally reported. Especially the missing PZ config and duplication of entities from lots of different mods along with PZ in the com.cfg. The Goblins mod had no config for its mobs - though they were present in the last CMS version, they are entirely absent in this version.
I resolved the issues that Arkenor reported with MoCreatures DEV 5.2.0a. Redownload from the same link to get it. It detected all of his mods correctly and generated all configs fine.
In Global mod options - IDResolver button is back. But at any one time if checked in game, or with a world closed, I have between 1 to 3 identical Mo Creatures buttons. - that all seem to do the same function - not sure whats going on there. A guess - its generating one button each time I create a new world?
There is a noticable 5 sec gap before loading world begins. World generation takes much longer, sometimes double the time it took before. However, once the world opens a LOT of the lag I was experiencing under the last CMS version has vanished and the worlds are smooth again.
I'll see if I can optimize what I do during world loads.
I noticed at this point that sveral biomes from the same mod - such as EBXL or BOP were already replicated in the MOC Biome groupings - appearing more than once under different groups? Not sure why this should be? (These were not ones I had interfered with for the arcticmountain grouping.)
This was intended. You should be able to edit the default groups directly if you so desire.
So I then changed and added sixteen more (the set up I had constructed on the previous version of CMS which seemed to work fine) - result - game would not open - MC black screen. Thinking I made a typo at some point I've now started adding the additional groupings one by one and reopening a new game to test each time. This is a very laborious and time consuming process, I still have five to go, but no game failures so far and the new groupings are appearing in game fine.
Make sure to use the correct Biome Tag defined in mod-mappings under MoCGlobal.cfg. The format is TAG|Biome
What this part of the GUI needs is a "Create and name new grouping" button, with a simple click to transfer to new group mechanism of some kind as already exists on the following screens for adding or subtracting biomes to existing groupings. Working with a larger number of biome groupings directly in the config is very open to typos etc. Its a painful process that could be simplified I think.
There is already a menu for this called "Biome Groups". Although I need to fix a few things with it. Good Idea, I apparently forgot to add it =). This will fix the tedious process of doing in the config.
Biome groupings registration - misses two biomes from Myth & Monsters mod - Deep Ocean & Ice Sheet - puts them into a com.doc but not into the game and attempting to add them manually leads to a game crash. But I think there are problems with the way this mod generates its biomes anyway as they have no config ID's for them. So there are I think conflicts with other mods biome iD's to start with.
Fixed in MoCreatures DEV 5.2.0a. Keep in mind, all mod-mappings can be found in MoCGlobal.cfg. This is how it determines what to generate as the filename. There are a bunch of default mappings for certain mods and any new ones *should* be autogenerated depending on the package name of the mod. I improved the autogenerated process in 5.2.0a. If it ever ends up as "com.cfg", you can always fix it in mod-mappings.
On the Biome groupings - I just finished them and have no crashes. But, there were NO typos or mistakes in the original, so it should not have crashed? What i had done however was entirely delete one of the original biome groupings - FOREST - and replace with three other categories. It seems to be this deletion that caused the crash. I therefore left the original biome name of forest on one of the replacements and it worked fine.
Copy of the BiomeGroupings here, so you can see what I did:
EDIT: New version working fine. Goblins etc now have own configs. Project Zulu config still empty and its mobs are in com.cfg.
Odd, I think Arkenor had this problem originall but then I had him update zulu to Project Zulu v1.0.3.3 Complete. My guess is you are using 1.0.3.2 as well? If so, try 1.0.3.3.
Just finished all the mod configs - and everything seems to be spawning just fine.
Project Zulu is now the only problem - the version I have is 1.0.3.3Complete, but i will download another copy and replace, just in case there is something odd there. Would PZ creatures still spawn from the com.cfg ?
I've run a few test worlds and everything at first look over seems to be working very well. The creatures and mobs are spawning in the right biomes and to the numbers i'm setting.
Loks like a good job so far!
Great!
Really strange how they are still ending up in com.cfg. Try this, open MoCGlobal.cfg and look for the section 'mod-mappings', do you see the following line ?
S:projectzulu <ZULU:ProjectZulu.cfg>
If not, add it and retest. It should create a config file in config/MoCreatures/Creatures/ProjectZulu.cfg
Rollback Post to RevisionRollBack
Help me support Mo Creatures SMP by donating for my time and effort=)
I can report that raising the tick rate in MoCGlobal.cfg does indeed give vanilla monsters breathing space to spawn. To test it I bumped it from 30 to 200, and got almost all vanilla list monsters. Obviously need to find a number with a suitable balance, but we've got a solution now.
With the MoC monsters, I ended up spawning them only in river biomes due to that, which was not ideal. Glad you found a solution for it that can help us all.
Edited to include the *right* quote. Apologies Arkenor.
Awesome information - thanks! I'll link your last 2 posts in the OP and add Utility Mobs to the Global IDs list. You da man!
I have fixed Utility Mobs to register its entities properly, now.
Thanks to Arkenor for bringing that to my attention; I completely forgot to fix that as I was updating the mod from 1.2.5.
Hurrah! Many thanks. We've had a lot of progress on that project. MoC has converted many of its entities to Mod Entity IDs now. I think its just the tameables using Globals now, as converting is going to be a bit of a pain. At any rate, it's a lot harder to run out of Global IDs.
Now if I can just persuade Thaumcraft and Mystcraft to get on board...
Indeed, I can't see any reason not to use mod entity ids! At least, not for entities that can be deleted and nobody screams about. Even then, you should be able to register some sort of dummy entity under the old global id that immediately converts itself into the mod id version and remove the dummy entity after a while (finally freeing up the global id).
The whole process should only take two Minecraft updates, so that the dummy exists continuously for a whole version, before it's taken out entirely in the next version.
I have fixed Utility Mobs to register its entities properly, now.
Thanks to Arkenor for bringing that to my attention; I completely forgot to fix that as I was updating the mod from 1.2.5.
Sorry for not keeping up to date on the forums. As John Lennon said, "Life is what happens while you're busy making other plans." I'll update the OP now. Thanks for bringing it to my attention!
Rollback Post to RevisionRollBack
The config files are your friends! Get to know them, and shape your world!
Sorry for not keeping up to date on the forums. As John Lennon said, "Life is what happens while you're busy making other plans." I'll update the OP now. Thanks for bringing it to my attention!
It's no problem! It would be silly to expect you to constantly check on every mod just to see when it changes. Thanks for updating!
Yes, I do believe the HorseMob entity from Mo Creatures is one that doesn't let you separate .. the diseased horse, bone horse, black Pegasus horses are all in the one... which I agree,. is very annoying. I would love to spawn bone horses in dead lands, and black Pegasus in the ominous woods... but cant set them separately. So I agree.
My server admin made a goof during a restart and caused a mess with no backup... so we all started over. Anyway, in the new world we noticed some spawn issues, namely 400+ entities at load and around 230 as things settled down - much more than we should've had. There were tons of MoC insects, snails, etc. about, and I told him that they were defaulting to Ambient now and I left them there to see how it would go.
We agreed to go back into JAS and set them to Opensky, and they returned to managable numbers. However, there was another issue that we still haven't seemed to fix. MoC insects set to false for spawn (and even in category None) were still spawning...
Wait, I think I may know what's going on. I'll have to check JAS documentation, but with configs already set with a new world loaded, I wonder if 0.5.1 auto-sets the doMobSpawning rules? I don't recall us entering those commands when we started the new world. I'll try them and report back.
However, this brings up something else I'd like to mention. I'm using a slightly older CMS/MoC (1.12.2 and 5.0.7) and have CMS disabled. With JAS also disabled prior to the commands, it means we had to have been running on vanilla spawning only.
That has me wondering now... what determined the MoC ambients' spawn settings? I'd assume the MoC configs, right?
The convo continues in that thread, basically that he/she's watching the world to see if things are still working. They used MCEdit to trim chunks and remove unwanted mobs.
It was mentioned by another user that while a great fix, it sounds like the problem will only occur again once more exploring takes place. I wanted to bring this to everyone's attention, as it was something I experienced in 1.4.7 under MSC/MoC/CMS. Others said exploring a little restarted the spawns, but if what the poster reports is the case, once your world is "too big", exploring more of it only makes the issue worse.
Interesting indeed, and will definitely require more information.
I believe the point was about how non-despawning creatures can take over the cap preventing creatures that do despawn from appearing. Of course I could be misinterpreting.
Hmm. Lets see if I got this straight. You think that maybe non-despawning entities might have been getting preference over despawning entities regardless of weighting the despawners higher?
Given how crazy entity spawning is I have no idea if this is possible or not. Maybe it was just the fact that you saw less of the despawning entities, even with a higher weight, due to their despawning? If you have 3 of 'mob a' spawn and 2 of 'mob b,' and then one or two of 'mob a' despawned while 'mob b' was persistent it could give the appearance of a preference to the non-despawner even before the cap was reached; as far as I know despawning happens regardless of what the respective entity cap is at.
Meh, who knows (I sure don't, I am not a programmer or anything). All this spawning stuff is so hard to keep straight; makes my head spin at times.
Now off to try and see if I can determine if/how CMS despawning is interacting with JAS. Yay...
Not yet, but I have just recently started messing with my mob mods and spawn settings. Of course I am using JAS instead of CMS, which I have been able to effectively disable by setting the spawn-rates of all monsters to 1 and removing them from all biome-groups giving CMS no where to spawn them. In my few tests it also seems that CMS isn't altering the despawn behavior of JAS which is good.
Of course once the bug with simply disabling the use CMS is fixed so the game doesn't crash things should be much easier and not need a hackish workaround.
Now I am working on figuring out how I am going to divide and group all the biomes.
JAS isn't that bad once you get your head around the differences between {spawn} and {!spawn}. Once I started to understand that most of the rest seemed pretty natural in terms of configuring the spawning/despawning of entities.
CMS/Vanilla spawning tables are completely seperate. Setting weight on CMS side has no affect on vanilla. Any custom entities defined with no biomegroups will be left untouched on vanilla spawning tables by default unless you explicity set the frequency to 0 on CMS side. It is up to the user to configure it correctly for CMS. I'm sure many users will start to share their configs once they figure out the best balance.
Bug with MSC2 with how it is reading spawnlists.
I don't understand how ProjectZulu is being created as "com.cfg". The way it *should* work is you setup the mod-mappings in MoCGlobal.cfg with the file it should go to. So for example, since ProjectZulu uses "projectzulu" in its package name, that is what i use to map to ProjectZulu.cfg as shown here :
As each entity is read, I check the class name to see if it contains one of my mappings and if so place it in the mapped cfg. The tags are mainly used for handling duplicate biome names. When you define a biomegroup, you must use the correct tag and name like so "TAG|Biomename".
Can you verify that your project zulu mod zip/jar contains "projectzulu" in its package name? And if so, turn on debuglogging and paste me the output.
As for Farlanders, the package name they use is "net.minecraft". I was originally setting this name to vanilla for use in eclipse but i have no switched it to "net.minecraft.entity". I'm currently testing Rancraft and Farlanders and will let you know when it is working.
I also added the ability for MoCreatures to automatically generate new mods that are not currently in mod-mappings. Any mapping that gets generated like this will have a comment "automatically generated" above its comment in MoCGlobal.cfg. However there is a bug with this in current release and has been fixed. I will update the file shortly.
Hope this helps =)
Help me support Mo Creatures SMP by donating for my time and effort=)
Every creature type(CREATURE, AMBIENT, WATERCREATURE, MONSTER) have its own spawn tick rate. So if MoC monsters are overwhelming vanilla's, you will have to raise monsterSpawnTickRate so CMS spawns that type less frequently. In previous CMS versions, all types were using the same tick rate but this has been fixed by seperating them all. You can also adjust CMS monster limits by lowering maxMonsters value. I may have set it a bit too high. I didn't really have time to find the best balance so if you find better numbers, please share.
As for the "com.cfg", I meant the package name but I'll grab that version of zulu and test it myself. Also can you tell me your exact setup? Forge Build, MC version etc.
Here is what generated for me using ProjectZuluComplete1.0.3.3.zip on a fresh new client :
ProjectZulu.cfg
# Configuration file
####################
# entity-biome-settings
####################
entity-biome-settings {
S:Alligator <>
S:Armadillo <>
S:Beaver <>
S:BlackBear <>
S:BlueFinch <>
S:Boar <>
S:BrownBear <>
S:Centipede <>
S:Eagle <>
S:Elephant <>
S:Follower <>
S:Fox <>
S:Frog <>
S:Giraffe <>
S:Gorilla <>
S:GreenFinch <>
S:HauntedArmor <>
S:HornBill <>
S:HorseBeige <>
S:HorseBlack <>
S:HorseBrown <>
S:HorseDarkBlack <>
S:HorseDarkBrown <>
S:HorseWhite <>
S:Lizard <>
S:Mammoth <>
S:Mimic <>
S:Minotaur <>
S:Mummy <>
S:MummyPharaoh <>
S:Ostrich <>
S:Pelican <>
S:Penguin <>
S:PolarBear <>
S:Rabbit <>
S:RedFinch <>
S:Rhino <>
S:SandWorm <>
S:TreeEnt <>
S:Vulture <>
}
####################
# entity-spawn-settings
####################
entity-spawn-settings {
S:Alligator <CREATURE:6:1:2:3>
S:Armadillo <CREATURE:6:1:2:3>
S:Beaver <CREATURE:6:1:2:3>
S:BlackBear <CREATURE:6:1:2:3>
S:BlueFinch <AMBIENT:6:1:2:3>
S:Boar <CREATURE:6:1:2:3>
S:BrownBear <CREATURE:6:1:2:3>
S:Centipede <MONSTER:6:1:2:3>
S:Eagle <AMBIENT:6:1:2:3>
S:Elephant <CREATURE:6:1:2:3>
S:Follower <UNDEFINED:6:1:2:3>
S:Fox <CREATURE:6:1:2:3>
S:Frog <CREATURE:6:1:2:3>
S:Giraffe <UNDEFINED:6:1:2:3>
S:Gorilla <CREATURE:6:1:2:3>
S:GreenFinch <AMBIENT:6:1:2:3>
S:HauntedArmor <MONSTER:6:1:2:3>
S:HornBill <AMBIENT:6:1:2:3>
S:HorseBeige <CREATURE:6:1:2:3>
S:HorseBlack <UNDEFINED:6:1:2:3>
S:HorseBrown <CREATURE:6:1:2:3>
S:HorseDarkBlack <CREATURE:6:1:2:3>
S:HorseDarkBrown <CREATURE:6:1:2:3>
S:HorseWhite <CREATURE:6:1:2:3>
S:Lizard <MONSTER:6:1:2:3>
S:Mammoth <CREATURE:6:1:2:3>
S:Mimic <MONSTER:6:1:2:3>
S:Minotaur <MONSTER:6:1:2:3>
S:Mummy <MONSTER:6:1:2:3>
S:MummyPharaoh <MONSTER:6:1:2:3>
S:Ostrich <CREATURE:6:1:2:3>
S:Pelican <AMBIENT:6:1:2:3>
S:Penguin <CREATURE:6:1:2:3>
S:PolarBear <CREATURE:6:1:2:3>
S:Rabbit <CREATURE:6:1:2:3>
S:RedFinch <AMBIENT:6:1:2:3>
S:Rhino <CREATURE:6:1:2:3>
S:SandWorm <MONSTER:6:1:2:3>
S:TreeEnt <CREATURE:6:1:2:3>
S:Vulture <MONSTER:6:1:2:3>
}
Help me support Mo Creatures SMP by donating for my time and effort=)
I'll need a log with 'debugLogging' turned on in MoCGlobal.cfg. Setting this option to true will generate a ton of output in the FML log. Same goes with 'debugCMS' if you are having issues with spawning. 'debugCMS' will show the entity class, spawned coord, type:freq:min:max:chunk, and the biome it spawned in. It also shows some debug for light levels if you noticed a type of creature/monster that shouldn't of spawned.
Help me support Mo Creatures SMP by donating for my time and effort=)
I resolved the issues that Arkenor reported with MoCreatures DEV 5.2.0a. Redownload from the same link to get it. It detected all of his mods correctly and generated all configs fine.
GUI bug which will be fixed.
I'll see if I can optimize what I do during world loads.
This was intended. You should be able to edit the default groups directly if you so desire.
Make sure to use the correct Biome Tag defined in mod-mappings under MoCGlobal.cfg. The format is TAG|Biome
There is already a menu for this called "Biome Groups". Although I need to fix a few things with it.Good Idea, I apparently forgot to add it =). This will fix the tedious process of doing in the config.Fixed in MoCreatures DEV 5.2.0a. Keep in mind, all mod-mappings can be found in MoCGlobal.cfg. This is how it determines what to generate as the filename. There are a bunch of default mappings for certain mods and any new ones *should* be autogenerated depending on the package name of the mod. I improved the autogenerated process in 5.2.0a. If it ever ends up as "com.cfg", you can always fix it in mod-mappings.
Help me support Mo Creatures SMP by donating for my time and effort=)
Interesting, I'll have to fix that too =).
No, the spawn list entry will only be entered once in each biome spawn list.
Odd, I think Arkenor had this problem originall but then I had him update zulu to Project Zulu v1.0.3.3 Complete. My guess is you are using 1.0.3.2 as well? If so, try 1.0.3.3.
I forgot to add a comment about it. It means max spawn in chunk during world gen.
So, Type:Frequency:MinGroupSpawn:MaxGroupSpawn:MaxSpawnInChunk
Help me support Mo Creatures SMP by donating for my time and effort=)
Great!
Really strange how they are still ending up in com.cfg. Try this, open MoCGlobal.cfg and look for the section 'mod-mappings', do you see the following line ?
If not, add it and retest. It should create a config file in config/MoCreatures/Creatures/ProjectZulu.cfg
Help me support Mo Creatures SMP by donating for my time and effort=)
With the MoC monsters, I ended up spawning them only in river biomes due to that, which was not ideal. Glad you found a solution for it that can help us all.
Edited to include the *right* quote. Apologies Arkenor.
I have fixed Utility Mobs to register its entities properly, now.
Thanks to Arkenor for bringing that to my attention; I completely forgot to fix that as I was updating the mod from 1.2.5.
Indeed, I can't see any reason not to use mod entity ids! At least, not for entities that can be deleted and nobody screams about. Even then, you should be able to register some sort of dummy entity under the old global id that immediately converts itself into the mod id version and remove the dummy entity after a while (finally freeing up the global id).
The whole process should only take two Minecraft updates, so that the dummy exists continuously for a whole version, before it's taken out entirely in the next version.
Sorry for not keeping up to date on the forums. As John Lennon said, "Life is what happens while you're busy making other plans." I'll update the OP now. Thanks for bringing it to my attention!
It's no problem! It would be silly to expect you to constantly check on every mod just to see when it changes. Thanks for updating!