Print

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

[bloop_bleep]

So, I was thinking that it might not be completely impossible to implement multi-tile creatures with DFHack.

The basic idea I had was this -- multi-tile creatures would consist of a "parent" creature and many "child" creatures. The parent creature is the creature that gets exposed to legends mode and historical records ("<name> is a <parent creature>. It was one of the first of its kind." or "This <parent creature> has devoured ten in its lust for blood!"), while the child creatures get exposed to direct adventure/fortress mode gameplay. The children would each represent one tile of the creature, and would be connected to each other using a network of either dragging or grappling references. Units in adventure mode or fortress mode would interact with each child creature separately, attacking its components as if it were standalone.

There are several accomplishments that have to be made in order for this to work:

• Prevent children creatures from being exposed to legends mode records. Some of this can be accomplished by adding [DOES_NOT_EXIST] to children creatures, but creating them anyway when it is determined that a multi-tile creature should be spawned. Additionally, whenever a child creature becomes a histfig, through killing a fortress member or something similar, the histfig endowment could be passed along to the parent creature, or deleted if the parent is already a histfig.
• Prevent parent creatures from being exposed to direct adventure/fortress mode gameplay. For this, I am very doubtfully guessing that it might be sufficient to just set the position to (-30000, -30000, -30000), as if the unit is offloaded, and nullifying any position-dependent data like pathing information. Something else might be needed, though.
• Bridge the gap between parent and children creatures, so that effects to one happen to the other as well. The most important aspect of this is that injuries to one class of creature correspond to injuries to the other class of creatures. This just might be accomplished, just might, by making the parent and child creatures share the same body part pointers (though of course each child would only have the body parts that logically should be part of itself.) Another thing that this implies is that when parent creatures appear in adventure/fortress mode, the child creatures spawn as well. This can be done by nullifying parent creatures on loading as described above and creating all the child creatures according to the body parts of the parent.
• Implement AI for the whole multi-tile creature. Quite possibly the hardest of the bunch. This has two categories.
  
  • Peaceful movement AI. Using dragging references, it might be possible to avoid doing very much at all -- only one of the children would be allowed to path (the only one that is not being dragged), and the rest would just follow behind.
  • Combat AI. At first this can just be left to the default -- only the child creatures able to touch the opponent will attack, and the rest of the body would stay in place. (Or perhaps the pathing child will charge at the opponent, bringing the rest of the body which will attack as well?) Once a more sophisticated combat AI is desired, one possibility is very temporarily placing the parent creature on top of the attacker, and letting it choose an attack. Then whichever body part(s) are chosen to attack will begin to move towards the opponent. The time cost for each attack could be dynamically changed to account for the time needed for the requisite child creature to move into place.

Are there any thoughts on this, and further suggestions on how this might be done? I might start working on this, after I get my moving-machines plugin up to the point I want it.

[Rumrusher]

well you could just have a snake be made up of multiple units being dragged around by a chain, and Wagons do exist.
probably doable to make a bunch of units just share the same historical unit id so they all register their actions under the same name and title.
having created a multi tiled wagon dragon through use of chaining up a bunch of wagons together through a drag script


the head is the only one able to move around and attack, the others are in a constant state of being tug along
...or just dfhack edit the image tile that represents the unit and have it span across multiple tiles.

[Bumber]

The hardest part would be preventing them from trying to run through 1-tile openings when the combat AI kicks in. Would it be best to just have them be immobile and teleport them around? That might make it hard to keep track of their current speed, though. Best bet would be to somehow disable the AI and do your own basic one. Peaceful wandering would be simple enough, but combat pathing sounds really difficult.

...or just dfhack edit the image tile that represents the unit and have it span across multiple tiles.

You'd want to be able to target and attack the parts.

[bloop_bleep]

Oh, yeah... multi-tile creatures can't path to the same places that normal ones can...

Alright, time to formally define/expand upon some of the idea. Multi-tile creatures will be defined as a directed tree of creatures, every creature (expect one -- the root creature) having a parent. The creatures, at all times, must satisfy two constraints:

• No two creatures can occupy the same position.
• Every creature, except the root, must always be adjacent (possibly diagonally) to its parent.

Then, define the width of a creature tree as:

• If the tree has one node, the width is 1.
• If the tree has more than one node, the width is the sum of widths of the sub-trees.

Let us suppose that all multi-tile creatures can fit through spaces that are at least as wide as the tree. (This is... not actually true, but let us assume it for the purpose of simplicity.)

Define w as the width of a particular creature tree. Then, it will probably be necessary to re-implement the A* search algorithm, which is the same as the original except it only allows tiles where the entirety of a w * w square centered on the tile is walkable. Then the rest of the multi-creature can be situated within the w-wide path that the root creature "sweeps out" as it moves.

Although the A* algorithm can work without storing information between runs, it might prove to be a performance benefit to maintain at least some sort of walkability cache for each type of multi-tile creature present on the map at any time. It will probably increase RAM usage by a lot, so maybe it could be enabled only when they are at most a certain number of types of multi-tile creatures present on the map. Though, as they say, premature optimization is the root of all evil, so this will only come much further into development.

EDIT: Come to think of it, the multi-tile cache could just consist of booleans instead of the full 16-bit integers of the original walkability cache, so RAM usage might not be all that bad.

[Rumrusher]

hmm animated trees sounds like a cool concept.

[bloop_bleep]

hmm animated trees sounds like a cool concept.

That could also be possible, with an immobile multi-tile machine, but on top of pathing there's also the problem of motor planning of the limbs, which could end up being even more complex, especially in combat.

[Warmist]

i'm just posting to say you are insane!

Keep it up

[Meph]

Suggestions for creatures:
 - Whales
 - Sea snakes
 - Jellyfish
 - Giant worms
 - Giant snakes
 - Golems/Clouds
 - Armies of tiny units, like fairies/insects

[bloop_bleep]

Suggestions for creatures:
 - Whales
 - Sea snakes
 - Jellyfish
 - Giant worms
 - Giant snakes
 - Golems/Clouds
 - Armies of tiny units, like fairies/insects

Though all of those are great suggestions, the idea I was thinking of was that the plugin would be able to load multi-tile creature descriptions from a file, like perhaps a new type of raw file. In that case modders using my plugin could just write into a text file instead of editing my code directly.

And I was also focusing my thought process around "limb-y" creatures, since those have easily-definable components. Whales and stuff like that might have potentially hundreds of creatures inside, so defining each of those separately in a raw file would be nigh-impossible. Not to mention the performance hit from that, without special optimization. Maybe later I could add layer definitions to multi-tile creatures, so you could simply specify a three-thick layer of "blubber" units at some position within the multi-tile creature.

[bloop_bleep]

So! I have been working on this recently, and have gotten to the first milestone of merely loading the creature template and spawning multi-tile creatures on request!

The currently available commands are "mtcreatures load" and "mtcreatures spawn" -- the former takes the absolute path to a file of a creature template as the only argument, while the latter takes the creature template ID and the ID of the root unit to spawn from, in that order.

"mtcreatures load" loads a creature template into memory and assigns it the next ID in line. The creature template file is a text file with that is constructed using certain rules; these rules and a sample is given below.

Spoiler: Rules for creature template files (click to show/hide)

First thing to remember is that each 2D direction is assigned a number from 0 to 7, as below:
N=0
NW=1
W=2
SW=3
S=4
SE=5
E=6
NE=7
Now, the creature template file is formatted similarly to a XML file, and describes the creature tree similarly to how an XML file describes a tree of elements. Every description of a creature component has the format of:

• The line "<start>".
• A line with the creature raw id of the creature component.
• A line with the "preferred relative direction" of the component (explained later).
• Any descriptions of child components.
• The line "<end>".

The "preferred relative direction" of a component is the direction of the component relative to the direction of the parent. Summing the relative directions of a component and all its ancestors gives you the absolute direction of the component, which dictates how the component is positioned relative to its parent.

Code: (test_mtc.txt) [Select]

<start>
DWARF
0
<start>
DWARF
1
<end>
<start>
DWARF
2
<end>
<end>

Using the above template I was able to spawn a three-dwarf conglomerate in arena mode (root is bottom right).



I can post the source code if anyone is interested in seeing it.

[Bumber]

7 dwarves combine to form Dwarftron:

Code: [Select]

...☺....☺/
./≡☺≡\./..
☺.≡≡≡.☺...
..|.|.....
..☺.☺.....
Left leg dwarf!
Right leg dwarf!
Left arm dwarf!
And my axe!
Right arm dwarf!
Head dwarf!
And I'll form the beard!

[bloop_bleep]

I have a question regarding DF's unit struct. How can I cause the pathfinder to be entirely disabled for a certain unit, or at least take no effect? Specifically, I either want to stop the unit from taking jobs and trying to path somewhere, or prevent them from moving even if a job is taken.

[Warmist]

I have a question regarding DF's unit struct. How can I cause the pathfinder to be entirely disabled for a certain unit, or at least take no effect? Specifically, I either want to stop the unit from taking jobs and trying to path somewhere, or prevent them from moving even if a job is taken.

Afaik spam it's "thinking" (not sure about exact name) counter. This disabled all AI though.

Edit: also if you find any way to do that it would really help with multiplayer project. Maybe it's worth to just inject something in pathing logic that overwrites "this unit needs pathing recalculated" logic

[thefriendlyhacker]

...
Afaik spam it's "thinking" (not sure about exact name) counter. This disabled all AI though.
...

I believe it is the counters.think_counter variable you are thinking of. However, while I remember units holding still in the past when firing projectiles (which uses the think counter), I am pretty sure they now respond to station orders even when the think_counter is set, so it might not be sufficient for bloop_bleep's purposes.

On a related note, there are also the issues of dodging, knockback and grappling throws. I don't know how much dragging/grappling will prevent those.

[Roses]

What about giving the body part creatures IMMOBILE and NOTHOUGHT?