Print

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

[lethosor]

Yeah, map unloads happen a lot more frequently in adventure mode than fortress mode. What kinds of scripts are breaking specifically?

[Atomic Chicken]

I took a look at what it does edit to see if any of it links to syndromes indirectly, and it looks like wounds are created for syndromes. What might be happening is that some syndrome effects reference either just the wound or both the wound and the syndrome, and deleting the wound breaks those effects. However, I tried a couple of tests and full heal only deleted those wounds for a single tick - they were back again in the wounds vector the next tick, and stuff like nausea was applied properly despite being momentarily removed by full-heal. I wouldn't be surprised if the recreation of syndrome related wounds and the correct reapplication of the associated effects wasn't universal, though.

If that is what is creating your problem, then the fix for full-heal would require skipping the deletion of wounds that have associated syndromes. This may potentially lead to undefined behavior when it comes to things like werecreature bites, however, since as far as I know wounds created by those would have both a syndrome and "conventional" wound info (or it might be fine, who knows).

This is correct; most of the effects of a syndrome are mediated through a special wound created upon infection (via the wound_curse_info data), and deleting this wound hence removes the pertinent syndrome effects. However, the persistence of the syndrome within unit.syndromes causes the generation of a new wound as soon as the game realises that this is missing. (Similarly, the early version of syndrome-utils consistently failed at properly removing syndromes as it deleted the syndrome data whilst leaving the wound untouched). The issue is rather easy to solve; just add an "if not wound.curse" check and clear any actual injury data instead of deleting the wound outright in that case. In addition, thorough syndrome removal could be implemented and made optional via a separate arg, possibly with the option of whitelisting certain syndromes to prevent their deletion (specified by syndrome name or class). Thoughts?

Afaik it was always that way. In the source (not eventful as it wraps (among other stuff) eventmanager module) here it's called more explicit: SC_MAP_UNLOADED.

Why is SC_MAP_UNLOADED used as opposed to SC_WORLD_UNLOADED? It seems to me that the latter would surely make more sense in the context of adventure mode, with no difference in fort mode functionality (I think).

[Warmist]

<...>

Afaik it was always that way. In the source (not eventful as it wraps (among other stuff) eventmanager module) here it's called more explicit: SC_MAP_UNLOADED.

Why is SC_MAP_UNLOADED used as opposed to SC_WORLD_UNLOADED? It seems to me that the latter would surely make more sense in the context of adventure mode, with no difference in fort mode functionality (I think).

Both have their uses. However most stuff is developed without adventure mode in mind. I.e. what scripts are braking? Why are they running in adventure mode in first place?

Also IIRC map unload might still have useful data not destroyed, while world unload would have more stuff unavailable (same applies to map vs world load).

[thefriendlyhacker]

<...>

Afaik it was always that way. In the source (not eventful as it wraps (among other stuff) eventmanager module) here it's called more explicit: SC_MAP_UNLOADED.

Why is SC_MAP_UNLOADED used as opposed to SC_WORLD_UNLOADED? It seems to me that the latter would surely make more sense in the context of adventure mode, with no difference in fort mode functionality (I think).

Both have their uses. However most stuff is developed without adventure mode in mind. I.e. what scripts are braking? Why are they running in adventure mode in first place?
...

modtools/item-trigger breaks, for starters. All the set item triggers get cleared on site offloading.

The scripts interaction-trigger, random-trigger, syndrome-trigger, projectile-trigger and outside-only (all modtools scripts) use the same style of clearing triggers using onUpload, and thus have the same problem.

modtools/reaction-trigger and modtools/reaction-product-trigger are exceptions solely because they currently do not support adventure mode at all. If support was added (AFAICT just handling reactions/jobs without associated buildings), then they would have the same problem.

modtools/invader-item-destroyer also has the same problem, but frankly I have no idea how adventure mode armies/invasions work so I can't say whether this even should be running at all in adventure mode. EDIT: I suppose the same goes for outside-only, should it even run in adv mode?

These are all the scripts that use onUpload, according to the github search I did. Every script that touches onUpload uses it as if it is synonymous with leaving a world, and as such every one of those scripts that could apply to adventure mode breaks as soon as a site is offloaded.

EDIT:

The issue is rather easy to solve; just add an "if not wound.curse" check and clear any actual injury data instead of deleting the wound outright in that case.

Would that play nicely with syndromes that do stuff on a body part by body part basis? Like, say, bruising or blistering whatever body parts the syndrome's material comes in contact with?

[Roses]

<...>

Afaik it was always that way. In the source (not eventful as it wraps (among other stuff) eventmanager module) here it's called more explicit: SC_MAP_UNLOADED.

Why is SC_MAP_UNLOADED used as opposed to SC_WORLD_UNLOADED? It seems to me that the latter would surely make more sense in the context of adventure mode, with no difference in fort mode functionality (I think).

Both have their uses. However most stuff is developed without adventure mode in mind. I.e. what scripts are braking? Why are they running in adventure mode in first place?
...

modtools/item-trigger breaks, for starters. All the set item triggers get cleared on site offloading.

The scripts interaction-trigger, random-trigger, syndrome-trigger, projectile-trigger and outside-only (all modtools scripts) use the same style of clearing triggers using onUpload, and thus have the same problem.

modtools/reaction-trigger and modtools/reaction-product-trigger are exceptions solely because they currently do not support adventure mode at all. If support was added (AFAICT just handling reactions/jobs without associated buildings), then they would have the same problem.

modtools/invader-item-destroyer also has the same problem, but frankly I have no idea how adventure mode armies/invasions work so I can't say whether this even should be running at all in adventure mode. EDIT: I suppose the same goes for outside-only, should it even run in adv mode?

These are all the scripts that use onUpload, according to the github search I did. Every script that touches onUpload uses it as if it is synonymous with leaving a world, and as such every one of those scripts that could apply to adventure mode breaks as soon as a site is offloaded.

I believe all of those scripts were originally just made with fort mode in mind (Expwnent was the author for most of them IIRC). It probably would be a good idea to update them though so that they don't break in adventure mode

EDIT:

The issue is rather easy to solve; just add an "if not wound.curse" check and clear any actual injury data instead of deleting the wound outright in that case.

Would that play nicely with syndromes that do stuff on a body part by body part basis? Like, say, bruising or blistering whatever body parts the syndrome's material comes in contact with?

Sort of. Syndromes are notoriously tricky in their application and removal, although removal usually is easier. You will typically just get a single wound with a single syndrome, but for each instance of the syndrome you can get a different wound for a different body part. I'm not sure if syndrome-util handles all of that (I know it was previously not working for any syndromes that needed to function through wounds, both for application and removal), but you should be able to handle removal fairly easily with a lua script

[Rumrusher]

then there's the historical figure syndromes and interactions that come back on reload of the map or a while if you use any heal script.

[PatrikLundell]

I cooked up a script to dampen the not quite regular loyalty cascade conflicts that seems to have become more common:
It seemed to work on two test cases, although I had to reapply the script when a character died (anyway?) in one case.

Spoiler (click to show/hide)

Code: [Select]

local help = [====[

mute_conflict
=============
Attempts to put a damper on a conflict the selected unit is involved in by reducing its level
to a Brawl. Note that there are checks in place to try to detect 'real' conflict and not
tamper with those, as the effects are even less predictable than on a normal lethal non lethal
fight.
]====]

function mute_conflict (arg)
  if arg and (arg:match ('help') or arg:match ('?')) then
    print (help)
    return
  end

  local unit = dfhack.gui.getSelectedUnit (true)

  if not unit then
    qerror ("This script acts on a selected unit")
  end
 
  local activity
 
  for i, act in ipairs (unit.activities) do
    activity = df.activity_entry.find (act)
   
    if activity and activity.type == df.activity_entry_type.Conflict then
      for m, event in ipairs (activity.events) do 
        for k, side in ipairs (event.sides) do
          for l, unit_2_id in ipairs (side.unit_ids) do
            local unit_2 = df.unit.find (unit_2_id)
            if unit_2 then
              if unit_2.flags1.active_invader then
                qerror ("Sorry, at least one of the involved is an active invader, indicating a 'real' conflict")
           
              elseif unit_2.flags1.hidden_in_ambush then
                qerror ("Sorry, at least one of the involved is hidden in ambush, indicating a 'real' conflict")
           
              elseif unit_2.flags1.invader_origin then
                qerror ("Sorry, at least one of the involved is of invader origin, indicating a 'real' conflict")
           
              elseif unit_2.flags1.hidden_ambusher then
                qerror ("Sorry, at least one of the involved is a hidden ambusher, indicating a 'real' conflict")
           
              elseif unit_2.flags1.invades then
                qerror ("Sorry, at least one of the involved is currently invading, indicating a 'real' conflict")
           
              elseif unit_2.flags2.visitor_uninvited then
                qerror ("Sorry, at least one of the involved is an uninvited visitor, indicating a 'real' conflict")       
              end
            end
         
            if side.enemies [0].conflict_level < df.conflict_level.Lethal then
              qerror ("This doesn't seem to be a serious conflict: " .. df.conflict_level [side.enemies [0].conflict_level])
            end
          end
        end
       
        for k, side in ipairs (event.sides) do
          side.enemies [0].conflict_level = df.conflict_level.Brawl
        end
       
        dfhack.println ("Deescalated a conflict to a mutual Brawl")       
        return
      end
    end
  end
 
  qerror ("Failed to find a conflict this unit is involved in.")
end

mute_conflict (...)


[Lewa263]

Does anybody know of a nightly build with a working exportlegends command, that gives functional XML files for Legends Viewer? I had it working fine a little over a week ago, but all the more recent builds seem to be unable to generate the files correctly. I don't know which build it was that I got it to work on, so I guess I'm just hoping that somebody else still has a build where it works and can give me the number for it.

[PatrikLundell]

Does anybody know of a nightly build with a working exportlegends command, that gives functional XML files for Legends Viewer? I had it working fine a little over a week ago, but all the more recent builds seem to be unable to generate the files correctly. I don't know which build it was that I got it to work on, so I guess I'm just hoping that somebody else still has a build where it works and can give me the number for it.

If you have problems, please report them. Nobody's going to fix problems unless they're reported or accidentally detected by someone who actually goes about fixing the issues.

Having said that, I made a pull request 12 hour ago or so for an updated version that fixes the things I encountered. Due to the way DF is organized, it won't appear in a "nightly build" until it's been approved and then "imported" into the main DFHack repository. However, it should be possible for you to get that version off of Github to see if it works for your problems. The good thing with scripts is that they don't need to be compiled, so you don't need the rest of the infrastructure. The bad thing with scripts is that they're not compiled, so there is no compiler available to flag things that don't compile (any longer).

[Lewa263]

Does anybody know of a nightly build with a working exportlegends command, that gives functional XML files for Legends Viewer? I had it working fine a little over a week ago, but all the more recent builds seem to be unable to generate the files correctly. I don't know which build it was that I got it to work on, so I guess I'm just hoping that somebody else still has a build where it works and can give me the number for it.

If you have problems, please report them. Nobody's going to fix problems unless they're reported or accidentally detected by someone who actually goes about fixing the issues.

Having said that, I made a pull request 12 hour ago or so for an updated version that fixes the things I encountered. Due to the way DF is organized, it won't appear in a "nightly build" until it's been approved and then "imported" into the main DFHack repository. However, it should be possible for you to get that version off of Github to see if it works for your problems. The good thing with scripts is that they don't need to be compiled, so you don't need the rest of the infrastructure. The bad thing with scripts is that they're not compiled, so there is no compiler available to flag things that don't compile (any longer).

OK, I don't have much useful to give as a bug report because most of this stuff is beyond my understanding. But here's a screenshot of the error that I get with the current build 200322005: https://imgur.com/a/Z9cq8p4. Before I downloaded that one, the other nightly build that I had wouldn't give any errors in the DFHack window, but Legends Viewer would always say the file needed repair when it got down to the Events part. Allowing it to attempt a repair never accomplished anything, which was disappointing but not surprising. I have to assume the problem there was still on the DFHack side, because I didn't have that problem before I downloaded a newer build. I should probably stop doing that just because it's new and there are green checks on the nightly build site.

[lethosor]

Thanks - PatrikLundell fixed it here. The error was probably causing the script to leave behind a partial/truncated XML file, which isn't exactly easy to repair. Build 200324000 should work (when it's done, anyway); hopefully newer versions don't break again.

[PatrikLundell]

And, for your information Lewa263, what's in the screenshot is exactly what we'd need to understand the problem in most cases.

[Silverwing235]

*ahem* I wonder if, perhaps, a codeblock would also suffice as a substitute?  Like so:

Code: [Select]

...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:228: Cannot read field abstract_building_templest.deity: not found.
stack traceback:
        [C]: in metamethod '__index'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:228: in global 'export_more_legends_xml'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:826: in global 'export_legends_info'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:879: in local 'script_code'
        ...\DF4704W64VettlingrPack\df_47_04_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)


[lethosor]

*ahem* I wonder if, perhaps, a codeblock would also suffice as a substitute?  Like so:

Code: [Select]

...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:228: Cannot read field abstract_building_templest.deity: not found.
stack traceback:
        [C]: in metamethod '__index'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:228: in global 'export_more_legends_xml'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:826: in global 'export_legends_info'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:879: in local 'script_code'
        ...\DF4704W64VettlingrPack\df_47_04_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)


Yes - in fact, text is usually better, in case we need to copy something from it. (It's a bit annoying to copy from the console on Windows - one way to do it is by right-clicking in the title bar, or maybe in the console too, depending on your Windows version.)
Also, is this a separate bug report? I'm not sure, but I'll double-check that part of the script to see if it's up-to-date.

Edit: your error appears to be related to something accessing the "deity" field, which the current version doesn't do - my advice (if you're experiencing the issue) is to try upgrading.

[PatrikLundell]

Expanding on lethosor's response, the field(s) Silverwing235's version of the script tries to read is most likely one that changed its name during the last month or so, and the current version of the script (well, as of about 24 hours ago, which is the latest time I synchronized the data) actually does provide the contents of the deity_type field as well as the deity_data.Deity one. Thus, the current version of the script should handle it correctly.