Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 11 12 [13] 14 15 ... 244

Author Topic: DFHack 50.14-r1.1  (Read 892407 times)

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #180 on: July 27, 2017, 05:31:59 am »

Can someone explain how to interpret the entity_claims1 and 2 fields in df.global.world.world_data? Or is it still unknown?

Obviously it's two sets of bit map masks of bit mapped civs (as explained), but what do these masks represent (I find my goblin civ in both of them, for instance), and what are these masks intended to mask? There's an indication of a height/width of 3*3 (haven't seen anything else so far), but again, height/width of what? Trying to apply it to the geography doesn't make sense, at least not on the world tile scale, as my humans on the NE continent of a 33*33 4 square continent would claim almost everything immediately on creation (including the other continents), for instance.
Logged

Atkana

  • Bay Watcher
  • [CURIOUSBEAST]
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #181 on: July 27, 2017, 02:06:45 pm »

Bluh, it'd be nice if it was mentioned somewhere that eventful.registerReaction will only trigger on reactions with a product - I spent way longer than I should have before I worked that out. On the topic of the docs, I noticed the entry for the units module is missing at least:
Spoiler (click to show/hide)
and I didn't know the World module even existed until I stumbled across it in a script (okay, that applies to pretty much everything I know about dfhack, but what I'm saying is it doesn't appear in the docs :P)
/documentation rant

So back to my original point/problem: Anyone got a preferred goto dummy product they use for their reactions-that-actually-trigger-eventful?

Warmist

  • Bay Watcher
  • Master of unfinished jobs
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #182 on: July 27, 2017, 05:00:47 pm »

So back to my original point/problem: Anyone got a preferred goto dummy product they use for their reactions-that-actually-trigger-eventful?

I use
Code: [Select]
[PRODUCT:0:1:LIQUID_MISC:NONE:WATER][PRODUCT_DIMENSION:2000]
with code that cancels the creation with "call_native.value=false"

Atkana

  • Bay Watcher
  • [CURIOUSBEAST]
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #183 on: July 28, 2017, 03:10:25 am »

So back to my original point/problem: Anyone got a preferred goto dummy product they use for their reactions-that-actually-trigger-eventful?

I use
Code: [Select]
[PRODUCT:0:1:LIQUID_MISC:NONE:WATER][PRODUCT_DIMENSION:2000]
with code that cancels the creation with "call_native.value=false"
Huh, so it'll still trigger even if the reaction's only product has a 0% chance of being made? If so, is it actually necessary to cancel the creation with code?

Warmist

  • Bay Watcher
  • Master of unfinished jobs
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #184 on: July 29, 2017, 02:20:56 am »

So back to my original point/problem: Anyone got a preferred goto dummy product they use for their reactions-that-actually-trigger-eventful?

I use
Code: [Select]
[PRODUCT:0:1:LIQUID_MISC:NONE:WATER][PRODUCT_DIMENSION:2000]
with code that cancels the creation with "call_native.value=false"
Huh, so it'll still trigger even if the reaction's only product has a 0% chance of being made? If so, is it actually necessary to cancel the creation with code?
Probably not :P

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #185 on: July 30, 2017, 08:50:16 am »

Where is "dfhack.screen" located?
It's referenced by gui.lua, and the referenced operation is similar to one defined in Screen.cpp, but the profile differs, so there's a translation layer somewhere. However, my searches have failed to find any matching file (or contents in files I've looked at).
What I'm trying to do is to create "transparent" screens that can be used as overlays on top of DF's native UI (the current attempt is to provide an overlay that shows where non displayed sites are located pre embark [e.g. lairs and refugee camps]).
So far I've managed to get a "transparent" DFHack window where I can paint things only at selected tiles, which is sufficient for my purposes technically. The problem I have is that I can't "unpaint" what's painted: skipping rendering of no longer desired tiles doesn't do anything, although I suspect it would if I let DF advance a frame (which may be where I end up anyway, since it would be nice to allow movement while the overlay is present, but callback based operation is a bit messy).
Another alternative (which is the source if the question) is to read what's on the tile and before I put the overlay there and cache the info to paint the original info on the overlay to emulate it being cleared on that tile (or just paint all of it with the original data to start with).

Edit: Corrected the above by replacing "tick" with "frame".
« Last Edit: July 30, 2017, 08:54:48 am by PatrikLundell »
Logged

Warmist

  • Bay Watcher
  • Master of unfinished jobs
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #186 on: July 30, 2017, 11:21:03 am »

Where is "dfhack.screen" located?
It's referenced by gui.lua, and the referenced operation is similar to one defined in Screen.cpp, but the profile differs, so there's a translation layer somewhere. However, my searches have failed to find any matching file (or contents in files I've looked at).
What I'm trying to do is to create "transparent" screens that can be used as overlays on top of DF's native UI (the current attempt is to provide an overlay that shows where non displayed sites are located pre embark [e.g. lairs and refugee camps]).
So far I've managed to get a "transparent" DFHack window where I can paint things only at selected tiles, which is sufficient for my purposes technically. The problem I have is that I can't "unpaint" what's painted: skipping rendering of no longer desired tiles doesn't do anything, although I suspect it would if I let DF advance a frame (which may be where I end up anyway, since it would be nice to allow movement while the overlay is present, but callback based operation is a bit messy).
Another alternative (which is the source if the question) is to read what's on the tile and before I put the overlay there and cache the info to paint the original info on the overlay to emulate it being cleared on that tile (or just paint all of it with the original data to start with).

Edit: Corrected the above by replacing "tick" with "frame".
To do transparent display in c++ is quite easy. Either subclass the screen you want and then call parent->render (not sure the exact naming) or use vmethod interposing to replace the render and then call  INTERPOSE_NEXT(render) (which calls the next inserted function - usually the original)

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #187 on: July 30, 2017, 11:30:41 am »

You probably wouldn't want to subclass DF screens.

Anyway, as long as you're calling render() on the parent screen every time your screen is rendered, it should work. If it doesn't, can you post your code?
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #188 on: July 30, 2017, 11:52:22 am »

I'm using Lua, as I am under the impression that GCC isn't compatible with small soft compilers.

I've been using the pre embark screen as my test bed.
I've been messing around with various approaches, and my code is doing anything as it's purely experimenting to see what might work. I'm currently calling Screen:renderParent() every time the 'm' key is pressed and nothing else, after a starting state of putting up a DFHack "transparent" frame (the clearing of the innards removed from an overriding onRenderFrame(), a label, and a Grid widget that doesn't actually render anything at all at the moment).
renderParent() gives odd results, as random parts of the screen gets blanked out at random calls. When I did sent an 'm' on to the parent DF correctly moved the embark frame, but did not clear out the old one and parts get overwritten but with the old contents still displayed (flickering between two results when F1/F2 becomes available, for instance).

The mess looks like this:
Spoiler (click to show/hide)
Logged

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #189 on: July 30, 2017, 12:59:45 pm »

You can only call renderParent from render (or onRender, etc.). Calling it from onInput is likely the cause of the issues you're having.
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #190 on: July 30, 2017, 01:41:02 pm »

Thanks lethosor!

A few small changes results in both DF's embark rectangle moving and my "application" marker moving at the same time without leving trails behind.
I still wouldn't mind knowing how to read the DF screen for future use, but this will certainly bring me on to my next stumbling block on this "project".
Logged

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #191 on: July 30, 2017, 10:03:02 pm »

dfhack.screen.readTile(), I think. (Although it's not as easy for your purposes here, of course.)
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #192 on: July 31, 2017, 02:50:58 am »

Thanks again, lethosor. It looks like readTile (x, y) returns the tile info just fine, based on my simple experiment.
Logged

SalmonGod

  • Bay Watcher
  • Nyarrr
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #193 on: July 31, 2017, 11:29:19 pm »

PTW
Logged
In the land of twilight, under the moon
We dance for the idiots
As the end will come so soon
In the land of twilight

Maybe people should love for the sake of loving, and not with all of these optimization conditions.

gnome

  • Bay Watcher
    • View Profile
Re: DFHack 0.43.05-r2
« Reply #194 on: August 02, 2017, 05:24:10 am »

Someone told me this mod adds a little bit of mouse functionality for some menus - any chance that extends to the conversation menus in Adventure Mode? Those things are infuriating to scroll through after awhile.
Logged
Pages: 1 ... 11 12 [13] 14 15 ... 244