Print

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

[RedDwarfStepper]

Yes, you're correct. It should be "adjusted." there as like in all of the surrounding code, so yes please, take care of that one.

Will do.

Personally I find it easier to discuss these issues here.

Fine by me.

I think there is one more or something is off somehow somewhere else:
Please compare this line and this one with this one.
By using the

Code: [Select]

world_tile pointer it also uses x and y instead of "adjusted."
Should I adapt that one as well or is there an underlying reason I don't see?

[PatrikLundell]

I don't quite follow what you're after. The two first references seem to be to two different versions of the same code. The is_brook flag check has to be for the current world tile, as that property is independent of the biome, and so cares only for which world tile the tile resides in.

The third reference is to biome related code, and so needs to use adjusted coordinates.

Thus, unless I've missed your point (entirely possible) the code shouldn't be changed.

[RedDwarfStepper]

The is_brook flag check has to be for the current world tile, as that property is independent of the biome, and so cares only for which world tile the tile resides in.
The third reference is to biome related code, and so needs to use adjusted coordinates.

Ah - that was what I meant when I wondered if there is a reason for the difference.
So, just to make sure there is no misunderstanding: To retrieve the proper value for the "is_lake" flag the coordinates have to be "biome adjusted", but for the "is_brook" flag that is not true and the none-adjusted coordinates must be used, yes?

[PatrikLundell]

Correct.

To be overly explicit (not that I think it's really needed):

- "is_lake" is a biome type property and it's used to determine soil depth, which is also tied to the biome. The biome is tied to a host world tile, which may or may not be the current one.
- "is_brook" applies to all MLTs in the world tile, regardless of whether the biome of those are tied to surrounding world tiles or not (it only has any effect on the MLTs that actually have a watercourse in them, of course). That should mean that any watercourse joining "the official" brook watercourse in that world tile should also be a brook, even if it wasn't upstream, although I haven't investigated if that conclusion is correct.

[RedDwarfStepper]

Just in case someone is wondering: I'm still here.
I took a little sabbatical, as I needed some time to actually play a game or two for a change
And then 3 weeks ago I took the time to give the change concerning the inorganic vectors a go.
Having tested it originally in 0.47.04 made it look like it was worth the effort performance wise. But upon migrating the setup to 0.47.05 the performance gain is not that big anymore, like 4 seconds for a large world instead of around 7 as measured originally.
And that is for the code itself being measured in place. Testing in windowed mode the complete search took just a long as before, those 4 seconds somehow evaporated into thin air. And also taking into account that it can be quite fickle to reliably measure a difference of just 4 seconds on a regular desktop pc repeatedly... Only in fullscreen mode those 4 seconds translated into a net gain at the end of a search, strange that one.
Plus 0.47.05 seems to run faster as a whole, so I further doubt this change brings much to the table.

@PatrikLundell: What do you think? Are 4 potential seconds worth the trouble of a PR?

PS: Looking at my explanation in the PR again I'm tempted to give it another go either with std::vector<char>  and/or with std::memset just to make sure I'm not missing something (less) obvious. I'll report my findings.

[PatrikLundell]

It's better for the long run to take pauses to recharge batteries once in a while, and the current mess doesn't exactly help the spirits.

I suspect the oddities for the windowed mode is just that: an artifact introduced by the OS.

I think 4 seconds is borderline, but not useless, so it would be useful if it was introduced, but I wouldn't be upset if you considered it to be too much effort for too little gain (annoyingly inconclusive, but I feel taking a definite stance isn't the right action here).

I'd rather follow lethosor's advice and use uint8_t instead of char.

[RedDwarfStepper]

I'd rather follow lethosor's advice and use uint8_t instead of char.

Ah, I wasn't planning on disregarding his advice, I just wanted to see if another approach would result in a more favorable outcome.
And after experimenting around for 30 minutes and reading for 2 hours I learned something new:
- Compilers aren't as smart as we both wish them to be
https://blog.royalsloth.eu/posts/the-compiler-will-optimize-that-away/
- And sometimes you really have to trick them to get them to get it right:
https://travisdowns.github.io/blog/2020/01/20/zero.html

And at last: std::memset is much faster for a std::vector<POD> than std::fill, but std::vector<bool> is a special case as we already knew...:
https://stackoverflow.com/a/1665038/167865

=> Using std::memset on a std::vector<uint8_t> takes a total of 2 seconds, which is a good speedup in my book...

[PatrikLundell]

Experimenting is good, and two seconds for a rather minor change of the code is good as well.

[Deuslinks]

Hi there. I'm finally getting back into Dwarf Fortress after 2 years and I've downloaded the latest LNP from PeridexisErrant but keep having issues with the Embark Assistant Crashing. I have done fresh installs. Disabled the TWBT and generated new worlds. Full Screen and Windowed. It lets me get to the list of options you can choose from but when I add a filter and hit F it just freezes then crashes

I have managed to get it to work about 1 in every 10 times. But I cannot seem to narrow down what is causing it to crash the game. I've tried running a normal embark search first and then ran the embark assistant afterwards and that was the only times I managed to get it to work but it is not consistent most of the time it will present a black screen or just freeze on the filters page.

Any advice would be greatly appreciated.


Edit: more specific info

[RedDwarfStepper]

Any advice would be greatly appreciated.

Hm, that sounds ominous.
How is your system equipped memory-wise?

Can you provide us with a zipped download of your region/world save?
Like over here Dwarf Fortress File Depot for example.
That would allow us to check firsthand.

[PatrikLundell]

@Deuslinks: What do you set the filter to (including the embark size), and what's the size of the worlds you've used (if it's the largest ones there could definitely be memory issues)?

I suspect the problem is linked to something in the filter profile, so knowing what you search for could help us reproduce the problem.
Since you say "worlds" in plural, I guess you've tried several worlds, but it certainly won't hurt error reproduction if we get both the profile (i.e. what you've searched for) and a world it crashes in, although my gut feeling is that it may happen to most worlds when that criterion or group of criteria is used.

[Deuslinks]

Hi  RedDwarfStepper and PatrikLundell

Here are the links for two regions both of them crashed when searching

https://dffd.bay12games.com/file.php?id=15549 

Size Large
History Medium
Civ Very High
Beast High
Savagery Low
Minerals Frequent


https://dffd.bay12games.com/file.php?id=15550

Size Medium
History Medium
Civ  High
Beast High
Savagery Low
Minerals Frequent

My PC has 32 Gig Ram and a Nividia RTX 3070 with 8 gig inbuilt. I monitored it on the task manager and dwarf fortress gets up to about 1.5 gb on ram usage

For the Filters I left the embark size as default so 4by4. Typically my first filter is for 1/2 Towers and then I run it and then if it works for that first filter I am able to add all the others I want.

The second region is one I created this morning and have tried running a filter just for Elves and it crashed 


Thanks for helping with this

Edit: I managed to have a bit of luck this morning and have managed to get it to work twice I've needed to search for something with the original filter on the embark screen so set Clay to yes let that run once it is done hit esc to view the results and then go into the embark assistant and search for 1 tower and it has worked on both maps. But if there hasn't been that many people reporting the issue it may be my system

[clinodev]

I don't have a proper bug report, but I can say I saw a streamer get a CTD using embark-assistant. I assumed it was some particularity of their setup, but it would be on the current DFhack release.

[PatrikLundell]

Hm, frustrating.

I tried the second world provided by Deuslinks changing the embark size to 4*4 (mine's set to 3*3 as default) and elven presence, which worked as without any issues. I've tried to export the parameters of the world and regenerating it and then searched it with the same parameters (because DF sometimes generates different worlds from the same world gen data depending on whether it's a fresh start or a game has generated something previously, so there are some seeds that aren't reset full), but searching both the generated world and the original one again worked without problems.
I then tried the first world, again with a 4*4 embark, but searching for min 1, max 2 necro towers. Again, no crash for me.

Boogieman reported the same kind of issue in the Starter pack thread, but hasn't provided any additional details, so there's something, somewhere affecting at least 3 different people. Whether the issue lies in this plugin, something else, or a combination of factors is unknown, and without a way to reproduce it where it can be investigated it will be hard to track down.

[RedDwarfStepper]

Hi RedDwarfStepper and PatrikLundell...

Thanks for that Deuslinks!

@PatrikLundell: If it really is system-dependent we probably won't be able to reproduce the crash with our systems.
But throwing out a wild guess: It could be one of the Microsoft Visual C++ YYYY Redistributables. On my system there are 15(!) different versions installed, ranging from 2005 to 2015 alternating between x86 and x64...
Or as it does not happen every time it might have something to do with how some memory area is (un)initialized, which could depend on which other programs are running or what has happened in the memory of the DF process beforehand.
Still pretty hard to debug.
But if is modification of the starter pack itself or the config of the installation we might catch it with a zipped download of the installation minus the world saves and minus the folder "\LNP\utilities\" (so big!) we have already.
What do you think?