Print

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

[Warmist]

Re: machine connections.

Warmist, have you previously tried interposing canConnectToMachine() in this way?

1. If *this is a tracked machine component, then use the normal routine in determining whether it should be connected, already present in your code.
2. Otherwise:
2.1. For every tile in the machine:
2.1.1. If the tile contains the tracked machine component "other", then call other->canConnectToMachine() passing a df::machine_tile_set containing only *this's position.
2.1.2. If the call returns true, then return true.
2.2. Return the result of INTERPOSE_NEXT (assuming the function hasn't returned already in the for loop).

If you haven't, I could probably test it out myself.

I don't remember clearly but the issue is that this function is not called at all because df thinks this machine "can not be connected at all" or something like that. And if you look into disassembly of the  machine manager (IIRC) it had switch statement with all supported machines in there hardcoded. You could maybe change it's type to one of those for placement maybe...
Anyway i'm too "out-of-it" to help. Sorry . Would love for it to be fixed as it is still annoying me...

[falcn]

I have a few suggestions for scripts/plugins.

1) similar to other auto-x scripts, a script that would assign a set labor to a dwarf who wants to craft something, and disable the labor as soon as he got a happy thought out of it. Currently, it's a micromanagement nightmare. The idea is that player will set up a dedicated workshop with a recurring task limited to dwarves with a level 0-1 skill before enabling the plugin.
2) a script that allows zooming to holdings of a dwarf from a "z" screen with a new keybind. Could be a modification to /gui/room-list which currently can be called for a room that is owned by a citizen, but not for a unit. Currently, it can be done by pressing R and filtering out the list of rooms by the name of the dwarf.
3) plugin that outputs a custom game log with extended information for combat messages to make them on par with in-game reports.
 - who is hitting who (like the red/blue in df combat reports)
 - is it a sparring or combat
 - and maybe a name, since reports have this information, but game log doesn't
The idea is that SoundSense, AnnouncementWindow, DF Log and maybe some utilities that does not exist yet can make use of this information to fine tune sound, color-code combat log, filter out sparring, keep track of wounds etc.
Utilities must be updated to make use of this new information. DF log is closed source but fairly new, AW and SS are not actively maintained but open source, and most of the work could be done by updating external regex files / adding new sounds. Currently, it could be done with guesstimating what's going on with regexes, but it interferes with non-dwarf citizens, dwarf civ sieges, and any hostile dwarves in general.

[falcn]

2) a script that allows zooming to holdings of a dwarf from a "z" screen with a new keybind. Could be a modification to /gui/room-list which currently can be called for a room that is owned by a citizen, but not for a unit. Currently, it can be done by pressing R and filtering out the list of rooms by the name of the dwarf.

I changed a few lines in room-list, it seems to be working now.

Code: [Select]

keybinding add Alt-R@dwarfmode/ViewUnits "gui/room"
save it as a gui/room.lua, so you don't lose access to original room-list (although modified script seems to be working just fine for both modes - when called on a building 'q' and when called on a unit from 'v')
https://pastebin.com/c1qJ3B30
It's not working from 'z' and it exits with a wrong view mode, but it still solves the problem of quickly going to a room of unhappy dwarf without typing his name (which sometimes has non-english characters)

[falcn]

1) similar to other auto-x scripts, a script that would assign a set labor to a dwarf who wants to craft something, and disable the labor as soon as he got a happy thought out of it. Currently, it's a micromanagement nightmare. The idea is that player will set up a dedicated workshop with a recurring task limited to dwarves with a level 0-1 skill before enabling the plugin.

Autolabor can be modified to monitor and auto-satisfy substantial part of needs, if player would dedicate special zones and workshops just for needs.
Is it cheating? Dwarves with less unmet needs are more happy, basically making tantrum spiral less likely and removing substantial part of gameplay that connected to it. If it's done by a script, it's basically a happiness boost for free.

[FantasticDorf]

Autolabor can be modified to monitor and auto-satisfy substantial part of needs, if the player set up zones and workshops accordingly.
Is it cheating? Dwarves with less unmet needs are more happy, basically making tantrum spiral less likely and removing substantial part of gameplay that connected to it. If it's done by a script, it's basically a happiness boost for free.

Messing with any of the game is cheating, but its merely compensating for it not being fully rounded by itself with the contribution of a third party tool/s. Some of them are otherswise actually unobtainable, as are some lifetime wishes like 'see the great natural sites' that can't be fufilled whilst in fortress mode for a individual.

[forsaken1111]

'cheating' is meaningless in a singleplayer game anyway, everyone plays the way they want to play. No one should tell someone else that they are playing incorrectly. Do what you like, have fun with your game.

[Putnam]

Many would say autolabor is cheating to begin with, so I don't think adding another anti-micro feature to it and labormanager is much of a problem.

[seyedaed]

Hi everyone,

Thanks for all your hard work and dedication on making these mods and apps.  I can't express how awesome it has been using them over the years.

Anyway, I have a thought for a plugin but not sure if it is already possible or makes much sense.  I'm still learning and new to a lot of this.   However, I think it would be great if there was plugin that could allow lua scripts to easily be run in separate threads. 

To my understanding, right now when a lua script runs, it runs on the same thread that the main game runs. The issue though is that if there is a really heavy lua script running it can cause delays in the game FPS.

I understand there are reasons that running things on the same thread are ideal, but I think there are some things that might not be as dependent on the main game thread and some modders could take advantage of this. Some of the scripts I've been playing around with tend to be really heavy and I do notice they can cause an FPS hit. 

I know I do have a lot of work to do on optimizing things though.  I was originally thinking of just offloading some of the work using the socket connectors to other programs or going a C++ route, but then I'm afraid I'll lose a lot of data/functions/convenience that the dfhack lua api provides and have to rewrite a lot of stuff in the other app.

Anyway, thanks again for everything.

[Warmist]

Hi everyone,
 <... threading, lua, performance...>

The age old problem: you think something is slow. Solution: never theorize always profile!

AFAIK: the slow part is accessing a lot of data and/or accessing data that is scattered. This is not lua performance issue. We could read from other thread but then it would probably corrupt the data in process. Also if lua was slow part we could move to luajit with INSANE speed gains.

That out of the way there is already at least 2 threads and you can use more if you want to. The two threads are DF and the console. However if you used it e.g. during world gen you can see how it hangs until DF does reaches a point where it updates the view. So if you want to you can use however many threads you want but only in C++ plugins and usually plugins that do a lot of work are written in that way.

TL;DR: threads are complicated. Stuff is slow because it reads/writes a lot of memory, not because computation.

[bloop_bleep]

Plus, if your separate thread modifies game memory at all, then you’d either need a mutex for the entire DF core, nullifying all the performance bonuses you get from multithreading, or need many mutexes for different parts of DF memory, which would be difficult to set up and difficult to make consistent across many plugins by many authors.

[seyedaed]

Hi everyone,
 <... threading, lua, performance...>

The age old problem: you think something is slow. Solution: never theorize always profile!

AFAIK: the slow part is accessing a lot of data and/or accessing data that is scattered. This is not lua performance issue. We could read from other thread but then it would probably corrupt the data in process. Also if lua was slow part we could move to luajit with INSANE speed gains.

That out of the way there is already at least 2 threads and you can use more if you want to. The two threads are DF and the console. However if you used it e.g. during world gen you can see how it hangs until DF does reaches a point where it updates the view. So if you want to you can use however many threads you want but only in C++ plugins and usually plugins that do a lot of work are written in that way.

TL;DR: threads are complicated. Stuff is slow because it reads/writes a lot of memory, not because computation.

Thank you so much for the feedback. I do appreciate it.  It definitely helps me understand the issue better.

I want to explain the issue I'm having a little more and maybe you or others might have other ideas on how I can approach this problem.

I've been experimenting with visualizing different parts of the game map while the game is actively running. I know that others have done this using sockets or custom C++ plugins to external apps.  The approach I took, mainly because of my lack of knowledge on dfhack with C++, was to cycle through the lua data and then use a socket to send the data to an external app.  This works ok, but the more I add to the lua script or frequently I run it, the more the FPS take a hit. This is especially an issue if I'm using other mod scripts I wrote.

I had an idea of what some of the issue could be and you helped clarify things better. I do thank you for helping me understand why the memory reads/writes are probably a bigger issue than the processing.  I don't know enough about this, but I had thought that the process to process memory access would cause more lag than the process to thread transfer. Any more advice on this would be appreciated.

However, because of the need to wait for other processes to complete, I originally thought threading could help. Especially in cases when running multiple mod scripts and those that aren't that memory heavy and that could improve the user experience by completing more timely.

To my knowledge I have a couple of options. 

1.  I could just send more of the data to an external app and let it handle more of the processing rather than relying on the dfhack lua. Doing so could allow the code to run by taking advantage of other processing cores.  I understand the lag from memory reads will still be there but some processing can occur during the memory/read write times.  However, doing so would require a lot of rewriting code and functions that already exist in dfhack LUA API.

2.  I could write a C++ plugin that could thread and handle the visualization data.  I might be able to use code from others to handle some of the functions.  However, I feel that I would be relying too much on my own coding ability to try to handle the table data that LUA already is optimized for. 

3.  Optimize my code (any other ideas are appreciated).

I know threads are a real pain to work with and can cause all kinds of craziness.  For me, it was the first way I could think of that could potentially help the issue and I thought maybe a plugin or something could help. 

Thanks again for the feedback though and I don't mean to bother everyone with this .  I know there are probably other workarounds, I'm not considering and I have a lot to learn, but I hope at the very least, it can help me and others that might be experiencing similar things gain additional insight or maybe someone else would come up with other solutions.

[seyedaed]

Plus, if your separate thread modifies game memory at all, then you’d either need a mutex for the entire DF core, nullifying all the performance bonuses you get from multithreading, or need many mutexes for different parts of DF memory, which would be difficult to set up and difficult to make consistent across many plugins by many authors.

Thank you for sharing this.  It definitely helps me make more sense of things.

[FantasticDorf]

Pity to see this thread fall into disuse, time to kick it back into life before the turn of the next month.
I have a request:

Baby yarn animals cannot be sheared which ends up in difficult situations where you have to slaughter strays or have dwarves go insane over other people's pets if they're the sole animal type of the specific yarn in the fort, could a script be comprised to force the job or simply set llama wool back to 0, and drop a clump of fur beneath them?

It would be super if the script was malleable to determine force-yarn-drop amounts to distinguish creature types or read the current hair level for a appropriate cue. It probably shouldnt matter whether the animal is owned, dead or alive just as a debug tool (for fun dead-troll fur harvesting on the side).

I have a related issue report regarding it.

[PatrikLundell]

If I recall correctly, there's a field somewhere in the creatures that determines the length of the hair or something like that. This field, or set of fields, could presumably be hacked to the value for full shearing length, after which normal shearing ought to be possible.

I forbid some of each kind of cloth in my fortresses to ensure I've got some on hand when moods strike (and I do the same with metal bars and leather). In addition to that, I bring sheep on embark exactly to make sure I've got a wool supply (3 males and 3 females almost always result in a reproductive population since the "unwilling to marry" animal bug was squashed), and I similarly bring silk thread on embark to tide me over until I start to harvest silk from the caverns. I also bring some metal bars, for the same reason.

I fail to see the connection between shearing and slaughter. While slaughtering an animal that has shearable wool does provide wool as well, shearing doesn't harm the animal, and I presume my dorfs shear the wool producing pets migrants brought to the fortress when I order my yearly wool shearing repeat action. Relying on chance to provide the fortress with wool also means relying on chance when it comes to the ability to not fail moods (on top of the shells you can't secure when embarking).

Butchering trolls, if you've hacked that in, ought to produce wool (I've never tried). If you want to decouple the product from its source, I don't see why you wouldn't just spawn it instead of going through some hacky middle route.

[FantasticDorf]

I fail to see the connection between shearing and slaughter. While slaughtering an animal that has shearable wool does provide wool as well, shearing doesn't harm the animal, and I presume my dorfs shear the wool producing pets migrants brought to the fortress when I order my yearly wool shearing repeat action. Relying on chance to provide the fortress with wool also means relying on chance when it comes to the ability to not fail moods (on top of the shells you can't secure when embarking).

Politely, i wasn't asking for gameplay advice to subvert suggesting this script. Its the sensible workaround to the bug in that children don't have anything different to adults other than size and behaviour (bearded babies etc) and therefore buildup yarn if they've lived for a while. But the way things are it'd be a nice band aid to when you're caught short on immediate notice like the circumstances of the report.

The wool from the stray child llama (if there is one that isnt a slaughter exempt pet being targeted in which this script is utmost nessecary for shearing adopted child pets) is clumped up in the butcher-shop when the slaughter designation is done, which is a needlessly violent solution. The long hair of a baby llama etc and other yarn animals is visible when you directly read their descriptions.

Butchering trolls, if you've hacked that in, ought to produce wool (I've never tried). If you want to decouple the product from its source, I don't see why you wouldn't just spawn it instead of going through some hacky middle route.

Doable with dead_dwarf_false scripts like sentientbutcher.lua, but the manner in which im suggesting the script can imply DFhack remotely does the shearing, if i wanted to keep a troll alive then by means of workshop local scripts or direct-cursor clicking, constantly shaving the wild or enemy POW troll when it's due without ever touching it directly.

That's one creative use i can see in the demand for this script suggestion.