Print

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

[scourge728]

ptw

[bloop_bleep]

Hmm... I'm trying to think ahead here to the implementation of combat. I'm not yet sure whether I want the components themselves to participate directly in combat, and any dodging, throwing, etc. could be somehow detected and propagated up the line, or whether all combat logic should be handled by a single unit, whose decisions then move the components in the required directions.

This is relevant because apparently think_counter disables combat AI as well (according to warmist -- did I understand that correctly?), but [IMMOBILE] doesn't.

I guess I could just implement whatever now, and change it later if needed.

[bloop_bleep]

I have decided to go with [IMMOBILE] for now, creating a MT_COMPONENT creature variation adding that tag and eventually the doubtless countless others that will be needed for this to work properly.

I have another question, however. In which data member is the allegiance (the "side") of an arena creature stored? I've used gui/gm-editor but I can't seem to find it.

EDIT: Never mind, turns out enemy.enemy_status_slot contains it. I needed to use it to make sure that the allegiances of all the components match the allegiance of the root component.

EDIT: Actually, another question: what's the difference between the unit path goals ChaseOpponent, ChaseOpponentFlood, and ChaseOpponentSameSquare?

EDIT: And yet another: would modifying a creature_raw's vector of string raw tags (data member raws) actually take effect on the creatures with that creature_raw?

[Roses]

I have decided to go with [IMMOBILE] for now, creating a MT_COMPONENT creature variation adding that tag and eventually the doubtless countless others that will be needed for this to work properly.

I have another question, however. In which data member is the allegiance (the "side") of an arena creature stored? I've used gui/gm-editor but I can't seem to find it.

EDIT: Never mind, turns out enemy.enemy_status_slot contains it. I needed to use it to make sure that the allegiances of all the components match the allegiance of the root component.

EDIT: Actually, another question: what's the difference between the unit path goals ChaseOpponent, ChaseOpponentFlood, and ChaseOpponentSameSquare?

EDIT: And yet another: would modifying a creature_raw's vector of string raw tags (data member raws) actually take effect on the creatures with that creature_raw?

I can't answer the path goals question, but he's, modifying the raws through dfhack does influence all creatures with those raws, but it resets when you quit and reload

[bloop_bleep]

I can't answer the path goals question, but he's, modifying the raws through dfhack does influence all creatures with those raws, but it resets when you quit and reload

Thanks!

Anyway, another update. So I found out, when you make a creature [IMMOBILE], they never take a job or set their path goal ever, for any amount of time, not even when there is an enemy two tiles away, which I guess is to be expected. What this means, however, is I can't detect a multi-tile creature's intentions -- whether it wants to attack or flee, wander about, anything that a usual creature would do. I don't want to re-implement vision cones, sneak sensing etc. to reproduce the creature's intentions. This could be worked around, however, if certain 'observer' components of the multi-tile creature were not [IMMOBILE] and thus could set path goals, so that my code could pick up on those (and immediately reprogram the actual paths themselves to whatever makes sense.)

However, this would require separate raws for the observer and non-observer components. In this case I let each component entry in the creature template file specify whether it represents an observer or not. If not, then during multi-tile creature spawning the component will be created from a special creature raw constructed during template loading, which is copied from the original that it otherwise would be, but [IMMOBILE]. It works now, so I can get to writing code to catch the observer path goals before the multi-tile creature dismembers itself.

[bloop_bleep]

I have run a couple experiments in fort mode to attempt to find a method of making the components automatically follow in the direction of the root unit, so that the creature stays together without special handling in my code.

I was hoping dragging might work, as there were two possible ways it could be implemented that came to my mind, only the latter of which would be useful: either the draggee is moved into the *position* that the dragger last occupied, or the draggee is moved in the *direction* that the dragger last moved in. I embarked and assigned a horse to pasture, and then teleported it two tiles away from the dwarf as the job was in progress, seeing if it would spring forward and continue following the dwarf at one tile away, as previously, or if it would continue following at two tiles away. Alas, the former implementation method turned out to be the reality, so dragging cannot be used in my case.

I then tried using mounting to accomplish the desired effect. I used Rumrusher's online script to try to mount a mason on a woodworker; however, it crashed initially by trying to access the 'relationships' data member of the rider unit. I originally didn't know how to fix it, so I just commented out that line and hoped for the best; in doing so, however, I managed to accidentally stumble upon exactly the sort of thing I needed for observer components -- although the woodworker (the mount) wandered about as normal, the mason (the rider) was completely immobilized, but *still attempted to take jobs.* I suppose setting the 'rider' flag while not completing the cross-references creates this effect, so warmist, if you still need such a method but don't want to go the route of copying the raws entirely like I did for non-observer components, then here it is.

I suspected commenting out the line that accesses the 'relationships' data member was the culprit for this strange behavior, so I decided to check if units actually have a 'relationships' data member through gui/gm-editor, and thus found the 'relationship_ids' member. Surmising that this was the replacement for the original, I edited Rumrusher's code accordingly, booted up a new world and new embark, and this time mounted a woodcutter on a yak, then designated a swath of trees to be felled. The woodcutter took the woodcutting job, but both woodcutter and yak were immobile for a moment. Then the yak moved, and as far as I could deduce the woodcutter immediately teleported onto the yak's back. However, both of them wandered about the wagon, like the yak would normally do, instead of moving towards the tree that was the object of the woodcutter's job.

These findings seem to imply a startling fact: that the *mount* is in fact the unit that is leading and is responsible for pathing, not the rider. Those goblins which storm your fortress on beak dogs are actually entirely subservient to their beak dogs (at least, until the beak dogs get killed). This might change soon enough, though, as Toady introduces adventurer mounts; I assume he intends the player to have at least some measure of control over their mount.

In any case, mounting will not be useful to me either, as I do need components to stay on different tiles. I guess I will have to manually assign paths and/or movement velocities for every component in the creature.

[LeoCean]

I find this pretty neat but idk if you know that mutli tile creatures will be possible for steamdf release, and steam df's features will be in the df updated here, just without graphics. But I assume the mutli tile creatures would be included. Note they'll take up one units space while moving but be 1x2, 2x2(tiles) visually. It's mentioned in Steam DF tileset - Mayday/Meph - Discussion and Suggestions.

[bloop_bleep]

I was not aware of that, but that seems to be a mostly aesthetic feature, in that creatures remain functionally the same but their sprites are allowed to be bigger. (Correct me if I’m wrong, though.) What I’m aiming for is to allow multi-tile creatures that are indeed spread out over several tiles — so that you have to be adjacent to a creature’s leg tile if you want to attack its leg, for example, and additionally so that the multi-tile creatures will be able to move their component parts relative to each other, allowing them to bend their joints, etc. I believe that these added mechanics will greatly increase the depth of combat, as one now will need to pay greater attention to how they move around their opponent’s body. There’s also the coolness factor of witnessing and fighting enormous behemoths in adventure and fortress mode.

[Bumber]

These findings seem to imply a startling fact: that the *mount* is in fact the unit that is leading and is responsible for pathing, not the rider. Those goblins which storm your fortress on beak dogs are actually entirely subservient to their beak dogs (at least, until the beak dogs get killed).

It's not so surprising that the issue with mounted toads drowning their own riders wasn't at the riders' orders.

[bloop_bleep]

For a couple hours today I was searching for the source of an absolutely bizarre bug where for some reason the multi-tile creature components would only be spawned correctly if the root unit was a female, and instead be spawned with the original dwarf raws instead of the artificially created immobile ones if the root unit was a male.

I eventually pinpointed the problem to be happening somewhere within create-unit.lua, but even after setting up debugging statements within that file, I could not locate the problem.

Then it dawned on me. create-unit.lua was inserting the raw/caste ids of the immobile raws at the beginning of the appropriate vectors in the arena creature spawning viewscreen as required, but incorrectly choosing the *second* entries in those vectors (those that corresponded to the original dwarf raws) when the root unit is male. The source for this? When I create the male root unit, I move down to the *second* entry in the same viewscreen (as opposed to staying at the first as with females), and apparently that position is carried over to the next time this viewscreen is opened by create-unit.lua.

That was horribly difficult to find, as you might imagine.

This bug is easily fixed by changing a section of code in create-unit.lua on lines 155-159 from

Code: [Select]

  if dfhack.world.isArena() then
    -- Just modify the current screen in arena mode (#994)
    spawnScreen.race:insert(0, race_id)
    spawnScreen.caste:insert(0, caste_id)
  end

to

Code: [Select]

  if dfhack.world.isArena() then
    dfhack.print("dfhack.world.isArena()")
    -- Just modify the current screen in arena mode (#994)
    spawnScreen.race:resize(0)
    spawnScreen.race:insert(0, race_id)

    spawnScreen.caste:resize(0)
    spawnScreen.caste:insert(0, caste_id)
  end

.

What are the proper channels to go through to notify the DFHack team about this? Do I just send one of the devs a PM?

EDIT: Actually, the above on its own isn't enough. You also have to insert the line

Code: [Select]

  spawnScreen.layer_objects[1]:setListCursor(0)

right after the first code segment.

EDIT 2: In my research on how to artificially make the components move, I may have discovered the meaning of unit::T_job::unk_v40_5 -- it seems to signify direction of movement, albeit in a somewhat odd way.

[Warmist]

<... stuff about create_unit ...>

i remember a problem with that. In arena mode :resize(0) might mess up normal unit spawning. Also remember it not working correctly if the filter is not empty.

Anyway correct way of addressing this is adding an issue to dfhack github page and/or a pull req with a fix.

[Rumrusher]

uhh later ended up crashing the game trying to coil around a hostile unit so uhhhh maybe in the works

[bloop_bleep]

<... stuff about create_unit ...>

i remember a problem with that. In arena mode :resize(0) might mess up normal unit spawning. Also remember it not working correctly if the filter is not empty.

Anyway correct way of addressing this is adding an issue to dfhack github page and/or a pull req with a fix.

Well, the :resize(0) is only done on the current arena spawn screen in the code I posted. A global :resize(0) (that is, on df.global.world.arena_spawn) is done in a previous code segment (lines 132-142, below), which is specifically only run if not in arena mode. The default creature creation screen seems to work fine afterwards. Additionally, the filter is not empty as I always search for "dwarf" before creating the root unit, but it works okay (with my mentioned changes).

Code: [Select]

  if not dfhack.world.isArena() then
    -- This is already populated in arena mode, so don't clear it then (#994)
    df.global.world.arena_spawn.race:resize(0)
    df.global.world.arena_spawn.race:insert(0,race_id)

    df.global.world.arena_spawn.caste:resize(0)
    df.global.world.arena_spawn.caste:insert(0,caste_id)

    df.global.world.arena_spawn.creature_cnt:resize(0)
    df.global.world.arena_spawn.creature_cnt:insert(0,0)
  end


uhh later ended up crashing the game trying to coil around a hostile unit so uhhhh maybe in the works

Although that method is interesting would be useful for snake-like creatures, it will not work every time in my case, as sometimes multiple children have to be connected to a single parent -- which means that they will all move to the same tile if they are dragged behind the parent.