11 réponses à ce sujet

[Herw81]

Hi

I would like to fire a script when a party member levels up. But I found no event to track that (there are some events around leveling subject, but no one usable for my case).
There is the function TrackLevelUp which seems nice but it returns nothing ...

Any idea ?

Modifié par Herw81, 11 avril 2010 - 03:12 .

[Herw81]

Nobody knows how to detect a party member level up ?

[Proleric]

I haven't done this, but since no one else replied yet...

Assuming you're interested in when a party member is eligible for level up, I'd trap this event in a custom version of sys_rewards_h (circa line 154).

Since the call to SendLevelUpEvent in that line is dummied out, I wonder whether EVENT_TYPE_PLAYER_LEVELUP is deprecated. At any rate, it seems safer to change the header script.

Bear in mind that the standard hire functions force the party member to use the script player_core regardless of what script you give them, so you'd have to work around that.

If you're interested in when the player has actually levelled up the follower, a BFI method would be to use the resource-intensive EVENT_TYPE_HEARTBEAT to detect a change in level (but no doubt there is a cleaner way).

[Herw81]

Thanks to answer Proleric1 :happy:

EVENT_TYPE_PLAYER_LEVELUP doesn't allow determining if a party member levels up.  In fact there is no event for that (I used a script to display on screen each event code and no code appears when a party member levels up ...).
I haven't understand yet how works EVENT_TYPE_HEARTBEAT, but what is a BFI method ?

[Proleric]

BFI = Brute Force & Ignorance.

[TimelordDC]

If you are using the standard RewardXP function to assign XP reward, then it automatically checks if the party members are ready to level up using the Chargen_CheckCanLevelup function.

If you want to send some other events or set plots on level up, you can write a custom RewardXP function and route all XP through that function. In the custom function, include what you want to do in the "if Chargen_CheckCanLevelUp returns true" block.

[Herw81]

Your solution seems very interesting TimelordDC, with that I just have to add a #include "MyScript" and a line with my function in sys_rewards_h.
You said "you can write a custom RewardXP function and route all XP through that
function". I thought to modify the sys_rewards_h script but from what you said it seems it's possible to avoid that (I think it's cleaner to not modify original scripts). Is there a clean and easy way ?

[TimelordDC]

Well, I posted that late yesterday night and didn't think through it fully

Overriding RewardXP will still work (you can have your own script with the custom function in it). However, that will require you to recompile all scripts that reference RewardXP and a quick search shows a whole lot of them (core scripts, I mean). If your mod will be an add-in to the Single Player campaign, that route is very, very messy.

You said you tracked every event - was that every event to every core script? I'm asking because EVENT_TYPE_PLAYER_LEVELUP is routed to player_core.

If that doesn't fire, the simplest solution is to use EVENT_TYPE_HEARTBEAT. Writing so as to check specific companion tags (instead of using multiple functions to get hero, then partypool and iterating) using the Chargen_CheckCanLevelUp function would make it easy on the resources (I guess)

Modifié par TimelordDC, 07 avril 2010 - 12:50 .

[Herw81]

It's an addin for the Single Player Campaign. I didn't explained why I need that because I thought that was not useful, but I'm working on passive talents which give "dynamic" bonuses. Bonus values are based on player level and I need to detect when a party member levels up to update the bonuses.
EVENT_TYPE_PLAYER_LEVELUP doesn't work for what I want, EVENT_TYPE_PLAYERLEVELUP is not appropriated (fires each time we open the level up screen), so I wrote a script which catches every event and displays their code on screen to know which event I can use ... and no code appears when a party member levels up ... So I started to study functions with "level" in their name, which game scripts work with party member levels ... that can be interesting for later but there is too information to assimilate , so I posted my question.

I haven't had the time to work on it these last days, and I think also in these next days. I think I will overwrite the sys_rewards_h by changing the RewardXP function, and not override it
I will study also EVENT_TYPE_HEARTBEAT (and scripts where it is used), even if I will not use it to track level up, I think that can be useful for active talents that I will try to do after.

Thank you to TimelordDC and Proleric1 for your help. Now I'm not more blocked and I have tracks to study and I think I will have soon the solution for my addin. I will give a feedback when I will succeed (or not).

[Herw81]

It seems it is impossible to override (or overwrite as I wrote in my previous post even if it is not correct) scripts with "_h" because they are resources. The only way is to do as TimelordDC said, create a new RewardXP function and override all scripts using the original one ... that is a lot of work. Moreover, if I create another mods with the same principle I will have problems of compatibility (plus the problems of compatibility with third party mods).
So I found an easier solution. I used local variables to store the party members level.

Here is what I did:
- Created a var_mymod.gda to declare my variables (link to wiki)
- Place the .gda into the override folder of my mod
- Open my toolset and update the Properties of my mod by selecting var_mymod in "Variable 2da" field
- Add some lines in my mod script to "track" the level up (the code below it's not very clean and not optimized, it is what I used for my tests). If the current level is different from what we have stored, there was a level up. The update will be near instantaneous that a corresponding event existed.

#include "utility_h"

void BonusUpdate(object oPartyMember)
{
     [...]
}

void main()
{
    object oHero = GetHero();
    object oModule = GetModule(); // the local variables are attached to the module

    if (GetLevel(oHero) != GetLocalInt(oModule, "HERO_LEVEL"))
    {
        if ( HasAbility(oHero, MYABILITY) ) BonusUpdate(oHero);
        SetLocalInt(oModule, "HERO_LEVEL", GetLevel(oHero)); // storage of the hero level
    }
}

Here is what I put in var_mymod.gda file:

ID  Label              Type    Default  IsPlot
int  string              string  string     int
0    HERO_LEVEL  int        0             0

Modifié par Herw81, 12 avril 2010 - 04:56 .

[Proleric]

That's a good solution. You might want to tie it to a specific event, such as the hearbeat - the module script gets called very frequently, so in theory there's a performance overhead.

[Herw81]

You're right. I wanted to do the update as soon as possible and I noticed that when a command is not specific to an event (with GetEvent and co. plus the switch) it is launched at any event. But I didn't think about the performances ... Thanks