Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - lethosor

Pages: 1 ... 10 11 [12] 13 14 ... 268
166
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r1
« on: July 05, 2021, 11:28:53 pm »
Quote from: Kat on July 05, 2021, 03:25:11 pm
Hello,
I was using the "show unit syndromes" in my game, and it was throwing an error on one of the citizens, who had a vampire curse active on them. It wouldn't show syndromes on any other citizens after it found the cursed one.

in the stderr.log, it has this:

Invoking: show-unit-syndromes
E: NoMethodError: undefined method `unk_6c' for #<DFHack::CreatureInteractionEffectBodyMatInteractionst:0x000000090e48c8>
 hack/scripts/show-unit-syndromes.rb:840:in `get_effect'
 hack/scripts/show-unit-syndromes.rb:886:in `block (2 levels) in <top (required)>'
 E:/Dwarf stuff/df_47_05_win/hack/ruby/ruby-autogen-defs.rb:439:in `block in each'
 E:/Dwarf stuff/df_47_05_win/hack/ruby/ruby-autogen-defs.rb:439:in `each'
 E:/Dwarf stuff/df_47_05_win/hack/ruby/ruby-autogen-defs.rb:439:in `each'
 hack/scripts/show-unit-syndromes.rb:886:in `collect'
 hack/scripts/show-unit-syndromes.rb:886:in `block in <top (required)>'
 hack/scripts/show-unit-syndromes.rb:947:in `[]'

Once I used add-syndrome to remove the syndrome (I used -eraseClass with both VAMPCURSE and DISTURBANCE_CURSE), then show-unit-syndromes ran properly with all citizens with syndromes shown.

Would this be because I am using modded creatures in my game ? Or because those kinds of curses cause a problem with the show-unit-syndromes command ?
It's an issue with the script. Looks like you're the first one that's reported it since it broke a year or so ago, so thank you! (It may be a rare case - I don't seem to have a save where I can reproduce the issue easily.)

Here's a fix that should work. If you can test it out, that'd be great. You can either make the changes manually to hack/scripts/show-unit-syndromes.rb, or replace that file with the new version (be sure to save the new one with a ".rb" extension and overwrite the existing one).

This fix will also be in the next DFHack release, which is hopefully soon.

167
DF Modding / Re: DFHack script to delete cave spider webs?
« on: July 04, 2021, 08:56:47 pm »
Quote from: DwarfStar on April 29, 2021, 06:46:03 pm
If someone that maintains DFHack is reading this, may I suggest this script might be useful enough to include in the standard distribution.
Looks like I ran across this thread after a couple months. In the future, it's best to report things like this to us directly at one of these places: https://docs.dfhack.org/en/latest/docs/Support.html

Atomic Chicken implemented this here, so it'll be in the next release: https://github.com/DFHack/scripts/pull/285

168
DF General Discussion / Re: LET'S FIX THE WIKI! - A DF COMMUNITY PROJECT
« on: July 02, 2021, 09:31:24 pm »
It was added in this edit, which basically merged in a separate "Traitor" page with less information than that.

The wording could stand to be improved. Maybe this would be a good opportunity for the {{stub}} template to draw attention to the fact that the topic needs more research. I imagine it's not a particularly easy topic to research, so it's understandable that it hasn't been documented (especially if people don't realize that content is missing).

169
Utilities and 3rd Party Applications / Re: DFHack plugin embark-assistant
« on: June 23, 2021, 11:09:24 pm »
Quote from: PatrikLundell on June 21, 2021, 01:30:18 am
I did get one call that was initiated by embark-tools (I think the key issued was A102, but I may be misremembering)
For what it's worth, this is normal when other plugins are enabled and hook into the same screen - they'll end up calling each others' hooks, and unless they specify a priority, there's not a fixed order to these calls across DF runs (although they should usually occur in the same order in a single DF session, unless plugins are loaded/unloaded).

170
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r1
« on: June 22, 2021, 06:15:39 pm »
Quote from: Bumber on June 22, 2021, 10:19:08 am
Code: [Select]
extern DFHACK_EXPORT df::plant *getPlantAtCoords(int32_t x, int32_t y, int32_t z);

inline df::plant *getPlantAtCoords(df::coord pos) { return getPlantAtCoords(pos.x, pos.y, pos.z); }
Was getting a red squiggly line for "return Lua::PushDFObject" in "static int maps_getPlantAtCoords(lua_State *L)" with the message. Error was result of copying from "maps_getTileBiomeRgn" and editing to "PushDFObject", instead of from "maps_ensureTileBlock" (which returns 1.)

Doing it like getBlock with WRAPN seems to work. Not used to working with function pointers, so the syntax was confusing.

How does the Lua C API way determine which implementation it's using?

Edit: Doesn't look like it's accepting DFCoord (using xyz2pos) in Lua using WRAPN with cast. C API works for both DFCoord and three int32_ts.
The function passed to WRAP is the one that's exposed to Lua. Casting the function to a specific type essentially forces the compiler to pick the implementation of that function that can be cast to that type - otherwise it would be ambiguous (I could have phrased this better earlier). if you're choosing to expose the one that takes (int32, int32, int32) params to Lua, you will only be able to pass those from Lua, not a df::coord object, and vice versa if you expose the other implementation. There isn't a way to support both types of arguments without using the Lua C API. If you want to do that, there are several examples - maps_getTileBlock() might be a good one since it returns a map_block pointer.

171
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r1
« on: June 22, 2021, 09:33:53 am »
Quote from: Bumber on June 22, 2021, 05:21:55 am
Why do some functions in Maps.h use "extern" and others don't? E.g.:
Code: [Select]
extern DFHACK_EXPORT bool RemoveBlockEvent(uint32_t x, uint32_t y, uint32_t z, df::block_square_event * which );

DFHACK_EXPORT bool canWalkBetween(df::coord pos1, df::coord pos2);
How do I add my function to the Lua API? Seems like it's a bit more complicated than adding the line "WRAPM(Maps, getPlantAtCoords)," to LuaApi.cpp.

Edit: Trying to do it like "maps_ensureTileBlock" gives me the error "return value type does not match the function type".
If you could provide the function signature and any relevant pieces of the error you're getting, that would help. WRAPM should be all that's necessary in most cases, but sometimes weird argument or return types can trip it up.

maps_ensureTileBlock() is an example of a custom-implemented function that uses the Lua C API (section 4 of https://www.lua.org/manual/5.3/manual.html). That is an option, but the WRAP macros are much less maintenance effort.

Quote
Also, what am I looking at here: "WRAPN(getBlock, (df::map_block* (*)(int32_t,int32_t,int32_t))Maps::getBlock),"
There are two implementations of Maps::getBlock - one takes three int32_ts and one takes a df::coord. Casting to a function pointer specifies which one to select. Without it, we'd get a fairly confusing error:
Spoiler (click to show/hide)

On that note: thanks for taking the time to expose this to Lua!

172
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r1
« on: June 20, 2021, 11:56:47 pm »
Did the "x / 48 * 48 < 0"-style checks come directly from disassembly? I agree with PatrikLundell that there is a bounds issue there: -47 / 48 == 0, so some small negative numbers will slip through those checks.

I think the first section could be simplified (or corrected) to:
Code: [Select]
if (x < 0 || x >= world->map.x_count || y < 0 || y >= world->map.y_count)
  return NULL;
x_count and y_count do happen to be multiples of 48 currently, so the "/48 * 48" bits don't affect checks against those fields, but I suppose the behavior could be different if map sizes change in the future.

I think this could be a good fit for the Maps module (modules/Maps.cpp), by the way. Gui::getAnyPlant() could definitely stand to be optimized by using your logic, but I don't think yours really belongs in the Gui module.

173
Utilities and 3rd Party Applications / Re: DFHack plugin embark-assistant
« on: June 20, 2021, 10:15:50 pm »
Quote from: RedDwarfStepper on June 19, 2021, 02:27:21 pm
- Would more crash dumps with the debug-dlls help? Perhaps we're missing something?
In general, I would say yes. You currently have a crash dump with several active threads, and it can be difficult to know where the crash actually originated sometimes, despite what the dump might say. It's likely that the crash occurred in the embark-assistant thread, given that using embark-assistant triggers the crash, but it would be easier to rule out unrelated threads with a handful of other crash dumps (say, 5 maybe).

Your advice about disabling other plugins is also a good idea.

Quote
PPS:
One more thing I just found: The current pressed key is CURSOR_UPLEFT_FAST, coming from here
https://github.com/DFHack/dfhack/blob/1c32783dd2628f22c5355b84e49e5c7357b52cb8/plugins/embark-assistant/matcher.cpp#L2966
or to be exact here
https://github.com/DFHack/dfhack/blob/1c32783dd2628f22c5355b84e49e5c7357b52cb8/plugins/embark-assistant/matcher.cpp#L2967
so the end of a loop - hm.

One possible important thing to check would be to ensure that the core is suspended when matcher.cpp calls feed_key() - this is writing data that DF reads from, so if DF is accessing that data at the same time, there could be a possible race condition there. I'm not sure why that would result in a crash when reading from a std::set, though - that should be local to the calling thread.

Edit: per "Core::getInstance().isSuspended()" it does appear to be suspended here, which is good.

Edit: one more thing: the getHotkeyCmd() thread is normal and expected to be idle in that function. It typically acts only on DFHack-managed hotkeys (registered with the "keybinding" command). feed_key() probably can't trigger this thread.

174
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r1
« on: June 15, 2021, 12:05:51 am »
Quote from: lethosor on May 24, 2021, 06:55:21 pm
I updated the first post of this thread with some new chat options. We have a Discord server and an IRC channel on Libera now. (I'm avoiding linking them here in case any links become stale, so check out the first post for links.)
Update: Freenode has effectively been dismantled at this point - user and channel registrations have been wiped, and most previous servers have been split from the network. Sad to see it go. Fortunately, both Discord and Libera are alive and well (the latter has most of the Freenode staff, from my understanding), so those two are our "official" real-time channels for the time being.

Our documentation has a new page listing all of the relevant support channels (which were previously listed on the "Introduction" page, so hopefully this change makes them easier to find): https://docs.dfhack.org/en/latest/docs/Support.html

175
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r1
« on: June 14, 2021, 11:52:49 pm »
Quote from: Bumber on June 14, 2021, 05:12:33 pm
I'll just leave a comment:
Code: [Select]
if bits.whole & 0x7F > 0 then --Any non-blocked tree_tile
It should probably be implemented in C++, really, since you get type checking (coords are int16_t?) and loop continue, which would look more like the assembly. I had to flip some of the conditions.

Edit: Actually, Lua supports GOTO, so I could really make my script look like assembly if I wanted.
Yeah, there are some limitations to Lua (not that it's necessarily a bad thing, but code can't always correspond one-to-one). Higher-level languages often limit what "goto" can do, at least compared to assembly. In Lua's case, for instance:
Quote from: https://www.lua.org/manual/5.3/manual.html#3.3.4
A goto may jump to any visible label as long as it does not enter into the scope of a local variable.

Quote
Maybe it should be printed for "gui/gm-editor" and the Lua "printall". Could something be done about allowing tree_tiles to be indexed (beyond the z-level) instead of using "_displace", or is that not possible due to them not being vectors? I'll add this to the issue tracker it if it's possible.
There's a substantial risk of breaking code by doing that (e.g. if existing code relies on all fields returned by pairs() being booleans); I'd say it's better just to document.

Your _displace() note is due to the fact that those fields are 2D arrays implemented as double pointers. The Lua layer doesn't have great support for these - I don't know exactly why, but I suspect it has to do with "references" that are exposed to Lua (like an "<int32: ...>" field you see somewhere) not supporting multiple layers of indirection (to be clear, I'm pretty sure that's a limitation in our implementation, not Lua itself). https://docs.dfhack.org/en/stable/docs/Lua%20API.html#container-references has a brief note that stemmed from https://github.com/DFHack/dfhack/issues/597.

176
Utilities and 3rd Party Applications / Re: DFHack 0.47.05-r1
« on: June 14, 2021, 04:33:29 pm »
Generally, due to optimizations (possibly including the ones you've noted), we cannot call DF functions directly from DFHack in a cross-platform way. There are some exceptions, like virtual methods, where it's easy, however. There's some precedent in existing library modules for reimplementing pieces of DF logic in DFHack (e.g. Units::getNominalSkill, Units::getVisibleName).

Apparently there are holes in our documentation about bitfields. There's a special "whole" field that provides the raw integer value of a bitfield (i.e. "bits.whole"). That said, I would prefer using symbolic names (e.g. "flags.trunk" instead of "flags[0]") except in cases where it makes a significant difference in performance.

177
DF General Discussion / Re: Lazy Mac Pack (v0.47.05)
« on: June 06, 2021, 11:19:05 am »
Quote from: Alphum5 on June 06, 2021, 09:42:27 am
Sorry, with big Sur 11.1 on m1.
Since you mentioned "rehabilitation" I assume you mean that DF doesn't work for you. Could you go into more detail about how it doesn't work? (Does it crash on embark, fail to launch entirely, etc.)

178
DF General Discussion / Re: PeridexisErrant's DF Starter Pack
« on: June 04, 2021, 11:41:46 pm »
Quote from: Timeless Bob on June 04, 2021, 03:36:11 pm
Why is PerfectWorld no longer in the utilities?
I don't use this pack, but PerfectWorld is still listed in the contents at the beginning of this thread (which was last updated yesterday). To help gather a bit more information: what pack version are you using? And do you remember what version you had before?

For reference: I just downloaded 0.47.05-r03 of this pack, and it has a "LNP/utilities/PerfectWorld" folder. I don't know whether it works, however. If that's missing, maybe some antivirus software could have done something to it.

179
Utilities and 3rd Party Applications / Re: DFHack plugin embark-assistant
« on: June 02, 2021, 11:43:50 pm »
Quote from: PatrikLundell on June 02, 2021, 05:52:17 pm
@lethosor: This is what the call stack looks like.

>   SDLreal.dll!00007ffdc856e804()   Unknown
    Dwarf Fortress.exe!00007ff775ad9a6d()   Unknown
    Dwarf Fortress.exe!00007ff775ada0a7()   Unknown
    Dwarf Fortress.exe!00007ff775ada580()   Unknown
    Dwarf Fortress.exe!00007ff775ada87d()   Unknown
    Dwarf Fortress.exe!00007ff775adb062()   Unknown
    Dwarf Fortress.exe!00007ff77645cf8e()   Unknown
    Dwarf Fortress.exe!00007ff77645cd25()   Unknown
    Dwarf Fortress.exe!00007ff77645c1fa()   Unknown
    [External Code]   

I suppose the answer to this question isn't really relevant, but I'd be interested in knowing whether ">" marks the current or oldest frame. If current, I would expect to see an intermediate call to SDL.dll, and I don't think such a call could have been optimized out. If oldest, it's possible that DF has registered a callback that SDL calls - this feels more feasible to me, since it wouldn't need to go through DFHack's SDL.dll, but I'm unaware of DF code that does this explicitly.

To RedDwarfStepper's points: DF does use some threading primitives implemented by SDL. Hard to say if that's part of this stack trace without knowing what "SDLreal.dll!00007ffdc856e804()" refers to, though. Multithreading isn't exclusive to the SDL layer, but that's what provides e.g. locks that DF uses.

180
Utilities and 3rd Party Applications / Re: DFHack plugin embark-assistant
« on: June 02, 2021, 03:52:03 pm »
Quote from: PatrikLundell on June 02, 2021, 11:51:45 am
However, the Call Stack tab shows an address in SDLreal.dll, with the rest of the call stack entries pointing to DF itself, and the fact that it refers to SDLreal.dll is odd, since that ought to be DF's original version of SDL.dll, rather than the DFHack one, as if DF was running with the original DLL but somehow managed to call DFHack ones anyway (I tried to start DF with DFHack disabled, and couldn't reach the Embark Assistant, as expected).

Could you post the call stack? I'm not really sure how to interpret this.

I'm assuming you are aware that SDL.dll is essentially the DFHack core on Windows, and that SDLreal.dll is just a renamed copy of DF's SDL.dll (so I wouldn't be surprised if it expects debug info to be in "SDL.pdb", since that is likely compiled into the DLL). To my knowledge, DF will call functions in SDL.dll for any SDL functions, and DFHack will forward most of those calls to SDLreal.dll untouched. I don't believe there is a mechanism for SDLreal.dll to call into DF directly - there is some SDL code that gets called before main(), but that should be compiled into the DF executable as part of SDLmain.lib.

Pages: 1 ... 10 11 [12] 13 14 ... 268