Print

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

[Putnam]

...Which means that if I decide to make a music generator I can make that in whatever language. Huh, that's convenient.

[Rallor]

Other way is have dfhack talk to your program through a socket. We use protobuf and basically you write stuff you need from dfhack to your program. This way you have way more control and can even program in any language you want.

Is dfhack listening for those requests by default or do I need to write a c++ plugin for it?
My goal is to access variables that store a dwarves appearance. One would place the in-game cursor over a unit and have my application display image files based on these values.

Using a lua script I can access the values like this:

Code: [Select]

local unit=dfhack.gui.getSelectedUnit()

print(printall(unit.appearance.tissue_style))
print(printall(unit.appearance.bp_modifiers))


[PeridexisErrant]

There's not a lot of new code needed to update to a new version, aside from changes needed to fix things that depend on changed structures. The most work involves figuring out the layouts of changed structures, and maybe new ones too.

How's this work going?  I've looked at the commit logs on df-structures, but all that told me was that I don't understand it enough to help      Even a confirmed ETA of "no idea" would be nice!

Once structures are updated - but before all the plugin fixes - could someone run the devel/export-dt-ini script?  I've got a number of people asking when it'll be ready 

[Warmist]

Other way is have dfhack talk to your program through a socket. We use protobuf and basically you write stuff you need from dfhack to your program. This way you have way more control and can even program in any language you want.

Is dfhack listening for those requests by default or do I need to write a c++ plugin for it?
My goal is to access variables that store a dwarves appearance. One would place the in-game cursor over a unit and have my application display image files based on these values.

Using a lua script I can access the values like this:

Code: [Select]

local unit=dfhack.gui.getSelectedUnit()

print(printall(unit.appearance.tissue_style))
print(printall(unit.appearance.bp_modifiers))


It's listening by default, but not everything is supported: stuff for visualizers is supported but it might be strange format (e.g. export EVERYTHING!). And it's not writing a full plugin in c++ just some commands you need (e.g. "GetSelectedUnitId" and "GetUnitAppearance").
Also i have not looked at that part very much...

[lethosor]

There's not a lot of new code needed to update to a new version, aside from changes needed to fix things that depend on changed structures. The most work involves figuring out the layouts of changed structures, and maybe new ones too.

How's this work going?  I've looked at the commit logs on df-structures, but all that told me was that I don't understand it enough to help      Even a confirmed ETA of "no idea" would be nice!

Once structures are updated - but before all the plugin fixes - could someone run the devel/export-dt-ini script?  I've got a number of people asking when it'll be ready 

Angavrilov said he would work on it today, I think, but there are a lot of structures that still haven't been fixed. That script actually crashes at the moment, which is surprising, but probably related to mismatched layouts (apparently creature raws changed significantly). Plugins are typically fixed as structures are fixed, but it's usually faster than figuring out structures.

Other way is have dfhack talk to your program through a socket. We use protobuf and basically you write stuff you need from dfhack to your program. This way you have way more control and can even program in any language you want.

Is dfhack listening for those requests by default or do I need to write a c++ plugin for it?
My goal is to access variables that store a dwarves appearance. One would place the in-game cursor over a unit and have my application display image files based on these values.

Using a lua script I can access the values like this:

Code: [Select]

local unit=dfhack.gui.getSelectedUnit()

print(printall(unit.appearance.tissue_style))
print(printall(unit.appearance.bp_modifiers))


DFHack has a server built in that listens for protobuf requests, but you have to implement request handlers (the commands warmist mentioned) in plugins. You could alternatively set up your own server, which could be done with lua, but it's probably easier to use the built-in one if you're able to use protobuf.

[Rose]

Yeah, you can look at how the remotefortressreader does things, and implement something similar, either in the same plugin, or as your own.
I think it'd make things easier to have all of that sort of stuff in the same place, but that's up to you.

[jaked122]

Is there a thread or page somewhere for the new version's progress?


Or will this one metamorphose into it as the time is right?

[notfood]

df_structures for windows seems almost there for 42.02. Can't really test, I don't use windows.

[Warmist]

df_structures for windows seems almost there for 42.02. Can't really test, I don't use windows.

Globals are there, but the structures are not. So it would appear to work until crash or corruption.
It will be done when all of these: file on github will be "VERIFIED" IIRC

[jaked122]

Ah, thanks for clarifying the relevant part of the repo.


At any rate, we are 13/1401. Not so close then.

[notfood]

Globals are there, but the structures are not. So it would appear to work until crash or corruption.
It will be done when all of these: file on github will be "VERIFIED" IIRC

Didn't the autotool detect some of those? They just need human verification and correction.

From previous experiences, some tools work. More than often, the simple and useful tools are already working. Though it's like playing with fire, corruption is around the corner. But then, so is life when you live as dangerously.

Query/info tools like prospect tend to work fine.

[Max™]

Yeah, I tried to load up df in evan's debugger and poke around in there for structures, but I had to update my video card recently so I took that opportunity to switch to plasma next from the old kde workbase stuff so I'm unstable as shit and edb just kinda laughs at me until I load a different tty and kill it from there.

[Roses]

So modtools/add-syndrome, for lack of a better term, needs some work, I'm just not exactly sure what. First off most syndromes are added correctly, you can give a unit an interaction that it will use correctly, change display name/tile, change attributes, and basically anything that is considered a "Special Effect" on http://dwarffortresswiki.org/index.php/DF2014:Syndrome. But any of the base effects will have do nothing. My brief bit of science that I did found the following.

When applying a syndrome via interaction (which is what I figure we should model add-syndrome after, instead of adding a syndrome via attack). There are several additional components that are not correctly set.

1. None of the target_ vectors are populated in the symptoms list.
2. This leads to no wound being generated.
3. If the target_vectors are artificially populated a wound is automatically created, but it's parts vector is empty
4. Filling in the parts vector seems to correctly "apply" the syndrome. Unfortunately using this method means that out of everything in;

Code: [Select]

[CE_NECROSIS:SEV:100:PROB:100:RESISTABLE:BP:BY_TYPE:THOUGHT:ALL:BP:BY_TYPE:NERVOUS:ALL:START:30:PEAK:60:END:1200]the only thing we can really do is apply necrosis to the correct body parts for the correct times. As you have to populate all the values, and there is no easy way to handle SEV or RESISTABLE.
5. Unfortunatelyx2 in 3 of my 5 tests the game crashed. This may be because I was creating entries by copying another units. I am unsure

I am hoping that someone more knowledgeable about the workings of things can come up with a way to add damaging syndromes via add-syndrome. Otherwise I will move back to just adding wounds directly (this suffers from the same Unfortunately as number 4)

Posting to remind myself later.

After further testing I have found that some of my assumption are incorrect. It appears all you really need to do is populate the target_ fields in unit.syndromes.active[].symptoms[]. The game will then create a wound, link it to the syndrome, and begin to populate the parts of the wound as necessary (filling in correct values of pain, bleeding, etc...). In my custom version this is easily handled by simply looking up the df.global.world.raws.syndrome.all[].ce[].target with BY_TYPE being mode 0, BY_TOKEN being mode 1, and BY_CATEGORY being mode 2 and then determing the creatures body parts and tissues.

So far I haven't had any crashes with adding syndromes like this, although I still need to test what happens if you artificially remove those same syndromes.

[palu]

Do you have any recommended resources for learning lua? I have some programming experience, mostly Javascript, with bits of other languages.

[Putnam]

lua is basically javascript with fewer parentheses, curly brackets and semicolons