Print

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

[lethosor]

Here's r1! https://github.com/DFHack/dfhack/releases/tag/0.42.06-r1
Thanks to everyone who helped test the pre-releases and reported back.

A big thank you to everyone on the team!  A weapon trap with masterwork silver serrated discs and mechanisms for each of your rooms

Ooh, impressive (I normally just use regular mechanisms because I have extra stone lying around and my mechanics don't know what they're doing).

[Dirst]

Does anyone have a handle on determining if a given tile is inside a fort's temple location, and figuring out the Spheres of the power to which it is dedicated (if any)?

[expwnent]

Front post edited.

[Abadrausar]

Here's r1! https://github.com/DFHack/dfhack/releases/tag/0.42.06-r1
Thanks to everyone who helped test the pre-releases and reported back.

Thanks for your team effort!
There are any plans to include support, as a dependency, for Luasocket in DFHACK ? https://github.com/diegonehab/luasocket
Apparently it is all that is needed to use most of lua debuggers out there!  ZeroBrane -> https://studio.zerobrane.com/
It supports windows, linux and OSX platforms, lua versions from 5.1 up to 5.3 and visual studio.

Following this https://github.com/diegonehab/luasocket/blob/master/doc/lua05.ppt presentation in their docs, the total number of lines for the version 2.0 are:

1. 4600 C code
2. 2500 Lua code
3. 4700 man code

With each new DFHACK version more and more external DF utilities use some kind of remote connection with DF to have access to its internal in real time.

The Network support that luasocket brings for the Lua language  https://github.com/diegonehab/luasocket/blob/master/doc/lua05.ppt is object oriented, extensive, standard, documented, tiny (as it does not weigh a lot, as we have seen) and it has interfaces polished over the years.
Should we question what would represent more effort in the long term?
a) Integrating luaSocket once as a dependency and have access to their bug corrections and evolutions.
b) Integrating little by little the regions of functionality that are actually used in DFHACK.

My concern is that if we continue to use the path b) we could lose some corrections or have interfaces slightly differing one of the other for one operation of the same kind, depending of the version of luaSocket taken at the moment of their integration into the DFHACK base, this could be potentially tricky and time consuming for the DFHACK developers, the project will have a reduced functionality (substandard), hardships in the maintenance versus really little reductions in the number of lines integrated into DFHACK...

And we should not forget that the blobs of lines copy-pasted and adapted in a project are maintained as a whole only by this project, however if a project includes another as a dependency and then adds over some adaptations, their responsibility in the maintenance is limited to their own internal adaptation, if they use the interfaces of the depended upon project.

My opinion is that option a) gives more possibilities and requires less developer effort over the long term, but also that it could generate some initial breakage of some utils (specially if some transitory transparent support for the old system is not enabled for a few versions) and worse, it would generate one actual peak of work that maybe no one have the time or interest to do.
There are any other opinions about the convenience or not of opening such an issue in DFHACK?

[Warmist]

<quite good analysis of lua sockets status>

One point missed though. We have almost working lua socket replacement that uses csockets(our socket lib) and is mostly compatible. However I lacked the necessary experience at that time to get it as bug free as possible.
Code is C side and lua part
Also there is already an issue: https://github.com/DFHack/dfhack/issues/420

Oh and generally: you can spam the #dfhack channel in freenode irc and/or open issues on everything. Currently we are not (yet) that big that the issue count would be (pardon the pun) an issue Just try searching before posting.

[Warmist]

1. An Expedition system. <...>

Yes that would be fun. I think i'll make a widget that allows to see the world map in biggest scale (as i think df generates small scale details on the fly so it's quite hard to make small scale maps). From there on you need there is the small part of "causing changes to the world". This would probably require huge amount of code (e.g. adding historic events by hand, figuring out the details for various historical things, etc...)

[Roses]

1. An Expedition system. <...>

Yes that would be fun. I think i'll make a widget that allows to see the world map in biggest scale (as i think df generates small scale details on the fly so it's quite hard to make small scale maps). From there on you need there is the small part of "causing changes to the world". This would probably require huge amount of code (e.g. adding historic events by hand, figuring out the details for various historical things, etc...)

If you could get the world map I could work on the rest. The most basic system I think would just move items around and kill creatures, which are both pretty easy to do. But being able to trigger actual historic events would be awesome. I suppose I should just look at a bunch of previous historic events and see what is there. I wonder if you could even send out expeditions to learn about new animals and tame them.

I'm not sure how DF handles the map generation, I was poking around in df.global.world.world_data but wasn't really able to piece anything coherent together. Several of the tables have values that aren't present when looking at them, but can still be accessed (e.g. ~df.global.world.world_data.region_areas will only print value as an output but numbers work as well) unfortunately some of those that I tried to access caused crashes, so that slowed things down. Luckily you really don't need small details for an expedition system, you would mainly just want if there are any features (caves, fortresses, hfs, etc...) and the general animal population. More specific information, like if a cave has an artifact or megabeast in it, will be stored in the site/feature information and that is pretty easy to access.

[Warmist]

I'm not sure how DF handles the map generation, I was poking around in df.global.world.world_data but wasn't really able to piece anything coherent together. Several of the tables have values that aren't present when looking at them, but can still be accessed (e.g. ~df.global.world.world_data.region_areas will only print value as an output but numbers work as well) unfortunately some of those that I tried to access caused crashes, so that slowed things down. Luckily you really don't need small details for an expedition system, you would mainly just want if there are any features (caves, fortresses, hfs, etc...) and the general animal population. More specific information, like if a cave has an artifact or megabeast in it, will be stored in the site/feature information and that is pretty easy to access.

I've currently had an irc chat with ragundo just about this last 6 month work in this theme. You can see it here: his pull request so he could be an expert in that regard.

[Roses]

I've currently had an irc chat with ragundo just about this last 6 month work in this theme. You can see it here: his pull request so he could be an expert in that regard.

Interesting, I will give that a look.


And as per the multistory buildings topic, I present you with a floating building


By changing the tile designation of the tile to that of a floor I built a building using dfhack.buildings.allocInstance and then placed it on said floor. Two seasons later and it is still floating there, so it is definitely possible to do multistory buildings. The only issue I could see would be deconstruction. If you take out the bottom level it's going to need to deconstruct the top levels and return it to open space, but that can all be done. So, as soon as I can get back into DF I will provide a utility for constructing multistory buildings.

EDIT: Hmmm, I may have spoken too soon. After a year the structure collapsed. More testing is needed. But I still think something should be possible.

[Warmist]

I think building in same 16x16 block might trigger to df do the collapse logic and this would fall down. However i'm not sure...

[baldamundo]

Hopefully not. Some crashes in 0.42 have been attributed to TwbT, so try disabling that first and see if it helps. Otherwise, it would help if you could test without DFHack entirely and see if it's reproducible.

Cheers - turned of TWBT and it's been working fine since. And made me discover Truetype mode which is actually amazing (tbf probably the one weakness of Ironhand is the fonts)!

[kane_t]

As far as I can tell, none of the plugins or scripts or the Lua API directly allow moving items from units' or buildings' inventories to the ground.  But, it should be possible, right?  Just set the item's position, remove the references to it being in the inventory, and set the appropriate flags.  Is there a reason why this isn't done in any of the existing scripts and plugins, like for autodump and cleanowned?

(I'm trying to get back some clothing items that a dwarf annoyingly claimed and put on, and don't want to wait for however long it takes them to get dumped after I clear the ownership flags and set them for dumping)

[Putnam]

As far as I can tell, none of the plugins or scripts or the Lua API directly allow moving items from units' or buildings' inventories to the ground.

dfhack.items.moveToGround(item,pos)

[kane_t]

dfhack.items.moveToGround(item,pos)

When I try that, it consistently returns "false."  It only fails for items that are in inventories, though.  I could probably manually delete all the inventory references and then try moveToGround(), but I'm assuming there must be some reason it doesn't do that itself.

[lethosor]

There are a number of cases where it will refuse to move items, including that. I don't know if there are specific reasons behind all of those cases, or if it was just too much effort to make it handle everything properly.

(The relevant function that moveToGround() calls out to is detachItem() in library/modules/Items.cpp, if you want to take a look.)