7 réponses à ce sujet

[Rolenka]

I'm sure this is a simple question with an obvious answer.

I'm working on a mod that will make all attribute and skill checks in dialogue automatically succeed. The first way I might do it is by replacing the scripts that do the check by default, gen00pt_attributes and gen00pt_skills, so that they always return true.

I've done this, and it's functional.

But I was thinking, a conversation may be scripted to send the check somewhere else. What if I applied a massive buff to the party leader at the start of dialogue, then took it away at the end? Then the player would succeed at any reasonable check.

It would have to be tied to EVENT_TYPE_GAMEMODE_CHANGE. I'm pretty sure I can figure out how to apply and remove a custom effect, (it looks like it would require a new ability effect in abi_base?) but adding and removing skills is trickier. Even if I figured out how to do it (I think the debug scripts will be of great help here), I'd need to store the data of which skills were added, so I'd know which ones to remove (if it's even possible to remove a skill) once the event fires again and we leave GM_DIALOG.

Or is this just a giant amount of unnecessary work? Is what I've got good enough, and this other method is actually unwise in some way?

[Magic]

If the goal is to make checks automatically succeed, I would just do what you did first. If you make custom skills, you should be able to recognize them by their IDs, no?

Thanks for reminding me that the gamemode change event can be used to detect the end of the dialogue! I used the end conversation script but that is tiresome when it's necessary for many creatures. Were you able to retrieve the NPC speaker though? I think you need to store it somewhere then the conversation starts. This, at least, can be detected by the EVENT_TYPE_DIALOGUE as well.

Ah the possibilities! ^^

[Rolenka]

Oh, I wasn't very clear. The reason I'd have to add skills in the second method is because some skill checks aren't tied to after-attribute values, only skill ranks. So if you didn't have Stealing 4, the buff would have to give you Stealing 4, then take it away at the end of dialogue, back to whatever skill level you had before.

The hard part is "remembering" what was added, so you know what to take away. I've never had to learn to store data for later retrieval the next time the script is accessed...

Then again, that method wouldn't work if there were a custom skill in a module, since it wouldn't be a part of the buff.

I guess each method has its advantages and disadvantages, which is sort of why I was also looking for opinion.

Modifié par Rolenka, 06 février 2010 - 12:19 .

[Magic]

I see. Yes, I was thinking in the wrong direction. Even then though, can't you just replace the script checking for skill ranks as well? Too many?

[Rolenka]

I did, and it works, but I worry that a conversation somewhere may be scripted to send the check to another script. Like, what if instead of "low," "medium," "high" or "very high," they wanted to see if the player had something even higher? Or at least exactly 27 intimidate? They'd need a custom script, which would bypass my mod.

I may just be being paranoid.

Actually wait, never mind, I'm being dumb. Some checks are for skill ranks, others are for after-attribute-bonus skill levels. My existing script would do the trick for skill rank checks -- there'd be no reason for a module maker to bypass that; there are only so many ranks and the default accounts for all of them. They could bypass it, but there'd be no reason to.

If they wanted a custom check for after-attribute-bonus skill levels, all I'd need is an in-dialogue attribute buff to ensure compatability.

I'm having a hard time explaining it, but I shouldn't have to worry about adding or removing skills after all. Just buffing attributes, which won't even be needed often.

[Magic]

I think you did the right approach. There are always methods to circumvent a system. That's nothing to worry about in this case, in my opinion. If the buff is making troubles, you could also increase the base attribute values by a fix number during the conversation. This way, it's easy to know what to remove afterwards.

[Rolenka]

Magic wrote...

I think you did the right approach. There are always methods to circumvent a system. That's nothing to worry about in this case, in my opinion. If the buff is making troubles, you could also increase the base attribute values by a fix number during the conversation. This way, it's easy to know what to remove afterwards.

I could have sworn looking through the code there was a comment about them deliberately not allowing increases/decreases in base attributes, preferring to use effects instead...

Anyway I haven't gotten to coding a buff yet, since the circumstances under which it would be necessary seem so unlikely. But I may at some point, especially if I find a point in the original campaign where it would be needed.

[Magic]

I just found this in utility_h.nss which is called by the standard skill check plot scripts. Are you aware of this?

int UT_SkillCheck(int nSkill, int nLevel, object oObject = OBJECT_SELF)
{
//There is an override set on the moduel to ensure success or failure.
//if the override is 0, do not use it.
//if the override is 1, always return TRUE.
//if the override is anything else, always return FALSE.
//David Sims, Novermber 7, 2006

// Intimidate will now work like persuade
// Yaron Jan 12, 2009
object oModule = GetModule();
int nOverride = GetLocalInt(oModule, DEBUG_SKILL_CHECK_OVERRIDE);