Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 59 60 [61]

Author Topic: [SUGGESTIONS] for DFhack plugins  (Read 84593 times)

Warmist

  • Bay Watcher
  • Master of unfinished jobs
    • View Profile
Re: [SUGGESTIONS] for DFhack plugins
« Reply #900 on: January 04, 2019, 04:43:08 pm »

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

  • Bay Watcher
    • View Profile
Re: [SUGGESTIONS] for DFhack plugins
« Reply #901 on: January 09, 2019, 10:57:30 am »

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.
Logged

falcn

  • Bay Watcher
    • View Profile
Re: [SUGGESTIONS] for DFhack plugins
« Reply #902 on: January 09, 2019, 06:17:39 pm »

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)
« Last Edit: January 11, 2019, 08:28:17 am by falcn »
Logged

falcn

  • Bay Watcher
    • View Profile
Re: [SUGGESTIONS] for DFhack plugins
« Reply #903 on: January 11, 2019, 08:48:30 am »

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.
« Last Edit: January 11, 2019, 01:52:11 pm by falcn »
Logged

FantasticDorf

  • Bay Watcher
    • View Profile
Re: [SUGGESTIONS] for DFhack plugins
« Reply #904 on: January 11, 2019, 11:23:40 am »

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.
Logged

forsaken1111

  • Bay Watcher
    • View Profile
Re: [SUGGESTIONS] for DFhack plugins
« Reply #905 on: January 23, 2019, 01:06:15 pm »

'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.
Logged

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: [SUGGESTIONS] for DFhack plugins
« Reply #906 on: February 03, 2019, 12:25:09 am »

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

  • Bay Watcher
  • In honor of Zutthan Govoslorbam
    • View Profile
    • Twitchin
Re: [SUGGESTIONS] for DFhack plugins
« Reply #907 on: February 04, 2019, 01:54:37 am »

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.
Logged
We honor Zutthan Govoslorbam: "For having one of the most exciting, yet boring lives ever."

Gitlab:   https://gitlab.com/deadeyesisnewb/
Twitch:   https://www.twitch.tv/seyedaed/
Twitter:  https://twitter.com/adwarfslife

Warmist

  • Bay Watcher
  • Master of unfinished jobs
    • View Profile
Re: [SUGGESTIONS] for DFhack plugins
« Reply #908 on: February 04, 2019, 05:08:11 am »

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

  • Bay Watcher
    • View Profile
Re: [SUGGESTIONS] for DFhack plugins
« Reply #909 on: February 04, 2019, 06:44:17 pm »

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.
Logged
bloop_bleep's Moving Fortress Parts Mod!

Quote from: KittyTac
The closest thing Bay12 has to a flamewar is an argument over philosophy that slowly transitioned to an argument about quantum mechanics.
Quote from: thefriendlyhacker
The trick is to only make predictions semi-seriously.  That way, I don't have a 98% failure rate. I have a 98% sarcasm rate.

seyedaed

  • Bay Watcher
  • In honor of Zutthan Govoslorbam
    • View Profile
    • Twitchin
Re: [SUGGESTIONS] for DFhack plugins
« Reply #910 on: February 05, 2019, 12:51:44 am »

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.
« Last Edit: February 05, 2019, 01:23:03 am by seyedaed »
Logged
We honor Zutthan Govoslorbam: "For having one of the most exciting, yet boring lives ever."

Gitlab:   https://gitlab.com/deadeyesisnewb/
Twitch:   https://www.twitch.tv/seyedaed/
Twitter:  https://twitter.com/adwarfslife

seyedaed

  • Bay Watcher
  • In honor of Zutthan Govoslorbam
    • View Profile
    • Twitchin
Re: [SUGGESTIONS] for DFhack plugins
« Reply #911 on: February 05, 2019, 12:52:50 am »

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.
Logged
We honor Zutthan Govoslorbam: "For having one of the most exciting, yet boring lives ever."

Gitlab:   https://gitlab.com/deadeyesisnewb/
Twitch:   https://www.twitch.tv/seyedaed/
Twitter:  https://twitter.com/adwarfslife
Pages: 1 ... 59 60 [61]