Print

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

[lethosor]

I just ran into the game-ending open-legends script bug described here.  The embark explodes in brutal fashion a little while after loading the save, revealing all tiles, regenerating the map, etc.  Odd, since it looks like this commit fixed that problem.

Anyway, judging from the comments in the issue page and related pages, I guess this save is done for?


To help any possible future searchers: Save is massively bugged, one a certain day the entire map is revealed, including HFS.  All dug stone is changed to undug stone as if the dwarves never mined out the fortress, and all buildings on the surface collapse.  The only tiles not replaced by their original stone are those which have items or dwarves standing in them.  In short, just about the entire embark is obliterated.  This is the same thing described in this reddit post, this mantis issue, and these DFHack threads.

The reason https://github.com/DFHack/dfhack/issues/805 is still open is because of https://github.com/DFHack/lethosor-scripts/pull/3#issuecomment-195966083 - the commit you linked isn't a full fix. I'm not sure a full fix is possible. The solution I planned was a large warning telling people not to save after running open-legends (i.e. "quicksave" before, "die" after is safe), and maybe detect if the world has been unpaused since it was loaded too. Evidently I never implemented that, so sorry, but it's on the list for r2 now.

I'm unaware of a way to fix it unless you have backups (it might be possible to copy over the region-*.dat files).

Oh no. I just included a little workshop to run open-legends in my pack.  :-/

I hope this can be fixed, or i have to delete it again.

Can the workshop work within the constraints I mentioned above? They seem strict, but maybe people will still find it useful. Worth noting that this issue has probably been around since open-legends was written in 0.40-ish.

In any case, I haven't seen this locally in the (admittedly few) times I've tried open-legends, and it seems like a pain to reproduce, and there are lots of things that legends mode could touch, depending on what you do in legends mode, so that's why a full fix is very hard. I can try for some partial fixes in addition to a warning message if that would help.

Hey guys, longtime player/luker/fan of DF and all her utilities.

Couple questions:

How interested would you guys be in an updated(graded) make-monarch script?
I've used the underlying logic to make the script applicable to all noble positions in entity.positions.own ("MONARCH", "DUKE", "COUNT", "BARON", "DIPLOMAT", "GENERAL", "LIEUTENANT", "CAPTAIN", "OUTPOST_LIAISON") and made it so that you can "demote" a unit without raising another.

This sounds good! I saw someone ask for that somewhere recently (maybe Reddit?), so it will be appreciated.
Some things could be changed (tabs to spaces, naming conventions, etc.) but those aren't hard.

I noticed the github repo doesn't have a contributing guidelines, so here I am rather than just doing a PR. Also the original make-monarch doesn't have any licensing attached to it, so while I'd be happy to release under a GNU GPLv3 I'm not quite sure if that's kosher.

Which repo? DFHack/dfhack has https://github.com/DFHack/dfhack/blob/master/Contributing.rst and https://github.com/DFHack/dfhack/blob/master/LICENSE.rst. DFHack/scripts is exclusively a subproject of DFHack/dfhack, so all DFHack guidelines/licensing/etc. apply to it as well. That includes the DFHack license, which is Zlib. For that reason, I'm strongly opposed to GPLv3 - the current script is already Zlib-licensed, and I have no idea what kinds of hoops we'd have to jump through to deal with something GPL-licensed instead (I'd much rather not include it in that case).

Now, admittedly, it's not clear how to find those docs if you just look at DFHack/scripts, but that's one reason for the link back to the main DFHack repo (the docs cover all of the DFHack project). Maybe we could add a readme to the scripts repo explaining this better, although I'm not sure if that will break Sphinx (our HTML doc generator).

[comnom]

https://github.com/DFHack/dfhack/blob/master/Contributing.rst and https://github.com/DFHack/dfhack/blob/master/LICENSE.rst.

Ah, missed those, sorry about that. I'm used to a contributing.md on github. Any license is fine, just didn't want to conflict with what the original author used.

I'll review all that, and once I flesh out a couple maybe features (elevate the fort, promote an offsite histfig if you demote one), I'll see about a PR since there's interest.

[Tryble]

Evidently I never implemented that, so sorry, but it's on the list for r2 now.

I'm unaware of a way to fix it unless you have backups (it might be possible to copy over the region-*.dat files).

I actually do have some (kind of old) backups, so I'll see how copying the files discussed in the commit works - thanks for the suggestion.
I'm not terribly bummed about probably losing the save.  Better me as a sacrificial dummy than who knows how many people later down the line.  I'm actually kind of surprised there's so few reports about this...only two or three discussions over two years!  I woulda thunk that people exported legends more often to look at how sieges (and especially raids, nowadays) played out.

[lethosor]

The commit doesn't discuss files (only in-game structures). The files I was referring to are the region-X.dat files inside your data/save/regionY folder. It's possible that they were corrupted, and it's possible that overwriting them will break parts of your fort, but I'm not really sure.

I've seen a few more reports of open-legends issues than that over the years, but not as frequently as I would expect for a common issue either, so maybe it's not consistent.

[PatrikLundell]

I too was under the impression the open-legends corruption bug was fixed, and so have tried to dispel the previous advice to quicksave, open-legends, die. Apparently that was unsuitable (and I've continued playing such saves without suffering a crash myself). Time to go back to the old practice and advice, then.

[carewolf]

Does the fix-fat-dwarf script still make any sense? The bug it originally referred to has been closed for a long time. Perhaps some of the other fixes are now also redundant?

[zaporozhets]

Apologies in advance if this is not the right place to ask and for asking a potentially scrubbish question, but is there any way to call the dfhack.units.getUnit() function or something analogous from inside the anonymous-script modtool?
I'm at my wits' end and I'd greatly appreciate some help if anybody would be willing.

[Rumrusher]

so I take it open-legends doesn't break down on Advmode given the nature of that game loading and unloading maps?

[lethosor]

Does the fix-fat-dwarf script still make any sense? The bug it originally referred to has been closed for a long time. Perhaps some of the other fixes are now also redundant?

It could probably be removed. I don't think any others are outdated, though.

Apologies in advance if this is not the right place to ask and for asking a potentially scrubbish question, but is there any way to call the dfhack.units.getUnit() function or something analogous from inside the anonymous-script modtool?
I'm at my wits' end and I'd greatly appreciate some help if anybody would be willing.

What function? Are you thinking of dfhack.gui.getSelectedUnit() or something else? If you have a unit selected in-game, there's no situation where that function wouldn't work.

so I take it open-legends doesn't break down on Advmode given the nature of that game loading and unloading maps?

I don't think that's a safe assumption. I don't know if anyone has ever even used it in adventure mode.

[zaporozhets]

What function? Are you thinking of dfhack.gui.getSelectedUnit() or something else? If you have a unit selected in-game, there's no situation where that function wouldn't work.

Something else, I have a unit ID provided through modtools/item-trigger //ATTACK_ID and I want to call dfhack.units.getUnit() (located in dfhack/Units.cpp at line 92) in order to get the unit object itself so I can pass it to dfhack.units.getPosition() all within my anonymous-script.

When the script tries to call dfhack.units.getUnit() I get the error "(anonymous lua script):1: attempt to call a nil value (field 'getUnit')" and I don't know why.
Could the function be outside of the scope of anonymous-script for some reason? I am not a smart man.

I hope I've explained the problem better. Thanks.

[Putnam]

For that you want df.unit.find(id).

[zaporozhets]

For that you want df.unit.find(id).

Yes! I could kiss you. Whereabouts is "unit" located, though? I can't seem to find it to take a look.

[Putnam]

df.unit is a type; you'll find there's similar functions for historical figures, buildings, nemesis records and basically anything else with an ID.

[lethosor]

When the script tries to call dfhack.units.getUnit() I get the error "(anonymous lua script):1: attempt to call a nil value (field 'getUnit')" and I don't know why.
Could the function be outside of the scope of anonymous-script for some reason? I am not a smart man.

The function doesn't exist, and has never existed. "Attempted to call a nil value" means the thing you're trying to call (right before the parentheses) is nil, similar to "undefined" in other languages, and therefore can't be called.

I'm not sure where you're looking to find "df.unit.find" - it's a function, much like dfhack.units.[anything](), and is defined by DFHack as well - it doesn't have a location, whatever that means.

[zaporozhets]

The function doesn't exist, and has never existed. "Attempted to call a nil value" means the thing you're trying to call (right before the parentheses) is nil, similar to "undefined" in other languages, and therefore can't be called.

I'm new to doing anything like this, sorry if this is like pulling teeth with me.
Putnam solved it but I'm still curious, if I were to call "dfhack.units.getPosition(unit)" for example that would refer to dfhack/library/modules/Units.cpp line 131 "Units::getPosition(df::unit *unit)", right?

Why then am I not be able to refer to Units.cpp line 92 "*Units::getUnit (const int32_t index)" as dfhack.units.getUnit(index)?
I don't understand what you mean when you say the function doesn't exist when I can see it right there at line 92. Am I missing something fundamental? Go easy on me.

I'm not sure where you're looking to find "df.unit.find" - it's a function, much like dfhack.units.[anything](), and is defined by DFHack as well - it doesn't have a location, whatever that means.

I was just wondering in which file in the dfhack directory the unit type (and find function) is defined, I guess 'location' is confusing or just plain wrong terminology. My apologies. Either way I'm further along to getting it working now. Thanks for the help.