Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 33 34 [35] 36 37 ... 360

Author Topic: DFHack 0.43.03-r1  (Read 1120248 times)

Rose

  • Bay Watcher
  • Resident Elf
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #510 on: August 22, 2014, 12:23:29 am »

Stonesense is forced to OpenGL by default, at least in that release.

Try forcing it to DirectX. I have more luck with that.
Logged

TheKaspa

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #511 on: August 22, 2014, 02:22:02 pm »

Since I just want to use showmood and prospect, is there a way to make it compatible with .09 or do I have to wait for the actual release of dfhack .09?
Logged
Tai'shar DwarfFortress

I've heard Minecart Airlines Express offers nice trips to nobility. Alternative trips include a voyage over the volcano. Call 1-800-I-THE-GUINEAPIG-VOLUNTEER and book now!
My fucking armok, you broke the game.

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #512 on: August 22, 2014, 02:47:17 pm »

DFHack for 0.40.08 won't work with 0.40.09 due to a few structure changes, so you'll have to wait or compile it on your own. Also, there's a showmood crash in 0.40.08-r2 that should be fixed in the next version.
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.

TheKaspa

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #513 on: August 22, 2014, 02:51:24 pm »

Is there an ETA for the release?
Logged
Tai'shar DwarfFortress

I've heard Minecart Airlines Express offers nice trips to nobility. Alternative trips include a voyage over the volcano. Call 1-800-I-THE-GUINEAPIG-VOLUNTEER and book now!
My fucking armok, you broke the game.

ag

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #514 on: August 22, 2014, 03:22:57 pm »

Whenever expwnent will have time?..  ;)
Logged

breadman

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #515 on: August 22, 2014, 04:16:51 pm »

most stockpile applications would be happy with a simple list of stored items.

I'm a newbie in c++, so lua is my way.

I'm not that hot at C++ myself, though I'm decent with straight C or a number of other languages.  But I might have just enough example code to pull off an iterator that could be called from Lua...

For example, need to create "cut gems" jobs in linked workshop according stored rough gems in stockpile.

Hmm.  This shows a limitation in the design of stockflow.  By duplicating the manager job entry screen, I precluded a generic "cut gems" job.  So the only way to do this with straight stockflow is to have a separate stockpile for each type of gem, which would be insane.

I wonder if it would let me create such an order anyway?

There is an unnamed vmethod in df.buildings.xml
How to call a numbered vmethod in lua? All vmethods in *.h are protected.

This would require modifying and compiling DFHack on your own.  It also risks crashing the game, perhaps corrupting your save, and maybe worse.

A little change in hack/lua/plugins/stockflow.lua.
For test, I replaced function findItemsAtTile by this:

Spoiler: Code (click to show/hide)

and run check_pile(stockpile, true)

Was: 101 sec.
Now:  1 sec.

Wow.  I expected an improvement, but not that much; I must not have been testing on mature enough forts.  I'll have to see if I can slip this in before the next release.

If vmethods are unnamed, then it means we don't know what they do (and, in some cases, what parameters they take), so attempting to call them could just make DF crash. Experimenting with unnamed vmethods from DFHack is also completely pointless - if you want to figure out what it does and how it's used, you disassemble the entire game (e.g. in IDA Pro) and then analyze the vmethod code directly (and, if possible, track down and identify the places that call it).

My disassembly skills are rusty enough that just trying it to see what happens sounds much more fun, and potentially more fruitful.  I never did get around to determining how the "xx% done" bit on the bookkeeper settings page gets calculated.  (I found the viewscreen variable that caches it, but nothing else holds the same value consistently.)

And I'm not opposed to a few crashes.  Even if something goes wrong with the save, I can always git reset.

Besides, there's no reason why Toady would put a stockpile-specific operation in a virtual method available within the base class - he'd put it as a non-virtual method directly within stockpile itself (which I'm pretty sure is what he's already doing).

Oh.  So there's no way we can call such a method once the symbols have been stripped?
Logged
Quote from: Kevin Wayne, in r.g.r.n
Is a "diety" the being pictured by one of those extremely skinny aboriginal statues?

Quietust

  • Bay Watcher
  • Does not suffer fools gladly
    • View Profile
    • QMT Productions
Re: DFHack 0.40.08-r2
« Reply #516 on: August 22, 2014, 07:38:00 pm »

My disassembly skills are rusty enough that just trying it to see what happens sounds much more fun, and potentially more fruitful.  I never did get around to determining how the "xx% done" bit on the bookkeeper settings page gets calculated.  (I found the viewscreen variable that caches it, but nothing else holds the same value consistently.)

And I'm not opposed to a few crashes.  Even if something goes wrong with the save, I can always git reset.
In all likelihood, random probing of vmethods will be totally fruitless, since even if they don't crash, they may appear to do nothing at all while instead having some obscure side effect on the game which will ruin any further testing efforts unless you test each one in complete isolation and monitor the entire game's memory for changes, by which point you'd be better off just disassembling it and seeing exactly what it does.

And God help you if the vmethod you're tinkering with takes a pointer as a parameter, because you're never going to figure out what type it is through experimentation. As an example, out of all the known Building vmethods, these are the types of pointers that can be provided as parameters:
* Hospital supply data
* Machine power information
* Machine connection data
* Unit
* Item
* File compressor
* Map viewport
* Map draw buffer
* STL String
* STL Vector of Squad Use information

If you get into Items, you'll get to deal with pointers to Flagarrays, Item Filter specifications, Jobs, Historical Figures, Civilizations, Sites, Wounds, Caravan states, and Squad uniforms. Good luck figuring out which is which without looking at a disassembly.

Oh.  So there's no way we can call such a method once the symbols have been stripped?

Non-virtual class methods are infeasible to call on Windows due to whole program optimization, which stuffs function parameters (including "this") into random registers rather than putting them on the stack (and ECX), making it impossible to just call them as if they were function pointers (as we can for virtual class methods). There's also the issue that the compiler is allowed to inline non-virtual class methods, so if it's only used in one place (e.g. inside a loop), the compiler may decide to dump it in there exclusively and leave you with nothing to call (unless you want to do everything else the outer function was trying to do).

You really need to understand that the work done with DFHack is not just smashing things together randomly until they stick - it's more like carefully cutting the game apart and examining the pieces under a microscope, something best left to people who are experienced in doing such things (or are willing to learn a lot to figure out how to do it themselves).
« Last Edit: August 22, 2014, 07:46:24 pm by Quietust »
Logged
P.S. If you don't get this note, let me know and I'll write you another.
It's amazing how dwarves can make a stack of bones completely waterproof and magmaproof.
It's amazing how they can make an entire floodgate out of the bones of 2 cats.

mifki

  • Bay Watcher
  • works secretly...
    • View Profile
    • mifki
Re: DFHack 0.40.08-r2
« Reply #517 on: August 23, 2014, 04:40:47 am »

Non-virtual class methods are infeasible to call on Windows due to whole program optimization, which stuffs function parameters (including "this") into random registers rather than putting them on the stack (and ECX), making it impossible to just call them as if they were function pointers (as we can for virtual class methods).

Oh that's why I was finding parameters in completely "wrong" places on Windows... Of course we can call such functions anyway, but that doesn't matter since it's much harder (or impossible if they've been inlined) to find them compared to vmethods.

Roses

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #518 on: August 24, 2014, 08:05:41 am »

Couple questions:

1. This one may be a silly one, but does addReactionToShop(reaction_name,shop_name) work the way I think it does? Meaning can you add a reaction to a workshop mid-game? And will those reactions stay post-save-quit-reload?
2. Is there a script to allow only one of a particular building to be built? If not I can write one, but I figured I would ask first.
3. Is there an eventful command for triggering every season?
Logged

expwnent

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #519 on: August 24, 2014, 08:34:48 am »

Couple questions:

1. This one may be a silly one, but does addReactionToShop(reaction_name,shop_name) work the way I think it does? Meaning can you add a reaction to a workshop mid-game? And will those reactions stay post-save-quit-reload?
2. Is there a script to allow only one of a particular building to be built? If not I can write one, but I figured I would ask first.
3. Is there an eventful command for triggering every season?

There is no such script for one of a kind buildings.

There is no eventful command, but there is the repeat-util.lua module.
Logged

IndigoFenix

  • Bay Watcher
  • All things die, but nothing dies forever.
    • View Profile
    • Boundworlds: A Browser-Based Multiverse Creation and Exploration Game
Re: DFHack 0.40.08-r2
« Reply #520 on: August 24, 2014, 10:07:34 am »

Well, I'm glad that most of the new structures are added on instead of removed outright.  Most of the old scripts should still work.

That being said, has anyone been playing with trees?  I've worked out how to change the tiles of a tree provided they are already part of that tree, but how does the game determine the tree's current shape?  It doesn't seem to be all tree tiles within a cube, since adding new tree tiles within a tree's cube just creates a species-less 'tree' tile.  Stranger still, trees don't seem to have ID numbers.  How does the game determine which tiles belong to which tree if the tree has no ID?

There's a list of trees in the first map_block_column of the embark square, each of which has a list of all the branches in the tree, and their sizes. You have to modify that if you want to add new tiles to the tree. Keep in mind that the bounding box of the tree is kinda fixed after the tree is made, so you can't easily make ygdrassil, as far as I know.

I've been experimenting with this, but still no luck.

While df.global.world.map.map_block_columns[c].plants does indeed contain a list of plants in that map column, their data seems to be identical to those found under df.global.world.plants.

In both cases, most of the variables are very basic and seem to be carryovers from the last version, so I'd expect everything tree-related to be in the new variable, tree_info.

Tree_info contains a handful of integers, mainly related to the tree's boundaries.  The body and roots variables could be expected to hold the tiles...but that's where I'm stuck.  There is just one variable per tree (value), which contains a handful of promising-looking variables (trunk, thick_branches, twigs)... but these are booleans, rather than the array of tiles I would expect.  Changing them doesn't seem to do anything.

So where is the list of branches you speak of?

lukesleftleg

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #521 on: August 24, 2014, 11:09:05 am »

Hi all, and thanks once again for all your hard work on DFHack.

Just a quick question....

I realise it makes me a bad person, but I can't help it, children really annoy me, and dwarf children are no better.

I've been experimenting with editing the Rejuvenate script (disabling the under 20 y/o check in my version), and I've discovered that just making a kid twenty just gives you a twenty year old kid, but if I make them eleven, and wait for their next birthday, then they seem to mature into an adult properly.

Now I undertsand how the script works. It simply changes the unit's birth year to twenty years before the current one, which is gets with df.global.cur_year, and that's all well and good, but what I'd really like to do is to make it so that their birthday is tomorrow, so I don't have to wait too long before putting them to work and can still face looking myself in the mirror.

So my first question is, do functions such as df.global.cur_month or df.global.cur_day exist? (I've a feeling there's one for season, but not sure).

And actually, my second question is this: is there a list of DF structures anywhere, something like an API, so that I don't have to hassle you guys every time I have an idea for a script?
For instance, what other toys might there be to play with under df.global, or other similar structures?

Thanks very much in advance, and thanks again for all your work in making the masterpiece that is Dwarf Fortress actually playable. :)
« Last Edit: August 24, 2014, 11:27:29 am by lukesleftleg »
Logged

IndigoFenix

  • Bay Watcher
  • All things die, but nothing dies forever.
    • View Profile
    • Boundworlds: A Browser-Based Multiverse Creation and Exploration Game
Re: DFHack 0.40.08-r2
« Reply #522 on: August 24, 2014, 11:14:07 am »

Now I undertsand how the script works. It simply changes the unit's birth year to twenty years before the current one, which is gets with df.global.cur_year, and that's all well and good, but what I'd really like to do is to make it so that their birthday is tomorrow, so I don't have to wait too long before putting them to work and can still face looking myself in the mirror.

A simpler method: just change their profession.  BABY and CHILD are simply professions that automatically change into DEFAULT (adult peasant) when the creature reaches their adult age.  You can do this at any age.

lukesleftleg

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #523 on: August 24, 2014, 11:24:18 am »

Hi IndigoFenix, and thanks for the prompt reply.

A simpler method: just change their profession.  BABY and CHILD are simply professions that automatically change into DEFAULT (adult peasant) when the creature reaches their adult age.  You can do this at any age.

Oh that sounds like it might work. How would I go about doing this though, I'm not sure I've ever tried to assign 'Peasant' to a dorf?
Do I do it through DF itself, or maybe Therapist, or is there a DFHack command to do it?

Also, any intelligence on some sort of API refernce for all this stuff, or maybe a command to dump the names of all the stuctures, something like that?

Thanks again, and thanks again in advance. :)
Logged

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.08-r2
« Reply #524 on: August 24, 2014, 11:31:01 am »

In Lua: unit.profession = df.profession.STANDARD
(Edit: Fixed)
« Last Edit: August 24, 2014, 11:37:48 am by lethosor »
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.
Pages: 1 ... 33 34 [35] 36 37 ... 360