Print

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

[Rumrusher]

ok wrote a script that purges all but the adventurer from the site in hopes of easing FPS so far this script kinda needs to run multiple times to get everyone.

Code: [Select]

function Gigapurge()
local adv=df.global.world.units.active[0]
for k,v in pairs(df.global.world.units.active) do
if v.civ_id ~= adv.civ_id then
df.global.world.units.active:erase(k)
end
for ko,vp in pairs(df.global.world.units.all) do
if adv.id ~= vp.id then
df.global.world.units.all:erase(k)
end
end
end
end
Gigapurge()
so far this script spits out and error a couple of times but repeated use will work. said script will wipe companion, I don't know what pandora's box this script will open wiping out the units in the all and active lists will do.

oh and I notice the unit levels return to normal after a long long jog away from the camp in slow travel so I guess it's a mix of needing to dump the cache of wild animals spawn in the camp, and walking away from the camp so the game will unload and save the camp new set up.... and toggling town flag on the camp.


edit: this might lead to save corruption so uhh yeah probably be wary on using this.

[PatrikLundell]

I suspect you're playing with fire, Rumrusher. This is unpleasantly similar to the bugged DFHack clearing of "dead" (inactive in reality) units that just left them in limbo at map entry. I'd recommend you to take a very close look at what you're doing

I don't know how the "pairs" operator handles iteration over lists that are modified in the process, but the normal way to purge things from dense lists (which these lists are) is to iterate over each index backwards. If you remove element i, that will move all elements beyond that one one step forward, and you'd then take a look at i - 1, which has not been affected except possibly of a "next" link, if one is present. If you were to do it forwards you'd have to refrain from increasing the index when you delete an element (and I suspect that's why you have to run it several times, as each deletion probably skips looking at the next element).

Note that I still advocate a great deal of caution and to analyze what's done. I haven't, so this warning is a gut feeling one.

[Rumrusher]

I suspect you're playing with fire, Rumrusher. This is unpleasantly similar to the bugged DFHack clearing of "dead" (inactive in reality) units that just left them in limbo at map entry. I'd recommend you to take a very close look at what you're doing

I don't know how the "pairs" operator handles iteration over lists that are modified in the process, but the normal way to purge things from dense lists (which these lists are) is to iterate over each index backwards. If you remove element i, that will move all elements beyond that one one step forward, and you'd then take a look at i - 1, which has not been affected except possibly of a "next" link, if one is present. If you were to do it forwards you'd have to refrain from increasing the index when you delete an element (and I suspect that's why you have to run it several times, as each deletion probably skips looking at the next element).

Note that I still advocate a great deal of caution and to analyze what's done. I haven't, so this warning is a gut feeling one.

yeah this script is pretty much a big risk for being a solution for what I would pretty much avoid if it happen to me in adv mode, but was made to solve 'accidental influx of animal and wildlife filling up a camp.' which I noticed is caused by folks slow traveling around the camp edges repeatedly and ended up triggering the adv mode wildlife fill in in the campgrounds which ends up filling it up.

and it took me this long to notice this due to all the fast travel scripts I use bypass all that by plopping the adventurer into the camp instead of walking towards it or fast traveling near the camp barrier move in a bit then fast traveling to the part of the camp where I set up my stuff if I did this with out dfhack.
that said thanks for the helpful tip.

[MobRules]

OK, apologies if this is a dumb question, but google and readthedocs have failed me, so...

In the enhanced stocks view, some items have a blue asterix right before the quality marker. I have been unable to find anything that tells what this asterix is intended to indicate, nor can I find any pattern in which items have it and which items don't. It's driving me batty .

So, what does the blue asterix indicate?

[lethosor]

OK, apologies if this is a dumb question, but google and readthedocs have failed me, so...

In the enhanced stocks view, some items have a blue asterix right before the quality marker. I have been unable to find anything that tells what this asterix is intended to indicate, nor can I find any pattern in which items have it and which items don't. It's driving me batty .

So, what does the blue asterix indicate?

According to the code it's for improved items. It does seem like something that ought to be in a legend somewhere.

[MobRules]

According to the code it's for improved items. It does seem like something that ought to be in a legend somewhere.

Ah! Thanks

[neutrino431]

Can you create teeth to use in decoration with any of the available item spawning tools?

[Pvt. Pirate]

i am redirecting an issue with mousequery:

I am getting the same mouse problem jaynixxo was having as well, it seems to be 87 by 43 tiles that the mouse will let me click on in full screen, so the problem goes away if I play very zoomed in. 

I'm getting this problem as well, the mousequery only works inside a set area, if i zoom out the mouse doesn't scale to the now larger view area, doesn't matter if i'm windowed or fullscreen.

But in my case i also can't use right-click to pan around the map properly and it seems related to zoom level. At some levels i can only pan up or left and up, sometimes it pans up and down but not left or right.

this problem might relate to my mousequery problem, where it works fine for top and left mouse scrolling, but not the right and bottom border. i use 5:4 screen and 1280x960 windowed mode. so far none of the widescreen players confirmed if they get the same problem when they chose windowed and smaller res.

Yeah, most of the time i can scroll left or up, but not right or down.

I play with 1920x1080 and the problem remains the same in windowed or fullscreen. And i just tried windowed with a low resolution (800x600) and the problem remains the same.

If i zoom the map all the way out, mousequery only works on a part of the top-left corner that is 87x40 tiles, which i designated on this image. The entire map is 192x192 tiles.

Spoiler (click to show/hide)

the problem got introduced in 44.09, but there still was a fix back then:
installing an alternative dfhack version including different mousequery code

ever since 44.12 the fix doesn't work, because that dfhack fork was dropped.

[Clément]

Are Core::runCommand or printing to Core::getConsole thread-safe?

Edit:

I currently only access/modify DF data when a CoreSuspender is locked, but I wonder if this could be relaxed. Can any assumption be made on some pointers validity with regards to state change events (SC_WORLD_LOADED, SC_WORLD_UNLOADED, SC_MAP_LOADED, SC_MAP_UNLOADED, SC_PAUSED, SC_UNPAUSED, ...) for read-only access?

I did not have any answer for this question. I am asking again a more precise version: can raws be read between SC_WORLD_LOADED and SC_WORLD_UNLOADED without suspending the core?

[PatrikLundell]

Without having any proof, I assume the data structures populated from raws are all created/read during world gen, with potential additional entries added as part of the world gen (e.g. syndromes). I see no point in ever removing any entries as they're not that many, and in many cases they don't even have numeric identifiers (e.g. creatures and plants), with indices being used in other data structures. If any changes would occur, they'd probably be in the form of new entries added at the end. Even if you were to make modifications, such as e.g. a ritual that turned all strawberries blue and poisonous, you'd probably still have to keep track of the old kind (e.g. in a depiction of a dorf eating a strawberry), from the new kind, hunting down and replacing all applicable entries (i.e. all the berries and plants in existence).
Similarly, I'd suspect art and art forms only grow through addition at the end of the vectors, with nothing being removed.

Regardless, if you access data while DF is running, you'd have to determine whether it's probably safe on a case-by-case basis.
Also note that nothing is safe from DFHackery, but I'd rather use a disclaimer for that case.

[Clément]

Adding at the end is still an issue because DF mostly uses std::vector which may invalidate pointers/references to existing elements when it is resized (you need std::deque or std::list to avoid that). Although a lot of vectors contain pointers, so only the pointers are moved, not the pointees. So if the raws are never removed, I could keep these pointers, as long as I don't read through vectors, it should be safe.

For example, if I want to access item information at any time, I could copy world.raws.itemdefs, then look for itemdefs in my own copy. Reading itemdefs would then be safe except maybe for complex objects like std::string if a DFHack script or plugin decide to modify them during the game.

[Roses]

As far as I know, the raws entries are never modified after world gen except if a script uses dfhack to do it, although they are re-read every time you start df which is why changes made with dfhack revert. I don't see why you couldn't just create a copy of the raws structure on start and access it whenever you want. Of course if you want to access other information this no longer is true since almost all of the other information changes through the game (I do believe that PatrikLundell is correct though and that most things append instead of prepend or replace)

[Staalo]

I have noticed an increasing tendency to segfault without warning in my latest fort. Now the save is finally in a state where I can't let the game run more than a week before crashing; the message is typically like this:

line 15: 80035 Segmentation fault: 11  DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"

Earlier I thought this was about TWBT, since I was trying it out with this fort, but with a clean DF install (the latest Mac version) with only DFHack added the problem still persists.
Any ideas what could be causing this? I saw a mention to weapon traps, but apparently that bug got fixed few versions ago.

[PatrikLundell]

The main crash reason for the current version is caused corruption related to raiding. The troop equipment lists (where you select equipment for troops) get corrupted to contain various books/codices, and not long after that DF crashes. Presumably this is caused by improper handling of equipment carried away from the fortress on raids and then restoring equipment as the troops return, so never raiding is probably safe from that bug, and I speculate that it may be safe if you don't save a fortress when any squads (and parts thereof) are out of the embark, but that speculation is untested, as far as I know.

The weapon trap bug has been fixed.

Have you tested without DFHack and verified that the problem goes away? If so it's likely to be DFHack related, while a remaining problem may still be caused by damage caused by some earlier DFHacking.

[Staalo]

Tested it with a fresh clean DF install with no changes or additions; it still crashes after few game days without warning.

Interesting point about raiding corruption though; I'm doing a "conquer the continent" challenge with this fort so there are constant raids coming and going. There have been dozens of occupation squads who were sent out permanently (with their gear and all) and might contribute to this corruption.
I have tried to avoid saving when there are units off screen (remembering earlier bugs with lost squads) but most likely at least auto saves have happened while a raid team was out.

So maybe this isn't about DFHack, it's just Dwarf Fortress itself not being ready for this style of playing?