Print

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

[Roses]

so I just got an adv mode idea given how stealth works and how it's invisible to the player but not to everyone else. is it possible to make Dfhack npcs that spawn in and hide out of site to do stuff you can't just force with dfhack yet.
like making an unit named Aimed Shot that hits like a space station and sets up aimed attacks that pierce and probably sticks into the person you told Aim to hit.
you could even set up how much force and damage the attacks are you could even assign the same historical figure to Aimed Shot so any kills they get would transfer over to the player.

this script idea would only work as long as the whole sneaking thing isn't fixed and probably break if someone uses any reveal any hidden units scripts.

Theoretically I think it would be possible, but spawning units with DFHack can be problematic, so I'm not sure you would want to do that too much. I also don't think there are too many things that a hidden npc could do that you couldn't do without it. For instance, in your example, you can already make an attack and add it to a unit and modify it's attack values

[Rumrusher]

so you're saying one could slap an attack on the unit modify it and have it target themselves?
well then that's one work around to get control of which body part you want to shoot.

[Roses]

so you're saying one could slap an attack on the unit modify it and have it target themselves?
well then that's one work around to get control of which body part you want to shoot.

Hmmm, normally I would say no because projectile attacks don't function the same as normal attacks and self targeted attacks usually don't work, but if your goal is to be able to target specific body parts in adventure mode (or say a special ammo that always targets the head or legs or something) it may actually be possible by modifying the projectile right before it hits the target. I'll have to explore how the game handles projectile attacks.

For reference, I was referring to melee attacks, which can easily be added and modified such that you can change the velocity, hit chance, and target body part of an attack.

[Roses]

Alright, I've got the basics of the Enhanced Reactions all up and running. I am still experimenting and testing a bit with how the various triggers are being handled together (onJobCompleted and onReactionComplete) along with my custom triggers, but they seem to all be cooperating together. The trick being making sure that the required information is available regardless of if a product from a reaction is created or not.

Currently script calling is enabled through the system, which lets you do anything you could want, but I am also working on getting shortcuts set up for some of the more obvious uses (miasma/smoke generation, long time reactions, variable reactions, power/water/magma consumption, etc...).

Some of my previous work on the Enhanced Reactions has been invalidated with the 0.47 release as well, which means I still want to go through and make sure I am not duplicating anything that is currently doable with the new reactions.

[Roses]

So I am finally back working on some DF stuff and getting back into the swing of things. I will be moving my devel branch to the master branch in the next week or two and making an official release of the new system. As a little preview of the type of things that are possible with my new set up, here is the unit metatables

Code: (Works like the df.unit.find(id) function, except it returns a new metatable) [Select]

[lua]# unit = reqscript("functions/unit").getUnit(752)
[lua]# ~unit
table: 000001F81AE9CDA0
id                       = 752
_unit                    = <unit: 000001F81AE7E0C0>        -- The old return of df.unit.find(id)
Flags                    = table: 000001F81AE9CFE0         -- Each of these are metatables that access the desired information
Counters                 = table: 000001F81AE9D060
Attributes               = table: 000001F81AE9CEE0
Skills                   = table: 000001F81AE9CF20


Code: (Access the same information from the df.unit reference the same way) [Select]

[lua]# !unit.name == unit._unit.name
true
[lua]# ~unit.name
<language_name: 000001F81AE7E0C8>
first_name               =
nickname                 =
words                    = <int32_t[]: 000001F81AE7E108>
parts_of_speech          = <part_of_speech[]: 000001F81AE7E124>
language                 = -1
unknown                  = -1
has_name                 = false


Code: (Physical and Mental attributes are all stored together, no more need to look in different spots) [Select]

[lua]# ~unit.Attributes.STRENGTH
table: 000001F81B143420
token                    = STRENGTH
type                     = Physical
_unit                    = <unit: 000001F81AE7E0C0>
_attribute               = <unit_attribute: 000001F81AE7E6A4>
[lua]# ~unit.Attributes.WILLPOWER
table: 000001F81BE4C8A0
token                    = WILLPOWER
type                     = Mental
_unit                    = <unit: 000001F81AE7E0C0>
_attribute               = <unit_attribute: 000001F819EDBB64>


Code: (dfhack functions are linked to the new metatable) [Select]

[lua]# ~unit.getAge()
230.81025793651
[lua]# ~dfhack.units.getAge(unit._unit)
230.81025793651


[Roses]

Alright! The git repo has been updated and migrated to the master branch. Development will continue in the devel branch so if you want the most up to date stuff check that branch out first.

This release adds the Enhanced Reactions system to what was already there. For now it is just the basics and supports easy running of scripts based on queing up reactions, starting the actual reaction, finishing the reaction, and producing products from a reaction (see the third post for more information). It also allows easy checking for nearby water and magma (cancelling the reaction if there is not enough) and easy production of flows and liquids from reactions. For example, adding

Code: [Select]

{PRODUCT:100:150:FLOW:MIASMA:NONE:NONE}to the reaction means that the reaction will produce a 150 density miasma flow with 100% probability, and

Code: [Select]

{PRODUCT:50:7:LIQUID:WATER:NONE:NONE}will produce a 7 depth tile of water with a 50% probability.

All scripts on the second post and systems on the third post should be working and I have written tests to make sure they keep working in future updates.

Moving forward I still need to implement the Enhanced Creatures and Enhanced Materials systems. Then I will probably work on migrating the Journal, Encyclopedia, and Detailed Unit Viewer gui's from the old repo to the new repo. I also want to re-implement the Class and Civilization Systems from the old repo but it will need to be heavily modified.

[Roses]

Alright, Enhanced Creatures is on its way! As a little taste you can now put

Code: [Select]

{ON_DEATH}
  {SCRIPT:map/spawn-flow -unit UNIT_ID -type Fire -density 100:100}OR just put

Code: [Select]

{EXPLODES_ON_DEATH}
Into the creatures raws and when that creature dies it will now create a little explosion of fire!

[Roses]

Another update.

I've got the attributes and sizes for units working correctly now. Essentially you declare the size numbers and attribute numbers the same way they are done now, but instead of capping them, the script assigns the correct numbers to the unit. Note that this doesn't work for world gen mode as it only sets them once they appear on the screen, I might try to tie the setting into the historical figure generation in world gen so that it might work, but that is a stretch goal at this point.

Attack modifications are also in place so for instance if we take a kick attack like

Code: [Select]

[ATTACK:KICK:BODYPART:BY_TYPE:STANCE]
[ATTACK_SKILL:STANCE_STRIKE]
[ATTACK_VERB:kick:kicks]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PREPARE_AND_RECOVER:4:4]
[ATTACK_FLAG_WITH]
[ATTACK_PRIORITY:SECOND]
[ATTACK_FLAG_BAD_MULTIATTACK]we can add some extra tokens to do some fancy things

Code: [Select]

[ATTACK:KICK:BODYPART:BY_TYPE:STANCE]
[ATTACK_SKILL:STANCE_STRIKE]
[ATTACK_VERB:kick:kicks]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PREPARE_AND_RECOVER:4:4]
[ATTACK_FLAG_WITH]
[ATTACK_PRIORITY:SECOND]
[ATTACK_FLAG_BAD_MULTIATTACK]
{ON_ATTACK}
{SCRIPT:do-something}
{ON_HIT}
{SCRIPT:do-something}
{ON_WOUND}
{SCRIPT:do-something}
I am also planning on adding some more features to the attacks that are basically shortcuts, so you could modify the velocity or hit chance of the attack directly, add repeat attacks, or even have targeted attacks (e.g. HEAD_KICK).

Interactions are a little harder due to the fact that they are handled differently than all the other raws I've processed so far, namely, a unit can have several different [CAN_DO_INTERACTION:MATERIAL_EMISSION] in their raws and each one will be different in DF but my current code would just create a single one (since it would just read the MATERIAL_EMISSION). An easy work around for now would be to only allow unique interaction entries read from the [OBJECT:INTERACTION] files, so that you would have multiple copies of the [INTERACTION:MATERIAL_EMISSION] (e.g. [INTERACTION:MATERIAL_EMISSION_DRAINBLOOD]) that has the Enhanced Raws stuff in them. But I'd rather be able to add the Enhanced Raws stuff to both places if the user wanted.

Other triggers that I've added are {ON_DEATH}, {ON_KILL}, {ON_MOVE}, and {ON_STRESSED}. Currently they only accept scripts with the triggers (except for the ON_DEATH shortcut {EXPLODES_ON_DEATH}), but I'll be adding other shortcuts as well.

[Fleeting Frames]

Encouraging to see the system develop. The advantage of rawified approach in keeping the entire thing in one place is quite nice for compartmentalizing, despite what limits it may hold.

If I were to make a suggestion, {ON_EXISTENCE} (or _LIFE?) i.e. something to run when the unit enters map for the first time (through being born or migrating on-site) for ex. assigning animalmen to player fort and announcing migrants, though I think you currently can do a lot by just self-applied syndrome.

How to use it

• Copy the Scripts/raw/scripts folder into your DF raw folder (hopefully there are no conflicts with any other scripts you have installed there)
• Copy the Scripts/raw/systems folder into your DF raw folder (directly into the raw folder, not the raw/scripts folder)
• Put core/initialize in your onLoad init file. If you want more verbose output you can use -v repeatedly (up to -vvvvv)
• All available systems should now be working, and all scripts should now be callable through any other methods you want

Regarding this list, couldn't the third step (core/initialize) be skipped by adding init.lua into raws for the purpose of sharing existing saves?

[Roses]

Encouraging to see the system develop. The advantage of rawified approach in keeping the entire thing in one place is quite nice for compartmentalizing, despite what limits it may hold.

If I were to make a suggestion, {ON_EXISTENCE} (or _LIFE?) i.e. something to run when the unit enters map for the first time (through being born or migrating on-site) for ex. assigning animalmen to player fort and announcing migrants, though I think you currently can do a lot by just self-applied syndrome.

How to use it

• Copy the Scripts/raw/scripts folder into your DF raw folder (hopefully there are no conflicts with any other scripts you have installed there)
• Copy the Scripts/raw/systems folder into your DF raw folder (directly into the raw folder, not the raw/scripts folder)
• Put core/initialize in your onLoad init file. If you want more verbose output you can use -v repeatedly (up to -vvvvv)
• All available systems should now be working, and all scripts should now be callable through any other methods you want

Regarding this list, couldn't the third step (core/initialize) be skipped by adding init.lua into raws for the purpose of sharing existing saves?

There actually is already a trigger for when a unit is first detected on the map (it's how the attributes and sizes are assigned) but I hadn't exposed it to script calls and such, but that is easy enough to do.

As for the other part, yes you are completely correct. I had meant to do that a while back and it must have slipped my mind.

[Luckyowl]

Hey, got this bug going on. The item_enhanexample name are invisible in the object test arena. Can you tell me how to fix it?

[Luckyowl]

Figured out was the problem. You didn't have a plural name for the example items. It should've been
power digger:power diggers.

But that's honestly a minor thing.
I got a question are the skills and attributes changes attached to the item invisible? Or are they suppose to show up in you the player's stats?

[Roses]

Thanks for pointing that out. I'll make sure to update the examples.

The changes should be visible in the players stats, but I have only really tested in fortress mode and looked at the stats in DFHack. I'll test out in adventure mode and make sure it is correctly applying and is visible (also looking through the code right now it seems I didn't finish all of the attribute and skill change things, so some of them may not even be working correctly).

[Evans]

Roses,

I'm trying to bring back old script for cage-thrower that cages target.
So far I've managed to restore projectiles into cages and they do capture targets.

But, the hunter or attackers keep at the target. Apparently there has been a change between then and now on how units store their targets.

After searching through forums I've noticed you have a script for creating an attack and clearing actions from units. Any ideas how to remove current action target from unit? :/

[Roses]

Roses,

I'm trying to bring back old script for cage-thrower that cages target.
So far I've managed to restore projectiles into cages and they do capture targets.

But, the hunter or attackers keep at the target. Apparently there has been a change between then and now on how units store their targets.

After searching through forums I've noticed you have a script for creating an attack and clearing actions from units. Any ideas how to remove current action target from unit? :/

Just for clarification, what exactly happens? The cage gets thrown correctly, and the target gets put in the cage correctly, but the unit keeps attacking the caged target? More than one attack, or just a single extra attack?