Print

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

[lethosor]

Fastdwarf teleport does not bring along the visiting mercs.

Ive a hu mercenary in shock squad, 4. S4 is filled to 10 souls. It was ordered to kill something in caverns. 9 soldiers teleported to  thing in cavern. All the dwarfs minus the mercenary.

Crossing fingers. To me teleport works like marching orders, for the squad soldiers. I hope someone out there in forumland, can fix this.

Looks like there's a check to skip non-citizens. That part was last changed in 2012, well before mercenaries and other visitors were added, so presumably it was meant to exclude livestock, invaders, etc.. I'm not sure what a better check would be - maybe Units::isOwnGroup()?

Probably reported in one of 1xx's of dfHack pages, but in the event it hasn't been reported.

A quick search of the DFHack issue tracker turned up https://github.com/DFHack/dfhack/issues/664, which is a similar issue. Unclear if the reporter there wanted it to apply to visitors or some other group of units, though.

In any case, thanks for the report! Feel free to report issues if you can't find them already reported. 2-3 reports are better than no reports. (There is such a thing as too many reports, but that's not an issue here.)

[lethosor]

The modified script as of now just work eagerly before trapping and has some new nice features:
- it stamps the safe part of blueprints that are same size than the embark. (with some more tinkering and 4 additional params partial stamping should be in the reachable zone)
- it warns when some lines and/or rows of the blueprint could had been ignored because the dimensions of the blueprint are bigger than the design-able zone of the embark.
- well formed multilevel nanoforts of 48x48 or 47x47 tiles faultily rejected by the previous script over an 1x1 embark are now possible.

It has been a while, but I finally got around to this. It turns out the map boundary check was off by one, so it thought any blueprint that touched the bottom or right edge of the map went off the map. I fixed that, and added a "force" option to allow drawing partial blueprints instead of failing. I hope this is what you were aiming to do with your changes - if not, feel free to let me know.

I'm no Ruby expert either, but you can see the changes I made to the script here. This change specifically fixed the off-by-one error I mentioned.

Some things that are on my list include:

- Documenting the RPC (remote) interface - https://github.com/DFHack/dfhack/issues/1574 has some information, and BenLubar put together a description of the format, so this mostly just involves integrating this into the docs

Here's some remote API documentation (forgot to mention it a week or so ago when I put it up): https://docs.dfhack.org/en/latest/docs/Remote.html
I know some of you have struggled to get information about the remote API, and I'm not very familiar with it either, so this is a bunch of information I've pulled together from various places. If there's more information that would be helpful to include, let me know and I can try to integrate it.

[knutor]

Stumbled upon a confirmed mantis bug in 47.04 last night.

http://www.bay12games.com/dwarves/mantisbt/view.php?id=9943&nbn=6#bugnotes

Thank you dfHack, using the changeitem command, I was able to fix things. All good now. I only wanted to, thank you.

[lethosor]

Thanks for the feedback!

A heads up: I'm planning on releasing 0.47.04-r2 "soon", if all goes well (rough progress here). I encourage people to try out a development ("unstable") build from https://dfhack.org/builds/ and let us know if you spot any issues with it - it should be at least as stable as 0.47.04-r1, with some extra fixes, and probably won't change very much before r2.

Edit: and even if you don't do that, please consider taking a look at the new documentation: https://docs.dfhack.org/en/latest/
There are some new pages and some organizational changes, so let me know if anything needs fixing. This will become the new "stable" version when r2 is released.

[knutor]

clearowned all

This does not clear all owned objects on the embark map, like a player would think it would. It ignores visitors items, which are held in their inventory. Call these item(vb)

Autodumping item(vb) dumps it right out of a visitors inventory. Once on ground cleanowned all, still fails on item(vb). However oddly, cleanowned scattered works. Turning item into item(c). Cleaned of ownership. This is a lagubrious click intensive way to circumnavigate the ALL feature, failing to work on item(vb).

Not sure item(c) is usable, however. It sits where dumped, alone.

[lethosor]

I'm not sure what items it's supposed to handle - I don't see an explicit check for owners' citizenship, like some other plugins, but the logic is a bit complicated: https://github.com/DFHack/dfhack/blob/0.47.04-r1/plugins/cleanowned.cpp#L58

It looks like there are a couple messages that this plugin can print. For an item that you're having issues with, does the plugin say that it was handled, say that it was handled "(unsuccessfully)", or not mention it at all?

[knutor]

When it fails, it scrolls past, before I can tell. I do not remeber seeing a notice of failure.

cleanowned

 -does junk on ground with ownerships, like socks.

cleanowned all

-clears every ownership on every item on embark map, except gear being tracked for special names, I wanna say. I could be mistaken, however I dont ever remember a conflict with the equipment naming code, before, when using this command.

Ive never used scatter before, but oddly, it did work on that visitor's instrument, once it was on the ground. It was another civ's instrument, the dwarfs from my fort could not make that item.

Bumped into this problem, while trying to move my higher quality instruments all into the public tavern from unused temples.

[knutor]

I had a look at that link. I'm guessing the problem is around lines 17,18,19. It calls for unit.h, item.h, translation.h but there is some additional options now, these days, visitor.h and instrument.h <--- hunch, no idea if these even exist. I am no programer, but this seems to me to be where it breaks.

[lethosor]

Those actually aren't part of the logic for cleaning items at all (line 58, which I linked to, is roughly where that starts). A basic explanation: the lines you mentioned are just the plugin including other files that it needs to work with certain types of data - everything in question is an item, so the "item"-related lines are enough, but also don't affect cleaning directly. The link was mostly for my own reference (and in case someone more familiar with the plugin could chime in) - sorry for the confusion.

If you want someone else to take a look at this, it would be helpful if you could upload a save with some items that show this issue, as well as a clear description of how to find the problematic items.

[knutor]

Buggy Reproduction for cleanowned.
It is done all in one pause, in any fort with a public tavern, with an entertainer guest with an owned instrument.

Open an entertainer(bard) visitor's inventory
Attempt the Magneto Gambit+.
While instrument sits on the ground, observe it. Owned.
Run cleanowned all. Reobserve it. Still owned. #1 Bug verified.
Run cleanowned scattered. Reobserve it. Instrument cleaned.++

Backup, retry another bard visitor's inventory without Magneto Gambit.
cleanowned all. observe it. Still in bard's inventory, still owned #2 Bug verified.

The -all extension fails on owned instruments in inventory AND on ground.

+autodump metal straight from inventory, in this case not goblinite, but the visitor's randomly generated, owned, foreign crafted, music instrument
++workaround, repurcusions on cleaned object unknown.

[lethosor]

Buggy Reproduction for cleanowned.
It is done all in one pause, in any fort with a public tavern, with an entertainer guest with an owned instrument.

Thanks for the detailed instructions, but I don't have a save that has most of the things needed to reproduce it. Can you upload a save to make it easier for us to reproduce? http://dffd.bay12games.com/ is one site that takes DF-related files, but somewhere else would also work. (In case you're unfamiliar with the process, we would only need a compressed copy of the data/save/regionX folder you're using.)

[Bumber]

I've noticed that lua scripts use `` in their help text instead of ". Is there a reason for this convention?

[lethosor]

I've noticed that lua scripts use `` in their help text instead of ". Is there a reason for this convention?

It produces inline code blocks in ReStructuredText, which is what our documentation system uses.
Example: https://github.com/DFHack/scripts/blob/0.47.04-r1/add-thought.lua#L9 gives https://docs.dfhack.org/en/0.47.04-r1/docs/_auto/base.html#add-thought

https://docs.dfhack.org/en/latest/docs/Documentation.html goes into a bit more detail (this page is relatively new, although bits of it were taken from other pages, so let me know if it needs improving)

[Warmist]

Btw i'm still impressed how nicely this all works

[Roses]

Question about the onReactionComplete eventful trigger. IIRC it only triggers when a product is actually created, is that still true? Also, if using both onReactionComplete and onJobCompleted will the always trigger in the same order, or will it be somewhat random which one triggers first?