For those of you who are getting "DIPotionEffects" packet leaks (and resultant lag) from this mod - I might have a solution.
Turns out, packets being sent weren't being disposed of after being processed by the client, so they were just building up in the packet queue endlessly. If you're using other mods which use potion effects for continuing buffs to mobs/players, this can result in very significant lag.
With some shamefully crude hackery (wirking from uncommented decompiled source), I've managed to build a version of DI 3.2.0 which fixes the problem, disposing of the packets as they get read by the client. I'll post it to this thread if/when I get permission from rich1051414 to do so.
See, I don't think it's something Vazkii could - or should - fix. Botania isn't "broken", and neither is Special Mobs - they're both working exactly as intended (finally!). They just have an unintended side effect when used together. Asking for mob shedding to be disabled would be pointless, as there's already a config option for Botania to disable shedding.
Altering the code for Hungry Spiders again might not even be necessary, as it would just add complexity to cover this particular edge case - an edge case that is easily fixed by editing the config. It's hardly the first time two mods from two different authors needed config tweaking in order to play nice together.
The best solution is probably to just remember this issue for the next time somebody posts about massive hungry spiders. (About three pages from now, I'd guess.) If there was a FAQ for Special Mobs, I'd say this should be added to it.
I think I found the other half of why Hungry Spiders used to get so huge, and why they're still currently getting ridiculous HP. And boy, do I feel foolish for not putting the pieces together earlier.
Botania (and maybe a couple of other mods, but particularly Botania) adds "natural shedding", which causes certain mobs to randomly drop related items while they're wandering around, so you can collect mob-related resources without needing to murder everything in sight. Chickens shed feathers, ghasts shed tears, skeletons shed bones, and spiders shed string.
Botania's handling of this appears to check both the mob's entity class and all entity classes a mob is derived from, so Hungry Spiders get the shedding of both SpecialMobs.HungrySpider (which is nothing by default) and vanilla Spiders (which is good). However, when a Hungry Spider sheds string, it almost immediately eats it, getting more HP and getting marked as no-despawn (also good - you wouldn't want it despawning with your UberArtifact in its belly). So it hangs around, continuing to shed and eat its own string, until you stumble across it with 500+ HP, exploding into a giant stack of string if you manage to kill it. (I actually checked the NBT data this time - the "Stomach" tag list I checked had over a hundred single stacks of string, and one dirt block, probably dropped by an Enderman.)
So basically, everything's working as intended, but there was an unforeseen interaction between what Botania and Special Mobs were doing.
For now, I've disabled spiders shedding string in my Botania config - hopefully, that will make Hungry Spiders less insane. At the risk of adding to "feature creep", I'd like to suggest that Hungry Spiders either not eat or gain no nourishment from spider-related drops (i.e. string, and maybe spider eyes). I'm not sure that's the best solution, but it's probably the second-easiest to implement. (The easiest, of course, being to disable Botania's shedding, for spiders or altogether.)
One possible solution might be to have Hungry Spiders not eat a dropped item if an identical item already exists in its Stomach list. This would make the eating code more complicated, but would allow them to eat anything (once) without allowing this sort of self-feeding behavour, and without needing to screen for specific items to not eat.
Very well done mod, fitting very well with Minecraft's theme. Except that perhaps the particle effects are almost...too magical.
One way to balance out the OPness of removing enchantments from damaged items might be to have the enchantment removal potentially fail, losing the enchantment altogether, if performed on a damaged item. For example, if a sword with 25% durability remaining with Sharpness I and Knockback II was disenchanted into a book, the resulting book would have a 25% chance of preserving Sharpness I, along with a 25% chance to keep each level of Knockback, checked separately (so in total, 37.5% Knockback I, 6.25% Knockback II, 56.25% Knockback lost completely). Of course, you'd have to hide the actual levels kept/lost until the player clicked the book to finalize the disenchantment. On average, if an item is X% damaged, you'd lose about X% of the enchantments.
One small issue: The XP cost of disenchanting items into books seems a little too affordable. Perhaps it's just because I'm playing with mods which add randomly enchanted low-tier equipment to mobs (with the occasional high-tier item), I'm practically swimming in enchanted books, which generally cost 2-4 levels to strip the enchantments off of any given mob drop, ready to slap onto diamond-or-better gear. Granted, I'm still losing the initial equipment, but when that equipment is wooden picks and gold helmets, the "cost" becomes irrelevant.
Would it be possible to add a config option to make the cost of disenchanting into a book into a given percent of the cost of enchanting a plain book in a regular enchantment table? For example, if "disenchant_cost_scale=0.3", if the resulting book would take 20 XP levels if done at an enchanting table, disenchanting it through the enchvil would cost 20*0.3=6 XP levels. It'd still be cheaper (and more predictable) than enchanting books from scratch, but would make stripping highly-enchanted items more costly.
- Your brackets simply don't match up. Using a text editor that can check JSON formatting would help you catch errors like that. (The forum's BBCode parser might have eaten those brackets, though.)
- Each of the "remove" functions needs to be in their own object block, i.e. surrounded by { curly braces } and separated by commas if there's more than one in the same array. (That applies to all functions, actually.)
why is there no config for editing the player properties, like the player gets poisoned when recently hit... that would be kinda cool
I'm not sure if players can be altered in the same way that mobs can be. In any case, implementing something like that would require MobProperties to change a mob's state during its lifespan when triggered by events other than spawning and death (e.g. when hit).
...which would be very cool, as that could be a starting point for building custom mob AI with JSON. However, that's way beyond the current scope of MobProperties.
So I ran into a 500+ HP Hungry Spider with Special Mobs 3.0.3. The fight was a little chaotic, but I think it dropped about two stacks of string, which more or less matches up with the hit points it had (20 HP + 4 HP per non-food-stack eaten). (The string might have been eaten out of my own inventory, though I didn't think I had that much on me at the time.) There was nothing that should have worked as a mob grinder nearby to feed it with drops, and it was in an area that I had been through a few times since upgrading from 3.0.2 (so it wasn't just a leftover broken-size spider). At least it wasn't sky-darkeningly huge - big-ish, but not titanic (like they used to get). Just with ridiculous HP.
Testing a little bit in a Creative world, I found that a Hungry Spider fed at least once will not despawn with distance or chunk unload (good), but sometimes still gets an extra 4 HP each time their chunk is unloaded-then-loaded (trouble). Trying to get this to happen reliably was maddening - sometimes it happened, sometimes it didn't, and I couldn't see a pattern. It happened reliably with some hungry spiders, then not at all with others fed the exact same objects.
I think there's at least two possibilities:
setCurrentItemOrArmor() might be getting called with an empty but non-null stack when the entity is being reloaded. Since the hungry spider code only checks if the stack is null, it might be able to "eat" an empty stack. Maybe check if itemStack.stackSize > 0.
setCurrentItemOrArmor() might be getting called repeatedly on the same item, if the item that was just eaten is getting left in slot 0. Maybe throw in a super.setCurrentItemOrArmor(0, null) at the very end of EntityHungrySpider.setCurrentItemOrArmor(), to ensure the spider can't keep chewing on the same piece of string***.
Those are just wild guesses, though. I don't know enough (yet) about exactly when Minecraft makes its own calls to setCurrentItemOrArmor(). More testing is needed.
*** How long is a piece of string? Seventeen characters, not counting delimiters.
I play Thaumcraft 4.2.1.4 together with Biome o plenty 1004 and Highlands 2.2.1 (Forge 1232). I dont see any Taint or magical Forest Biome. I change the Biome weight in the Thaumcraft config many times but nothing changing. Have somebody have the same problem ?
This was discussed a bit back on pages 6-7 of this thread. Short answer: Forge's biome handling was pretty broken a few versions ago (and may or may not still be - some of Forge's biome issues actually have been fixed since then), so Highlands has its own implementation of biome handling that (currently) only supports biomes (during world generation) from other mods that are explicitly coded for - and Thaumcraft's biomes are not explicitly coded for (yet). Maybe in a future version, but not now, not as of Highlands 2.2.2.
Post-world-generation, Thaumcraft's biomes are still available in a sense. Eerie biomes can generate, and if you can find a silverwood tree, you can make your own Magical Forest. However, no Mana Beans for you.
EDIT/postscript: As of Thaumcraft 4.2, Salis Mundus is made from Balanced Shards, instead of from Mana Beans. So the unavailability of Mana Beans just means you're missing out on the "convenience" of breeding your own aspect sources, instead of completely crippling the mid-to-end-game content of Thaumcraft, like it used to for 4.1.x. Tiny steps.
In that example, you should be able to add "count": 0.25,either just after "function": "all",or just after "function": "name",. Depends on whether you want to make the entire "all" block have a 25% chance of triggering, or just the "name" function.
EDIT: I should have realized that any function that sets an entity property or an NBT tag might not take "count".
Logic: It wouldn't make sense to set the "name" field more than once, at once.
Implication: You can't use "count" with "name" directly, even to set a fractional chance. "count" has to be used in an enclosing "all" block (unless "choose" is used to provide randomization instead).
The "simple" way is to use the "count" field inside the "add" function, which if you set to a fractional value, has a chance of being rounded up or down depending on whether the fractional part is closer to .0 or .99999. Simple, but really only gives you a choice between 0 and 1 feathers (or between N and N+1 feathers).
{ "_name": "Zombie",
"_comment": "Demo of one way of adding a 12% chance of dropping a feather",
"drops": [
{
"_comment": "12% chance of 1 feather",
"function": "add",
"id": "minecraft:feather",
"count": 0.12
}
],
"pre_stats": [],
"stats": [] }
The "flexible" way is to enclose the "add" function in an "all" function block with a "count" field. This way, you could have a 12% chance of dropping a feather, but then you could do things like vary the quantity of feathers dropped while keeping the same odds of dropping at least one feather, for example.
{ "_name": "Zombie",
"_comment": "Demo of another way of adding a 12% chance of dropping a feather",
"drops": [
{
"_comment": "12% chance",
"count": 0.12,
"function": "all",
"functions": [
{
"function": "add",
"id": "minecraft:feather",
"_comment": "1 feather",
"count": 1
}
]
}
],
"pre_stats": [],
"stats": [] }
IMHO, this deserves a link in the OP. Nicely done, Morus!
One small quibble - Could you possibly make the dropdown list to select the chest category a bit wider? DeadlyWorld adds a number of chest categories qualified by the mod name (i.e. "DeadlyWorld.chestRogueTie?????"), which are too long to fit in the current dropdown list control and are hard to tell apart as a result.
Tiny issue with SpecialMobs 3.0.3: The default value for pigzombies to spawn hostile has been increased to 5%, but the corresponding comment in the config still says that the default value is 1%.
Looking forward to safely re-enabling hungry spiders. Bugfixes ftWOOT!
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.
1
Turns out, packets being sent weren't being disposed of after being processed by the client, so they were just building up in the packet queue endlessly. If you're using other mods which use potion effects for continuing buffs to mobs/players, this can result in very significant lag.
With some shamefully crude hackery (wirking from uncommented decompiled source), I've managed to build a version of DI 3.2.0 which fixes the problem, disposing of the packets as they get read by the client. I'll post it to this thread if/when I get permission from rich1051414 to do so.
0
Just to confirm my observations - are you using Botania, or another mod that adds items dropping from still-living mobs?
0
Altering the code for Hungry Spiders again might not even be necessary, as it would just add complexity to cover this particular edge case - an edge case that is easily fixed by editing the config. It's hardly the first time two mods from two different authors needed config tweaking in order to play nice together.
The best solution is probably to just remember this issue for the next time somebody posts about massive hungry spiders. (About three pages from now, I'd guess.) If there was a FAQ for Special Mobs, I'd say this should be added to it.
1
Botania (and maybe a couple of other mods, but particularly Botania) adds "natural shedding", which causes certain mobs to randomly drop related items while they're wandering around, so you can collect mob-related resources without needing to murder everything in sight. Chickens shed feathers, ghasts shed tears, skeletons shed bones, and spiders shed string.
Botania's handling of this appears to check both the mob's entity class and all entity classes a mob is derived from, so Hungry Spiders get the shedding of both SpecialMobs.HungrySpider (which is nothing by default) and vanilla Spiders (which is good). However, when a Hungry Spider sheds string, it almost immediately eats it, getting more HP and getting marked as no-despawn (also good - you wouldn't want it despawning with your UberArtifact in its belly). So it hangs around, continuing to shed and eat its own string, until you stumble across it with 500+ HP, exploding into a giant stack of string if you manage to kill it. (I actually checked the NBT data this time - the "Stomach" tag list I checked had over a hundred single stacks of string, and one dirt block, probably dropped by an Enderman.)
So basically, everything's working as intended, but there was an unforeseen interaction between what Botania and Special Mobs were doing.
For now, I've disabled spiders shedding string in my Botania config - hopefully, that will make Hungry Spiders less insane. At the risk of adding to "feature creep", I'd like to suggest that Hungry Spiders either not eat or gain no nourishment from spider-related drops (i.e. string, and maybe spider eyes). I'm not sure that's the best solution, but it's probably the second-easiest to implement. (The easiest, of course, being to disable Botania's shedding, for spiders or altogether.)
One possible solution might be to have Hungry Spiders not eat a dropped item if an identical item already exists in its Stomach list. This would make the eating code more complicated, but would allow them to eat anything (once) without allowing this sort of self-feeding behavour, and without needing to screen for specific items to not eat.
0
If I get another one, I'll have to see what happens if I throw something else in...
If there's no altered result from that...well, maybe there should be.
0
One way to balance out the OPness of removing enchantments from damaged items might be to have the enchantment removal potentially fail, losing the enchantment altogether, if performed on a damaged item. For example, if a sword with 25% durability remaining with Sharpness I and Knockback II was disenchanted into a book, the resulting book would have a 25% chance of preserving Sharpness I, along with a 25% chance to keep each level of Knockback, checked separately (so in total, 37.5% Knockback I, 6.25% Knockback II, 56.25% Knockback lost completely). Of course, you'd have to hide the actual levels kept/lost until the player clicked the book to finalize the disenchantment. On average, if an item is X% damaged, you'd lose about X% of the enchantments.
One small issue: The XP cost of disenchanting items into books seems a little too affordable. Perhaps it's just because I'm playing with mods which add randomly enchanted low-tier equipment to mobs (with the occasional high-tier item), I'm practically swimming in enchanted books, which generally cost 2-4 levels to strip the enchantments off of any given mob drop, ready to slap onto diamond-or-better gear. Granted, I'm still losing the initial equipment, but when that equipment is wooden picks and gold helmets, the "cost" becomes irrelevant.
Would it be possible to add a config option to make the cost of disenchanting into a book into a given percent of the cost of enchanting a plain book in a regular enchantment table? For example, if "disenchant_cost_scale=0.3", if the resulting book would take 20 XP levels if done at an enchanting table, disenchanting it through the enchvil would cost 20*0.3=6 XP levels. It'd still be cheaper (and more predictable) than enchanting books from scratch, but would make stripping highly-enchanted items more costly.
1
- Each of the "remove" functions needs to be in their own object block, i.e. surrounded by { curly braces } and separated by commas if there's more than one in the same array. (That applies to all functions, actually.)
Try this:
{ "_name": "Zombie", "drops": [ { "function":"remove", "id":"minecraft:carrot" }, { "function":"remove", "id":"minecraft:potato" } ], "pre_stats": [], "stats": [] }I'm not sure if players can be altered in the same way that mobs can be. In any case, implementing something like that would require MobProperties to change a mob's state during its lifespan when triggered by events other than spawning and death (e.g. when hit).
...which would be very cool, as that could be a starting point for building custom mob AI with JSON. However, that's way beyond the current scope of MobProperties.
2
Testing a little bit in a Creative world, I found that a Hungry Spider fed at least once will not despawn with distance or chunk unload (good), but sometimes still gets an extra 4 HP each time their chunk is unloaded-then-loaded (trouble). Trying to get this to happen reliably was maddening - sometimes it happened, sometimes it didn't, and I couldn't see a pattern. It happened reliably with some hungry spiders, then not at all with others fed the exact same objects.
I think there's at least two possibilities:
- setCurrentItemOrArmor() might be getting called with an empty but non-null stack when the entity is being reloaded. Since the hungry spider code only checks if the stack is null, it might be able to "eat" an empty stack. Maybe check if itemStack.stackSize > 0.
- setCurrentItemOrArmor() might be getting called repeatedly on the same item, if the item that was just eaten is getting left in slot 0. Maybe throw in a super.setCurrentItemOrArmor(0, null) at the very end of EntityHungrySpider.setCurrentItemOrArmor(), to ensure the spider can't keep chewing on the same piece of string***.
Those are just wild guesses, though. I don't know enough (yet) about exactly when Minecraft makes its own calls to setCurrentItemOrArmor(). More testing is needed.*** How long is a piece of string? Seventeen characters, not counting delimiters.
0
0
This was discussed a bit back on pages 6-7 of this thread. Short answer: Forge's biome handling was pretty broken a few versions ago (and may or may not still be - some of Forge's biome issues actually have been fixed since then), so Highlands has its own implementation of biome handling that (currently) only supports biomes (during world generation) from other mods that are explicitly coded for - and Thaumcraft's biomes are not explicitly coded for (yet). Maybe in a future version, but not now, not as of Highlands 2.2.2.
Post-world-generation, Thaumcraft's biomes are still available in a sense. Eerie biomes can generate, and if you can find a silverwood tree, you can make your own Magical Forest. However, no Mana Beans for you.
EDIT/postscript: As of Thaumcraft 4.2, Salis Mundus is made from Balanced Shards, instead of from Mana Beans. So the unavailability of Mana Beans just means you're missing out on the "convenience" of breeding your own aspect sources, instead of completely crippling the mid-to-end-game content of Thaumcraft, like it used to for 4.1.x. Tiny steps.
1
eitherjust after "function": "all",or just after "function": "name",. Depends on whether you want to make the entire "all" block have a 25% chance of triggering, or just the "name" function.EDIT: I should have realized that any function that sets an entity property or an NBT tag might not take "count".
Logic: It wouldn't make sense to set the "name" field more than once, at once.
Implication: You can't use "count" with "name" directly, even to set a fractional chance. "count" has to be used in an enclosing "all" block (unless "choose" is used to provide randomization instead).
2
The "simple" way is to use the "count" field inside the "add" function, which if you set to a fractional value, has a chance of being rounded up or down depending on whether the fractional part is closer to .0 or .99999. Simple, but really only gives you a choice between 0 and 1 feathers (or between N and N+1 feathers).
{ "_name": "Zombie", "_comment": "Demo of one way of adding a 12% chance of dropping a feather", "drops": [ { "_comment": "12% chance of 1 feather", "function": "add", "id": "minecraft:feather", "count": 0.12 } ], "pre_stats": [], "stats": [] }The "flexible" way is to enclose the "add" function in an "all" function block with a "count" field. This way, you could have a 12% chance of dropping a feather, but then you could do things like vary the quantity of feathers dropped while keeping the same odds of dropping at least one feather, for example.{ "_name": "Zombie", "_comment": "Demo of another way of adding a 12% chance of dropping a feather", "drops": [ { "_comment": "12% chance", "count": 0.12, "function": "all", "functions": [ { "function": "add", "id": "minecraft:feather", "_comment": "1 feather", "count": 1 } ] } ], "pre_stats": [], "stats": [] }1
One small quibble - Could you possibly make the dropdown list to select the chest category a bit wider? DeadlyWorld adds a number of chest categories qualified by the mod name (i.e. "DeadlyWorld.chestRogueTie?????"), which are too long to fit in the current dropdown list control and are hard to tell apart as a result.Edit: Perfect, thanks!
1
Looking forward to safely re-enabling hungry spiders. Bugfixes ftWOOT!
1