Print

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

[A_Curious_Cat]

I will investigate if I'm able to do so only when DF becomes playable, i.e. keyboard support is returned. That doesn't stop mouse tolerant people to take up the task earlier, as this is part of DFHack.

I can mention two things here:
- The biome determination logic was changed prior to the Premium release, so some biome determinations were incorrect. The underlying logic could use an update, although it's no longer part of this plugin itself. The differences were not huge, but present.
- I've noticed that mousing around pre embark causes mid level tiles to get loaded, so once you can order the cursor to move with keyboard input again you should be able to load all of this info into memory before performing any processing, thus removing issues with having to cache information and processing the data in two passes. It can be noted that the information is loaded unordered, but that can be handled e.g. with an intermediate coordinate translation matrix.

Any chance of anyone who knows Lua and isn’t mouse-adverse updating embark-assistant for 50.x?  Also, I searched DFHack/scripts on GitHub for the embark-assistant script but couldn’t find it…

[myk]

It's a c++ plugin, though it's possible it could be rewritten in Lua. Source code is here: https://github.com/DFHack/dfhack/tree/develop/plugins/embark-assistant

Note that it's an entire directory of files, not just one.

[A_Curious_Cat]

Interesting.  I thought it was in Lua.  I was asking about other people who knew Lua because I don’t know it and I’m currently learning C++ (and learning two programming languages at once is a bad idea…).  Anyways, I took a look at embark-assistant.cpp, and it’s chock  full of stuff I haven’t learned about yet (although, I have noticed that it uses ‘#pragma once’ in the header files, which the site I’m learning from recommends against as it makes the program non-portable, recommending a “header guard” using #ifdef, #define, and #endif instead).

[joostheger]

You can also list them in-game. For example, open gui/launcher and run:

Code: [Select]

:lua @df.unit_labor

thanks! exaclty what i needed

[PatrikLundell]

The reason embark-assistant is written in code rather than as a script is performance. My prototype was written in Lua, but as I expected from the start, the performance was completely unacceptable. It's was slow enough when compiled (although the majority of the time in the compiled code was spent loading DF data structures done by DF itself: I don't know how the current, changed, data loading logic of DF will affect this).

[myk]

I've been collecting thoughts on how embark-assistant can be updated here: https://github.com/DFHack/dfhack/issues/3327

tl;dr we might be able to hook into the new vanilla site search interface and algorithm to extend it rather than replace it.

[lethosor]

Interesting.  I thought it was in Lua.  I was asking about other people who knew Lua because I don’t know it and I’m currently learning C++ (and learning two programming languages at once is a bad idea…).  Anyways, I took a look at embark-assistant.cpp, and it’s chock  full of stuff I haven’t learned about yet (although, I have noticed that it uses ‘#pragma once’ in the header files, which the site I’m learning from recommends against as it makes the program non-portable, recommending a “header guard” using #ifdef, #define, and #endif instead).

We use "#pragma once" because it's portable enough for our purposes. All compilers we use support it, and we are limited to those specific compilers because DF uses them. it has a couple advantages over header guards - it's harder to make mistakes (e.g. by forgetting one of the three lines a header guard requires), and it's guaranteed to avoid name conflicts with header guards using the same name.

[A_Curious_Cat]

Interesting.  I thought it was in Lua.  I was asking about other people who knew Lua because I don’t know it and I’m currently learning C++ (and learning two programming languages at once is a bad idea…).  Anyways, I took a look at embark-assistant.cpp, and it’s chock  full of stuff I haven’t learned about yet (although, I have noticed that it uses ‘#pragma once’ in the header files, which the site I’m learning from recommends against as it makes the program non-portable, recommending a “header guard” using #ifdef, #define, and #endif instead).

We use "#pragma once" because it's portable enough for our purposes. All compilers we use support it, and we are limited to those specific compilers because DF uses them. it has a couple advantages over header guards - it's harder to make mistakes (e.g. by forgetting one of the three lines a header guard requires), and it's guaranteed to avoid name conflicts with header guards using the same name.

Interesting.  I guess that makes sense.

Also, out of curiosity, what are the compilers that DFHack uses?

[myk]

Currently, we compile with latest MSVC on Windows and GCC 10 on Linux. We also run additional tests with GCC 12.

[joostheger]

Is there a script to elevate a fortress, or to trigger elevation in some way?

[Roses]

I've got to say, I am very impressed with the amount of work that seems to have gone into the many many changes since I was last active. I have been spending a lot of time reading the documentation and looking through examples and it has been very exciting. I am sure I am going to have more and more questions as I read more, but the following are some of the first questions that have come to my mind.

List of Questions:

• Custom tokens - I see that custom tokens are now supported by DFHack, which is very nice. I had previously done this using curly brackets and parsing the raws when the game was started (see examples below). Looking through the custom-raw-tokens.lua code it seem that multi-line tokens aren't a thing though, is this correct? No problem if it is, I can just change my stuff to be a single line(s) as needed.

Code: [Select]

[ITEM_SHIELD:ITEM_SHIELD_EXAMPLE]
[NAME:Example Shield]
{DESCRIPTION:Knocks enemy backwards half the time when you block}
... DF Item Stuff ...
{ON_BLOCK}
{SCRIPT:unit/propel -unit OPPONENT -source BLOCKER -velocity [ 50 50 0 ] -mode Relative:50}

[ITEM_WEAPON:RAPID_FIRE_CROSSBOW]
[NAME:Fast Shooting Crossbow]
{DESCRIPTION:Shoots bolts very fast}
... DF Item Stuff ...
{FIRE_RATE:10:2:1} -- Base fire rate is 10, increases by 2 for each skill level, max shot speed is 1

[ITEM_WEAPON:BLOOD_SWORD]
[NAME:Blood Sword]
{DESCRIPTION:Drains blood from opponent when wounded}
... DF Item Stuff ...
{ON_WOUND}
{SCRIPT:unit/change-body -unit OPPONENT -blood \-10:100}
{SCRIPT:unit/change-body -unit HOLDER -blood 10:100}


• Mod paths and installation - This seems like its a fairly large change. We used to just drop stuff in the "raws" folder or put them in the hack/scripts folder, but now it seems there is an official way to handle mods (reading through the modding guide and the DFHack documentation). I noticed the mod makers development section in the DFHack guide which is very nice (and likely how I will use things most), and I also noticed that it is much easier to change vanilla raws without editing them directly (also very nice). My main question here is; are there any limitations in the new system that weren't in the previous? My previous work has dozens of lua scripts (some runnable, some just as functions for others) across many different folders. Are subfolders still allowed, or does everything have to be flat in scripts_modactive and scripts_modactive/internal?
• Persistance - Previously, for large amounts of information, I just manually saved a lua table to a json file periodically (and on save) and then read it in on game start, and for small amounts of information (e.g. a script callback) I used the persist-table.lua functionality. Is this still the best way to handle persistant data storage and function callbacks, or is there a more "modern" way?
• Syndromes - I used to have a working class system with spells and such. I did this using syndromes which were attached to custom inorganics that didn't have the tags to appear in the world. I am wondering if that is still the best way to handle this type of system, or if there would be a better way to handle unit based modifications (like changing displayed name and adding interactions)?
• DF Structures - Similar to the above, my class system allowed for custom attributes (e.g. Perception). Because the DF structures were fixed, you couldn't just add another body or mental attribute to the list and have it work, so I had to write a wrapper function around the C++ function wrapper which returns the attribute values. I'm guessing the structures are still fixed (wouldn't make much programmatic sense for Toady to make them mutable), but I am wondering if there has been any work on the DFHack side of things to track things like custom DF structures.
• Custom Files - Where should custom files that aren't techincally raw objects or scripts go? For instance, my old codes would read files like;
  
  Code: [Select]
  0,0,1,0,0
0,0,1,0,0
1,1,T,1,1
0,0,1,0,0
0,0,1,0,0
  and parse that to understand what tiles to target. Another example would be a mod specific configuration file that would be read once when a game is started?

I think that is good for now. I am sure that as I get deeper into getting my old codes running I will have more questions.

[myk]

I will defer to Tachytaenius for questions on custom-raw-tokens, but I can answer the others:

> are there any limitations in the new system that weren't in the previous?

Not that I know of. To my knowledge (which isn't complete) the syntax and capabilities of the raws have not changed

> Are subfolders still allowed, or does everything have to be flat in scripts_modactive and scripts_modactive/internal?

The folder structure under the scripts directories is up to you. DFHack essentially adds scripts_modinstalled and scripts_modactive to its script search path, and script modules can be organized however you like. Scripts in the internal subdirectory won't clutter up the autocomplete list in ls or gui/launcher and cannot be run by the player, but they can still be reqscript'd from your top-level scripts.

> saved a lua table to a json file ... or used persist-table... Is this still the best way to handle persistant data storage and function callbacks?

Persisting data to json manually (for state not tied to a savegame) or with persist-table (for savegame state) are still the best options. The biggest related change is how you reload on start. Before, the player had to manually invoke a script or you had to specifically start your script from an init file. Now, all (non-internal) scripts that declare themselves to be module loadable are parsed at game start (and again before the game is loaded). You can reload your state (including whether your script was enabled, if it can be enabled/disabled) in a callback hook attached to dfhack.onStateChange. A good, simple example is emigration.lua, which stores state with the savegame via persist-table and restores its enabled state on game load: https://github.com/DFHack/scripts/blob/master/emigration.lua

> Syndromes

Syndromes haven't changed since 0.47. I don't have a lot of experience with using them for actual modding, but to my knowledge, they're still the best way to apply unit based modifications.

> I am wondering if there has been any work on the DFHack side of things to track things like custom DF structures.

Even if DFHack adds to the structures or extends the enum values, it's DF that will be interpreting them. Adding new enum values, for example, might cause DF to take unexpected paths through switch statements. I don't think this can be supported. I think a safer architecture would be to keep your own mapping of units to extended attributes and reference that map when you need to make a decision based on the value for a unit.

> Custom Files - Where should custom files that aren't technically raw objects or scripts go?

You can distribute whatever files you want in a mod, even when it is distributed via the Steam Workshop. You can look up your mod source path in df.global.world.object_loader.object_load_order_src_dir. You shouldn't write there, though. Dynamic data/configuration can be saved to dfhack-config/mods/yourmodid/somefile

[myk]

Is there a script to elevate a fortress, or to trigger elevation in some way?

do you mean change the displayed elevation relative to sea level? or do you mean physically transporting it to a different z-level?

[joostheger]

Is there a script to elevate a fortress, or to trigger elevation in some way?

do you mean change the displayed elevation relative to sea level? or do you mean physically transporting it to a different z-level?

sorry for the vagueness :-)
Elevating a site to barony or to county or duchy. So land_holder comes and stuff.

[myk]

Ha, boy did I interpret that incorrectly : P

We've looked into it, and while it is very feasible to *replace* a baron or other noble, elevating a site from scratch is much trickier and may not be safe to do with our current understanding. If you're a member of the DFHack discord (https://dfhack.org/discord), here's a link to the discussion: https://discord.com/channels/793331351645323264/1017471248567124049/1158850122671739010