Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 177 178 [179] 180 181 ... 242

Author Topic: DFHack 50.11-r6  (Read 795440 times)

Uthimienure

  • Bay Watcher
  • O frabjous day!!
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2670 on: October 30, 2020, 08:59:30 pm »

Is it just me, or is dwarfvet not working properly?

I've followed the instructions below. In DFHack "dwarfvet enable" works, and "dwarfvet report" shows an animal hospital at the correct location, which is accessible to all the injured animals.  DFHack lists them all "Telling intelligent unit 17843 (etc.) to report to the hospital".  They wander around looking for it and I get spammed repeatedly:  "(animal) cancels Rest: Area inaccessible."
Spoiler (click to show/hide)
Logged
"I've never really had issues with the old DF interface (I mean, I loved even 'umkh'!)" ... brewer bob
As we say in France: "ah, l'amour toujours l'amour"... François D.

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2671 on: October 30, 2020, 10:23:45 pm »

That sounds to me like this issue, which was reported recently: https://github.com/DFHack/dfhack/issues/1681
Unless that's you under a different name, it's not just you having the issue, although I'm not aware of any further attempts at diagnosing/fixing it at this point.
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.

Nilsolm

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2672 on: October 31, 2020, 09:16:03 am »

Is it just me, or is dwarfvet not working properly?

I've followed the instructions below. In DFHack "dwarfvet enable" works, and "dwarfvet report" shows an animal hospital at the correct location, which is accessible to all the injured animals.  DFHack lists them all "Telling intelligent unit 17843 (etc.) to report to the hospital".  They wander around looking for it and I get spammed repeatedly:  "(animal) cancels Rest: Area inaccessible."
Spoiler (click to show/hide)

Strangely enough, I can't reproduce the issue with DFHack 0.47.04-r3. Animals seem to be able to path to the hospital area just fine. Can you upload a save file maybe? I can have a look at it.
Logged

Uthimienure

  • Bay Watcher
  • O frabjous day!!
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2673 on: October 31, 2020, 11:14:57 am »

That sounds to me like this issue, which was reported recently: https://github.com/DFHack/dfhack/issues/1681
Unless that's you under a different name, it's not just you having the issue, although I'm not aware of any further attempts at diagnosing/fixing it at this point.

That's not me, but it sounds exactly like what's happening.
BTW I'm on DF 0.47.04 with Hack 0.47.04-r1-Windows-64bit

Quote
Nilsolm:
Strangely enough, I can't reproduce the issue with DFHack 0.47.04-r3. Animals seem to be able to path to the hospital area just fine. Can you upload a save file maybe? I can have a look at it.

Thanks! Here's the save:
https://dffd.bay12games.com/file.php?id=15281
Logged
"I've never really had issues with the old DF interface (I mean, I loved even 'umkh'!)" ... brewer bob
As we say in France: "ah, l'amour toujours l'amour"... François D.

Nilsolm

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2674 on: October 31, 2020, 03:30:23 pm »


Quote
Nilsolm:
Strangely enough, I can't reproduce the issue with DFHack 0.47.04-r3. Animals seem to be able to path to the hospital area just fine. Can you upload a save file maybe? I can have a look at it.

Thanks! Here's the save:
https://dffd.bay12games.com/file.php?id=15281

Cheers, I had a look, but I can't reproduce it with your save either. I can slap down an animal hospital zone anywhere and animals will be able to path to it. You mentioned that you're using  DFHack 0.47.04-r1. You could try upgrading to 0.47.04-r3, because the problem doesn't seem to occur with that version.

I am running into other problems though:
  • Game crashes during clean patient job (#1417)
  • I am also getting crashes sometimes when an animal enters the hospital zone. Not sure of the exact reason for this though.
  • Animals sometimes don't seem to stay put in the hospital zone. They rest for a few ticks, then get back up and walk off again before being sent back to the zone by dwarfvet. This sometimes interrupts the diagnose patient job.
I'll try to debug these issues once I get access to a functioning Linux system.
Logged

Uthimienure

  • Bay Watcher
  • O frabjous day!!
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2675 on: October 31, 2020, 05:05:10 pm »

Thanks for taking the time to do that.  Yes, I debated upgrading to 0.47.04-r2 and then r3 when they were released but I'm afraid of messing things up and decided to wait until I start a new fort because this one has been one of my most fun forts.  This animal hospital problem isn't a game killer so I'm alright.
Logged
"I've never really had issues with the old DF interface (I mean, I loved even 'umkh'!)" ... brewer bob
As we say in France: "ah, l'amour toujours l'amour"... François D.

Rinin_Rus

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2676 on: October 31, 2020, 05:45:54 pm »

What should I do to prepare a dwarf before sending him to burrow to avoid being stuck with previous activity?

Right now I'm doing only
Code: [Select]
dfhack.job.removeWorker(unit.job.current_job, 1)But it seems it's not enough, because I already had dwarfs stuck "socialising", and plant gatherers can't finish the task because "dropoff inaccessible" inside burrow. It also probably not gonna work with different noble interactions.
Could I do something like:
Code: [Select]
unit.military.individual_drills = {}
unit.social_activities = {}
unit.conversations = {}
unit.activities = {}
And if I could, should I? What pitfalls may arise from it?
Logged
He has a lot of willpower,  but he has very little linguistic ability

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2677 on: November 01, 2020, 04:52:06 am »

What should I do to prepare a dwarf before sending him to burrow to avoid being stuck with previous activity?

Right now I'm doing only
Code: [Select]
dfhack.job.removeWorker(unit.job.current_job, 1)But it seems it's not enough, because I already had dwarfs stuck "socialising", and plant gatherers can't finish the task because "dropoff inaccessible" inside burrow. It also probably not gonna work with different noble interactions.
Could I do something like:
Code: [Select]
unit.military.individual_drills = {}
unit.social_activities = {}
unit.conversations = {}
unit.activities = {}
And if I could, should I? What pitfalls may arise from it?

- Any dorf in the process of delivering something to a stockpile will probably have to be relieved of the object hauled.
- Based on my burrowing experience, forcibly cutting off needs activities is unlikely to be successful, as I've had dorfs take up socializing after they were burrowed: it seems there is no check that the "work target" is within the burrow if the dorf is in the tavern when the job check is performed. I'm not sure about this, but I think I've see dorfs being burrowed when outside of the tavern walk to the tavern and then start socializing.
- In my view "individual drill" is a stupid thing that shouldn't be in DF, as it almost totally negates the effect of giving militia time off, as they'll spend almost all their time on drills rather than catching up on civilian jobs and fulfilling needs. I work around it by manually removing the training facilities from squads when they're taken off duty and adding them back they they're sent on duty. Of course, that means that the schedule has to be managed manually, so setting up a long term schedule becomes pointless.

The best way to block need fulfillment "jobs" to be taken illegally is probably to ensure there is a "proper" job available in the burrow (such as e.g. a lever pull for a lever with that particular dorf as the only permitted user). You still have the issue with uninterruptible needs fulfillment, but I'd hesitate to try to override that.

Side effects? Who knows? Those who try to hack it are those who will find out.
Logged

Rinin_Rus

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2678 on: November 01, 2020, 09:38:49 am »

Quote
- Any dorf in the process of delivering something to a stockpile will probably have to be relieved of the object hauled.
Seems so, but I'm still can't find how to do so, using dfhack.

Quote
as I've had dorfs take up socializing after they were burrowed:
Did they start socializing before or after burrow assignment? Because I had the same issue, but they probably started before assignment, and even the destruction of the guild hall didn't stop them from socialising in it's former location.

Quote
The best way to block need fulfillment "jobs" to be taken illegally is probably to ensure there is a "proper" job available in the burrow (such as e.g. a lever pull for a lever with that particular dorf as the only permitted user). You still have the issue with uninterruptible needs fulfillment, but I'd hesitate to try to override that.
That's exactly opposite of what I'm doing now. Basically I want to move dwarfs to burrows based on their needs, so they have no other jobs to do till they are finished fulfiling their needs. If someone is interested script could be found here
Logged
He has a lot of willpower,  but he has very little linguistic ability

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2679 on: November 01, 2020, 01:52:32 pm »

I have no idea if it's useful, but it's possible to use DFHack to change the location of an item (to the ground beneath the character, and to remove the connection of the item being in the inventory of the dorf from both.

The experience I had was that they took up socializing after being interrupted from their previous task by the burrowing.

Yes, you want them to get to the burrow to socialize, procreate, etc., but a "proper" job task will help you to actually get the buggers to haul their sorry asses there. Note, though the they have a tendency to escape the burrow because the perform the job, then walk away for 10 steps or so before checking what to do next. The "walk away" thing does not respect burrows, and so can easily take the bugger out of it. Once outside, the won't go back inside unless given a "job" there, and if they don't feel the need to socialize/eat/drink/sleep/... they just root themselves on the spot until the eventually do feel a need.
Logged

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2680 on: November 09, 2020, 10:11:42 pm »

A heads-up: I'm planning to do another release soon (maybe in a week? real life things have caught up to me and delayed this a bit)

It would be great to have people test it out beforehand - there are lots of buildingplan and quickfort changes, thanks to Myk. I'm reasonably confident that they work, but more eyes on it would always be appreciated. As usual:
- Nightly builds can be found at https://dfhack.org/builds
- Issues can be reported here or at https://github.com/dfhack/dfhack/issues - if you're using a nightly build, please include the exact version number (as reported by the console, e.g. "0.47.04-r3-92-g3aa902bd") or build number
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.

Rumrusher

  • Bay Watcher
  • current project : searching...
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2681 on: November 11, 2020, 06:17:33 am »

ok just now notice my copy of advfort isn't working with buildings and just realize it's because someone changed the module stuff to be a dfhack_flag. check in advfort_items.
odd time to realize there been a revamp to the code structure but I hope I don't have to like edit some important dfhack file to connect a different script to advfort_items, or dummy out that line of code in advfort_item?
edit: it seems the 'require' code got changed to reqscripts .... so I dread if I have to rewrite a whole bunch of my scripts or just the scripts that touch dfhack stuff.
« Last Edit: November 11, 2020, 06:59:36 am by Rumrusher »
Logged
I thought I would I had never hear my daughter's escapades from some boy...
DAMN YOU RUMRUSHER!!!!!!!!
"body swapping and YOU!"
Adventure in baby making!Adv Homes

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2682 on: November 11, 2020, 01:03:59 pm »

ok just now notice my copy of advfort isn't working with buildings and just realize it's because someone changed the module stuff to be a dfhack_flag. check in advfort_items.
odd time to realize there been a revamp to the code structure but I hope I don't have to like edit some important dfhack file to connect a different script to advfort_items, or dummy out that line of code in advfort_item?
edit: it seems the 'require' code got changed to reqscripts .... so I dread if I have to rewrite a whole bunch of my scripts or just the scripts that touch dfhack stuff.

Could you clarify exactly what is broken? Is advfort.lua in the DFHack repository not working, or is this your own copy? If it's your own, is there any particular reason you're maintaining your own copy? Are there changes that you would like included in DFHack's version?

I did change how advfort_items needs to be imported in https://github.com/DFHack/scripts/commit/ad67c79f8074a491c144144b2825cd05c80a2236 - it was previously the only script in the scripts repo to use mkmodule() and work with require(), so I changed it for consistency. This did also require changing the require() calls in two places in advfort.lua (see the diff for exactly what changed) - those should be all that you need to change on your end, unless you've added more. advfort_items should still be able to be used in exactly the same way, but let me know if there are other issues.

Edit: oh, I think you might have figured it out already. The recommended way to share functions/etc. between scripts is to use reqscript() or script_environment() along with a module check - see the diff above for examples. There is no hard requirement to do it this way for scripts outside of the DFHack/scripts repo, and advfort is the only one I know of that changed recently.
« Last Edit: November 11, 2020, 01:07:07 pm 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.

Rumrusher

  • Bay Watcher
  • current project : searching...
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2683 on: November 13, 2020, 09:41:05 am »

ok just now notice my copy of advfort isn't working with buildings and just realize it's because someone changed the module stuff to be a dfhack_flag. check in advfort_items.
odd time to realize there been a revamp to the code structure but I hope I don't have to like edit some important dfhack file to connect a different script to advfort_items, or dummy out that line of code in advfort_item?
edit: it seems the 'require' code got changed to reqscripts .... so I dread if I have to rewrite a whole bunch of my scripts or just the scripts that touch dfhack stuff.

Could you clarify exactly what is broken? Is advfort.lua in the DFHack repository not working, or is this your own copy? If it's your own, is there any particular reason you're maintaining your own copy? Are there changes that you would like included in DFHack's version?

I did change how advfort_items needs to be imported in https://github.com/DFHack/scripts/commit/ad67c79f8074a491c144144b2825cd05c80a2236 - it was previously the only script in the scripts repo to use mkmodule() and work with require(), so I changed it for consistency. This did also require changing the require() calls in two places in advfort.lua (see the diff for exactly what changed) - those should be all that you need to change on your end, unless you've added more. advfort_items should still be able to be used in exactly the same way, but let me know if there are other issues.

Edit: oh, I think you might have figured it out already. The recommended way to share functions/etc. between scripts is to use reqscript() or script_environment() along with a module check - see the diff above for examples. There is no hard requirement to do it this way for scripts outside of the DFHack/scripts repo, and advfort is the only one I know of that changed recently.
the thing that got me confused was the module check otherwise thanks for the clear up.
to answer the question about having a copy of advfort... it's so I could do modifications and add fort mode jobs and or see if I could add more fort mode jobs... which now that I remember this I might have to change and patch my companionfort scripts as they were old copies of advfort that used that old set up to connect to advfort_items.
Logged
I thought I would I had never hear my daughter's escapades from some boy...
DAMN YOU RUMRUSHER!!!!!!!!
"body swapping and YOU!"
Adventure in baby making!Adv Homes

Evans

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2684 on: November 14, 2020, 07:11:43 pm »

timestream.lua

In new version you have removed the ability to slow down calendar speed.

Why?


I was using timestream exclusively for this reason, because I hate how one day takes 14 seconds in vanilla.
Would you kindly reconsider adding ability to slow down time back in?
Logged
getlost.lua # How to get rid of tavern guests
function getlost ()
   local unit = dfhack.gui.getSelectedUnit (true)
   unit.flags1.forest = true
end
getlost ()
Pages: 1 ... 177 178 [179] 180 181 ... 242