Print

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

[Clément]

It may cover the legs for protection but the test is meant for nudity bad thoughts.

By the way, I have doubts about the foot test.

Code: [Select]

    //for shoes, compare how many they're wearing compared to how many legs they've still got
    process_uncovered(SHOES,tr("Feet Uncovered!"),shoes_count,m_unit_health.limb_count());If I understand correctly, socks count as "SHOES" type, so, if a dwarf wears only one sock and one shoe/boot on the same foot and nothing on the other, he would pass the test. But, he would still have a bad thought because of the naked other foot, wouldn't he?

[PatrikLundell]

And he'd also succumb to whatever syndrome inducing stuff he walks into. If you're going to update the logic you may also want to check the hands for the same reason. If you want to go the extra mile, heads should be checked for ettins and hydrae...
While missing legs implies missing feet, isn't it possible to have lost just a foot (or hand), but keep the leg?

I'm taking this opportunity to thank those who picked this tool up when Splinterz left: it's much appreciated.

[Clément]

I am getting too many development branches, I need an upstream to merge them. If no one has objections, I will create a new repo with a github organization (so it is easier to pass on or add maintainers). Is that okay to use Hello71's branch as a base? I see there are several branches based on splinterz's.

[Clément]

Hello71, are you still reading this thread? While trying to merge everything, I discovered that you added some commits since I made my patches based on fd5d9a0. I cannot rebase my patches because db7016a broke the whole repo. You should really be more careful with your commits (and be more descriptive in the commit messages because they are really not helpful either). I was going to create a new upstream repo but I will wait for you tell me your plans for this project before going any further.

[Hello71]

Hello71, are you still reading this thread? While trying to merge everything, I discovered that you added some commits since I made my patches based on fd5d9a0. I cannot rebase my patches because db7016a broke the whole repo. You should really be more careful with your commits (and be more descriptive in the commit messages because they are really not helpful either). I was going to create a new upstream repo but I will wait for you tell me your plans for this project before going any further.

heh, I can hardly bother to actually work on it, you want useful commit messages?

that one I think I did dos2unix on all the files, and some other stuff too. I guess you could do git diff -w if you wanted to merge the other changes manually or something.

edit: I don't have any plans for continuing DT. I think dfhack has most of DT's functions already, or something? (I don't actually play DF)

[Clément]

You are making a lot of changes for someone who can hardly bother to work on it.

I will see what I do when have the time and motivation to deal with that.

[Fleeting Frames]

I don't have any plans for continuing DT. I think dfhack has most of DT's functions already, or something? (I don't actually play DF)

Mostly, but disparate.
 
It has some of the basic functionality in manipulator. Skills, and I think something with squads. Custom professions, sorting by happiness and arrival.

It has preference counts for x preference.

It has autolabor/labor-manager which are bit similar to the labour balancer mechanism (name might be wrong) in DT, though they're dynamic.

It has script to find most common bad thought in fortress.

You can't do things like "enable armorsmithing on all dwarves who don't have a moodable skill and don't have a preference for gauntlets or highboots" or it's weaponsmithing equivalent for a common DT usage example - not in a few clicks and single filter; I think the simplest way you'd have to check the skills of each dwarf manually with manipulator and then checking the preferences for each and then enable said skill for each dwarf that matched after opening two pages about the dwarf and reading the preferences in page-long text.

Or "butcher all poults larger than 1800 cm^3" - there's autobutcher, but it doesn't check body size (no script does), only age, so it'll butcher the smaller poults which will give only nigh-useless skull. You'd have to use gui/gm-editor to navigate 3 submenus and find the body size of a given poult, then give the order for each poult.

Or "enable all medical skills on all dwarves in the fortress who are religious", if you combine hospitals and temples.

Or "assign 9 most suitable unskilled dwarves for being an axedwarf who are not in a squad into your latest squad with experienced commander".

Or "display orientation and age at once" for arranging marriages.

I think manipulator and labor-manager/autolabor and search functions for age and such are only things which do any sorting, in fact.

I surely am forgetting some things, but this is off the top of my head.

[xhumanoid]

Clément, what do think about merge all changes in one repository?

I have some problem with running you branch on osx64 =)
as fix I started refactoring DT from memory patching to use DFHack as backend.

All communication over network in protobuf protocol.
I already implemented connection, load units, animals, basic information about world, etc.

My build it's pretty unstable now, but I think I can fix this problem soon.

Main benefit it's unification DT for work on all platforms without magic with Authorization and requirement admin permissions

[Clément]

Clément, what do think about merge all changes in one repository?

That exactly what I wanted to do, but I was waiting for news from people like you. What branch are you based on? Different branches have been diverging for a while and merging won't be simple.

I have some problem with running you branch on osx64 =)

I don't have OSX, I cannot compile or test it. I only have Linux and Windows, so that was expected, and your help is welcome.

as fix I started refactoring DT from memory patching to use DFHack as backend.

All communication over network in protobuf protocol.
I already implemented connection, load units, animals, basic information about world, etc.

My build it's pretty unstable now, but I think I can fix this problem soon.

Main benefit it's unification DT for work on all platforms without magic with Authorization and requirement admin permissions

Are you adding a new backend or replacing the current one? I perfectly understand the benefits, but there will also be drawbacks: this adds a dependency on DFHack, I personally do use DFHack, but does every DT user do? and we can expect regressions for a while. If it replaces the current method, it would be best to keep it in a separate branch until it works perfectly while taking care to keep it and the main branch as close as possible (i.e. refactoring the main branch to prepare for the switch).

[xhumanoid]

Yes, it's replacement because current model of working DT very depend on direct work with memory.

Main benefits:
1) DFHack add support new version of memory layout more faster then DT
2) DT don't require admin/root permissions for work with DF

It not possible keep current state and simple add new backend,
all classes use QPointer and memory vector for direct read-write in memory
for support both backend in the same time we need for first will do big refactoring and cut working with memory in separate module
but for me it's unnecessary work which will gone in trash soon.

[Clément]

As I said I understand the benefits but I don't think they are worth breaking everything.

1) support for new versions can be added fast enough thanks to the dfhack script for generating DT inis.
2) I don't know about OSX, but on Linux you don't need root permission if you run DT as the parent of DF. But it is annoying as DT cannot be restarted without restarting DF at the same time.

It not possible keep current state and simple add new backend,
all classes use QPointer and memory vector for direct read-write in memory
for support both backend in the same time we need for first will do big refactoring and cut working with memory in separate module
but for me it's unnecessary work which will gone in trash soon.

QPointer are not related to DF memory, VIRTADDR is used for holding pointers to DF memory. But, yes, it is tightly coupled, and I am not fond of this. But since you need to refactor everything anyway, you might as well try to do it properly.

[Rose]

I'm giving my vote for DFHack just because it would mean far less worrying about addresses, etc.

And seeing as how most people who use things like DT get it from newb packs, having DFHack is a given anyway.

[xhumanoid]

2) I don't know about OSX, but on Linux you don't need root permission if you run DT as the parent of DF. But it is annoying as DT cannot be restarted without restarting DF at the same time.

On OSX you must access to attach to separate process for reading memory from them.
Attach possible in 2 cases:
1) you have admin permissions
2) your applications have right access. this means sign key from apple and correctly permissions

solution 2 not possible for us, as result DF always ask login/password on start.
fork, run separate privileged process, stop main process.
debug in this case very difficult

QPointer are not related to DF memory, VIRTADDR is used for holding pointers to DF memory. But, yes, it is tightly coupled, and I am not fond of this. But since you need to refactor everything anyway, you might as well try to do it properly.

Yes, I said incorrect.

1) support for new versions can be added fast enough thanks to the dfhack script for generating DT inis.

looks on this block:

Code: [Select]

[addresses]
fortress_entity=0x019865c4
historical_entities_vector=0x01b41280

[hist_entity_offsets]
histfigs=0x00a8
squads=0x0c60
positions=0x0930
assignments=0x0958
assign_hist_id=0x0004
assign_position_id=0x000c
position_id=0x001c
position_name=0x0068
position_female_name=0x00a0
position_male_name=0x00d8

in this example you have:

Code: [Select]

list<history_figures_ids> = fortress_entity + histfigs
list<squiad_ids> = fortress_entity + squads

list<positions_offsets> = historical_entities_vector + positions

real_position = positions_offsets[index] + position_id

why in one case we have fortress_entity as base address,
but in other case we must use historical_entities_vector
etc

all of this offsets live in one block

DFHack for all of this cases have generated data structures with correctly offsets
without any manual calculation in runtime
this less flexible but much more safe

for most people a try change something in DT it's like magic =)

[Hello71]

I suggest doing it incrementally. First write read_/write_raw that communicates with dfhack, then change the actual manipulations one by one.

Also, I suggested once to write df-structures using real C++ headers. Dunno what came of that, but I think it would make this easier (or not?).

If you have questions about DT's operation, you can ask me in #dwarftherapist on freenode.

[xhumanoid]

I suggest doing it incrementally. First write read_/write_raw that communicates with dfhack, then change the actual manipulations one by one.

Also, I suggested once to write df-structures using real C++ headers. Dunno what came of that, but I think it would make this easier (or not?).

most classes already exist in DT (Dwarf, Squad, Fortress), but they use read-write data in memory by offset with OS-specific implementations.

i want use protobuf as transport protocol, current state of Basic.proto and BasicApi.proto can fill more then 70% оf requirements for DT. But yes, I must do some work for extend this proto (or develop custom plugin for DFHack) for fulfill all requirements.

After that DT don't need know about what version of DF/DFHack running, because we don't now know anything about memory layout, structures and c++ headers.

Current main work it's replace directly work with memory on rpc calls.

after you fix one place and can display something, you must fix another place
(I use DF osx64, DT are not working for me and he simple crash on a try work with memory)
but mostly it's routine work for replacing read-write data one by one