Print

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

[Bogus]

thats certainly possible, tho using this tool is likely only marginally less complicated than just writing the selection logic for each script that uses it. i dont think any script in existance has a reason to select units over appearance features, so writing a gui to do this selection would have little practical value.

other than that, that gui were to allow sorting by each and every property a unit can have, it could be useful, but its a lot of flags and things to check.

also, in the examples you mentioned (dwarves with brown beards and shearing stock with long enough hair), you dont find these things in the raws but in the vector for active units.

you can use the gm-editor gui in game to explore df memory and look through this data manually, that way you can easily check out the structure of these entries and where things are saved.

[FantasticDorf]

thats certainly possible, tho using this tool is likely only marginally less complicated than just writing the selection logic for each script that uses it. i dont think any script in existance has a reason to select units over appearance features, so writing a gui to do this selection would have little practical value.

What if you wanted to build

Spoiler (click to show/hide)

A barber?

EDIT - But more realistically, you could use appearance based scripts against (or for) vampires.

[FantasticDorf]

A unnessecary bump but a kickstart to the thread again after i seem to have capsized it.

I want to set the record straight with a actual constructive suggestion (rather than a collection of well intentioned shitposts) though im still quite fond of the appearance driven barber idea (adventure mode workshop magic haircuts for sprouting beards?/ dyeing your beard pink?)

What i am suggesting is a extension to the plant plugin to control the age of trees. Through testing with dfhack and arena mode (im running the 42.06r1 version) i came across that it only forces the trees to grow to the exact point of maturity by forcing the processes. The actual age of the tree is exactly 1 year (or to say day) old leading to complaints that the command can't generate multilevel trees. This new plugin redesign/rethink would also have some greater controls UI wise via use of co-ordinates to place down trees within a specified space rather than rely on the cursor, meaning they could be run autonomously.

One particular idea i have in general is to force a type of tree to spawn inside/outside to a fixed x/y/z so that we dont have to rely on mouse/all grow UI as currently in the plugin  (alternatively on a non collision 1 or 2x2 tile big 'tree-planter' workshop that obscures the trunk from cutting but allows general orchard picking when in season or leave the sapling to grow naturally and force it to grow with progressional uses of bonemeal*) fixture, feed the workshop a proxy reaction  with seeds/reagent to force sapling/saplings to spawn, but to also respect trees that are also on the same x/y/z grid adjacent to the workshop active zone.

So in quite literal terms

Reaction=
(Plant 'insert sapling name here' NW)

• X and Y in relation to the specified space based off the (hopefully central workspace 2:2 in a 3x3 ideally) location to the workshop using the plugin
• Run checks to whether the surface is soil & solid and not obscured (for simplicity's sake not having mandatory z level minimum height requirements for the sapling to grow naturally is not a great deal and can be thought about and put in later)
• proceed with the 'plant create TOWER_CAPS 100* etc, if not return and issue a announcement and print a message in dfhack that reaction is not available to be completed, and don't execute it. It could be a autonomous grow to that number

The base plugin already has the dirt restrictive preference, so attempting to plant the tree sapling on a rough surface like stone anyway wouldn't work without a varying script composure

*Bonemeal is a powder material collected from grinding bones in a quern to be allocated inside the 'bonemeal' page of the stockpiles stored in bags, its just a end to a means of providing a meaningful reagent to prompt running the sub-command to grow progressional growth, more age via a flat age progression 1/10/25  just demands more powder to be consumed for the reaction at once. Unless there were flexible variables.

*that 100 number variable in the plant create would be the spawned in tree's age upon creation effectively skipping 'plant grow' as to directly grow trees with meaningful lifespans

Post-post creation edit - I have found a Vjek's rejuvenation script

Spoiler: Vjek's rejuvination script in full (click to show/hide)

Code: [Select]

-- This script will make any "old" dwarf 20 years old
-- usage is:  target a unit in DF, and execute this script in dfhack
-- via ' lua /path/to/script '
-- the target will be changed to 20 years old
-- by vjek, version 2, 20120703, for DF(hack) 34.11
-- Paise Armok!


function rejuvenate()
local current_year,newbirthyear
unit=dfhack.gui.getSelectedUnit()

if unit==nil then
print ("No unit under cursor!  Aborting with extreme prejudice.")
return
end

current_year=df.global.cur_year
newbirthyear=current_year - 20
if unit.relations.birth_year < newbirthyear then
unit.relations.birth_year=newbirthyear
end
print (unit.name.first_name.." is now 20 years old")

end

rejuvenate()

That's all very well and nice but the reason i pulled this out was because of this bit of code.

Code: [Select]

current_year=df.global.cur_year
newbirthyear=current_year - 20

This sets a dwarf's age to a flat 20 diminishingly (as in it does not act additive to children to force them to grow up), if the same rhetoric can be applied to trees then we can flat out control what age they grow too. Observe this noobish mockup i created as proof of concept.

Code: [Select]

current_year=df.global.cur_year
(grow++ date)=current_year + 20
Reaction=
(Feed NW tree one bag of bonemeal/compost)

• Establish a X and Y relationship to reading the iftree=true in that location
• If it is not a iftree=true at the x y location, cancel and spam that it cannot be completed by the workshop and in dfhack
• Proceed to execute age differences and forcefully grow the tree consuming the reagent in the workshop side reaction

I don't know enough about the background coding to effectively make any substantial plugin code myself but throwing it out to the community is the best thing i can do right now. It would be especially helpful to speak to the creator of the plant plugin, and i invite them to talk with me privately about this over PM's if they wish.

[Bogus]

https://github.com/DFHack/df-structures has xml files detailing the layout of various struct types in the game, including plants:
https://github.com/DFHack/df-structures/blob/master/df.plants.xml

it does not seem to have an age field per se, but there is a grow counter that one could tinker with and also the twigs and branches and all the other stuff seems to be defined here. so my guess is, not having tried it, that you could beef up the original script/plugin fairly easily to do the thing you want to.

and, again, i recommend to you the gm-editor that lets you explore(and edit!) the very same structs in game.

[FantasticDorf]

https://github.com/DFHack/df-structures has xml files detailing the layout of various struct types in the game, including plants:
https://github.com/DFHack/df-structures/blob/master/df.plants.xml

it does not seem to have an age field per se, but there is a grow counter that one could tinker with and also the twigs and branches and all the other stuff seems to be defined here. so my guess is, not having tried it, that you could beef up the original script/plugin fairly easily to do the thing you want to.

and, again, i recommend to you the gm-editor that lets you explore(and edit!) the very same structs in game.

Thanks. This depository was invaluable in providing a firm reference, concise as always bogus. GM editor too, only affects units but its very interesting to look into the peripheral guts of a unit.

In my initial twiddling i've just repurposed the growage to be directly relevant to the supposed current year in a additive number (because the sapling age in the original was done by - 1 it seems, i can swap that out if thats a non-compliant use of the + value in that context to something else), i've been taking a few tutorials over youtube as to C++ so i get a grip of what im looking at besides trial and error.

I would like to ask somebody to test it out, as i completed the changes on Notepad++ (notepad with the capacity to write in CC and display in notepad, read from notepad and also show in C++ for instance) and can't seemingly find a supported file type to run it into dfhack directly to test. Slot it around the 216 mark i guess for a additional sub command to appear on the original plugin, if it does work, it should work as before with cursor co-ordinates.

Code: ( custom grow code) [Select]

command_result df_growage (color_ostream &out, vector <string> & parameters)
{
    for(size_t i = 0; i < parameters.size();i++)
    {
        if(parameters[i] == "help" || parameters[i] == "?")
        {
            out.print("Usage:\n"
                "This command grows additively all saplings on the map by 20 years of age.\n"
                "With active cursor, work on the targetted one only.\n");
            return CR_OK;
        }
    }

    CoreSuspender suspend;

    if (!Maps::IsValid())
    {
        out.printerr("Map is not available!\n");
        return CR_FAILURE;
    }
MapExtras::MapCache map;
    int32_t x,y,z;
    int grown = 0;
    if(Gui::getCursorCoords(x,y,z))
    {
        for(size_t i = 0; i < world->plants.all.size(); i++)
        {
            df::plant * tree = world->plants.all[i];
            if(tree->pos.x == x && tree->pos.y == y && tree->pos.z == z)
            {
                if(tileShape(map.tiletypeAt(DFCoord(x,y,z))) == tiletype_shape::SAPLING &&
                    tileSpecial(map.tiletypeAt(DFCoord(x,y,z))) != tiletype_special::DEAD)
                {
                    tree->grow_counter = df.global.cur_year
                    tree->grow_counter = current_year + 20
                    grown++;
                }
                break;
            }
        }
    }
    else
    {
        for(size_t i = 0 ; i < world->plants.all.size(); i++)
        {
            df::plant *p = world->plants.all[i];
            df::tiletype ttype = map.tiletypeAt(df::coord(p->pos.x,p->pos.y,p->pos.z));
            if(!p->flags.bits.is_shrub && tileShape(ttype) == tiletype_shape::SAPLING && tileSpecial(ttype) != tiletype_special::DEAD)
            {
                tree->grow_counter = df.global.cur_year
                tree->grow_counter = current_year + 20
                grown++;
            }
        }
    }
    if (grown)
        out.print("%i plants grown to 20 years of age.\n", grown);
    else
        out.printerr("No plant(s) found!\n");

    return CR_OK;
}
I wonder who created the plant plugin. I never found that out and its been rather ambigious, im happy to take my plugin to another thread for more intensive work & discussion about fixing it up if people dont want me cluttering up here.

[Bogus]

GM editor too, only affects units but its very interesting to look into the peripheral guts of a unit.

actually no, tho the mode is different. you may be able to inspect other world-objects using the gm editor hotkey (such as furniture, ..). otherwise, you can call it from the dfhack console with the name of the target data structure as an argument.

for example: (not sure about the syntax but should be like this)
gm-editor df
gm-editor df.global.world.raws.inorganics
gm-editor dfhack

df is the root for all the original game data dfhack has access to. note that whatever entry point you choose is the root folder for this instance of the editor gui, so if you inspect a specific object (such as a unit), you cannot use the "back" operation to get to the field containing this object (also the same object may be contained in several vectors). so to just freely browse whats going on in df memory, use the df argument. most of the relevant game data including all raws is contained in df.global.world.

regarding changes to the plugin, ive never done any c++ coding with df so i cant tell you how to compile yourself - but you could try making a pull request on the github and that way possibly get feedback from the original author.

[FantasticDorf]

GM editor too, only affects units but its very interesting to look into the peripheral guts of a unit.

actually no, tho the mode is different. you may be able to inspect other world-objects using the gm editor hotkey (such as furniture, ..). otherwise, you can call it from the dfhack console with the name of the target data structure as an argument.

for example: (not sure about the syntax but should be like this)
gm-editor df
gm-editor df.global.world.raws.inorganics
gm-editor dfhack

df is the root for all the original game data dfhack has access to. note that whatever entry point you choose is the root folder for this instance of the editor gui, so if you inspect a specific object (such as a unit), you cannot use the "back" operation to get to the field containing this object (also the same object may be contained in several vectors). so to just freely browse whats going on in df memory, use the df argument. most of the relevant game data including all raws is contained in df.global.world.

regarding changes to the plugin, ive never done any c++ coding with df so i cant tell you how to compile yourself - but you could try making a pull request on the github and that way possibly get feedback from the original author.

Ah. i was thinking about the gui/gm-editor, this explains a bit.

Well for one i dont even know if it definitively works so there's that, id rather pr a working build (though i've seen people shop shoddier things in other github places).

[Putnam]

Bogus is also talking about gui/gm-editor. gui/gm-editor can access everything Lua can access, which is nearly everything.

[FantasticDorf]

Bogus is also talking about gui/gm-editor. gui/gm-editor can access everything Lua can access, which is nearly everything.

Interesting. I couldn't get it to process targets outside of unit view mode before using the dfhack console, ill have to look into it.

Im beginning to have doubts about my application of the plus twenty the biggest change to my incase it isn't applicable due to syntax or some other silly reason born out of my literally entry level C++ understanding. (Theres still the fact it might interpret unexpectedly towards current year in general so finding another application to facilitate testing is on the checklist of things i need to do)

Code: [Select]

tree->grow_counter = df.global.cur_year
tree->grow_counter = current_year + 20
If my understanding is correct it should add (+20 years) on, rather than stay at the baseline (-20) however as a contingency plan, applying minus variables as UI input as i detailed before could well be easier for a flat one way transition to that age (because even so, plants aging in reverse doesn't make much sense game wise outside "its magic, i aint gotta explain it" but for just a plugin utility thing its neat to have for control, say if you wanted to revert the eventual death of a plant with revitalizing ingredients.)

[Bumber]

Would it be possible to make it so that worn clothing is counted as refuse?

[Dirst]

Would it be possible to make a print-like command for Lua (or just its own script) that accepts markdown syntax?  It doesn't need to be 100% faithful (maybe use colors for bold and italic), but something that could make sense out of the same markdown text used in the documentation on GitHub.

[FantasticDorf]

Throwing out a suggestion just because it crossed my mind earlier today.

What about mixing the code (i've heard it mentioned around) for Putnam's forced pregnancy, with a modified non-specific version of vjek's age rejuvenation in a plugin additionally with some custom code to force a unnatural 'child' state (even if not explictly in the raws) in a creature so that tame parents (however unnatural means that came to be) can give birth to a domesticated animal with good consistent training and player input. (GCS for instance or cave dragons)

It'd be the full taming bundle; it might even revive the dungeon keeper role within some DFhack capacity.

For instance you could tame a breed of forgotten beast (by applying a training level on it forcefully) in this fashion and then domesticate the child naturally without perversely having to go into gm-edit yourself to mess with those settings. Might help modders on projects with end level goals for bringing powerful unnatural beasts on board without being explicit about it.

[Putnam]

Would it be possible to make a print-like command for Lua (or just its own script) that accepts markdown syntax?  It doesn't need to be 100% faithful (maybe use colors for bold and italic), but something that could make sense out of the same markdown text used in the documentation on GitHub.

What exactly are you proposing to convert to markdown?

[Dirst]

Would it be possible to make a print-like command for Lua (or just its own script) that accepts markdown syntax?  It doesn't need to be 100% faithful (maybe use colors for bold and italic), but something that could make sense out of the same markdown text used in the documentation on GitHub.

What exactly are you proposing to convert to markdown?

Mostly helptext, so that it can be formatted once and used in GitHub, script comments, and on-screen help.

Something along the lines of

Code: [Select]

local helptext = [[
=goto.lua=
Move the viewer to a bookmark or a set of coordinates.
Enter *goto* _#_ _#_ _#_ to move the screen to a set of XYZ coordinates.
Enter *goto* _foo_ to move the screen to be centered on bookmark _foo_.
*goto* _help_ prints this command summary.
]]

args = {...}

if args[1]=="help" then dfhack.printmd(helptext) endbut more geared to whatever the norms are for documenting DFHack on GitHub.

[PeridexisErrant]

Would it be possible to make a print-like command for Lua (or just its own script) that accepts markdown syntax?  It doesn't need to be 100% faithful (maybe use colors for bold and italic), but something that could make sense out of the same markdown text used in the documentation on GitHub.

What exactly are you proposing to convert to markdown?

Mostly helptext, so that it can be formatted once and used in GitHub, script comments, and on-screen help.

Context:  documentation for scripts is now contained in the script files, between tokens that (in lua) denote a multiline comment or string (comment only in Ruby).  This text is marked up in "restructured text" format, which is similar to markdown but better for large documents, and used to generate the html docs.  It is also used as in-console help for some scripts - unifying the interactive help, documentation, and comments for maintainers.  An upgrade to the dfhack core command "help" is planned which will make the docs for all scripts available without adding -help flags on a per-script basis.

Dirst - I think what you want is for help text in the console to have some actual formatting, rather than just dumping all the markup characters.  This is a logical extension of the open issue, and actually pretty easy to do.  (though IMO it's plenty readable anyway...)

There are, I think, only a few main constructs to handle. 
- **bold**, *italics*, and ``monospace`` can be handled by colors, and nesting is not supported. 
- The title is always the first word, on it's own line, and underlined with its length in ===== on the next line -- another color would do. 
- 'Definition lists' have the term (command) first between colons, then spaces to align and the explanation (possibly multiline) -- just color term and remove the colons. 
- "::" indicates that the following (indented) block is monospaced; it should be replaced with ":" if on the end of a line or removed if nothing precedes it.
- leading and trailing empty lines should be stripped.
- `cross-references` are surrounded by single backticks -- another color.

It's not trivial, but nor would that be too difficult to implement in Lua... I'll open an issue with this summary to start tracking it.