Print

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

[Warmist]

You need to accept the thing that is in header file thus void* and the name that is there. As for what you pass into a lua event, you might need to do a cast (i.e. reinterpret_cast<df::unit*>(p1) ). Also i think that there is no DEFINE_LUA_EVENT_8, so you might need to add it (or skip some parameters).


fake edit:
Looked at structures, looks like somebody did research on it. Now it's called "doAction".

Code: [Select]

<vmethod name='doAction'>
                <pointer type-name='unit'/>
                <pointer type-name='unit_syndrome'/>
                <pointer type-name='syndrome'/>
                <int32_t name='intensity'/>
                <int16_t name='bp_index'/>
                <int16_t name='bp_layer'/>
                <pointer pointer-type='unit_wound'/>
            </vmethod>
As for vmethod_name, see the generated headers. It'll be something like "anon_method3" or something.

[Roses]

Hmmm, it looks like someone already did the work, and unfortunately it doesn't look like the information I want is there, unless unit_syndrome means the unit who casted the syndrome. I suppose I will check if that is the case.

EDIT: Do you know who might have done the research on that vmethod? Might save me time to just talk to them.

[Putnam]

If anything, "unit" would be the one who did the interaction and "unit_syndrome" would be the one who didn't.

[Putnam]

Hmmm, it looks like someone already did the work, and unfortunately it doesn't look like the information I want is there, unless unit_syndrome means the unit who casted the syndrome. I suppose I will check if that is the case.

EDIT: Do you know who might have done the research on that vmethod? Might save me time to just talk to them.

angavrilov was the one who added the info.

[Warmist]

If anything, "unit" would be the one who did the interaction and "unit_syndrome" would be the one who didn't.

Even if that is true, there is no easy way to get to unit when you know unit_syndrome. Also the last argument is "df::unit_wound**" so maybe it's used to create new wounds? Not sure how that works.

[Putnam]

Since the previous two are bp_index and bp_layer, I assume it has to do with tissue-affecting creature effects.

[Roses]

If anything, "unit" would be the one who did the interaction and "unit_syndrome" would be the one who didn't.

Even if that is true, there is no easy way to get to unit when you know unit_syndrome. Also the last argument is "df::unit_wound**" so maybe it's used to create new wounds? Not sure how that works.

Well I was hoping that they would both be available so that a plugin could read both when called. I will contact angavrilov and ask what they know, and possibly try and determine what exactly is being pointed to. Hopefully both the caster and target will be available.

[Putnam]

As for vmethod_name, see the generated headers. It'll be something like "anon_method3" or something.

anon_vmethod_3, in fact. Lua can't access the anon vmethods, I assume due to the fact that they're protected methods.

[ag]

If anything, "unit" would be the one who did the interaction and "unit_syndrome" would be the one who didn't.

If you look at the XML properly, you will note that unit_syndrome is a structure type, and it has nothing whatsoever to do with doing interactions. This method is involved in per-tick processing of syndromes already active on a unit.

[Roses]

If anything, "unit" would be the one who did the interaction and "unit_syndrome" would be the one who didn't.

If you look at the XML properly, you will note that unit_syndrome is a structure type, and it has nothing whatsoever to do with doing interactions. This method is involved in per-tick processing of syndromes already active on a unit.

Hmm, thats too bad.

The only thing left that I can think about is a more rigorous analysis of the announcements. There are these two types;

Code: [Select]

        <enum-item name='INTERACTION_ACTOR'/>
        <enum-item name='INTERACTION_TARGET'/>Maybe I can trigger an announcement check right when the script is run? The only problem with that is that I was getting some cross chatter between multiple interactions being used at the same time.

I'm surprised there isn't a more direct link between units that use interactions and their targets, or maybe its just buried somewhere else. Anyway, I will try and see what I can do with the announcements, if anyone has any ideas I am all ears.

[Meph]

Well, what exactly are you trying to do with announcements?

[Roses]

All I am trying to do is reliably get the target and user of an interaction when it is used. Like how you can currently say \UNIT_ID, I would like to instead have \TARGET_ID and \USER_ID.

The only way I have found so far is to read announcements (generated from CDI:VERB and CDI:TARGET_VERB) to determine the users name and find the unit that way. The problem with that method is when there are several interactions being used at once, I have not found a reliable way to make sure the correct announcement is tied to the correct action. It may be that the announcements (VERB and TARGET_VERB) are linked in some way, if that is the case then I could read the targets announcements and determine from there, although it may have the same problem as it does now, where many interactions, used simultaneously, results in incorrect assignment of \USER_ID.

[Meph]

I know nothing about lua/dfhack, but why not write a short message to Tarn Adams? He has always replied to me relatively quickly and in a friendly manner. If this question is so specialized that even veteran dfhack scripters dont know the answer, maybe he can point you in the right direction.

[Roses]

I have thought about it, but given the fact that we are basically hacking into his code (albeit in the nicest way possible), I am not sure he would take kindly to a question concerning the inner workings of the code. I will attempt to try a couple more things and look through some more of the df-structures to see if there is anything I see. If all else fails I suppose it can't hurt to ask.

[Putnam]

He hasn't reacted all too negatively whenever I've seen people say how things work in the code while he's watching; hell, IIRC I've seen him confirm it occasionally. He also accepts binary patches readily.