Print

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

[expwnent]

So modtools/add-syndrome, for lack of a better term, needs some work, I'm just not exactly sure what. First off most syndromes are added correctly, you can give a unit an interaction that it will use correctly, change display name/tile, change attributes, and basically anything that is considered a "Special Effect" on http://dwarffortresswiki.org/index.php/DF2014:Syndrome. But any of the base effects will have do nothing. My brief bit of science that I did found the following.

When applying a syndrome via interaction (which is what I figure we should model add-syndrome after, instead of adding a syndrome via attack). There are several additional components that are not correctly set.

1. None of the target_ vectors are populated in the symptoms list.
2. This leads to no wound being generated.
3. If the target_vectors are artificially populated a wound is automatically created, but it's parts vector is empty
4. Filling in the parts vector seems to correctly "apply" the syndrome. Unfortunately using this method means that out of everything in;

Code: [Select]

[CE_NECROSIS:SEV:100:PROB:100:RESISTABLE:BP:BY_TYPE:THOUGHT:ALL:BP:BY_TYPE:NERVOUS:ALL:START:30:PEAK:60:END:1200]the only thing we can really do is apply necrosis to the correct body parts for the correct times. As you have to populate all the values, and there is no easy way to handle SEV or RESISTABLE.
5. Unfortunatelyx2 in 3 of my 5 tests the game crashed. This may be because I was creating entries by copying another units. I am unsure

I am hoping that someone more knowledgeable about the workings of things can come up with a way to add damaging syndromes via add-syndrome. Otherwise I will move back to just adding wounds directly (this suffers from the same Unfortunately as number 4)

Posting to remind myself later.

[lethosor]

Yeah, solid items disintegrate when they start boiling (you can modify item->temperature to cause that), although they leave behind flow_info objects (e.g. "boiling bronze") which are accessible with gm-editor.
I'm not sure what exactly you mean by "entity loyalties", but here's a way you can access the entities a citizen belongs to:
* Run "gui/gm-editor" with the unit selected
* Run ":gui/gm-editor df.historical_figure.find(<value of unit->hist_figure_id>)"
* Locate the entity_id value in each entry in entity_links of the type "histfig_entity_link_memberst" (e.g. entity_links->0->entity_id, entity_links->1->id, etc.)
* Run ":gui/gm-editor df.historical_entity.find(<entity ID>)" for each

[Max™]

Wait do the colons make it search the current target with gm-editor?

[Putnam]

No.

[lethosor]

Colons cause DFHack to treat everything after the command name as the first argument to the command. For example, ":devel/print-args a b" prints "a b", and "devel/print-args a b" prints "a" and "b" on separate lines. This is useful when passing lua snippets to commands, since it avoids issues if whitespace is accidentally added (the whitespace is passed through as part of the first argument).

[scamtank]

I'm trying to do a thing, but I'm terrible and I can't figure out what's wrong.

What I want to make happen is that nobody trades with clay anymore, elves in particular. UristdaVinci's blood-del script already crawls entity resource lists and purges all mentions of blood and other useless extracts, so I thought I'd repurpose that, but it seems I can't just make the script look in "misc_mat.clay" instead of "misc_mat.extracts" instead.

Code: [Select]

local my_entity=df.historical_entity.find(df.global.ui.civ_id)
local sText=" "
local k=0
local v=1

for x,y in pairs(df.global.world.entities.all) do
 my_entity=y
 k=0
 while k < #my_entity.resources.misc_mat.clay.mat_index do
  v=my_entity.resources.misc_mat.clay.mat_type[k]
  sText=dfhack.matinfo.decode(v,my_entity.resources.misc_mat.clay.mat_index[k])
  if (sText==nil) then
   my_entity.resources.misc_mat.clay.mat_type:erase(k)
   my_entity.resources.misc_mat.clay.mat_index:erase(k)
   k=k-1
  else
   if(sText.material.id=="CLAY") then
    my_entity.resources.misc_mat.clay.mat_type:erase(k)
    my_entity.resources.misc_mat.clay.mat_index:erase(k)
    k=k-1
   end
   if(sText.material.id=="SANDY_CLAY") then
    my_entity.resources.misc_mat.clay.mat_type:erase(k)
    my_entity.resources.misc_mat.clay.mat_index:erase(k)
    k=k-1
   end
   if(sText.material.id=="SILTY_CLAY") then
    my_entity.resources.misc_mat.clay.mat_type:erase(k)
    my_entity.resources.misc_mat.clay.mat_index:erase(k)
    k=k-1
   end
   if(sText.material.id=="CLAY_LOAM") then
    my_entity.resources.misc_mat.clay.mat_type:erase(k)
    my_entity.resources.misc_mat.clay.mat_index:erase(k)
    k=k-1
   end

  end
  k=k+1
 end
end


This was my crude attempt. What do?

[TheFlame52]

Okay, so the first part is useful, I'm in the creature's historical_figure entry.

But
uh
There aren't any entries under histfig_entity_link. Is this my problem? The creature is a tamed roc, by the way.

So what I really want to know, I guess, is there a way to make tamed megabeasts (and their children) loyal to my fortress?

[lethosor]

I'm not very familiar with civ loyalties. What I suggested just lists the civs that a unit belongs to, which probably doesn't include animals.

PSA: I'm working on a release, so let me know of any last-minute changes (preferably not large ones)! There's a sort of checklist here (in no set order) if anyone's curious.

[PeridexisErrant]

Turns out that read the docs wrongly sets readme.md as the root instead of docs/index.rst - try adding the file to the ignore list in conf.py, and specifying the file extensions as a one-element list instead of a string.

[lethosor]

https://dfhack.readthedocs.org/en/latest/ is returning a 404 error now.

Edit: http://dfhack.readthedocs.org/en/latest/docs/ works. Is is possible to get rid of the docs/ subfolder? (It doesn't exist in an offline DFHack installation.)

[PeridexisErrant]

Seems that https://github.com/DFHack/dfhack/commit/5826b49d09f12ebc16cc6937234b1e56aa39a559 is the culprit, thanks to readthedocs ignoring the relevant config

And a release package should include that; the whole docs folder is moved over.  readthedocs.org should be hosting the subtree from "~/docs/html/..." See https://github.com/DFHack/dfhack/blob/develop/CMakeLists.txt#L244

[lethosor]

Looks like it's working now.

[PeridexisErrant]

Yay!  Just a not to anyone interested:  the canonical url is https://dfhack.readthedocs.org, which redirects to the correct version - and soon that will be "stable" (master) rather than "latest" (develop).  We'll also have any notable older versions tagged, for historical builds.

[Rose]

Is there an easy way to detect whether a unit is hostile, neutral, or a member of your fort?

[mifki]

Is there an easy way to detect whether a unit is hostile, neutral, or a member of your fort?

There's some code in https://github.com/DFHack/dfhack/blob/master/plugins/ruby/unit.rb to categorise units, but it's quite complicated, you need to check that all the conditions are up to date.