Print

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

[Thisfox]

Interesting. Thankyou.

Got around to making female dwarves bearded while I was at it. I always forget to fix that...

[Fleeting Frames]

I've never tried to create them, but you can move existing sites around without harming fortress mode. I bet it'd be bad news for adventure mode, though.

Tweaking various stuff about the world is something best done after generating the world, just prior to embarking, while viewing the world looking for an embark location.
*snip*

The Minecart Necromancer gestures!
The thread shudders and begins to roll!

Adapted and changed these functions into a lua script, for my own convenience (short name, to type multiple times) and for helping others even less able to into lua:

Spoiler: mv_site.lua (click to show/hide)

Code: [Select]

local args = {...}

function mv_site(names)
  local name = ""
  for k, partOfName in pairs(names) do
    if partOfName then
      name = name .. partOfName .. " "
    end
  end
  name = string.sub(name, 1, (string.len(name)-1))
  if (tostring (args [1]) == NIL) or (tostring (args [1]) == "") then
    dfhack.println("This script moves a named site to current region tile. You must pass a native or translated name.")
  else
  local id = -1
  for ii, site in ipairs (df.global.world.world_data.sites) do
if (tostring(dfhack.TranslateName(site.name, false)) == tostring(name)) or (dfhack.TranslateName(site.name, true) == tostring(name)) then
  id = ii
  break
end
  end
  if id == -1 then
dfhack.println("Didn't find site " .. name)
  else
  local x = df.global.world.world_data.region_details [0].pos.x
  local y = df.global.world.world_data.region_details [0].pos.y
  curr_x = df.global.world.world_data.sites[id].pos.x
  curr_y = df.global.world.world_data.sites[id].pos.y

  df.global.world.world_data.sites[id].global_min_x = df.global.world.world_data.sites[id].global_min_x + (x - curr_x) * 16
  df.global.world.world_data.sites[id].global_min_y = df.global.world.world_data.sites[id].global_min_y + (y - curr_y) * 16
  df.global.world.world_data.sites[id].global_max_x = df.global.world.world_data.sites[id].global_max_x + (x - curr_x) * 16
  df.global.world.world_data.sites[id].global_max_y = df.global.world.world_data.sites[id].global_max_y + (x - curr_y) * 16

  df.global.world.world_data.sites[id].pos.x = x
  df.global.world.world_data.sites[id].pos.y = y
  dfhack.println("Moved site " .. name .. " to " .. x .. " , " .. y)
  end
  end
end

mv_site(args)


Usage:
1. Copy the code and save it as mv_site.lua into scripts folder in hacks folder in your df folder.
2a. Open up DF,
 b. start a new game in your world that you want to play in,
 c. find the name* of the site you want to move,
 d. move the embark selector over to the world tile you want it to move it in
 e. type mv_site Sitename into dfhack.
3a. Marvel as you get a new neighbour when you move your embark selector, even if they're not visible on local level on new or old position.
3b. Get told by dfhack of either success or failure.

* Both native and translated name will work, but english characters only, unless you know how to type the strange things it replaces accented characters with in world_sites_and_pops.txt (extracted by pressing p either as df finishes worldgen or in legends mode of your world). Sotukurar is ok, Olngöestu is not.

Caveats:
A) I also have no idea what it does to adventure mode.
B) It's probs lot more convenient to move things to same place; can just use multicmd to move all at once. But I do not know what happens when you do this and suspect there may possibly be some internal reason why df limits it to just 1 site per world tile. You're free to find out with a backup, though!
C) Haven't yet run anything with this used for a while.

[PatrikLundell]

This sound handy. I've had vague thoughts of trying to achieve it, and this ought to save me the trouble.

Comments (or code nitpicks...):
- The code requires exactly one parameter. If I understand it correctly, that would rule out multi part site names (e.g. "The High Life"). I'd probably try to accept multiple parameters and concatenate them into a string with a blank padding between the segments.
- You could use a "break" after "id = ii", although it doesn't affect the outcome.
- As far as I can see, the code moves the tower from where it is located in its "home" region to the corresponding location in the destination region. An idea would be to allow the user to select the destination tile within the destination region. This would be particularly useful for those who want to see if DF breaks when multiple sites are placed in the same world tile.
- The script moves any site with a matching name, but as far as I understand hamlets, forest retreats, etc. have numerous references and relations that get out of sync if you just move the structure. It might be useful to check if the site is of a type that can be moved "safely" (necro towers, of course, but there might be some other things that could be safe. Tombs might be, for instance).

[Fleeting Frames]

- Hm. You're right. Normally in my experience you don't get multi part names for generated visible sites, but there's player-generated sites as well as lairs that can do this. Wonder what happens if you move those? Added to above, anyway.
- Aye. Also added.
- That is correct. Hm, I suppose that explains the * 16 at the end of those lines as well...Which means potential segfault if trying to move a site that extends past the edge of the map on corner/edge tile. However, the issue is usability (gchristoper's original code actually requested destination coords - which meant another thing to lookup and type, slowing things down) + conflict with first point.
- Well, ideally, it'd iterate through all structures and buildings and maybe relations associated with site and move those as well, but I don't know what can actually be moved safely. Not sure how to do this at this time.

At least brief tests with embarking on moved sites moved gives nothing on both before and after locations (even when shared by multiple towers on new location).

[steel jackal]

oh hey sweet, i wasnt actually able to figure out how to move a tower even with the instructions. ill have to check this out next time i play.

i find it somewhat funny that a thread about necromancers got necrod; i was also supprised when i noticed my name in the "started by" list given that i havent made any threads recently.

and yes, i did just use a semicolon correctly; i just recently found out their purpose.

[PatrikLundell]

@Fleeting Frames:
- One way to deal with multiple part names would be to require quotes if there are blanks in the name (Didn't suggest that previously because I didn't think of it until now).
- If names are restricted to single items, region coordinates could be optional additional parameters (keeping the original ones if omitted).
- I don't know what can be moved safely either, which is why I suggested using a "safe" subset. I don't know if necro towers have claims, for instance. If they do, those can probably be moved safely. Hamlets etc. seem to have a rather tangled web of relations.

@steel jackal: A couple of additional steps on the writing self study course could include the usage of capital letters and spelling

[Fleeting Frames]

Mm. I don't currently plan on adding back in numerical way to specify target region, but if I were to, quotes would be indeed be neat way to handle names like "9 and three quarters" or "Voyager 1969" for player-created sites. Most optionally multiparameter scripts use -name, but this is more concise.

[anewaname]

i find it somewhat funny that a thread about necromancers got necrod; i was also supprised when i noticed my name in the "started by" list given that i havent made any threads recently.

Someone has been pulling your threads!

[PatrikLundell]

@Fleeting Frames: Looking at a necro tower, I find that it's considered to be a Fortress at the top level.
However, the part of interest is that it is associated with a Site Government entity (which probably goes for all sites) which has the tower site (and its coordinates) as one of its site links (the others were to a criminal gang and a market). When moving a site, its Site Government entity's site back link should probably have its world coordinates updated.
I also found that the claims section of the Site Government was empty, so that part doesn't need any treatment.

Edit:
I modified Fleeting Frames' script to update the entity link to the site government, but that had no visible effect: the site still does not appear at the target location, and embarking on it fails to provide a tower at the embark (I checked that embarking at the original location did get the tower at the embark [full of sleeping/unconscious(!) undead]). I've tried to find more references to the location, but failed to do so. Moving the tower, embarking elsewhere, abandoning, and bringing back the save for a new embark still did not show the tower, so it's not just a matter of something built on the fly on world loading that doesn't get refreshed.
Thus, my conclusion is that there is another structure somewhere that needs to be updated to complete the tower movement, but I've run out of ideas of where to look for it. As a result of thinking prodded by a question from Roses I've realized that an ability to move "real" sites at the civ placement world gen stage ought to allow you to "correct" placement of civ starting sites that did not get generated where they should be.

Edit 2:
The region map entry has a list of links to sites. Moving the appropriate link to the new tile and setting that tile's has_site flag to true causes a moved necro tower to show up in the new location on the world map, but it still remains absent both on the region map and embark, so there's still something missing.

[PatrikLundell]

Double posting as the previous post was made some time ago, and editing doesn't trigger "new" flags...

I've finally been able to move a necro tower successfully. It turned out Fleeting Frames had made an unfortunate copy&paste error when assigning global_max_y. Anyway, in addition to the original movement of the site, I've updated the link between the site and the site government, as well as moved the site reference from the source world tile to the destination one, set the has_site
flag on the destination, and reset it at the source if the site was the only one there.

mv_site.lua:

Spoiler (click to show/hide)

Code: [Select]

local args = {...}

function mv_site(names)
  local name = ""
  for k, partOfName in pairs(names) do
    if partOfName then
      name = name .. partOfName .. " "
    end
  end
  name = string.sub(name, 1, (string.len(name)-1))
  if (tostring (args [1]) == NIL) or (tostring (args [1]) == "") then
    dfhack.println("This script moves a named site to current region tile. You must pass a native or translated name.")
  else
  local id = -1
 
  for ii, site in ipairs (df.global.world.world_data.sites) do
if string.upper (tostring(dfhack.TranslateName (site.name, false))) == string.upper (tostring (name)) or
   string.upper (dfhack.TranslateName (site.name, true)) == string.upper (tostring (name)) then
  id = ii
  break
end
  end
 
  if id == -1 then
dfhack.println("Didn't find site " .. name)

  else  
  local x = df.global.world.world_data.region_details [0].pos.x
  local y = df.global.world.world_data.region_details [0].pos.y
  local curr_x = df.global.world.world_data.sites [id].pos.x
  local curr_y = df.global.world.world_data.sites [id].pos.y
  local site = df.global.world.world_data.sites [id]

  df.global.world.world_data.sites[id].global_min_x = site.global_min_x + (x - curr_x) * 16
  df.global.world.world_data.sites[id].global_min_y = site.global_min_y + (y - curr_y) * 16
  df.global.world.world_data.sites[id].global_max_x = site.global_max_x + (x - curr_x) * 16
  df.global.world.world_data.sites[id].global_max_y = site.global_max_y + (y - curr_y) * 16

  site.pos.x = x
  site.pos.y = y

  for i, site_link in ipairs (df.global.world.world_data.region_map [curr_x]:_displace (curr_y).sites) do
    if site_link == site then
  dfhack.println ("Site link found: moving...")
  df.global.world.world_data.region_map [curr_x]:_displace (curr_y).sites:erase (i)
 
  if #df.global.world.world_data.region_map [curr_x]:_displace (curr_y).sites == 0 then
    df.global.world.world_data.region_map [curr_x]:_displace (curr_y).flags.has_site = false
  end
 
  df.global.world.world_data.region_map [x]:_displace (y).sites:insert ('#', site)
  df.global.world.world_data.region_map [x]:_displace (y).flags.has_site = true
 
  break
end
  end
  for i, entity_link in ipairs (site.entity_links) do
    if entity_link.target_site_x == curr_x and entity_link.target_site_y == curr_y then
  entity_link.target_site_x = x
  entity_link.target_site_y = y
  dfhack.println ("Moving entity link")  
end
  end

  dfhack.println("Moved site " .. name .. " to " .. x .. " , " .. y)
  end
  end
end

mv_site(args)

Note that I haven't tried moving anything but that necro tower, but at least it shows up in the new region and it's possible to embark on top of it (provided "embark anywhere" is enabled).

Edit:
I tried moving a dark fortress during civ placement in world gen, and it looks like it worked (only two tiles, but nevertheless). My first attempt moved a human hamlet instead (array indices are one off from site id:s), but it looked like that worked as well.
I'm considering writing a breakout box based script to move goblin starting sites to predetermined locations in a PSV world to keep those where they're supposed to be.

[gchristopher]

Nice! Way to go!

My criteria for moving necro towers was that it showed up on the neighbors list in the site finder and generated invasions for a player fortress. I didn't test anything beyond that.

But it definitely worked for getting every fortress in the world moved nearby to get more necro invasions.

[Fleeting Frames]

The copy-paste error was there in original code (didn't notice it), though as far as I can tell just altered within the local 16x16? But nice, a straight-out upgrade

One of the things I've been specifically interested in doing has been letting towns grown isolated and then moving them where I desire, and I guess this very much helps that.

[PatrikLundell]

No, the difference was a rather substantial one: my 2, 76 tower got a global Y value of -1200 or something like that from being moved to 1, 75 ...
I got rather suspicious when I moved a tower and then returned it, and it still was lost...

Yes, isolated growth ought to work, but I'm not too keen on leaving long distance site links (such as market places, brigand groups, etc) which would probably happen when moving isolated established habitations.

One thing I thought of in world gen is movement of caves so they don't block the intended starting positions for various races.

Edit: I just remembered I'd forgotten about claims. They should probably be moved as well.

Question: Do lairs block the placement of a habitation the same way caves do? Could it be that habitations are incompatible with any other kind of site? What about vaults (I've never actually encountered one in the game)?

[Fleeting Frames]

Well, it still added them to neighbours, like gchristoper said. Not sure what's up with that then, maybe it was like super-long site?

Only 1 site per world tile, so yeah vaults will block it, even if they're only 1x1 local tile. Can be quickly checked with a pocket world:


The empty point at 0,0? Cave.

The other 5 empty squares? Vault in the center at map edge (0,11). Interestingly, this "leave some space" also tends to occur with towers blocking later pits (but not sites blocking towers or such, thankfully). (On that note, while mid-worldgen site moving doesn't seem like worth the effort, two uses: move the site nomading necro hails from just before the spam begins, so you can get up to like 99 towers into a 10x10, and instating a brief war with desired civ so that your fort is only eligible target.)

As for lairs, there are 389, and they're all over the place by legends xml. Though I guess they're instated last, and would block site placement post-worldgen.

[PatrikLundell]

If the X and Y coordinates of your source and destination locations were about the same (i.e. diagonal movement) replacing X for Y doesn't make much of a difference, especially since you can be 10 tiles off both up and down while still being in range, but in my case I had a massive difference.

Thanks for the site blockage investigation.

My current plan is to make a PSV world and a civ placement world gen breakout script for it once the next DF version is released. While DFHack won't be available, the release notes should help inform me on how to make the PSV world, and the script can be tried out using the current version and then wait for DFHack to catch up for the "real" world to be generated.

I'm hazy on how nomadic necros work, but it's not important to me anyway. It does sound nifty to be able to generate a lot of towers for those who aren't satisfied with one or two, though.

Edit: I've tried habitation movement during world gen, and it doesn't work as desired. I've been able to move the sites, but when the source and destination are on the same landmass new sites are sprouted near the original site locations, not near the targets. When moved between landmasses the sites become sterile. I've found an unnamed structure at the end of the civ data that contains region and landmass pointers, but changing those to match the destination didn't do anything (haven't tried that on the same landmass, though). In one case moved human sites transplanted into forest resulted in tombs sprouting around them, but that's not exactly the kind of expansion we want. Gobbos moved from one low savagery plain landmass to another low savagery plain landmass still become sterile. It also seems the civ's claim data gets wiped somewhere, even though I've changed the claim from the original tile to the destination one as part of the transplantation.
It all indicates there are required connections missing, so for the time being we should probably stick to transplanting "simple" things like necro towers.
When it comes to keeping your races to stick to desired starting positions, it might be better to hack the gobbos to have a single starting biome (like dwarves have), and remove that biome from other races starting set.

Edit 2:
Still no success on the habitation movement front. What I've found so far:
- The site has a position
- There are entity links with the site's position. During world gen "market" links can be made to nearby moved sites, but these links differ from ordinary links in that each of the sites in the pair has its own (rather than a shared link) with the own location as the position. (The necro tower I've played with had a market link that had a position at a human hamlet).
- The civ entity has a claim area consisting of the location of the site during world gen. It grows during history. I can make no sense out of the global claim1/2 structures, though.
- The civ entity has a pair of fields in the form of unknonwn2.unk14 and .unk15 pointing to the starting site's locations region and landmass entries, although the pointers seem to be mixed up by the DFHack layout description.
- There's a "resource allotments" structure in world data for each starting site and it contains the site coordinates. The site government refers to this allotment. During world gen more allotments are generated with coordinates of new sites, but they are fewer than the number of sites.

I've adjusted all of the coordinates above as well as the region/landmass pointers, but DF stubbornly generates new habitations around the original site location if the site is moved "short" distances only (my 33 * 33 test world contains 4 landmasses with uniform biomes on each), but refuse to produce anything but tombs (humans), refugees, and performance troupes when moved to a different landmass. Somewhere there is a structure where DF holds the locations from which to spread habitations, but I can't find it. With a mixture of moved and untouched sites 3*3 "holes" are left unsettled on landmasses otherwise completely filled with habitations after running the history. These holes form around moved sites, but I think the empty holes mark where sites were located before being moved.