Print

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

[Quietust]

The first map_block_column per embark square has the plant data, and no plants can cross embark square boundaries.

This is because if they were stored per column, they wouldn't be able to cross map_block boundaries.

To clarify, each map_block_column covers a 16x16 area (the "map_pos" field tells you exactly where it is) and mainly keeps track of special elevations or things which are independent of elevation. In older versions, map_block itself held the list of local plants, but the addition of large trees (which span multiple Z-levels) required moving it to map_block_column, and the fact that trees can span multiple map_blocks is why they're only stored in one column out of each 3x3 group (and why they can't extend between region tiles, which made it possible for Toady to much more easily keep terrain generation in Adventurer mode consistent).

[Roses]

New update on tree deletion. Successfully deleting the tree from the three different lists (plants.all, plants.tree_dry/tree_wet and map_block_column.plants) will remove the tree from the game and leave all tiles connected to that tree as just saying Tree. The game was fully able to be saved and reloaded as well. Even without changing the tile types. I have also figured out how to identify the position of each branch, thick branch, trunk, and twig of the tree so that they can be set to the correct tiletype.

[Warmist]

New update on tree deletion. Successfully deleting the tree from the three different lists (plants.all, plants.tree_dry/tree_wet and map_block_column.plants) will remove the tree from the game and leave all tiles connected to that tree as just saying Tree. The game was fully able to be saved and reloaded as well. Even without changing the tile types. I have also figured out how to identify the position of each branch, thick branch, trunk, and twig of the tree so that they can be set to the correct tiletype.

Such hatred for trees to go to these length to destroy them without leaving anything.

[PatrikLundell]

New update on tree deletion. Successfully deleting the tree from the three different lists (plants.all, plants.tree_dry/tree_wet and map_block_column.plants) will remove the tree from the game and leave all tiles connected to that tree as just saying Tree. The game was fully able to be saved and reloaded as well. Even without changing the tile types. I have also figured out how to identify the position of each branch, thick branch, trunk, and twig of the tree so that they can be set to the correct tiletype.

Interesting. A tangent question I get as a result is if the bugged underground tiles described as "grass" that sometimes appear are the result of a similar process, i.e. if they're "actually" underground fungal "grass", but the plant object has somehow been lost?

[Rose]

Probably. Grass is stored on a contaminant layer, similar to mud and blood splatters. So it's possible that the actual grass is missing from there, but the tiletype is still grass.

[PatrikLundell]

Probably. Grass is stored on a contaminant layer, similar to mud and blood splatters. So it's possible that the actual grass is missing from there, but the tiletype is still grass.

Are you sure? As far as I've seen grass is stored as plants together with trees and shrubs? Mud and blood can lie on top of grass (just look at mud covered caverns!). However, blood can coexist with mud as well, so that's not much of an argument. However, I'll be on the lookout for unspecified grass tiles underground to take a closer look.

[Rose]

Considering that I read the grass in order to show it in both armok vision and stonesense, yes, I'm sure.

[Quietust]

Probably. Grass is stored on a contaminant layer, similar to mud and blood splatters. So it's possible that the actual grass is missing from there, but the tiletype is still grass.

Are you sure? As far as I've seen grass is stored as plants together with trees and shrubs? Mud and blood can lie on top of grass (just look at mud covered caverns!). However, blood can coexist with mud as well, so that's not much of an argument. However, I'll be on the lookout for unspecified grass tiles underground to take a closer look.

Yes, he's sure - they're stored within "block_square_event_grassst" records, along with "block_square_event_mineralst" for mineral veins and "block_square_event_material_spatterst" for contaminants.

[utunnels]

By the way, does anybody tried 43.05 alpha2 for 32bit windows?

Here's what I got. It seemed none of the paths are available, how?


Could not load dfhack-config/script-paths.txt
Plugin does not exist: 3dveins
Plugin does not exist: add-spatter
Plugin does not exist: autochop
Plugin does not exist: autodump
Plugin does not exist: autogems
Plugin does not exist: autohauler
Plugin does not exist: autolabor
Plugin does not exist: automaterial
Plugin does not exist: automelt
Plugin does not exist: autotrade
Plugin does not exist: blueprint
Plugin does not exist: building-hacks
Plugin does not exist: buildingplan
Plugin does not exist: burrows
Plugin does not exist: changeitem
Plugin does not exist: changelayer
Plugin does not exist: changevein
Plugin does not exist: cleanconst
Plugin does not exist: cleaners
Plugin does not exist: cleanowned
Plugin does not exist: command-prompt
Plugin does not exist: confirm
Plugin does not exist: createitem
Plugin does not exist: cursecheck
.............

Edit*

It seems to be the problem on the certain old machine without a video card.
I ran the 32bit version on a 64bit system and it worked.

[lethosor]

That looks like an issue with your filesystem of some kind. DFHack sees each plugin in the hack/plugins folder, so it tries to load it, but then it can't find the plugin in the folder any more.

As for the first message, if you installed DFHack manually, did you remember to copy the dfhack-config folder?

[PatrikLundell]

Thanks Japa and Quietust, now I'm with you. It's stored there as well as in the regular plants, not instead of, similar to how trees and shrubs are stored in an additional block location.

Edit:
I found an underground "grass" tile and the plants.all array had no reference to that coordinate and both of the two grass "events" for that block showed an amount of 0, so it looks like the tile's growth has been lost somewhere in the process (or the material hasn't been reverted).

[scourge728]

So I'm using the alpha for the new version, where do I get the "ruby library" to use startdwarves?

[Bumber]

New update on tree deletion. Successfully deleting the tree from the three different lists (plants.all, plants.tree_dry/tree_wet and map_block_column.plants) will remove the tree from the game and leave all tiles connected to that tree as just saying Tree. The game was fully able to be saved and reloaded as well. Even without changing the tile types. I have also figured out how to identify the position of each branch, thick branch, trunk, and twig of the tree so that they can be set to the correct tiletype.

Such hatred for trees to go to these length to destroy them without leaving anything.

We will make these trees unpersons. Soon they will be removed even from people's thoughts.

[utunnels]

As for the first message, if you installed DFHack manually, did you remember to copy the dfhack-config folder?

Yes I did. And I copied the whole folder from the 32bit machine to the 64bit one and it worked.

Edit*

Oh, dfhack-config is empty except for the default subfolder. It appeared dfhack failed to create files in that folder for some reason.

[lethosor]

So I'm using the alpha for the new version, where do I get the "ruby library" to use startdwarves?

Which is "the" alpha? There have been two, 0.43.05-alpha1 and 0.43.05-alpha2. The latter comes with a ruby plugin and runtime library.

As for the first message, if you installed DFHack manually, did you remember to copy the dfhack-config folder?

Yes I did. And I copied the whole folder from the 32bit machine to the 64bit one and it worked.

Edit*

Oh, dfhack-config is empty except for the default subfolder. It appeared dfhack failed to create files in that folder for some reason.

Was that 32-bit DFHack? I wouldn't expect 64-bit DFHack to launch at all on a 32-bit system, but that's very strange.