Print

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

[Quatch]

Whats a dwarf need a formation for? you've got two modes here: shoot from behind a rock wall with no actual melee access, or charge like a madman.

Formations might be useful with rifles, or the side benefits of shields (shieldwall), spears (squares), etc.

[ArkDelgato]

Whats a dwarf need a formation for? you've got two modes here: shoot from behind a rock wall with no actual melee access, or charge like a madman.

Formations might be useful with rifles, or the side benefits of shields (shieldwall), spears (squares), etc.

Assuming traps get nerfed, there are repercussions to magma cannons and goblins get stronger, you could build a mixed group with a hammmer in from, two swords on his flank, three spears to defend the swords, two archers to slow the distant enemy defence, and a mace for the hell of it.

[Footkerchief]

I searched but I'm not sure whether this has been asked before. :/
Will it be possible to make a race where different castes have access to/use different equipment?

Basically I'm envisioning modding in a (non-playable) race to the game based on were-creatures. Since transformation isn't in, I could set up the creatures such that one cast is essentially human and the other are humanoid werebeasts, but they're considered the same species. For it to really work, though, I'd want the human-form caste to use weapons and armor and the animal-form caste to not use armor or weapons and attack by clawing/biting when you encounter them as enemies.

I still don't really fully understand castes. Will any of that be possible for this coming release?

Yeah, assuming the EQUIPS tag is still around, you can just leave it out of the general creature definition, and then add it to only the human caste.  Or you could remove the werebeasts' GRASP body tags to prevent them from holding weapons.

Spoiler: the most thorough explanation so far of caste mechanics (long) (click to show/hide)

Can BODY definitions for creatures be included in caste definitions or must all instances of a particular creature use the same body?

Say I have a race, the "Chef-Magi." This race has two castes, the Basillusionists and the Marinara Mages.

Now, if I had to use the caste system to allow a creature to have both males and females, I'd have to make FOUR castes: male/female Marinara Mages, and male/female Basillusionists.

Will there be a "body part" system for castes that allows one to define sets of attributes in the raws and use them as a shortcut for the caste info? More generally, can/will the creature body part system be extended to entities and other elements so that one can define an entity using shortcuts like [ETHICS:DWARFLIKE] and then below that make exceptions/additions?

Can one cast be a normal creature and another caste be a vermin?

The number of tokens that are creature rather than caste specific is very small.  Creatures handle the overall name, biome, whether the creature is considered fanciful/doesn't exist (for art), vermin information (so, no, Fault, sorry!... too much depends on that right now), whether groups hang together closely, whether it is mundane (from real Earth for age name purposes), population information including good/evil/savage, if it is equipment, sphere information (not sure how long that'll last, but there were annoyances), and that looks like it (they also have some general categories that have caste overrides, like child names and speeches for adv mode).  Everything else, including body information, is held in the castes.

For your chef example, if I understand it, you'd have:

Code: [Select]

[CREATURE:CHEF_MAGI]
*** insert creature stuff I mentioned above here ***
[CASTE:MARINARA_MAGE_MALE]
*** define all generic marinara information:  bodies, attacks, profession names, whatever ***
[MALE]
[USE_CASTE:MARINARA_MAGE_FEMALE:MARINARA_MAGE_MALE]
[FEMALE] <-- this overwrites male
[CASTE:BASILLUSIONIST_MALE]
*** define all generic basillusionist information ***
[MALE]
[USE_CASTE:BASILLUSIONIST_FEMALE:BASILLUSIONIST_MALE]
[FEMALE] <-- this overwrites male

There's no copy-pasting involved there, since the length bits are all written once.  Now, if the basillusionist and marinara mage shared information, you'd have to do a bit more work, but copy-pasting could still be avoided.  Note that in this example, males and females would breed with each other regardless of their overall group.  There's no way around that right now.

As another example, if you had body differences between the males and females within one of the larger groups, you could do it like this:

Code: [Select]

[CREATURE:CHEF_MAGI]
*** insert creature stuff I mentioned above here ***
[CASTE:MARINARA_MAGE_MALE]
*** define all generic marinara information ***
[USE_CASTE:MARINARA_MAGE_FEMALE:MARINARA_MAGE_MALE]
*** define specific marinara female information
[SELECT_CASTE:MARINARA_MAGE_MALE]
*** define specific marinara male information
[CASTE:BASILLUSIONIST_MALE]
*** define all generic basillusionist information ***
[USE_CASTE:BASILLUSIONIST_FEMALE:BASILLUSIONIST_MALE]
*** define specific basillusionist female information
[SELECT_CASTE:BASILLUSIONIST_MALE]
*** define specific basillusionist male information

You go around in a circle like that since you don't want the male info sitting in the male before you derive the female from it.  There isn't currently an easy way to erase info once it lands in a caste, aside from things that are overwritten like male/female and various other simple quantities.

You can also use [SELECT_ADDITIONAL_CASTE:token] to add more than one class to the list of castes you are working on.  If you haven't defined a caste yet, all of your information is stored in a default caste, and then that gets dumped into the first caste you define.  If you never define a caste, it creates one at the end and dumps the default caste into it.

In the case that you have information you want in all four castes, you can do this:

Code: [Select]

[CREATURE:CHEF_MAGI]
*** insert creature stuff I mentioned above here ***
*** insert shared caste tokens here ***
[CASTE:MAR_MALE] <-- default stuff is dumped in here
[USE_CASTE:BAS_MALE:MAR_MALE] <-- default stuff moves here too
*** define all generic bas information ***
[USE_CASTE:BAS_FEMALE:BAS_MALE] <-- default stuff and gen bas stuff moved
*** define specific bas female information
[SELECT_CASTE:BAS_MALE]
*** define specific bas male information
[SELECT_CASTE:MAR_MALE]
*** define all generic mar information
[USE_CASTE:MAR_FEMALE:MAR_MALE] <-- default stuff and gen mar stuff moved
*** define specific mar female information ***
[SELECT_CASTE:MAR_MALE]
*** define specific mar male information ***

It's a little convoluted (as is the situation itself), and there might be a faster way (and I might have screwed up!), but there are no copy-pastes of what might be dozens of tokens in each information segment.  You have to be a little careful, but you can build any tree of castes using this system, at least in terms of the information percolating up, because you can select and derive from a node at any time as information is added.  Note that the default caste isn't necessary here -- that information could also be added to the mar male after the mar male is created.  The default caste is just a minor convenience.

[Quatch]

There doesn't seem to be any layout advantage beyond keeping ranged in back, which you can do with separate squads. Does it matter that your speardudes are to the left or right of your sworddudes? Making a melee box with ranged in the center, or a guard-liason with box formation would be awesome, and possibly the point here, but again, small benefit for lots of work?

Formations sounds more like army arc to me.

[sweitx]

There doesn't seem to be any layout advantage beyond keeping ranged in back, which you can do with separate squads. Does it matter that your speardudes are to the left or right of your sworddudes? Making a melee box with ranged in the center, or a guard-liason with box formation would be awesome, and possibly the point here, but again, small benefit for lots of work?

Formations sounds more like army arc to me.

I think it's more of a user control issue.  In general you want all units within a formation to move at the same pace (namely, match the slowest unit).  So you might want to have a crossbowdwarf squad that is formed up such that they're either behind or surrounded by sworddwarf in the same squad, and another squad of melee dwarf acting as quick response unit.

[dragon0421]

I'm seeing a lot of green in those feature lists

Perhaps it is taboo to ask this, but is the next patch coming out in the near future? I'm holding off on playing DF until the next version is released because certain 40d limitations are bugging me too much, and they'll be fixed in this next version.

[Eduren]

We really need a standard response for these kinds of things.

Toady has said multiple times that he will release by the end of the year, even if it means cutting features.

[Toady One]

Ha ha, I've actually had to correct multiple times that I didn't say anything absolute about releasing by the end of the year.  It's a goal, but one that doesn't seem particularly easy to reach, even if I cut what I can cut.

[Eduren]

Oh, sorry then.

No pressure. Release it when you are ready.

[kiffer.geo]

edit. Well that got cleared up quick...
 

[Toady One]

He he he, I'm assuming you're referring to the little conversation I deleted before it managed to be reported.

[kiffer.geo]

I was indeed.

Toady, hammers made of light but strong metals will now not be very effective right? Do the decorative spikes count for damage from a weapon?

[Footkerchief]

Toady, hammers made of light but strong metals will now not be very effective right?

Yes:

In terms of adamantine weapons, the edge and shear properties mean it will be able to slice through steel for example quite easily, even though the low density means that it won't be effective in bludeoning weapons.

Do the decorative spikes count for damage from a weapon?

Not yet (I don't have a quote for that, but it sounds like item improvements have been left alone as much as possible for this release).  He's historically been positive about the idea though.

[G-Flex]

Keep in mind that heavier doesn't always mean better for bludgeoning items. Yeah, heavier weapons (including sharp or pointy ones) do more damage to a person with a given swing speed, but there's a reason why most swords and even hammers used in wars are historically a lot lighter than you think. You actually need to be able to handle the thing, and in addition to that, if a hammer (or sword, or axe) is too heavy, you won't be able to swing it very fast, or very well at all for that matter. So an aluminum hammer isn't necessarily the best idea, but neither is a lead one.

[Untelligent]

So my artifact Uranium warhammer isn't nearly as badass as I thought it was?