Print

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

[lethosor]

Removing items while they're displayed in a DF viewscreen probably isn't safe. If you're making a UI to stack items, you could probably implement a simplified list in lua, but it would have the disadvantage of not having the options of the native viewscreen (I'm not sure how necessary you consider that).
Anyway, you ought to be able to remove an item from a viewscreen listing multiple items from lua, as well as the corresponding refs, but I'm not sure how safe that is.

[Roses]

Does anyone know where the [MATERIAL_FORCE_MULTIPLIER] information is stored? I have found the corresponding syndrome based material force change, but can't seem to find where the creature/caste information is kept. I have looked all over the individual unit and the raws.creatures.all[unit.race], and I keep coming up empty handed.

[kane_t]

Removing items while they're displayed in a DF viewscreen probably isn't safe. If you're making a UI to stack items, you could probably implement a simplified list in lua, but it would have the disadvantage of not having the options of the native viewscreen (I'm not sure how necessary you consider that).
Anyway, you ought to be able to remove an item from a viewscreen listing multiple items from lua, as well as the corresponding refs, but I'm not sure how safe that is.

Yeah, it's possible, and I wrote a script that does it.  It didn't crash immediately, or after running the game for half a minute, and the item does disappear from df.item.find(), so it's probably safe.  It depends on how DF does its memory management internally.  If, internally, it uses reference-counted smart pointers, then as long as it doesn't do anything obscene with them it should be fine.

It doesn't update the inventory screen to show removals in real time, though, which makes it less useful as something to release to the public.  I'll probably just write something ugly that solves the minor inconvenience I had and keep it to myself.  (You know, two scripts, one to mark items for merging while you're in the inventory screen, storing their IDs in a persist table, the second to actually carry out the merges after exiting the inventory screen.)

I suppose I could still write a plugin that automatically merges stacks as items are added to containers (and containers to stockpiles), but I don't know how many people would care to have a utility like that.  Personally, I really think it should just be something DF does automatically.  It's kind of absurd the way the game handles stacks of items, really.  A cook grabs a stack of 30 eggs and a stack of one quarry bush leaf and figures that's a reasonable pairing?  And that takes the same amount of time to cook as four stacks of 30 eggs, or two stacks of one strawberry?  Instead of picking up stacks from containers, dwarves should make stacks in their hands by taking items, and try to hit a target stack size.  So, when a cook decides to add eggs as the next ingredient to a meal, they should try to collect (say) six eggs from the available stocks, even if that requires splitting and merging available item stacks.  Same deal with crossbow bolts.  Dwarves should just fill their quiver from the available stocks.

It's a minor gripe, I know, like the fact that you can't select material types for most jobs (though there is a script for that), but it's one of those little things that just sticks in my craw for some reason.

[mifki]

If, internally, it uses reference-counted smart pointers, then as long as it doesn't do anything obscene with them it should be fine.

No, it doesn't. However I don't see what's the problem to remove item from the viewscreen first.

[lethosor]

Right, although you'd also have to remove the corresponding general_refs and specific_refs before the item can be deleted with Items::remove().

[roguester]

Hi, I'm getting a crash whenever I use 'zone set'. 'zone zinfo' gives correct-looking information including the zone id. 'zone assign etc' doesn't crash, but of course doesn't work because the zone is not set. This happens on all the zones I have tried on my current map.

I am using DF v0.40.24, DFHack  release 0.40.24-r3-Windows

Running on Windows 8

Wondering whether this is a known issue or whether someone knows what might be wrong.

It is possible I am doing something wrong but I don't think so. I hit 'i', select the zone, then type on the console 'zone set' and I get a crash.

[lethosor]

It crashes for me if the cursor is in use but a zone isn't selected, which should definitely be fixed. Are you sure you're selecting a zone? (It might require the 'q' cursor to work properly.)

[roguester]

Yes, I had a zone selected. I tried just now with 'q' and same thing.

One thing that might help: When it crashes it prints out in the console 'Target building type: cage'. However if I try to do it on a cage I get: 'No pen/pasture or pit under cursor'

[lethosor]

Yeah, that's one of several crash issues (I'm surprised it went unnoticed for so long). In that case the logic is reversed - if there's no cage selected, the plugin should check other building types, but it doesn't and then tries to work with a null pointer (by printing the building's ID - without that, it's possible that the crash wouldn't occur and you'd only end up with no zone selected, as before). There were also issues with cage and chain checks crashing if a building wasn't selected at all.
Edit: Should be fixed now.

[kane_t]

I changed my mind and ended up writing the scripts anyway.  Here they are, if anyone wants to use them: combine_drinks and combine_plants.

For combine_plants, you can select either a stockpile (with q) or a container (with k).  In either case, the script will recurse into nested containers to find stacks to merge.  For combine_drinks, you have to select a stockpile.  Both scripts allow a -max param to set the desired stack size, with _plants defaulting to 12 and _drinks defaulting to 30.

As promised, they're ugly and poorly-optimised, but they do check for and ignore items that are currently tasked.  Importantly, they don't currently test to see if a viewscreen is open, so if you're selecting the item from an inventory screen it'll stupidly move items but be unable to remove empty stacks.  (For safety, I made it set the stack size of stacks to be removed to 1, but it's still undesirable.)

If anybody wants to copy the code and use it for merging, say, ammunition stacks, feel free.  Or I'll probably do it in the future when that starts annoying me.

[TheFlame52]

Is there a script to get rid of burned trees by any chance?

[Max™]

Not that I know of, trees are a pain to get rid of with hackery, they like to respawn inside solid tiletypes/liquids created walls.

In other news, for a first run activated on hotkey version this is remarkably fun:

Code: (artibash.lua) [Select]

local unit = df.global.world.units.active[0]
local attks = unit.actions
for k,v in ipairs(attks) do
if attks[k].type==1 and attks[k].data.attack.attack_item_id then
local item = df.item.find(attks[k].data.attack.attack_item_id)
if item.flags.artifact == true then
item.subtype.attacks[0].velocity_mult = 2700000
attks[k].data.attack.unk_30=99999999
end
end
end
I was trying to use Putnam's sparking trick of having it check for artifact weapon swings and then running the velocity booster and ended up stripping it back until it worked first (rather than trying to build it up and get it working) so I could at least test and make sure it was doing the right stuff. Basically you line up a multi-attack and before you advance time a step run the script (or use the hotkey) and pchew! Away the poor bastard you're hitting goes.

Similar effect to using launch to fling them except it's the actual hyper-accelerated weapon impact doing the work and thus getting the credit.

Before:
@>ë
After:
@ ~≈~≈≈~²~≈e ²

[Roses]

Hmm, that makes me think of something. I have been trying to figure out adding more custom attacks using scripts to add the wounds that would be caused by an attack with the item/body part made of a certain material. Would it be at all possible to just queue an actual attack, in game, and then let the game mechanics handle the wound calculation?

[Max™]

Uhhhh...

unit.actions:new()
unit.actions:insert('#',
                    type = 1,
                    id = y,
                    data = faked_attack,
                    )
unit.next_action_id = y+1

Set up the relevant fields for faked_attack and it should process it next tick I think?

I originally tried to get vertical leaps by messing with that before I bumped into propel/molested it into launch. I was able to take a readied jump and edit it and I recall directly gm-editor faking a jump with various effects but never getting the desired vertical leap in a satisfying manner.

I wonder if it wouldn't be easier to just fake a projectile for the attack?

[Roses]

Uhhhh...

unit.actions:new()
unit.actions:insert('#',
                    type = 1,
                    id = y,
                    data = faked_attack,
                    )
unit.next_action_id = y+1

Set up the relevant fields for faked_attack and it should process it next tick I think?

I will look into this, but I was just looking through the various fields that we can edit and unfortunately it seems like we can only specify an item id, body part id, and velocity. I was hoping to be able to simulate attacks made with body part X but with a different material (like steel punches). So unless one of those various unk parameters handles material and such I don't think it will be as useful as I hoped.