Print

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

[taleden]

Would it be possible to include neighboring races in the finder, i.e. "Elves/Humans/Goblins/Tower: NA/War/Yes/No", or is that information not easily available during the search?

[PatrikLundell]

Would it be possible to include neighboring races in the finder, i.e. "Elves/Humans/Goblins/Tower: NA/War/Yes/No", or is that information not easily available during the search?

It's possible, but not trivial. It would require its own search pass (although it would have to run only once and it's a world tile level search), because it depends on distances from civs, which means both figuring out what the distances are, and checking for impassable terrain (including the passability resulting from a player fortress [and I don't know if other pass-through sites can be placed on "impassable" tiles apart from probably dwarven fortresses on mountains, and I'm not completely sure what sites ARE pass-through]). If I was to do it, I'd probably implement a fairly crummy flood fill check for each site of each civ, which wouldn't be particularly efficient. Another issue is that I don't know how DF decides which civ gets to represent each race, which would be required to implement a relations check (presumably war is determined by the mother civ being at war with them [which ties into the dwarven civ selection], but the logic would still have to determine if that civ is considered the closest one).

Thus, there are known unknowns that would have to be investigated before an implementation can be made to hit the unknown unknowns.

[taleden]

Hm, ok. Pity there's no easy dfhack memory structure you could just pull it from while scanning over the world during the main search; it *seems* like it ought to be in there somewhere since the game can already display neighbors information, but maybe it only calculates and populates those structures if the user has actually TABbed to the Neighbors display. Oh well, just a thought.

Meanwhile, do you have any interest in making some adjustments to make embark-assistant more suitable for general use, to maybe get it enabled by default in future DFHack releases a-la manipulator? It's a great tool and I think a lot of people would appreciate it who currently don't even know it exists, but it'd be more work for you initially to make it work better as an always-on thing, and probably more work ongoing with all the newcomers asking for features.

If you're interested then I'm happy to help with the interface design considerations, or I could try implementing the changes myself if you'd like (is the source code available somewhere?).

[PatrikLundell]

Given how DF generally works, I'd expect DF to generate neighbor info on the fly based on which world tile and civ you've currently selected. Whether that's done when TAB-ing or selecting civ/moving doesn't really matter, I think.

It would probably be a worthwhile addition, but the logic details have to be determined first (i.e. exactly how sites affect pathing), which probably isn't an impossible task with some script investigations. In addition to that, it would have to fit into the UI somehow, i.e. if you're using one line per race you're going to end up with quite a few lines (especially with stuff like Masterworks which, as far as I understand, effectively multiplies the races by some factor, plus introduces new ones), but if that's used a fairly simple N/A, Any Relation, War, Peace, Absent selection would work. A possibility might be a sub menu/page.

The Manipulator is integrated via a key in parallel with the normal UI, which I think is a good way to handle this kind of tools, rather than replacing the vanilla functionality outright. There were a few different reasons I didn't go that route:
- I had no idea how the tool would be received, so an active opt-in seemed like the safer approach.
- I've never integrated anything, so I'd need to find out how to do that (probably not an impossible task).
- It definitely has to be possible to use vanilla without actively disabling it, both because it displays things that might want to be kept hidden, and because its increased screen real estate requirements.

The source code is integrated (as a plugin) into DFHack, so it's available from Github https://github.com/DFHack/dfhack (which is a royal pain to deal with, in my view, but that's what you have to deal with unless you want to support development environments for all OS' and bit combinations yourself). Since it's part of DFHack it means anyone (with an account) can submit Pull Requests for changes of it. The reasons for this thread is both as an advertisement of sorts, and a way to direct tool related issues/requests here rather than clutter the main DFHack thread with them.

[thefinn]

Do I have to wait for the search to complete to find the overlay working?

I'd love it to work even if I cancel the search after the first couple pop up.

Searches are long...

[PatrikLundell]

Searching does indeed take a long time. This is because it scanning a lot of data, plus that this data has to be loaded by DF itself. It can be noted that DF's own searches also take quite some time.

It should be possible to leave the search indications in the state they were when a search was cancelled, but I'd have to investigate what happens if you were to move the focus to world tiles that have not yet been searched. I suspect additional logic would be needed, and I wouldn't be surprised if you could get incorrect indications in such areas because they were based on data that hadn't actually been produced, in particular if the very first search is aborted.

[thefinn]

Searching does indeed take a long time. This is because it scanning a lot of data, plus that this data has to be loaded by DF itself. It can be noted that DF's own searches also take quite some time.

It should be possible to leave the search indications in the state they were when a search was cancelled, but I'd have to investigate what happens if you were to move the focus to world tiles that have not yet been searched. I suspect additional logic would be needed, and I wouldn't be surprised if you could get incorrect indications in such areas because they were based on data that hadn't actually been produced, in particular if the very first search is aborted.

Yeah I'm not too sure what I'm doing wrong. Clearly something substantial and probably quite basic. But even when leaving the search to go through to the end... I get nothing but a total of tiles that meet the requirements I set.

I'm using windowed mode, not sure if that makes a difference. I see some X's crop up when it's in the search but only in the region window - not the world or local windows. Very odd.

*shrug*

[PatrikLundell]

There are currently no indicators in the "World" section, only in the "Region" and "Local" ones. I've added the code needed to cover the "World" section as well, but it won't appear before the next DFHack release (provided the Pull Request is accepted). I've also changed to code to allow a 'f'ind to be 'c'ancelled while leaving the indicators for what has been found so far, but, again, it has to be accepted and released to have any end user effect.

Windowed mode or not should make no difference (I'm using windowed mode, and I don't think I've even tested it in full screen mode). It can be noted that the DF focus jumps around to look at the area at the focus during the search, and this is visible on the "Local" and "Region" sections, but if you have a large map (which I assume you have since searching takes a long time) the "Region" section shows only a portion of the world, and that portion may not cover any matches, so you'd have to scroll around to find the matches, in particular if the matching tile count is low, as that probably means they're far apart (or gathered in a cluster somewhere). Unless the "Local" window happens to show a world tile where you've got a match you won't see any matches, and, again, if the matches are few the chance of happening upon a matching world tile is slim.

[thefinn]

Gotcha I will give it another go then.

[PatrikLundell]

Gotcha I will give it another go then.

Another thing to try is to search for something that's very common, such a e.g. just the presence of a river in the form of a brook or larger. That should match most of the tiles, and thus should make it easy to see if (and how) it works in general. If you do that on a small world it doesn't take a long time...

[taleden]

PatrikLundell, do you by chance have a lua implementation of your process for scanning world tiles and identifying the soil layers present (even if it's super slow)?

I'm trying to gather some data on how soil, sand and clay generate, so what I'm hoping to do is run a script that can scan through every distinct biome in a world (or, if necessary, every world/region/local/whateveritscalled tile), generate a string describing the pattern of soil layers observed there, and report at the end all the distinct patterns that were found in the world. So if you happen to have that scanning logic already written in lua, it'd be easy for me to hack on some extra record keeping for what I'm trying to do, even if it takes forever to run compared to the C version.

[PatrikLundell]

I have the Lua script prototype for the Embark Assistant. There are bugs in it, of course, as I expected it to be too slow to be useful, but most of the basic logic is in there, and I don't think there are any bugs in the geo biome scannings themselves (yes, there are several versions of it, as the overall logic was needed in several places. I tried caching data, but the estimate indicated far too many gigabytes to be reasonable, so data is discarded and regenerated, which is what DF do a lot as well). However, I have copied the logic from Prospector, including some stuff involving an unnamed field and ocean biomes... I've estimated the time to scan a full size world using the script to be around 30 minutes.
https://www.dropbox.com/s/sfstaxr2yq1irvk/embark_assistant.lua?dl=0 AS IS, PROTOTYPE, NO SUPPORT. Not for actual use.

However, the Prospector logic takes soil erosion and SMR cutoff into consideration, and so has to be run for each tile rather than per biome. If you're just after how the geo biomes are constructed the Biome Manipulator is probably a better source http://www.bay12forums.com/smf/index.php?topic=164658.0.

[Burneddi]

Can you add an option that searches for underground fuel, ie. lignite or bituminous coal (or both)?

Also a wish from Keupo's stream: being able to search for surroundings that are husking but not reanimating.

[PatrikLundell]

Fuel: I have to look at it before answering, as such a functionality would require means to figure out how to determine if a mineral can be used as fuel (as the logic shouldn't be dependent on what's in the vanilla raw set).

Husking: Sounds like it should be possible, although I think it would require some restructuring of the evil biome search criteria.

[mifki]

Fuel: I have to look at it before answering, as such a functionality would require means to figure out how to determine if a mineral can be used as fuel (as the logic shouldn't be dependent on what's in the vanilla raw set).

Coke itself as fuel is hardcoded, then you need to find all reactions that produce it and see what their reagents are. Of course theoretically you can have complex reactions with multiple reagents or reaction chains instead of the default ones, but I think some simplified checks are enough.