Print

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

[Roses]

Is there a way to run a script anytime a unit enters the map? (Any unit, via birth, invasion, wandering, migrants, etc...) I know I could run through all the units every so often, but was hoping for something less intensive.

[Putnam]

Yeah, I made that a while ago. The gain in performance isn't nearly worth the unreliability. Running through all the units every so often works fine.

[Roses]

Ah right, I do seem to recall you posting something about it a while back. Good to know that the performance gain isn't really that great. How often do you think I should check units?

[lethosor]

It would be a lot faster to check on the C++ side, actually (maybe with eventful?).

Another suggestion:
A build up of the current DF hack Construction menu addon to support the construction of 'polygonal' walls and fortifications, as well as roads.

A player would select points and DFHack automatically creates construction orders to connect them.

Roads would be slightly trickier if you want to use materials effectively, since they'd have to be built to cover groups of tiles, but it shouldn't be too hard to do with constructions (although it could be difficult to use DF's material-selection interface).

[Bien]

It would be a lot faster to check on the C++ side, actually (maybe with eventful?).

Another suggestion:
A build up of the current DF hack Construction menu addon to support the construction of 'polygonal' walls and fortifications, as well as roads.

A player would select points and DFHack automatically creates construction orders to connect them.

Roads would be slightly trickier if you want to use materials effectively, since they'd have to be built to cover groups of tiles, but it shouldn't be too hard to do with constructions (although it could be difficult to use DF's material-selection interface).

Roads could perhaps be split into sections, then like:

[ooooooooooo]
                  [oooo]
                        [oooo]
                              [oooooooooooooooo]
Where:

• : Road section

After selecting the points, the DFhack would lay down roads of the selected width to connect the points, then ask the player to select the materials for the first section, then the second, then the third. It would essentially act as a macro for {b}-{o}/{O} and I assume would be a bit more complicated code-wise.

[Putnam]

OH CRAP I DIDN'T MAKE THIS PUBLIC

Code: [Select]

Button=defclass(Button,widgets.Widget)

Button.ATTRS={
    on_click = DEFAULT_NIL,
    graphic = DEFAULT_NIL, --refers to the name of a tilepage
    label = DEFAULT_NIL
}

function Button:preUpdateLayout()
    self.frame=self.frame or {}
    self.frame.w=self.page.page_dim_x
    self.frame.h=self.page.page_dim_y
end

function Button:onRenderBody(dc)
    for k,v in ipairs(self.page.texpos) do
        dc:seek(k%self.frame.w,math.floor(k/self.frame.w)):tile(32,v)
    end
end

function Button:onInput(keys)
    if keys._MOUSE_L_DOWN and self:getMousePos() and self.on_click then
        self.on_click()
    end
end

function Button:init(args)
    for k,v in ipairs(df.global.texture.page) do
        if v.token==self.graphic then self.page=v break end
    end
end
This is a button that uses an arbitrary graphics image as its display (with GRAPHICS:ON, otherwise will display ☺) that does some arbitrary thing when clicked. Example:

Code: [Select]

        Button{
            graphic='MINE',
            frame={t=0,l=0},
            on_click=function()
                self:sendInputToParent('D_DESIGNATE')
                self:sendInputToParent('DESIGNATE_DIG')
            end,
            label='Mining',
            view_id='mining_button'
        }

graphic='MINE' refers to [TILE_PAGE:MINE] in raw/graphics; it will load this tile page if possible (at least one creature must use part of this tile page for the tile page to load; I use GRIFFON or one of the other fanciful creatures). How large the button will be depends on PAGE_DIM (4:4 will make a 4x4 button). TILE_DIM and PAGE_DIM rules are same as creature graphics.

frame, view_id are as in normal widgets.

label is a thing that I added so that a highlighted button can have text describing what it is, such as in the renderSubviews(dc) method of my specialized button screen:

Code: [Select]

        local highlighted=false
        for _,child in ipairs(self.subviews) do
            if child:getMousePos() then self.subviews.highlight_label:setText(child.label) highlighted=true end
            if child.visible then
                child:render(dc)
            end
        end
        if not highlighted then self.subviews.highlight_label:setText('Highlight a button!') end
    end
Where highlight_label is a widgets.Label.

on_click is the function that fires when the button is clicked. Here, it opens the designations menu with the "mine" designation (assuming this button is on the main dwarf mode screen, which I recommend not doing for issues with OPTIONS and autosaves)

[Roses]

Questions regarding add-syndrome and syndromes in general

1. I'm not sure add-syndrome is working correctly. Using the below syndrome, I don't see any affect. The syndrome is added, but nothing else happens. No bleeding, no necrosis, no blisters. Am I doing something wrong? Or am I misunderstanding what add-syndrome is for?

Code: [Select]

[SYNDROME]
        [SYN_NAME:bad]
        [CE_NECROSIS:SEV:5000:PROB:100:START:1:END:300]
        [CE_BLISTERS:SEV:5000:PROB:100:START:1:END:300]
        [CE_BLEEDING:SEV:5000:PROB:100:START:1:END:300]
2. Do we understand what happens when a syndrome is added to a unit through an interaction? What I mean is, is it possible to do all of the syndrome stuff, without the actual syndrome. For example, with the above syndrome, what if I just wanted to add the necrosis and such without a syndrome? I assume lowering the blood count of the creature is what bleeding does?

The reason I ask is because I think it would be very fun to have an interaction whose outcome is dependent on the users WILLPOWER or something. This can already be done with my wrapper script, but if I want varying degrees of severity I would need to create many different versions of the syndrome, and then do a check, if WILLPOWER > 500 do this, if WILLPOWER > 1000 do this. Whereas, if we could apply the affects outside of a syndrome, I could change those numbers directly.

[Max™]

Sounds like something from sparking would help since the powerlevel checks are based on willpower among other things.

*lights the putnam signal, it begins screaming, I put it back out again and wonder if that's normal*

[Putnam]

2. Yes. A "unit syndrome" is added to the unit at that point. Said "unit syndrome" has a number that links to a syndrome ID, which is a proper raws syndrome. You cannot add creature effects without a syndrome due to the nature of syndromes. Bleeding actually creates a proper wound AFAIK.

I got around the "do things based on attributes without many syndromes" thing by manually programming what I wanted it to do without syndromes.

[expwnent]

It's entirely possible only transformation syndromes work with the current add-syndrome stuff.

[Roses]

2. Yes. A "unit syndrome" is added to the unit at that point. Said "unit syndrome" has a number that links to a syndrome ID, which is a proper raws syndrome. You cannot add creature effects without a syndrome due to the nature of syndromes. Bleeding actually creates a proper wound AFAIK.

I got around the "do things based on attributes without many syndromes" thing by manually programming what I wanted it to do without syndromes.

Might I inquire how and what you manually programmed? Which of your mods would have examples? That sounds like the route I should try and take.

It's entirely possible only transformation syndromes work with the current add-syndrome stuff.

I know name changes work as well. But adding things like CE_* doesn't seem to have any affect. At least I haven't gotten it to work.

[Putnam]

Sparking has stuff like that in its init.d/sparking.lua file. It's put together in a fairly formulaic manner (since it's a lookup table of syndrome names I used to replace syndrome-trigger, which I found to be unreliable).

[Roses]

Oi, that's a lot of information to take in. Lots of stuff that looks very useful to me, but alas, still not quite what I was looking for. I think I will just need to look into making wounds on targets. I know I have been able to alter already existing wounds, doing things like adding pain and bleeding and such, also changing things like bruises to burns. Does anyone know if there has been any research done on adding wounds to perfectly healthy units? If not, that is where I am going to invest some time. Hopefully make a script that can do it.

[Putnam]

If you can figure that out, I'd be very thankful, heh (as comments in the code there suggest).

Adding wounds shouldn't be difficult, just sorta... tedious to figure out. May be crashy at first.

[Roses]

Adding wounds doesn't seem like it will be the problem. Figuring out acceptable numbers on the other hand... I just added a wound to the upper body of a dwarf with a bleeding of 20. He lost almost half of his blood just from that wound.