Print

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

[Boltgun]

I fixed an issue in addsyndrome where it would not apply a syndrome to a creature affected by another syndrome.

I set up a ping/pong interaction to simulate a self buff in combat (since DF does not support that) using these 2 inorganics :

Spoiler (click to show/hide)

Code: [Select]

[INORGANIC:FOOCCUBUS_UPGRADE_BERSERK] // add berserk buff interaction
[SPECIAL]
[NO_STONE_STOCKPILE]
[MATERIAL_VALUE:1]
[STATE_COLOR:GAS:WHITE]
[STATE_COLOR:ALL_SOLID:WHITE]
[STATE_NAME_ADJ:ALL_SOLID:Learn Berserk rage (depends of unhappiness)]
[STATE_NAME_ADJ:LIQUID:liquid]
[STATE_NAME_ADJ:GAS:smoke]
[DISPLAY_COLOR:6:0:1][TILE:'*']
[MELTING_POINT:9000]
[BOILING_POINT:8999]
[SOLID_DENSITY:20000000]
[SYNDROME]
[SYN_CLASS:BERSERK]
[SYN_CLASS:\AUTO_SYNDROME]
[CE_ADD_TAG:LIKES_FIGHTING:START:0]
[CE_CAN_DO_INTERACTION:START:0]
[CDI:INTERACTION:FOOCCUBUS_BERSERK_TRIGGER]
[CDI:TARGET:A:LINE_OF_SIGHT]
[CDI:USAGE_HINT:ATTACK]
[CDI:TARGET_RANGE:A:20]
[CDI:FREE_ACTION]
[CDI:WAIT_PERIOD:3000]

[INORGANIC:FOOCCUBUS_BERSERK_3] // Berserk effet
[SPECIAL]
[NO_STONE_STOCKPILE]
[MATERIAL_VALUE:1]
[STATE_COLOR:GAS:WHITE]
[STATE_COLOR:ALL_SOLID:WHITE]
[STATE_NAME_ADJ:ALL_SOLID:rock]
[STATE_NAME_ADJ:LIQUID:liquid]
[STATE_NAME_ADJ:GAS:smoke]
[DISPLAY_COLOR:6:0:1][TILE:'*']
[SYNDROME]
[SYN_NAME:berserk]
[CE_FLASH_TILE:TILE:'!':4:0:1:FREQUENCY:800:300:START:0:END:2500]
[CE_ADD_TAG:TRANCES:START:0:END:2500]
[CE_ADD_TAG:NOEXERT:START:0:END:2500]
[CE_ADD_TAG:NOPAIN:START:0:END:2500]
[CE_ADD_TAG:NONAUSEA:START:0:END:2500]
[CE_ADD_TAG:NOFEAR:START:0:END:2500]
[CE_PHYS_ATT_CHANGE:STRENGTH:300:3000:START:0:END:2500]
[CE_PHYS_ATT_CHANGE:ENDURANCE:200:1000:START:0:END:2500]
[CE_PHYS_ATT_CHANGE:TOUGHNESS:200:1000:START:0:END:2500]
[CE_SPEED_CHANGE:SPEED_PERC:130:START:0:END:2500]

So the first one provides an interaction for the unit to use on its enemy who will send back the second syndrome using addsyndrome.

I found out that the syndrome could be applied on a creature without other syndrome running but not the original unit. Testing revealed that the syndrome was really added but the CE did not take effect. So the error was coming from the assignSyndrome function.

Since trying to apply the second inorganic through autoSyndrome worked, I looked at its code and saw that it was almost the same with a couple of tweaks. So I ported it back to your script :

Spoiler (click to show/hide)

Code: [Select]

local function assignSyndrome(target,syn_id) --taken from Putnam's itemSyndrome
    if target==nil then
        return nil
    end
    if alreadyHasSyndrome(target,syn_id) then
        local syndrome
        for k,v in ipairs(target.syndromes.active) do
            if v.type == syn_id then syndrome = v end
        end
        if not syndrome then return nil end
        syndrome.ticks=1
        return true
    end
    local newSyndrome=df.unit_syndrome:new()
    local target_syndrome=df.syndrome.find(syn_id)
    newSyndrome.type=target_syndrome.id
    newSyndrome.year=df.global.cur_year
    newSyndrome.year_time=df.global.cur_year_tick
    newSyndrome.ticks=0
    newSyndrome.unk1=0
--newSyndrome.flags=0
    for k,v in ipairs(target_syndrome.ce) do
        local sympt=df.unit_syndrome.T_symptoms:new()
        sympt.unk1=0
        sympt.unk2=0
        sympt.ticks=0
        sympt.flags=2
        newSyndrome.symptoms:insert("#",sympt)
    end
    target.syndromes.active:insert("#",newSyndrome)
    if itemsyndromedebug then
        print("Assigned syndrome #" ..syn_id.." to unit.")
    end
    return true
end

The change is that it set a couple of unk flags on the symptoms and starts the syndrome at 0 ticks instead of 1. AutoSyndrome also sets newSyndrome.flags=0 but since there is a comment about bad typecasting I left it out.

And voila, now my unit gets properly berserk in battle. You want a pull request for this?

[Putnam]

How'd that comment get there? The original comment in itemsyndrome pointed towards the original function...

[Roses]

I fixed an issue in addsyndrome where it would not apply a syndrome to a creature affected by another syndrome.

I set up a ping/pong interaction to simulate a self buff in combat (since DF does not support that) using these 2 inorganics :

Spoiler (click to show/hide)

Code: [Select]

[INORGANIC:FOOCCUBUS_UPGRADE_BERSERK] // add berserk buff interaction
[SPECIAL]
[NO_STONE_STOCKPILE]
[MATERIAL_VALUE:1]
[STATE_COLOR:GAS:WHITE]
[STATE_COLOR:ALL_SOLID:WHITE]
[STATE_NAME_ADJ:ALL_SOLID:Learn Berserk rage (depends of unhappiness)]
[STATE_NAME_ADJ:LIQUID:liquid]
[STATE_NAME_ADJ:GAS:smoke]
[DISPLAY_COLOR:6:0:1][TILE:'*']
[MELTING_POINT:9000]
[BOILING_POINT:8999]
[SOLID_DENSITY:20000000]
[SYNDROME]
[SYN_CLASS:BERSERK]
[SYN_CLASS:\AUTO_SYNDROME]
[CE_ADD_TAG:LIKES_FIGHTING:START:0]
[CE_CAN_DO_INTERACTION:START:0]
[CDI:INTERACTION:FOOCCUBUS_BERSERK_TRIGGER]
[CDI:TARGET:A:LINE_OF_SIGHT]
[CDI:USAGE_HINT:ATTACK]
[CDI:TARGET_RANGE:A:20]
[CDI:FREE_ACTION]
[CDI:WAIT_PERIOD:3000]

[INORGANIC:FOOCCUBUS_BERSERK_3] // Berserk effet
[SPECIAL]
[NO_STONE_STOCKPILE]
[MATERIAL_VALUE:1]
[STATE_COLOR:GAS:WHITE]
[STATE_COLOR:ALL_SOLID:WHITE]
[STATE_NAME_ADJ:ALL_SOLID:rock]
[STATE_NAME_ADJ:LIQUID:liquid]
[STATE_NAME_ADJ:GAS:smoke]
[DISPLAY_COLOR:6:0:1][TILE:'*']
[SYNDROME]
[SYN_NAME:berserk]
[CE_FLASH_TILE:TILE:'!':4:0:1:FREQUENCY:800:300:START:0:END:2500]
[CE_ADD_TAG:TRANCES:START:0:END:2500]
[CE_ADD_TAG:NOEXERT:START:0:END:2500]
[CE_ADD_TAG:NOPAIN:START:0:END:2500]
[CE_ADD_TAG:NONAUSEA:START:0:END:2500]
[CE_ADD_TAG:NOFEAR:START:0:END:2500]
[CE_PHYS_ATT_CHANGE:STRENGTH:300:3000:START:0:END:2500]
[CE_PHYS_ATT_CHANGE:ENDURANCE:200:1000:START:0:END:2500]
[CE_PHYS_ATT_CHANGE:TOUGHNESS:200:1000:START:0:END:2500]
[CE_SPEED_CHANGE:SPEED_PERC:130:START:0:END:2500]

So the first one provides an interaction for the unit to use on its enemy who will send back the second syndrome using addsyndrome.

I found out that the syndrome could be applied on a creature without other syndrome running but not the original unit. Testing revealed that the syndrome was really added but the CE did not take effect. So the error was coming from the assignSyndrome function.

Since trying to apply the second inorganic through autoSyndrome worked, I looked at its code and saw that it was almost the same with a couple of tweaks. So I ported it back to your script :

Spoiler (click to show/hide)

Code: [Select]

local function assignSyndrome(target,syn_id) --taken from Putnam's itemSyndrome
    if target==nil then
        return nil
    end
    if alreadyHasSyndrome(target,syn_id) then
        local syndrome
        for k,v in ipairs(target.syndromes.active) do
            if v.type == syn_id then syndrome = v end
        end
        if not syndrome then return nil end
        syndrome.ticks=1
        return true
    end
    local newSyndrome=df.unit_syndrome:new()
    local target_syndrome=df.syndrome.find(syn_id)
    newSyndrome.type=target_syndrome.id
    newSyndrome.year=df.global.cur_year
    newSyndrome.year_time=df.global.cur_year_tick
    newSyndrome.ticks=0
    newSyndrome.unk1=0
--newSyndrome.flags=0
    for k,v in ipairs(target_syndrome.ce) do
        local sympt=df.unit_syndrome.T_symptoms:new()
        sympt.unk1=0
        sympt.unk2=0
        sympt.ticks=0
        sympt.flags=2
        newSyndrome.symptoms:insert("#",sympt)
    end
    target.syndromes.active:insert("#",newSyndrome)
    if itemsyndromedebug then
        print("Assigned syndrome #" ..syn_id.." to unit.")
    end
    return true
end

The change is that it set a couple of unk flags on the symptoms and starts the syndrome at 0 ticks instead of 1. AutoSyndrome also sets newSyndrome.flags=0 but since there is a comment about bad typecasting I left it out.

And voila, now my unit gets properly berserk in battle. You want a pull request for this?

Yeah, give me a pull request.

Also, hopefully if I can nail down my self targeting script to be a little more reliable, you won't need to have a ping pong reaction to add syndromes. Right now it doesn't do very well when you have dozens of units using reactions at the same time.

[Boltgun]

How'd that comment get there? The original comment in itemsyndrome pointed towards the original function...

It pointed to itemsyndrome that pointed to the original function, so did autosyndrome.

Yeah, give me a pull request.

Also, hopefully if I can nail down my self targeting script to be a little more reliable, you won't need to have a ping pong reaction to add syndromes. Right now it doesn't do very well when you have dozens of units using reactions at the same time.

I'm on it. (edit: Done)

Ideally the creature at the origin of the syndrome would be available to use, perhaps with events this is doable.

[Roses]

Ideally, yes, you would be able to say \SELF_ID or something. I worked for awhile to find a suitable method (checking attacker ids, looking into syndrome flags, etc...), the best I could come up with was reading combat reports for the most recent with the correct type (146 for used interactions that add syndromes), get the name from there and then find the unit with that name. Works great for 1v1 or even up to several fighting at once, but once you get a large group together the reports come in faster than the check is made and it stats attributing the interactions to the wrong units. I put the search for a better method on hold for now, but once there is one I have several scripts written that can handle "reflect" like abilities and other fun shenanigans.

[Warmist]

Ideally, yes, you would be able to say \SELF_ID or something. I worked for awhile to find a suitable method (checking attacker ids, looking into syndrome flags, etc...), the best I could come up with was reading combat reports for the most recent with the correct type (146 for used interactions that add syndromes), get the name from there and then find the unit with that name. Works great for 1v1 or even up to several fighting at once, but once you get a large group together the reports come in faster than the check is made and it stats attributing the interactions to the wrong units. I put the search for a better method on hold for now, but once there is one I have several scripts written that can handle "reflect" like abilities and other fun shenanigans.

Actually there might to be "THE BEST WAY" to do this. But it needs more research for vmethods of "creature_interaction_effect" class. If anyone knows more about them please share the knowledge. e.g. 4-th vmethod could very well be "apply this from creature X to creature Y with params..." then we could interpose it and have it capture most interactions effects when they happen (and even cancel them if we wish to) as they happen with more information.

[Putnam]

...creature_interaction_effect has vmethods?

Frick. I'd better do some research on that. I feel like I should have a long time ago.

[Roses]

I'm gonna be pretty busy this next week with work stuff, hopefully I can put out an update to my personal stuff sometime this weekend before I am too busy, but Putnam, if you can figure something out with the vmethods, that would be unbelievable. I have so many ideas for spells and abilities that rely on having the casting units ID, I started to make some of them, but got disheartened when my method wasn't 100% accurate. If you don't have time to look into it before next week that is fine too, since I should have some extra time to devote to it.

[Putnam]

Not entirely sure how to actually check out these methods (<_<), but the fourth vmethod there looks promising.

[Roses]

That does look promising. I figure the game has to keep track of that information (it seems foolish that it wouldn't).

[Roses]

Major Overhaul:

-Changed all scripts to take advantage of the new selected.lua.
--Removed all built in selection criteria from scripts
--Removed out of date examples (new examples will be coming soon, can also be found in images)
-Combined changefixed and changepercent to one script
-Renamed storm.lua to spawnflow.lua
-Added changeattributes.lua to allow fixed and percentage changes
-Added todo.txt which shows future plans for scripts

NOTE: Currently the self check for selected.lua does not work very well. I suggest not using the self@, silence@, or reflect@ arguments

EDIT: See the first post for a detailed description of what selected.lua can do. It should now work for anyones scripts, not just mine.

[Boltgun]

Nice, the scripts are a lot simpler now. 

[Roses]

Not entirely sure how to actually check out these methods (<_<), but the fourth vmethod there looks promising.

Alright, I've got some time to investigate these vmethods. Did you have any luck Putnam?

[Putnam]

Well, I don't know how to investigate vmethods that much and I kinda forgot about it (if I hadn't, I'd have asked Quietust et al about that by now), so no, no luck.

[Roses]

Alrighty. I'm not sure how to investigate the vmethods either, so I will ask around and see what I can come up with.