Print

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

[Immortal-D]

I'm sure I saw a command to create colony vermin (defaulting to bees). However, I thought the question was about regular animals rather than vermin or sapients?

Yeah, I'm after normal animals for a bit of !SCIENCE!.  I actually didn't even know that spawning vermin was a thing, lol.

[Quietust]

Then delete the plant object from the list. Don't forget that there are actually two other lists containing trees (one for dry, one for wet), also you need to delete the tree object itself or you will leak memory.

You'll need to remove it from the matching map_block_column as well (corresponding to its location within your embark region), otherwise the game will probably crash.

[Roses]

Then delete the plant object from the list. Don't forget that there are actually two other lists containing trees (one for dry, one for wet), also you need to delete the tree object itself or you will leak memory.

You'll need to remove it from the matching map_block_column as well (corresponding to its location within your embark region), otherwise the game will probably crash.

It doesn't crash, but it does corrupt the save, so that is something to be very careful with. I think for now I will set aside the tree deletion and work on the other things.

[Max™]

hmm in other dfhack ideas I wonder if it's possible to remove the site restrictions on building in adventure mode in towns and have it not make a new camp on top of the site either.

Uh, put a tile of paint m lava_flow st 1 sv 0 l 0 underneath you and you can build, but it'll make the campsite still to save your changes.

Hmmm, there's something I'm forgetting that lets this work, but standing on an actual lava flow or in hell (paint m magma btw) works.

[Rumrusher]

hmm in other dfhack ideas I wonder if it's possible to remove the site restrictions on building in adventure mode in towns and have it not make a new camp on top of the site either.

Uh, put a tile of paint m lava_flow st 1 sv 0 l 0 underneath you and you can build, but it'll make the campsite still to save your changes.

Hmmm, there's something I'm forgetting that lets this work, but standing on an actual lava flow or in hell (paint m magma btw) works.

I found a dfhack way to unlock building in adventure mode but doing anything in that mode will spawn a camp.
my question was is there a way to take over the site so the game doesn't make a camp and just save the changes to the site itself.
though this probably requires poking around what connects adv mode building to a site and what not.

[Max™]

Which flag/setting/etc unlocks it and I"ll fuck around with it next time I get on to hack around.

[Rumrusher]

Which flag/setting/etc unlocks it and I"ll fuck around with it next time I get on to hack around.

oh found it. apperently there an option that allows you to expand the " you can build here zone"
usually it set around 148 but looking into it it seems to span farther
so it's possible to just walk into town and flip a
unk 3124 the menu above the anon 46  or where the timer for building is keeps all the adventure building screen data.
which seems to have a user data stored for sites and what not.

and in there anon 1 -4 controls the size of the build zones
just recently discovered this and pokin around it but it might be possible to expand the adventurer build mode now

[Max™]

Oh, I can't even do it because the linux 64 ui_advmode is still missing.

[milo christiansen]

Then delete the plant object from the list. Don't forget that there are actually two other lists containing trees (one for dry, one for wet), also you need to delete the tree object itself or you will leak memory.

You'll need to remove it from the matching map_block_column as well (corresponding to its location within your embark region), otherwise the game will probably crash.

It doesn't crash, but it does corrupt the save, so that is something to be very careful with. I think for now I will set aside the tree deletion and work on the other things.

This is VERY good to know. I probably need to change my tree limit script!

[Roses]

Then delete the plant object from the list. Don't forget that there are actually two other lists containing trees (one for dry, one for wet), also you need to delete the tree object itself or you will leak memory.

You'll need to remove it from the matching map_block_column as well (corresponding to its location within your embark region), otherwise the game will probably crash.

It doesn't crash, but it does corrupt the save, so that is something to be very careful with. I think for now I will set aside the tree deletion and work on the other things.

This is VERY good to know. I probably need to change my tree limit script!

Granted I did a few things so I don't know what exactly it was that did it, but somewhere in step 4 and 5 after I saved and quit and tried reloading the save the game just crashed.

[milo christiansen]

Regardless, a dangling pointer to a reference I just deleted is a Bad Thing and should be avoided...

[Roses]

Then delete the plant object from the list. Don't forget that there are actually two other lists containing trees (one for dry, one for wet), also you need to delete the tree object itself or you will leak memory.

You'll need to remove it from the matching map_block_column as well (corresponding to its location within your embark region), otherwise the game will probably crash.

So looking into this I have gotten a little confused. What exactly are map_block_columns referring to? With a 96x96 embark cite I have 6x6 blocks (since blocks are 16x16). There are then 36 map blocks per z level. The game shows that I do indeed have 36 map block columns, and if I look at the individual columns they all seem to start and end at the correct x,y coordinates. So all of that is good, but when I look at the map_block_columns.plants thats where things get all screwy. It seems the first map_block_column contains all of the plants for the first 3x3 blocks. This trend continues for the entire grid such that for every nine blocks there is only 1 with plant data in it. The table below illustrates what I mean, with the green colored blocks representing the ones with plant data (if you are wondering why the strange numbering scheme that is how DF does it. I assume because this is a 2x2 embark so that each one square on the embark region cooresponds to 3 blocks)

0	3	6	9	12	15
1	4	7	10	13	16
2	5	8	11	14	17
18	21	24	27	30	33
19	22	25	28	31	34
20	23	26	29	32	35

*Note that I messed up the numbering slightly. DF goes down before across so the 9-17 blocks should trade places with the 18-26 blocks

So basically I am just wondering, am I confusing what map_block_columns are, or is it just that only one map_block_column per embark square actually contains the plant data?

[mifki]

So basically I am just wondering, am I confusing what map_block_columns are, or is it just that only one map_block_column per embark square actually contains the plant data?

I haven't read everything, but here's the code I use. Oh, I mean I don't know why it's so, so it doesn't answer your question, but I confirm that's how it works.

Code: [Select]

                local mapcol = df.global.world.map.column_index[math.floor(x/48)*3][math.floor(y/48)*3]
               
                for i,p in ipairs(mapcol.plants) do
                    if not p.tree_info then
                        local pos = p.pos
                        if pos.x == x and pos.y == y and pos.z == z then
                            --found the plant
                            local plantraw = df.plant_raw.find(p.material)
                            --...
                            break
                        end
                    else
                        --handle trees differently
                    end
                end


[Snafu]

What exactly are map_block_columns referring to? With a 96x96 embark cite I have 6x6 blocks (since blocks are 16x16). [...] It seems the first map_block_column contains all of the plants for the first 3x3 blocks. This trend continues for the entire grid such that for every nine blocks there is only 1 with plant data in it.

Is it possible that trees/branches are 'bleeding over' into your embark (check also Z-levels)?

[Rose]

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.