Print

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

[kane_t]

Yeah, already got the history event bit in there since I wanted to make sure they were recorded right in legends mode.

I still can't figure out why the first one you make in a world ends up turning into a slab-duplicate that crashes unless removed.

If the code on your github repo is up-to-date, it's probably because of the way you try to find and initialise the artifact record.  You go through df.global.world.artifacts.all looking for an id of 0, which will be the first artifact created during world generation, which is probably a slab containing the secrets of life and death.  Then, for some reason, you change its item pointer to point to a newly-heap-allocated item (which I think you make as a copy of the item you already made earlier? I'm not totally sure how the Lua API does that table-initialisation thing) that isn't in the items list.  You never get around to inserting it into the items list, so you've got an artifact record pointing to an object that's out in the void, that the game otherwise doesn't know about.  Since it isn't in the items list, it won't get serialised out when you save the game.  The original artifact with id 0 will get serialised out to the save file, though, except its general_ref_is_artifactst will be pointing to an artifact record that doesn't point to it, and instead points to a non-existant item.
EDIT: Also, I totally forgot the part that causes it to only happen once: you set the id of artifacts.all[0] to global.artifact_next_id, so when you next try to create a new item it'll skip over it.  But, from what I can tell, it should just go through the whole loop and do nothing, because it shouldn't ever find an artifact with an ID of 0 (unless {new=df.artifact_record} initialises the id to 0, instead of -1 like df.artifact_record:new() does).

You should ditch that whole loop.  If you insert a new artifact record with '#' as the index, you don't need to find it, it'll always be at the end of the vector (so, df.global.world.artifacts.all[#df.global.world.artifacts.all - 1] or df.global.world.artifacts.all[df.global.artifact_next_id]).  No need to find it with a loop looking for an unintialised ID (which would be -1, not 0, as you're doing there; not expected, I know, but it's how dfhack initialises objects).  And, set the artifact record's item field to base, which is the item you already created with createItem(), then set it up from there, don't try to create another new object.

Also, you weirdly call new() on the artifact record and history events records, which shouldn't even work in a sane language, but in Lua probably means that a pair of vectors get heap allocated and then immediately discarded.  That probably wouldn't cause a crash on its own, just a tiny memory leak, but you should remove the "df.global.world.artifacts.all:new()" and "df.global.world.history.events:new()" lines just to be a good citizen, anyway.

[Max™]

I will look at that when I'm woken up more and fix it, thanks! Though, I thought I did the ' # ' index trick.

[Roses]

Does creating items with a the create-item script function the same as a reaction? That is to say, can I mimic the "make rock crafts" reaction or other hard coded reactions?

[Putnam]

It uses the reaction code to create items but I'm pretty sure hard coded reactions aren't actually reactions.

[kane_t]

Does creating items with a the create-item script function the same as a reaction? That is to say, can I mimic the "make rock crafts" reaction or other hard coded reactions?

I'm not 100% sure if it does or not, but I can say that it produces some unnatural results.  For example, naturally mined boulders have their heat properties set correctly for their material types, but if you create a boulder with createitem BOULDER NATIVE_GOLD, for instance, all its heat properties will be set to 0 or -1.

It doesn't seem to have any gameplay effect, though.  Presumably, DF actually gets the material properties from the base material data in df.global.world.raws, and the material properties in the item struct are just there either for legacy reasons or for when the game can't find a mat_type/mat_index match.

[Meph]

Quick question: There seems to be a new dfhack plugin that shows information in material/item descriptions. How do I add, remove or alter those?

I noticed that when I looked at "dog leather", which gave me some random information about animal leathers in DF.

The issue for me is that I also looked at "dragon scales" and "antman chitinplate", which are actually good materials in the game, and I get the same description about "leathers are not terribly good in DF".

I assume its not related to material, but rather an item description for TANNED_SKIN ?

[Warmist]

Quick question: There seems to be a new dfhack plugin that shows information in material/item descriptions. How do I add, remove or alter those?

I noticed that when I looked at "dog leather", which gave me some random information about animal leathers in DF.

The issue for me is that I also looked at "dragon scales" and "antman chitinplate", which are actually good materials in the game, and I get the same description about "leathers are not terribly good in DF".

I assume its not related to material, but rather an item description for TANNED_SKIN ?

The info is in item-descriptions.lua and view-item-info.lua. And yes it does look into item type only.

[PeridexisErrant]

Quick question: There seems to be a new dfhack plugin that shows information in material/item descriptions. How do I add, remove or alter those?

I noticed that when I looked at "dog leather", which gave me some random information about animal leathers in DF.

The issue for me is that I also looked at "dragon scales" and "antman chitinplate", which are actually good materials in the game, and I get the same description about "leathers are not terribly good in DF".

I assume its not related to material, but rather an item description for TANNED_SKIN ?

This is view-item-info.lua, which I designed with mod-ability in mind.

It takes item descriptions from hack/scripts/item-descriptions.lua, based on the item type (or subtype, for items with subtypes).  You can supplement this with a script in the same format in the raw folder, called raw/scripts/more-item-descriptions.lua - entries in this file take priority.  If you put a modified copy of item-descriptions.lua in the raw folder, view-item-info will not fall back to the vanilla descriptions.

Hope that helps and makes sense!

If you want to add material descriptions -- beyond the property listing that already happens -- it shouldn't be too hard to add a system similar to item descriptions.

[Meph]

Thanks Warmist and Peridexis

Seems like Toady didnt add the item-descriptions (like he has done for tools), but the community did.

[kane_t]

I'm curious: when you use tiletypes to change a construction to natural stone, what happens to the block or boulder that was used to build it?  Blocks used in constructions still appear in the stocks screen, and the count doesn't seem to decrease when you use tiletypes to replace them with natural stone, so is that object just getting orphaned and sitting in the items list forever?

[Rose]

Yes.

[Warmist]

I'm curious: when you use tiletypes to change a construction to natural stone, what happens to the block or boulder that was used to build it?  Blocks used in constructions still appear in the stocks screen, and the count doesn't seem to decrease when you use tiletypes to replace them with natural stone, so is that object just getting orphaned and sitting in the items list forever?

If you are curious about constructions in general i had a stab at making moving walls so there is relevant code here and there was a tweak that compacted walls by deleting their items and setting them to non-item based walls here

Also by just changing tiletype you leave an orphaned construction which probably is also a Bad thing (tm)

[kane_t]

Ah, shame.  I wonder how hard it would be to update tiletypes to just remove the orphaned constructions and blocks if it's turning a construction into not-a-construction.  I mean, would it be that easy?

[Warmist]

Ah, shame.  I wonder how hard it would be to update tiletypes to just remove the orphaned constructions and blocks if it's turning a construction into not-a-construction.  I mean, would it be that easy?

Tile type manipulation is full of stuff like this. E.g. if it's part of vein you need to find the vein entry and remove the tile from it's mask. Also tree and shrubs have special logic and so on...

Making sure that each one work correctly would take someone ages (and it would probably break a lot) but anyone who wants to do that is welcome

[kane_t]

Ah, shame.  I wonder how hard it would be to update tiletypes to just remove the orphaned constructions and blocks if it's turning a construction into not-a-construction.  I mean, would it be that easy?

Tile type manipulation is full of stuff like this. E.g. if it's part of vein you need to find the vein entry and remove the tile from it's mask. Also tree and shrubs have special logic and so on...

Making sure that each one work correctly would take someone ages (and it would probably break a lot) but anyone who wants to do that is welcome

Haha, fair enough.  Thanks for cleanconst, BTW, that actually does help a lot.

I actually might write a quick little script, just for myself, to clean up orphaned constructions from my tiletypes usage.  Shouldn't be too hard to iterate the list of constructions and remove the ones that are located at tiles that aren't constructions anymore.  I take it, from skimming the code on github, that the tiletypes enum isn't laid out in a sane way where I can just use a mask to figure out which ones are constructions and which ones aren't.  Unless I want to write a full plugin that can use df::enum_attrs, I'll have to just make a list of all the tile types that are constructions, right?