I'm getting this crash constantly, using a custom modpack for Minecraft 1.7.10 on Forge 1217. Running special mobs version 3.0.2. This happens even if I make a new world, or attack a special mob.
- Have you tried downgrading your Forge version to the lowest minimum version out of all your mods? (1208 might be a start.) For that matter, have you tried down/upgrading to the most recent "Recommended" Forge build, or the absolute most recent build? (1180 and 1224, as of this post, respectively)
- Do you have the same crash with that version of Forge and that version of Special Mobs, in a test world with no other mods installed? (or the absolute minimal amount of mods to make testing efficient, i.e. NEI)
- Have you tried a binary search to find an incompatible mod, to see if there's one in that honkin' huge list in particular?
i.e.
disable half of your mods (except for Special Mobs), run a new test world
if crash persists, disable half of the mods you kept in the last step and re-test with a new world
if crash stops, re-enable half of the mods you disabled in the last step and re-test with a new world
continue until you narrow it down to one mod that's incompatible with Special Mobs (when you add it the game crashes, when you remove it the game stops crashing), and report that incompatibility instead.
(This post was in the wrong thread (FatherToast's Mob Mods thread). I'm moving it here.)
This might have been a colossal waste of time, but at least it was educational...
I've written a JSON schema that validates MobProperties configuration files, as of 0.3.2. Plugged into something like a JSON editor that supports schemas, it could form the basis of a MobProperties configuration utility. (Unfortunately, that particular JSON editor, while it has the nicest interface I could find, kind of freaks out when you nest objects/arrays more than 12-15 levels deep, like the third example on the MobProperties wiki page does. I haven't found a JSON editor that handles oneOf-selected schemas and deep nesting...yet.)
This schema has some additional tags which made the formatting nicer under jdorn's JSON editor, but aren't strictly necessary for validation. They might be non-standard enough to break some extremely strict JSON schema verifiers, so if in doubt, maybe strip out all of the "propertyOrder" and "defaultProperties" fields.
I've done my best to use titles, enums and default values to fill in as much as possible, but you'll probably still need to refer to the MobProperties wiki when setting up the file, as well as use the "Properties" button to display any optional fields (such as "count") and to remove any extraneous properties left behind by changing a function type.
Also note that the conditional functions, while available through a dropdown, don't auto-fill the "function" field - they just set the regex for verifying what you (manually) set the function field to (since conditional function parameters, like dimension IDs and moon phases, are currently passed via the conditional function name itself instead of a "parameter" field). However, the regexes will verify the format of the embedded parameters in the function name (i.e. if_difficulty_hard, if_above_looting_2).
It might also be usable with a Java JSON validation library to validate/parse the config files rather than "manually" parsing via custom Java. But that might be overkill (it looks like most Java-based JSON schema validators are many times bigger than the MobProperties .jar itself!)
Maybe someone else can do something more constructive with this, or maybe not. Oh well, I learned JSON in the process, so no huge loss.
Also, if anybody might find them useful, here's a couple of rough MobProperties configs I've put together:
Named Villagers
Gives villages a surprising amount of personality for something so simple. Also makes it easier to re-find that one guy with the trade offer you want. Also in this file: An example of depacifying villagers by editing the NBT tags used by SpecialAI, rather than with the SpecialAI config file itself. Link.
More Zombie Tools
Gives zombies a few more (worn-out tools). Meant for use with SpecialAI's griefing, but unfortunately, SpecialAI seems to be ignoring "requires_tools=", possibly because everything in the default griefing list can be harvested empty-handed. So instead, maybe set "break_speed=0.2", so zombies will at least grief slower with the wrong tool (and reasonably well with the right tool). Link.
1) Look up the loot from ALL! hooks like Library, Stronghold, mod added loot to said hooks
2) Select randomly, if weapon or armor, add item damage at random or fixed figure
3) Apply a drop chance
Is this possible?
Not currently, and/or not entirely.
0) You could write a stats[{}] routine once to pick and equip an item, save it in a file in config/MobPropertiesExternal/stats, and refer to it from several mobs with the "external" function.
1a) The chest_loot function currently requires a specific ChestGenHooks key code (list with some obvious typos here) - it currently doesn't accept "all" as a key.
1b) The chest_loot function is for items in tags[{xxx}] arrays anyways, and is designed to produce NBT tag lists for filling chests and/or containers. What you want is something that generates an item ID that you can put into "stats"[{"function":"equip",xxx}], which chest_loot doesn't (currently) do.
2a) There are currently no conditional functions for "is_armor" or "is_weapon".
2b) There is currently no facility for executing conditional functions on an item generated by another function or already/recently equipped by a mob.
2c) The "equip" function requires a slot number (defaulting to 0=hand), and cannot currently equip to "the most appropriate slot given the id's weapon/armor type".
3) In theory, yes, totally possible with the current version - the "stats"[{"function":"equip","damage":NNN}] field does that. In practice... well, see below.
In summary, several distinct and fairly significant features would need to be added to MobProperties first before being able to implement this through MobProperties' JSON configs. (Not that some of those prerequisite features aren't in themselves good ideas - particularly 2)(c), that one would be very handy - they'd just take some doing, given the current form of the code.) It might almost be easier to write/commission a mod from scratch to implement that sort of almost-totally-arbitrary-any-mod-added-equipment-mob-equipping.
In the meantime, you could add all of the equipment you want to a "function":"choose"[] list - you'd have to add in all the mob-added equipment yourself though, but you'd be able to make sure the "slot":NNN fields are correct, and tweak the selection weights. I've posted an example of this here (under "More Zombie Tools").
Aaaaaand about point 3). (EDITED with corrected info) When writing the "More Zombie Tools" JSON, I found that I couldn't set damage values on equipment. It seems that when a mob drops equipment it was wearing/wielding, Minecraft sets its damage value automatically to a (supposedly) randomized (though it looks constant to me) amount. Dropped mob equipment (armor/weapons) will (apparently) always be pre-damaged when dropped, overriding any existing damage value. In order to have a mob drop equipment damaged to a particular amount, it needs to be added under drops[], not under stats[] - but that means the mob won't be wearing/wielding said equipment, as it'll only be spawned as the mob dies.
EDIT: ...unless the drop chance is greater than 1.0, in which case, Minecraft preserves the item's damage value (or lack thereof). (This is so that mobs that pick up equipment will drop them with the same damage value when they die - MC sets the drop chance on mob-picked-up items to 2, using the elevated drop chance as a crude "preserve damage value" flag.)
I think I've found a new trick with MobProperties. Thinking about FSMAcolyte's question, as well as a different question posted on the Toast Wiki, I realized that NBT tags could be used as "instance variables" for mobs - MobProperties functions can both write and read them. They could pass information between function groups, and even from pre_stats[] to stats[] to drops[] functions.
Basically, if you set a "useless" NBT tag in one function, you can check for that NBT tag somewhere else and react accordingly.
The example situation was one where a zombie would have a chance to become a "super powerful boss zombie of doom", which would only drop a wooden pickaxe when killed, without altering "regular" zombie drops. (This would of course be deliberate trolling of players - which I have no absolute objection to.) My solution was to set an NBT tag during the stats[] function that promoted a zombie to a boss zombie, then check for that tag during the drops[] list, overriding the drops if the boss zombie NBT tag was detected.
This could also be done by just having the boss zombie wield the pickaxe - but this way, the boss zombie could be wielding/wearing anything, and the drops can be absolutely controlled without affecting non-boss zombie drops.
My sample JSON code for this technique (implementing the example above) is here.
Other uses for this technique are possible, including within a "count":NNN loop to allow for the equivalent of an "if (condition) exit loop" function to be made. Not an "exit" in the strictest sense, of course, but you could set a tag within the "count":NNN functions to signal that the loop is to be terminated, then wrap all the "count"ed functions in a "!if_check_nbt_x" conditional, so that if the tag is set inside the loop, then all further iterations of the loop at least do nothing instead of continuing to execute.
MobProperties has conditionals, loops, and semi-persistent storage. It's not elegant, but it's actually Turing-complete. Now, if only there was a way for MobProperties to delete NBT tags, and/or check for non-numeric NBT tag values...
I'm getting this crash constantly, using a custom modpack for Minecraft 1.7.10 on Forge 1217. Running special mobs version 3.0.2. This happens even if I make a new world, or attack a special mob.
It looks like both MobProperties and SpecialMobs are able to fail with NullPointerExceptions when getEntityString() - a function that's supposed to return the string name of an entity - returns null. One or more of the mods in both of your games are probably adding mob types that don't have proper entity string names, and MobProperties and SpecialMobs are failing to handle "nameless" entities properly.
SpecialMobs.monsterKey() should be checking if key is null, and immediately return -1 if it is (as if the string wasn't found) before calling Arrays.binarySearch().
MobProperties.getProperties(String x) and MobProperties.getProperties(EntityLivingBase x) can both return null. MobProperties.jar/EventHandler.class should have an early-exit check between lines 38 and 39, so that mobProps.preInit() doesn't get called if mobProps is null.
It looks like both MobProperties and SpecialMobs are able to fail with NullPointerExceptions when getEntityString() - a function that's supposed to return the string name of an entity - returns null. One or more of the mods in both of your games are probably adding mob types that don't have proper entity string names, and MobProperties and SpecialMobs are failing to handle "nameless" entities properly.
SpecialMobs.monsterKey() should be checking if key is null, and immediately return -1 if it is (as if the string wasn't found) before calling Arrays.binarySearch().
MobProperties.getProperties(String x) and MobProperties.getProperties(EntityLivingBase x) can both return null. MobProperties.jar/EventHandler.class should have an early-exit check between lines 38 and 39, so that mobProps.preInit() doesn't get called if mobProps is null.
...and Lycanite's Mobs is installed in both cases. Looks like the source of the issue has been found.
Funny, I used to use Lycanite's Mobs as a temporary measure until Special Mobs was updated to 1.7.x, then removed it. Lycanite's just wasn't "Minecraft-y" enough for my tastes - it's still "good" though, just "not really my style".
Still, once this issue is resolved, one could probably do some nifty things by applying MobProperties to Lycanite's Mobs.
I think I've found why hungry spiders are becoming monstrously large - and how to fix it.
EntityHungrySpider.setFeedingLevel() adds to the render scale every time it is called, when the new feeding level is different from the current feeding level. It's also called when the spider's NBT data is being read from storage. The mob's render scale appears to be also saved and read already, though. So if a hungry spider has a non-zero feeding level, its feeding level gets added to its render scale every time the spider is read from NBT, i.e. whenever the chunk it's in is reloaded. Combined with the ability for hungry spiders to eat pretty much anything off the ground (including bones, arrows, and rotten flesh dropped by undead mobs killed by environmental causes) and odds are, hungry spiders will become massive if left alone long enough. (Which they do.)
There are a few possible options for fixing this:
EntityHungrySpider.readEntityFromNBT() should set feedingLevel directly, instead of calling setFeedingLevel(). (Least safe unless you add a redundant range check, but easiest.)
or, setFeedingLevel() should have a parameter flag to skip calling setRenderScale(), which should be used by readEntityFromNBT(). (Safer, a little more work.)
or, setFeedingLevel() should recalculate the render scale from scratch when set, instead of adding to getRenderScale() each time, i.e. getSpecialData().setRenderScale(0.8F + 0.1F * level) (Safest, but sacrifices random size variation - although the current setSize() call already ignores random variation)
Some other observations on the code:
EntityHungrySpider.setCurrentItemOrArmor() adds 4 to maxHealth every time it's called, without being capped by the feedingLevel < 7 condition or the "is food" check. I've seen larger hungry spiders with health in the 200-300+ range as a result (possibly from picking up stray drops over time). Is this by design, or should it be in the "if (this.feedingLevel < 7) {}" block?
EntityHungrySpider.setCurrentItemOrArmor() calls heal() if the item acquired is food, and calls it again with a value of 4 whether or not the item is food. Is "heal(4.0F)" supposed to be in the else-clause (for non-food healing) right after "this.stomach.add(itemStack)"?
Is there a particular reason why setCurrentItemOrArmor() is used, instead of onItemPickup()?
I think I've found why hungry spiders are becoming monstrously large - and how to fix it.
EntityHungrySpider.setFeedingLevel() adds to the render scale every time it is called, when the new feeding level is different from the current feeding level. It's also called when the spider's NBT data is being read from storage. The mob's render scale appears to be also saved and read already, though. So if a hungry spider has a non-zero feeding level, its feeding level gets added to its render scale every time the spider is read from NBT, i.e. whenever the chunk it's in is reloaded. Combined with the ability for hungry spiders to eat pretty much anything off the ground (including bones, arrows, and rotten flesh dropped by undead mobs killed by environmental causes) and odds are, hungry spiders will become massive if left alone long enough. (Which they do.)
There are a few possible options for fixing this:
EntityHungrySpider.readEntityFromNBT() should set feedingLevel directly, instead of calling setFeedingLevel(). (Least safe unless you add a redundant range check, but easiest.)
or, setFeedingLevel() should have a parameter flag to skip calling setRenderScale(), which should be used by readEntityFromNBT(). (Safer, a little more work.)
or, setFeedingLevel() should recalculate the render scale from scratch when set, instead of adding to getRenderScale() each time, i.e. getSpecialData().setRenderScale(0.8F + 0.1F * level) (Safest, but sacrifices random size variation - although the current setSize() call already ignores random variation)
Some other observations on the code:
EntityHungrySpider.setCurrentItemOrArmor() adds 4 to maxHealth every time it's called, without being capped by the feedingLevel < 7 condition or the "is food" check. I've seen larger hungry spiders with health in the 200-300+ range as a result (possibly from picking up stray drops over time). Is this by design, or should it be in the "if (this.feedingLevel < 7) {}" block?
EntityHungrySpider.setCurrentItemOrArmor() calls heal() if the item acquired is food, and calls it again with a value of 4 whether or not the item is food. Is "heal(4.0F)" supposed to be in the else-clause (for non-food healing) right after "this.stomach.add(itemStack)"?
Is there a particular reason why setCurrentItemOrArmor() is used, instead of onItemPickup()?
Woah, finally got a reply to work. HYPE!
Ah, hm. So, I just noticed SMScale saves as the current render scale, not the original like I thought. Well, there's the problem! Easy fix, the parameter flag thing will do it. Thank you very much! Also, thanks to all the people that provided info to lead up to that.
Right, I don't intend for them to have a max health limit. The constant heal(4.0F) is just to adjust for that maximum health increase. However, something I overlooked is modifiers that multiply the spider's health will skew the health gained per item eaten, so I have adjusted the code to add health equal to the difference between the new max health and the max health before adding 2 hearts to the base.
setCurrentItemOrArmor() is more general. However, if it is causing issues, I can change it.
Linus's Law: Given enough eyeballs, all bugs are shallow. (Or in this case, reasonably-sized. )
I'm not sure I quite understand how you're describing your new max-health formula, but if you're leaving it uncapped, maybe consider adding a little less health for eating specifically arrows, bones, and rotting flesh (items frequently found laying around a few minutes after the sun rises).
Using setCuttentItemOrArmor() isn't causing issues as far as I can see... I actually thought it would be more specific than onItemPickup(), not more general - I could easily be misunderstanding the intent of the interface method calls. The question was meant as less "why are you doing that because it's terrible", and more "why are you doing that because I want to understand how it works".
On a completely different subject, if anyone is using both Thaumcraft and SpecialMobs, I've posted a config file for ThaumcraftMobAspects which fixes/updates aspects for SpecialMobs. (The built-in defaults are currently both outdated and broken.)
That said, the villager names is a good start. Now I'd like to add the random names to mobs spawned from mods. Like Farlanders, Witchery, PrimitiveMobs.
But only the "villager" like mobs, i.e. the ones with trades. And how does a merged file look, i.e. ubertroll zombie and zombie. Need examples, examples, examples.<snip>
In the "Villager.json" file I posted, copy everything in the "stats": section (everything between the [square brackets], including the {curly braces}, and paste it into the corresponding "stats": section in whatever mob config file you want to add random names for.
The "ubertroll zombie" file I posted is merged with normal-zombie, in a sense. If you look closely at the file (which would be saved as "Zombie.json", it uses the "choose" function to apply a 0.5% chance of promoting a normal zombie to ubertroll. In the other 99.5% of cases, a zombie is left as it is.
If you already have some customizations added to your Zombie.json file, then "merging" the files would involve copying the {function blocks} from drops[] and stats[] from the ubertroll file, and pasting them into your existing Zombie.json drops[] and stats[] sections, separating the new {function blocks} from your existing {function blocks} with a comma.
FatherToast, I don't think you've gotten around to posting a version of MobProperties which handles null entity name strings without crashing yet, which I believe to be the source of FSMAcolyte's crashes.
Although, I did just install Lycanite's Mobs 1.10.2.5 and flew around in a test world for a while without having MobProperties crash on me, so either (1) Lycanite's Mobs is setting entity names properly now, or (2) there's still some leftover null-named entities in FSMAcolyte's game world, or (3) some other mod FSMAcolyte has installed is also not setting entity names.
FSMAcolyte, maybe try updating your version of Lycanite's Mobs (you appear to be running 1.10.2.4), make a creative-mode test world, and see if you still get that crash.
FatherToast, I don't think you've gotten around to posting a version of MobProperties which handles null entity name strings without crashing yet, which I believe to be the source of FSMAcolyte's crashes.
Although, I did just install Lycanite's Mobs 1.10.2.5 and flew around in a test world for a while without having MobProperties crash on me, so either (1) Lycanite's Mobs is setting entity names properly now, or (2) there's still some leftover null-named entities in FSMAcolyte's game world, or (3) some other mod FSMAcolyte has installed is also not setting entity names.
FSMAcolyte, maybe try updating your version of Lycanite's Mobs (you appear to be running 1.10.2.4), make a creative-mode test world, and see if you still get that crash.
Hm, I guess that must be it, then. If the entity string is null, it won't be able to find a property file for it, which I accidentally made cause a crash with the update. Regardless of whatever the problem really is that causes unregistered mobs to spawn, it won't crash in future updates... At least, not from my mods. It's almost definitely not Lycanite's Mobs, since my mods are commonly used with that without issue.
Not sure when I can get updates out, though. Low on time and high on computer problems. Hopefully, soon.
Get it on Github, if you aren't aversed to open sourcing that mod. I'm sure there's plenty of folks willing to help out with your awesome mods!
I'm not averse to open sourcing anything, apart from having people laugh at my terrible code.
I actually made a Github at some point to open source, I just never figured out how to use it and would probably be very bad at updating it for changes.
I'm not averse to open sourcing anything, apart from having people laugh at my terrible code.
I actually made a Github at some point to open source, I just never figured out how to use it and would probably be very bad at updating it for changes.
Have you seen my code/github? It would be hard do worse than I do on some of that. Took me some time to make github for windows work after breaking eclipse a few times trying to get built in git sync to work.
Github would certainly make it easier to keep track of what bugs have already been reported, even if you don't use it to post code. (re: fifty separate reports of giant spiders) But, you know, a computer that's not actively on fire is nice too.
Fixed it, thanks for the heads up.
Anybody?? This is a game-breaking bug, and I can't do much with it.
- Do you have the same crash with that version of Forge and that version of Special Mobs, in a test world with no other mods installed? (or the absolute minimal amount of mods to make testing efficient, i.e. NEI)
- Have you tried a binary search to find an incompatible mod, to see if there's one in that honkin' huge list in particular?
i.e.
This might have been a colossal waste of time, but at least it was educational...
I've written a JSON schema that validates MobProperties configuration files, as of 0.3.2. Plugged into something like a JSON editor that supports schemas, it could form the basis of a MobProperties configuration utility. (Unfortunately, that particular JSON editor, while it has the nicest interface I could find, kind of freaks out when you nest objects/arrays more than 12-15 levels deep, like the third example on the MobProperties wiki page does. I haven't found a JSON editor that handles oneOf-selected schemas and deep nesting...yet.)
This schema has some additional tags which made the formatting nicer under jdorn's JSON editor, but aren't strictly necessary for validation. They might be non-standard enough to break some extremely strict JSON schema verifiers, so if in doubt, maybe strip out all of the "propertyOrder" and "defaultProperties" fields.
I've done my best to use titles, enums and default values to fill in as much as possible, but you'll probably still need to refer to the MobProperties wiki when setting up the file, as well as use the "Properties" button to display any optional fields (such as "count") and to remove any extraneous properties left behind by changing a function type.
Also note that the conditional functions, while available through a dropdown, don't auto-fill the "function" field - they just set the regex for verifying what you (manually) set the function field to (since conditional function parameters, like dimension IDs and moon phases, are currently passed via the conditional function name itself instead of a "parameter" field). However, the regexes will verify the format of the embedded parameters in the function name (i.e. if_difficulty_hard, if_above_looting_2).
It might also be usable with a Java JSON validation library to validate/parse the config files rather than "manually" parsing via custom Java. But that might be overkill (it looks like most Java-based JSON schema validators are many times bigger than the MobProperties .jar itself!)
Maybe someone else can do something more constructive with this, or maybe not. Oh well, I learned JSON in the process, so no huge loss.
Also, if anybody might find them useful, here's a couple of rough MobProperties configs I've put together:
Named Villagers
Gives villages a surprising amount of personality for something so simple. Also makes it easier to re-find that one guy with the trade offer you want. Also in this file: An example of depacifying villagers by editing the NBT tags used by SpecialAI, rather than with the SpecialAI config file itself. Link.
More Zombie Tools
Gives zombies a few more (worn-out tools). Meant for use with SpecialAI's griefing, but unfortunately, SpecialAI seems to be ignoring "requires_tools=", possibly because everything in the default griefing list can be harvested empty-handed. So instead, maybe set "break_speed=0.2", so zombies will at least grief slower with the wrong tool (and reasonably well with the right tool). Link.
Not currently, and/or not entirely.
0) You could write a stats[{}] routine once to pick and equip an item, save it in a file in config/MobPropertiesExternal/stats, and refer to it from several mobs with the "external" function.
1a) The chest_loot function currently requires a specific ChestGenHooks key code (list with some obvious typos here) - it currently doesn't accept "all" as a key.
1b) The chest_loot function is for items in tags[{xxx}] arrays anyways, and is designed to produce NBT tag lists for filling chests and/or containers. What you want is something that generates an item ID that you can put into "stats"[{"function":"equip",xxx}], which chest_loot doesn't (currently) do.
2a) There are currently no conditional functions for "is_armor" or "is_weapon".
2b) There is currently no facility for executing conditional functions on an item generated by another function or already/recently equipped by a mob.
2c) The "equip" function requires a slot number (defaulting to 0=hand), and cannot currently equip to "the most appropriate slot given the id's weapon/armor type".
3) In theory, yes, totally possible with the current version - the "stats"[{"function":"equip","damage":NNN}] field does that. In practice... well, see below.
In summary, several distinct and fairly significant features would need to be added to MobProperties first before being able to implement this through MobProperties' JSON configs. (Not that some of those prerequisite features aren't in themselves good ideas - particularly 2)(c), that one would be very handy - they'd just take some doing, given the current form of the code.) It might almost be easier to write/commission a mod from scratch to implement that sort of almost-totally-arbitrary-any-mod-added-equipment-mob-equipping.
In the meantime, you could add all of the equipment you want to a "function":"choose"[] list - you'd have to add in all the mob-added equipment yourself though, but you'd be able to make sure the "slot":NNN fields are correct, and tweak the selection weights. I've posted an example of this here (under "More Zombie Tools").
Aaaaaand about point 3). (EDITED with corrected info) When writing the "More Zombie Tools" JSON, I found that I couldn't set damage values on equipment. It seems that when a mob drops equipment it was wearing/wielding, Minecraft sets its damage value automatically to a (supposedly) randomized (though it looks constant to me) amount. Dropped mob equipment (armor/weapons) will (apparently) always be pre-damaged when dropped, overriding any existing damage value. In order to have a mob drop equipment damaged to a particular amount, it needs to be added under drops[], not under stats[] - but that means the mob won't be wearing/wielding said equipment, as it'll only be spawned as the mob dies.
EDIT: ...unless the drop chance is greater than 1.0, in which case, Minecraft preserves the item's damage value (or lack thereof). (This is so that mobs that pick up equipment will drop them with the same damage value when they die - MC sets the drop chance on mob-picked-up items to 2, using the elevated drop chance as a crude "preserve damage value" flag.)
Basically, if you set a "useless" NBT tag in one function, you can check for that NBT tag somewhere else and react accordingly.
The example situation was one where a zombie would have a chance to become a "super powerful boss zombie of doom", which would only drop a wooden pickaxe when killed, without altering "regular" zombie drops. (This would of course be deliberate trolling of players - which I have no absolute objection to.) My solution was to set an NBT tag during the stats[] function that promoted a zombie to a boss zombie, then check for that tag during the drops[] list, overriding the drops if the boss zombie NBT tag was detected.
This could also be done by just having the boss zombie wield the pickaxe - but this way, the boss zombie could be wielding/wearing anything, and the drops can be absolutely controlled without affecting non-boss zombie drops.
My sample JSON code for this technique (implementing the example above) is here.
Other uses for this technique are possible, including within a "count":NNN loop to allow for the equivalent of an "if (condition) exit loop" function to be made. Not an "exit" in the strictest sense, of course, but you could set a tag within the "count":NNN functions to signal that the loop is to be terminated, then wrap all the "count"ed functions in a "!if_check_nbt_x" conditional, so that if the tag is set inside the loop, then all further iterations of the loop at least do nothing instead of continuing to execute.
MobProperties has conditionals, loops, and semi-persistent storage. It's not elegant, but it's actually Turing-complete. Now, if only there was a way for MobProperties to delete NBT tags, and/or check for non-numeric NBT tag values...
It looks like both MobProperties and SpecialMobs are able to fail with NullPointerExceptions when getEntityString() - a function that's supposed to return the string name of an entity - returns null. One or more of the mods in both of your games are probably adding mob types that don't have proper entity string names, and MobProperties and SpecialMobs are failing to handle "nameless" entities properly.
I found the issue, atleast for myself. Here: https://github.com/Lycanite/LycanitesMobs/issues/14
Funny, I used to use Lycanite's Mobs as a temporary measure until Special Mobs was updated to 1.7.x, then removed it. Lycanite's just wasn't "Minecraft-y" enough for my tastes - it's still "good" though, just "not really my style".
Still, once this issue is resolved, one could probably do some nifty things by applying MobProperties to Lycanite's Mobs.
EntityHungrySpider.setFeedingLevel() adds to the render scale every time it is called, when the new feeding level is different from the current feeding level. It's also called when the spider's NBT data is being read from storage. The mob's render scale appears to be also saved and read already, though. So if a hungry spider has a non-zero feeding level, its feeding level gets added to its render scale every time the spider is read from NBT, i.e. whenever the chunk it's in is reloaded. Combined with the ability for hungry spiders to eat pretty much anything off the ground (including bones, arrows, and rotten flesh dropped by undead mobs killed by environmental causes) and odds are, hungry spiders will become massive if left alone long enough. (Which they do.)
There are a few possible options for fixing this:
- EntityHungrySpider.readEntityFromNBT() should set feedingLevel directly, instead of calling setFeedingLevel(). (Least safe unless you add a redundant range check, but easiest.)
- or, setFeedingLevel() should have a parameter flag to skip calling setRenderScale(), which should be used by readEntityFromNBT(). (Safer, a little more work.)
- or, setFeedingLevel() should recalculate the render scale from scratch when set, instead of adding to getRenderScale() each time, i.e. getSpecialData().setRenderScale(0.8F + 0.1F * level) (Safest, but sacrifices random size variation - although the current setSize() call already ignores random variation)
Some other observations on the code:-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWoah, finally got a reply to work. HYPE!
Ah, hm. So, I just noticed SMScale saves as the current render scale, not the original like I thought. Well, there's the problem! Easy fix, the parameter flag thing will do it. Thank you very much! Also, thanks to all the people that provided info to lead up to that.
Right, I don't intend for them to have a max health limit. The constant heal(4.0F) is just to adjust for that maximum health increase. However, something I overlooked is modifiers that multiply the spider's health will skew the health gained per item eaten, so I have adjusted the code to add health equal to the difference between the new max health and the max health before adding 2 hearts to the base.
setCurrentItemOrArmor() is more general. However, if it is causing issues, I can change it.
I'm not sure I quite understand how you're describing your new max-health formula, but if you're leaving it uncapped, maybe consider adding a little less health for eating specifically arrows, bones, and rotting flesh (items frequently found laying around a few minutes after the sun rises).
Using setCuttentItemOrArmor() isn't causing issues as far as I can see... I actually thought it would be more specific than onItemPickup(), not more general - I could easily be misunderstanding the intent of the interface method calls. The question was meant as less "why are you doing that because it's terrible", and more "why are you doing that because I want to understand how it works".
On a completely different subject, if anyone is using both Thaumcraft and SpecialMobs, I've posted a config file for ThaumcraftMobAspects which fixes/updates aspects for SpecialMobs. (The built-in defaults are currently both outdated and broken.)
In the "Villager.json" file I posted, copy everything in the "stats": section (everything between the [square brackets], including the {curly braces}, and paste it into the corresponding "stats": section in whatever mob config file you want to add random names for.
The "ubertroll zombie" file I posted is merged with normal-zombie, in a sense. If you look closely at the file (which would be saved as "Zombie.json", it uses the "choose" function to apply a 0.5% chance of promoting a normal zombie to ubertroll. In the other 99.5% of cases, a zombie is left as it is.
If you already have some customizations added to your Zombie.json file, then "merging" the files would involve copying the {function blocks} from drops[] and stats[] from the ubertroll file, and pasting them into your existing Zombie.json drops[] and stats[] sections, separating the new {function blocks} from your existing {function blocks} with a comma.
Yes.
Other forms of modifying base health (additive, additive-multiply, etc.) are documented for MobProperties configs and for Minecraft attributes.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDo you have "auto_generate_files" enabled? That should prevent that kind of error for now, you can leave their files basically empty.
Although, I did just install Lycanite's Mobs 1.10.2.5 and flew around in a test world for a while without having MobProperties crash on me, so either (1) Lycanite's Mobs is setting entity names properly now, or (2) there's still some leftover null-named entities in FSMAcolyte's game world, or (3) some other mod FSMAcolyte has installed is also not setting entity names.
FSMAcolyte, maybe try updating your version of Lycanite's Mobs (you appear to be running 1.10.2.4), make a creative-mode test world, and see if you still get that crash.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHm, I guess that must be it, then. If the entity string is null, it won't be able to find a property file for it, which I accidentally made cause a crash with the update. Regardless of whatever the problem really is that causes unregistered mobs to spawn, it won't crash in future updates... At least, not from my mods. It's almost definitely not Lycanite's Mobs, since my mods are commonly used with that without issue.
Not sure when I can get updates out, though. Low on time and high on computer problems. Hopefully, soon.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm not averse to open sourcing anything, apart from having people laugh at my terrible code.
I actually made a Github at some point to open source, I just never figured out how to use it and would probably be very bad at updating it for changes.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHave you seen my code/github? It would be hard do worse than I do on some of that. Took me some time to make github for windows work after breaking eclipse a few times trying to get built in git sync to work.