Print

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

[PeridexisErrant]

For anyone interested:  I'm working on a pull request to clean up the documentation, and generally make it possible to check whether something is actually documented as it should be.

This is obviously a work in progress, but I'd love any feedback you have at the pull or here.

[lethosor]

Dirst: I think that would require run-time type information, which Toady does not have enabled.

Yeah, that's exactly what I wanted.  Can't have everything I suppose.

Thanks for the help guys!

Don't know why expwnent said that, since game types are known to us. You can use df.is_instance(df.building_workshopst,your_building).
(your_building._type == df.building_workshopst) will work too in your case, but is_instance handles subclasses as well.

Yeah, that's what I was referring to with

Try object._type

(This uses dfhack-implemented structure identities, which are similar to vtables for identification purposes, so RTTI isn't required.)

[Dirst]

I'm grateful this community is so full of helpful code wizards!

I knew there was a right way to do the check.

[Max™]

Gotcha. I am confident I know what all of the bp_modifier values do, as well as the values for tissue styles. I'll try to figure out how to add these values correctly...the XML structure is very confusing to me. I'm completely unfamiliar with C++ and Lisp, and I just dived into Lua for this project.

Man, it's all pretty raw in there still huh.

Code: [Select]

<stl-vector name='bp_modifiers' type-name='int32_t'
                        index-refers-to='$$._global.caste.ref-target.bp_appearance.modifier_idx[$].refers-to'/>If I'm not mistaken that can have the relevant type-name replaced with a list pulled from somewhere, hmmm, we need to take into account other species though.

The parts names are the relevant body parts and layers right? Bah, that's frustrating sounding right off the bat, because we can't just have it be skull_height, skull_width, nose_straightness, ear_height, eye_protrusion, teeth_spacing0, teeth_spacing1, and so forth can we?

[PeridexisErrant]

For anyone interested:  I'm working on a pull request to clean up the documentation, and generally make it possible to check whether something is actually documented as it should be.

This is obviously a work in progress, but I'd love any feedback you have at the pull or here.

You can now download the pretty, comprehensive html docs on DFFD, for those interested.

[mifki]

For anyone interested:  I'm working on a pull request to clean up the documentation, and generally make it possible to check whether something is actually documented as it should be.

This is obviously a work in progress, but I'd love any feedback you have at the pull or here.

You can now download the pretty, comprehensive html docs on DFFD, for those interested.

I usually hate auto-generated docs but this is pretty good.

[Warmist]

For anyone interested:  I'm working on a pull request to clean up the documentation, and generally make it possible to check whether something is actually documented as it should be.

This is obviously a work in progress, but I'd love any feedback you have at the pull or here.

You can now download the pretty, comprehensive html docs on DFFD, for those interested.

I usually hate auto-generated docs but this is pretty good.

I don't like auto-gen docs too. The idea of readme.rst and "lua api.rst" was that it would be readable both in html and txt format. Currently that is not exactly the case (because imho they are too big).

We'll see how it goes i guess...

Dirst: I think that would require run-time type information, which Toady does not have enabled.

Yeah, that's exactly what I wanted.  Can't have everything I suppose.

Thanks for the help guys!

Don't know why expwnent said that, since game types are known to us. You can use df.is_instance(df.building_workshopst,your_building).
(your_building._type == df.building_workshopst) will work too in your case, but is_instance handles subclasses as well.

Imho better way to check this is "building:type()==df.building_type.WORKSHOP (or was it workshop)". Though is_instance is more general this one is (for me at least) more readable. Also there is "subtype" and "custom_type" for more control (e.g. on all traps or just the boulder trap).

[PeridexisErrant]

For anyone interested:  I'm working on a pull request to clean up the documentation, and generally make it possible to check whether something is actually documented as it should be.

This is obviously a work in progress, but I'd love any feedback you have at the pull or here.

You can now download the pretty, comprehensive html docs on DFFD, for those interested.

I usually hate auto-generated docs but this is pretty good.

I don't like auto-gen docs too. The idea of readme.rst and "lua api.rst" was that it would be readable both in html and txt format. Currently that is not exactly the case (because imho they are too big).

We'll see how it goes i guess...

Ah - worth noting then that these are not autogenerated docs - just a more coherent system for building the .rst files into html (or pdf, or...).  Nicer style, but the big benefit is that everything can be linked and searchable from the single index file.  Easier building and integration means it's easier to break down the docs into manageable chunks, which should help.

You can find all the .rst files in the new /docs/ directory.  I agree that Readme.rst was too big; I broke it up into a file each for base, plugins, and scripts.  Still huge though   

Spoiler: Far future (click to show/hide)

Eventually it might be nice to have a single-source of docs for each plugin or script; I imagine a standard "help" (or "man") command.  We could then basically move the readme entry for each tool into that source code - easy to keep updated, and lint for - and then just pull it out of the files at doc-build time.  Still not autogenerated, but a really clean way to manage documentation for the hundreds of tools.  Unfortunately Sphinx does this best for Python, and the whole system is aimed at APIs rather than the system we've got - but it's still possible via the ..include directive.

[Nazushvel]

Code: [Select]

<stl-vector name='bp_modifiers' type-name='int32_t'
                        index-refers-to='$$._global.caste.ref-target.bp_appearance.modifier_idx[$].refers-to'/>If I'm not mistaken that can have the relevant type-name replaced with a list pulled from somewhere, hmmm, we need to take into account other species though.

The parts names are the relevant body parts and layers right? Bah, that's frustrating sounding right off the bat, because we can't just have it be skull_height, skull_width, nose_straightness, ear_height, eye_protrusion, teeth_spacing0, teeth_spacing1, and so forth can we?

Yeah, I figured that out yesterday after poring over the xml and looking for similar instances that link enum-lists to integer tables.

Unfortunately the different species pose a significant problem. Each index in bp_modifiers means something different depending on the unit species...and even within a species: males have about 20-30 extra variables relating to facial hair that get dumped into the middle of the table.

I'm not sure how the bp_modifier values are getting associated to specific body parts depending on the species. That must be in there somewhere, I would think.

[Max™]

Oh, that points to a part from the creature_raws.xml I think.

[expwnent]

What I was saying is that in the general case it is not possible. If there's a vector<void*> in df-structures there's no automatic way of determining the type. The reason we can do it for buildings is because of the building::getType() method (or whatever it's called) and because we've already mapped the enum it returns.

[mifki]

What I was saying is that in the general case it is not possible. If there's a vector<void*> in df-structures there's no automatic way of determining the type. The reason we can do it for buildings is because of the building::getType() method (or whatever it's called) and because we've already mapped the enum it returns.

Type is determined (for buildings as well) by matching vtable address to known addresses. If it's still void* in df-structures, then likely it's an unknown type indeed, but for known types we can determine what void* is.

[expwnent]

I believe that's only if it has virtual functions.

[milo christiansen]

For anyone interested:  I'm working on a pull request to clean up the documentation, and generally make it possible to check whether something is actually documented as it should be.

This is obviously a work in progress, but I'd love any feedback you have at the pull or here.

I use autogen docs every day, and these aren't half bad... Better than the hard to use PITA that is available now. (+1 from me)

[PeridexisErrant]

Yay, that got merged!  My new pull adds some nice stuff like internal hyperlinks, automatically pulling in the docs for third-party scripts (it they're there at build time), and so on.  I'm hoping this will get some of you excited enough to go improve it further...