Print

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

[armeggedonCounselor]

The first post says that superdwarf can be used in Adventure Mode. How do I use it? Does my adventurer have to be a dwarf?

you should be able to place the cursor on the adventurer.

Using 'l'ook? Or do I need to use something else?

[Rumrusher]

The first post says that superdwarf can be used in Adventure Mode. How do I use it? Does my adventurer have to be a dwarf?

you should be able to place the cursor on the adventurer.

Using 'l'ook? Or do I need to use something else?

look or talk

edit: okay so I just got spawnunit to work in r3, though it's the one warmist made originally and not his more recent version but at least now I can do something else.
oh and known quirks with spawnunit:
spawning more than 1 unit at a time will crash the game when you unload the area. the names don't match up when you talk to ungbuga. while you can attack ungbuga you might not land a hit so best not provoke ungbuga unless you have some firebreath or syndrome base attack to do damage. the script currently spawns a peasant who doesn't attack any one.

[Meph]

That sounds great.

What narihil/deon/me would be using this ingame for is running a reaction in a workshop that spawns a creature on it. I could get as far is making a workshop, creating a rock that triggers autosyndrome, and the syndrome runs "\command \spawnunit". That way the dwarf runs the script in fortress mode. It only needs to know the location of the workshop or dwarf, and some kind of input for the creature id. "spawnunit cat" and "spawnunit goblin", something like that.

spawning more than 1 unit at a time will crash the game when you unload the area.

This sounds like a serious obstacle ^^

[Putnam]

Well, spawning units is really, really hard.

[Rumrusher]

Well, spawning units is really, really hard.

well that's only for adventure mode, fort mode perfectly fine with spawning that many units... spawning that many units in fort mode in unison will make it impossible to save right away. though I don't know what causes that to happen. best bet is adventure mode spawn one then unload the area then spawn another.

[Kurik Amudnil]

I have made an adaptation of unsuspend.rb and autounsuspend.rb for the purposes of fixing handedness on gloves created through custom reactions.

fixhandedness.rb

Spoiler (click to show/hide)

Code: [Select]

# Fix handedness of gloves created by custom reaction


gloves=df.world.items.other[:GLOVES] # the collection of GLOVES
hand=0 # which hand  0=right, 1=left
count=0
gloves.each do |glove|
# if glove is unhanded (right and left = false, fix it)
unless glove.handedness[0] or glove.handedness[1]
glove.handedness[hand] = true # enable hand
hand ^= 1 # switch hand for next glove
# XOR assignment: 0 ^ 1 = 1 ; 1 ^ 1 = 0
count += 1
end
end

puts "Fixed #{count} unhanded glove(s)." unless count == 0


autofixhandedness.rb

Spoiler (click to show/hide)

Code: [Select]

# autofixhandedness [start|stop|end|status] ; Autofix handedness of gloves created by custom reaction

class AutoFixHandedness

def initialize
@running = false
end

def process
return false unless @running

gloves=df.world.items.other[:GLOVES] # the collection of GLOVES
hand=0 # which hand  0=right, 1=left
count=0
gloves.each do |glove|
# if glove is unhanded (right and left = false, fix it)
unless glove.handedness[0] or glove.handedness[1]
glove.handedness[hand] = true # enable hand
hand ^= 1 # switch hand for next glove
# XOR assignment: 0 ^ 1 = 1 ; 1 ^ 1 = 0
count += 1
end
end

puts "Fixed #{count} unhanded glove(s)." unless count == 0

end

def start
# 2400 = once every 2 dwarf days ; 1200 = once every dwarf day
@onupdate = df.onupdate_register('autofixhandedness', 2400) { process }
@running = true
@item_next_id = 0
end

def stop
puts @onupdate
df.onupdate_unregister(@onupdate)
@running = false
end

def status
@running ? 'autofixhandedness: Running' : 'autofixhandedness: Stopped'
end

end

case $script_args[0]
when 'start'
    $AutoFixHandedness = AutoFixHandedness.new unless $AutoFixHandedness
    $AutoFixHandedness.start
puts $AutoFixHandedness.status

when 'end', 'stop'
    $AutoFixHandedness.stop
puts $AutoFixHandedness.status
else
    if $AutoFixHandedness
        puts $AutoFixHandedness.status
    else
        puts 'Autofix Handedness not loaded.  To start it, use: autofixhandedness start'
    end
end



I set the auto check to 100 ticks and I think it can be set longer 2400 ticks for once every 2 dwarf days as I don't expect custom reaction gloves to be created frequently. 

*edited to increase the auto ticks, give start/stop feedback, to have a help string in the dfhack console's script listing, and improve the comments.

[xcorps]

The link in the OP is down, anyone have an alternate source for downloading?

[gchristopher]

Is anyone aware of how the game determines what map edges tiles are eligible for diplomats/traders/migrants and whether it can be changed?

It looks like the initial position of the embark wagon determines map edge eligibility. Does the game record the initial position of the wagon somewhere? The building record seems to be removed when the wagon is deconstructed.

Does the game dynamically figure out where the wagon should have appeared each time if processes a migrant, caravan or diplomat event? Can you trick it at that point by changing the surface tile types beforehand to create a new set of path-eligible map edges? (Actually, that's easily testable. I'll try it.)

edit: Modifying the map tiletypes to change which map area connects to the original wagon location updates world.map.map_blocks.walkable, but does not affect where caravans and liasons appear. Maybe that indicates the map edge is somehow flagged?

Is it a flag stored somewhere per-tile? I'm pretty sure it's not any data under df.global.world.map. Editing bap_blocks.walkable doesn't change it. Maybe it's in memory that dfhack doesn't index?

I still haven't had any luck finding something in the lua-addressable dfhack interface that relates to where visitors can appear.

Does anyone have an evidence of the accessible edge tiles varying by civilization?

[Kurik Amudnil]

Is anyone aware of how the game determines what map edges tiles are eligible for diplomats/traders/migrants and whether it can be changed?

It looks like the initial position of the embark wagon determines map edge eligibility. Does the game record the initial position of the wagon somewhere? The building record seems to be removed when the wagon is deconstructed.

Does the game dynamically figure out where the wagon should have appeared each time if processes a migrant, caravan or diplomat event? Can you trick it at that point by changing the surface tile types beforehand to create a new set of path-eligible map edges? (Actually, that's easily testable. I'll try it.)

edit: Modifying the map tiletypes to change which map area connects to the original wagon location updates world.map.map_blocks.walkable, but does not affect where caravans and liasons appear. Maybe that indicates the map edge is somehow flagged?

Is it a flag stored somewhere per-tile? I'm pretty sure it's not any data under df.global.world.map. Editing bap_blocks.walkable doesn't change it. Maybe it's in memory that dfhack doesn't index?

I still haven't had any luck finding something in the lua-addressable dfhack interface that relates to where visitors can appear.

Does anyone have an evidence of the accessible edge tiles varying by civilization?

 I had a fort where I made a covered road from the map edge to my depot by way of raised bridges on the side and constructed floors above it at the edge before it went underground.  After some forgotten beasts made a mess of things I reclaimed and that section of covered edge was no longer a valid spawning point for caravans (and probably others) even after deconstructing the floor above.  If I knew were to look I could try to see if there is data value involved.  I suppose another reclaim after uncovering those edge tiles might fix it too,  but the other reclaim bugs I had made that fort rather disappointing.

[gchristopher]

I had a fort where I made a covered road from the map edge to my depot by way of raised bridges on the side and constructed floors above it at the edge before it went underground.  After some forgotten beasts made a mess of things I reclaimed and that section of covered edge was no longer a valid spawning point for caravans (and probably others) even after deconstructing the floor above.  If I knew were to look I could try to see if there is data value involved.  I suppose another reclaim after uncovering those edge tiles might fix it too,  but the other reclaim bugs I had made that fort rather disappointing.

That would be consistent with it being re-calculated on each embark, then stored with the site data for the duration of that embark.

Oh hey! I found a likely data sequence in world.sav that matches this theory!

Bastardizing the bt hex edit format from the world parsing thread, something like this, where they're all 16 bit integers.

short count_x;
short x_coords[count_x];
short count_y;
short y_coords[count_y];
short count_z;
short z_coords[count_z];

Where all the count_.'s are the same, and the resulting coordinates appear to match the edge tiles. I can see gaps in the sequence where trees are growing on the map edge. I'll try editing this section and see if my caravan moves around.

Um, this might not relate to dfhack anymore, except to maybe help identify how the migrant/caravan/diplomat-eligible tiles might appear in memory. Please tell me if it should move to another thread.

Edit: Success! The visitor-eligible tiles are definitely determined at embark, and stored in a static set of coordinates that can be edited to change where they may appear. That doesn't completely rule out other sets of coordinates for other civilizations.

[Quietust]

The values you found were probably ui.map_edge.* (or possibly ui.unk_mapedge_[xyz].

[gchristopher]

The values you found were probably ui.map_edge.* (or possibly ui.unk_mapedge_[xyz].

Yep. The values appear to match df.global.ui.map_edge.surface_[xyz].

That's probably what controls the locations for diplomats, caravans and migrants.

Thanks!

I wonder what would happen if you added non-edge coordinates to the list? Build a microcline box around the spot and make a diplomat TARDIS?

[BriseRotule]

So looking at generating combat log outside of the reports screen menus ifoudn a link between
unit->reports.log[0] and the world->reports structure. Those int32 in the first structure are id for the second. That way i'm able to regenerate the reports menu.I can't check it right now, but i think the vector unit->reports.log[1], unit->reports.log[2] might be linked to sparring session and something (have to investigate further).

I think this is usefull and should be mentionned in the xml file as comment to put in the headers, who should i contact once my work is done on those fields ?

[ag]

I think this is usefull and should be mentionned in the xml file as comment to put in the headers, who should i contact once my work is done on those fields ?

It's all already known...

https://github.com/peterix/df-structures/blob/master/df.units.xml#L230

[BriseRotule]

I'm talking about :

Code: [Select]

<compound name='reports'>
    <static-array name='log' count='3' index-enum='unit_report_type'>
        <stl-vector type-name='int32_t' ref-target='report'/>
     </static-array>

     -- Garbage when the matching vector is empty:
     <static-array type-name='int32_t' name='last_year' count='3' index-enum='unit_report_type'/>
     <static-array type-name='int32_t' name='last_year_tick' count='3' index-enum='unit_report_type'/>
</compound>And in fact the 3 vector probably are for combat/sparring/hunting. should have looked at the xml files.