Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ag]

I include the add-spatter.plug.dll since V.2c and use it for the Toxicologist's Laboratory, the Rune Weaponry and the Rune Armory. The mod is now on V.3f, which is ~10 updates. I never had any crashes with add-spatter, and I did not change any raws that use this plugin. I did add more reactions for Kobold Mode, but those are not active when playing as dwarves, and the crashes happen in Dwarf Mode.

Found a buffer overrun bug caused by ADD_SPATTER reactions which have any non-improvement outputs. Until this is fixed in the dll itself, you can work around by avoiding such things. The crash happens when enumerating reactions on world load, so active/inactive is irrelevant.

[Meph]

So any reaction that has SPATTER_ADD in its ID that has no [IMPROVEMENT:800:object:COVERED:GET_MATERIAL_FROM_REAGENT:extract:NONE] does cause this crash?

Is [REACTION:KOBOLD_SPATTER_ADD_BOLTS_SHADOW] ok as ID? I just realized that I made new versions for the kobolds and changed that name, but the readme states "Reaction name must start with 'SPATTER_ADD_':".  I have 253 reactions that start with SPATTER_ADD, but another 21 have this KOBOLD_SPATTER_ADD.

AHA: I also found some Orc Reaction with the same problem. REACTION:RUNES_ADD_WEAPON_MITHRIL_ORC. 6 reactions.

[ag]

When I debugged it, it crashed on SPATTER_ADD_WEAPON_BITTER because of the KNOWLEDGE_STONE non-improvement products.

The bug is a simple error in loop bounds. If the reaction has only IMPROVEMENT outputs, there is no difference:

http://github.com/angavrilov/dfhack/commit/70a2ab91417281a39df2d26ab2ca2d654e4b58ff

[Meph]

Ah... I understand. The reaction might only create improvements, nothing else.

That actually causes a balancing problem ingame. Since improvements are not new items and give no XP, the PoisonWorker skill and the Runesmith skill gain no XP from applying runes or poisons. The Knowledge Stone is a boiling inorganic that I just add to have a XP gain with the reaction. If I remove it, the skills will never rise.

But THANK YOU !!!! YEAH One crash fixed.

EDIT: For ag: Falconne thought you might be able to find something about this one too. Its a crash that happened with the tweak plugin. Falconnes self-build tweak plugin fixes it, but he does not know why. I plan to use his version for the next release, but he thinks you might be able to see the actual reason why it crashed.

The report about the crash can be found here. If you need more info, please leave falconne a message, he knows more about it then I do.

I cant state how much I appreciate this help. I was completely lost looking at my mod, thinking: Mh. Might have to redo ~200 hours of work.

[ag]

The report about the crash can be found here. If you need more info, please leave falconne a message, he knows more about it then I do.

That save crashes because there are hives with uncollected products, but no bees. It confuses the hive code and makes it access an uninitialized pointer. For me the crash happens even with no dfhack loaded at all. The question therefore is how the hives got into this state.

One clue here might be the fact that the bee items in two of the other hives have a huge amount of wear on them, but I have no idea what it might signify. When I tried to put data breakpoints on the wear counters, they didn't trigger, so at least in my setup there seems to be no ongoing wear.

To fix the save you need to fake-collect products in the two hives with products but no bees. To do that, find the hives, select each of the uncollected products (with blue B next to them) in 't' mode and execute in the console:

Code: [Select]

[DFHack]# :lua dfhack.gui.getSelectedItem().flags.in_building = false
This should remove the blue B, and thus avoid the subsequent crash.

[Meph]

Are you a wizard?

How in hell can you know this stuff, modders have such a hard time finding a crash, and you are like: Yep, thats because of A and it will do B to the code, you can do C to fix it. Is it hard for you to find this info? Because my line of thought at this moment is: Oh, there is someone that can identify and fix crashes. Lets flood him will all the reports and all the saves and do a housecleaning of the mod. Of course that makes no sense if it's too much work for you... I'd like to help, but I dont even know how you know what you know.

Btw, falconnes tweak-plugin also fixes that crash, so I'll include it as well in the next release, if I can get my hands on it.

EDIT: Silly question coming up: Would [PRODUCT:0:1:BOULDER:NONE:INORGANIC:ANNOUNCEMENT_RUNEAMMO] crash a add-spatter reaction? It is a product in the reaction, but there is no actual product created. I assume that it would still crash. I only ask because I use this to trigger custom announcements, like "A stack of ammo has been inscribed with a rune."

[ag]

Well, determining that it was something to do with hives was about 15 min I guess; understanding how the hives work (including some new fields for data structures) and what's wrong with them - about 2 hours I'd say.

Anything that's not IMPROVEMENT will make it crash - the problem is that the plugin makes a list of only improvement products, and then indexes it with the number of all outputs.

[Meph]

Oh, wow, then thank you even more. I already made a set of raws without any products for the spatter_add reactions and rebalanced some mod features to fit. The hive-bug is probably neglectable, because falconnes tweak-plugin fixes it. I'll add it to the dfhack-init and have it run on every loadup. So if someone does have this weird crash, simply restarting DF should fix it.

Why a hive-product, which are usually tools, can degrade.. no idea. I added several modded hive-animals (cochineal, banespiders, silkmoths), but they still use tools with an inorganic mat.

I think I'll just release the crash-fixes I have now and see if any other issues pop up. Might be that its only these two things, who knows.

[ag]

Oh, wow, then thank you even more. I already made a set of raws without any products for the spatter_add reactions and rebalanced some mod features to fit. The hive-bug is probably neglectable, because falconnes tweak-plugin fixes it. I'll add it to the dfhack-init and have it run on every loadup. So if someone does have this weird crash, simply restarting DF should fix it.

Why a hive-product, which are usually tools, can degrade.. no idea. I added several modded hive-animals (cochineal, banespiders, silkmoths), but they still use tools with an inorganic mat.

Well, since I made most of the stuff in tweak, I had to make sure it isn't some bug messing up something so that an unrelated thing crashes later About the falconne tweak, what are the changes in it? Since the crash is caused by using an uninitialized value, the effect depends on what random value was in that address before, and thus completely unrelated things can seem to affect it.

It's not tools that are worn in those hives, it's the bees themselves, i.e. the actual vermin item listed under small live animals or something in stocks. I can't think of anything that could cause that really, other than maybe some temperature damage from too cold or hot, or maybe some actual bug. The original owner of that save may be in a better position to guess.

[Meph]

If a vermin is inside a workshop, nothing can affect it. Just like liquids. At least thats my understanding. I honestly dont know what might have caused this peculiar crash.

I also cant say anything about falconnes tweak plugin, since I only got a compiled .dll. I will let you know after I talked to him, or you write him. Would probably be better, because I dont know C++ so my information would just be copy+paste of whatever he will tell me.

Anyway, thanks for the spatter-add fix, and maybe, just maybe, I will come back to you with another crashed save, if any reproducable crashes will be reported with my next mod update. Curious to see if you can epically pinpoint those as well, if you find the time.

[Mr S]

No, no, no.  The mis-behaving honey bee hives were a result of Mallophora fautrix infestation.  They must have this predatory insect in the raws.

Bug Spray.

Regen.

It's the only solution.

[falconne]

The hive-bug is probably neglectable, because falconnes tweak-plugin fixes it.

No, based on what ag found, it's actually a coincidence that the crash didn't happen when I tried it in my build environment. If there's an uninitialised pointer, the data it contains will be random... when I used my build it just so happened that the random data made the crash not occur. But that's very situational... on a different day you will see different results.

So using the tweak plugin from my build won't help, as it has nothing to do with the plugin, so just ignore it. If the hives get to that state often then you'll have to figure out why that's happening. Maybe the original player did something unusual?

It might be worth figuring out a Lua script that can detect this hive state. Then you can run it on future bugged saves you get sent, to see if this is a one off occurrence or not.

[Kougarkat]

Might well also be related to the spatter-add bug.  Buffer overflows can cause some weird memory corruption. And then that state is what crashes later.

[Meph]

So I'd need a script that runs in the background, monitors if this state happens in any hive, then runs: [DFHack]# :lua dfhack.gui.getSelectedItem().flags.in_building = false automatically, while knowing in which hive it should target. Yeah... that sounds totally like something I can write; he said sarcastically. ^^

What happens if the hive is simply deconstructed? So someone has a crash, reports it, and I say: Load the save, raze your hives. Would that help?

I also have no idea if this is some sort of freak occurence, or a problem with any of the new hive-creatures that are in the mod. I'd let it go for now, and wait and see. I wouldnt want several people trying to fix something that might not happen again.

[Putnam]

Code: [Select]

function buildingIsHive(building)
if not string.find(tostring(building),"hivest") then return false else return true end
end

function itemIsHive(item)
for k,v in ipairs(item.subtype.tool_use) do
if v==12 then return true end
end
return false
end

function buildingHasProductButNoBees(building)
local buildingHasProduct = false
local buildingHasNoBees = true
for k,v in ipairs(building.contained_items) do
if string.find(v.item,"verminst") then return false end
if string.find(v.item,"toolst") and not itemIsHive(v.item) then buildingHasProduct = true end
end
if buildingHasProduct then return true else return false end --already checked if bees; if bees, then false anyway.
end

function getShortestHiveProductTime()
local shortestHiveProductTime = 2^128 --get a larger number than that for your time, eh?
for _,creature in ipairs(df.global.world.raws.creatures.all) do
for k,length in ipairs(creature.hive_product_1) do
shortestHiveProductTime=(length<shortestHiveProductTime) and length or shortestHiveProductTime --neat but incomprehensible lua trick
end
end
return shortestHiveProductTime
end

function checkForBuggyHives()
for k,building in ipairs(df.global.world.buildings.all) do
if buildingIsHive(building) and buildingHasProductButNoBees(building) then
for _,v in building.contained_items do
local item = v.item
if string.find(v.item,"toolst") and itemIsHive(v.item) then item.flags.in_building=false end
end
end
end
end

function fixHiveCrashRepeater()
checkForBuggyHives()
dfhack.timeout(shortestHiveProductTime-1,'ticks',fixHiveCrashRepeater) --if someone makes a hive that goes every 1 tick i would be so mad
end

dfhack.onStateChange.fixHiveCrash = function(code) --Many thanks to Warmist for pointing this out to me!
    shortestHiveProductTime=getShortestHiveProductTime()
if code==SC_WORLD_LOADED then
dfhack.timeout(1,'ticks',fixHiveCrashRepeater)
end
end

dfhack.onStateChange.fixHiveCrash()
Here's your fix, I think.