Temple+ New Feats

You can put wt_mindblade, I'll make sure the protos.tab parser knows how to read it.

Also it looks like IsVisibleInventoryFull doesn't do what you think it does. I've fixed it (it should use GetItemAtInvIdx(handle, i)).

Lastly, please don't submit something unless you're sure it can build. That's the bare minimum.

 

My bad, will keep that in mind.

For the weapon focus mind blade feat, would I hook to OnToHitBonusBase and return evt_obj.attacker.return_val += 1 for the attack bonus?

Additionally I'm not sure if I got the weapon type correctly, am I allowed to use objects.GetWeaponType in python? Otherwise how would I use the wpn PyObjHandle?

Code:

# Check if weapon used is mind blade
  wpn = evt_obj.attack_packet.get_weapon_used()
  type = objects.GetWeaponType(wpn)
  if (type != wt_mindblade):
return 0

 

ToHitBonusBase is for the Base Attack Bonus, generally only class levels should affect it.
You should always reference the Conditions list to see what similar effects are doing:
https://github.com/GrognardsFromHell/DllDocumentation/wiki/Conditions-(List)
https://github.com/GrognardsFromHell/DllDocumentation/wiki/Conditions-List-Pt2-(spell-effects)

As for weapon type, in this case it's a simple matter of accessing the obj_f_weapon_type field .

Generally you don't have direct access to any of the C classes in the Python layer. You only have the python object methods (python_game for game., python_object for objects), and the builtin modules such as tpdp, tpactions etc. But if something's missing from those and is available in the C layer, you can just add new methods like I've just added item_wield

 

Well I certainly feel less uncomfortable adding new methods now that I just had that practice you gave me.
Shape mind blade is pretty much the same as mind blade except handling some logic deciding which radial options are available, so I should be able to put that out within the next day or so. I'm going to start testing now too, should I have everything I need from TemplePlus if I copy the current branch into my install directory?

 

I haven't implemented the parsing of wt_mindblade yet, but maybe you'd like to add it?
Add wt_mindblade to temple_enums.h
For the protos.tab parser, check protos.cpp, ParseType (line 321). I've prepared a stub for expansion there, should be fairly straightforward for you to add handling for a "mindblade". I recommend you run it in debug mode and set a breakpoint to get a feel for it.

 

Do I need to use attachee.condition_add_with_args to add a modifier in radial build for modifiers connected to feats?

 

Not anymore, it'll now automatically apply the feat modifier due to the mapping ( the .MapToFeat() method).

 

Will the obj_f_prototype_handle field return the proto ID of an object, or is simply get_weapon_used() the proto id?

 

Neither. Proto id is the number in protos.tab, it has nothing to do with object handles.

Get weapon used returns an object handle, not the proto id.

You can get the proto id from the PyObjHandle, however, since I've implemented a "proto" property in python_object.

It's very important for you to understand that all objHndl objects (in the C++ layer) are converted to PyObjHndl objects in the Python layer.

So get_weapon_used() returns a PyObjHndl, and then you can use its .proto property to get its proto id (which is just a plain number).

 

Are all of the functions in python_object.cpp ones that can be called in the python layer? Also, does a PyObject always refer to an attachee? I can do attachee.has_feat(<feat string hash>) right?

 

All the functions in python_object are available, yes (and you can extend them as you've seen).
Attache is always a PyObjHandle object, if that's what you mean. In the context of Modifiers, attachee is the object who owns the Modifier instance.

Note that for Item Modifiers, the Modifiers are applied to the wielder and not the item itself, even though you specified it as an item property. So attachee will be the item holder. This is handled by the engine.

 

What are your thoughts on my method for some feats where I do a check in the radial that decides if it is displayed or not

Code:

def PsychicStrikeRadial(attachee, args, evt_obj):
  isEmbued = attachee.d20_query("PsyStrike Embued")
  if isEmbued:
    return 0
    radial_action = tpdp.RadialMenuEntryPythonAction(-1, D20A_PYTHON_ACTION, psiStrikeEnum, 0, "TAG_INTERFACE_HELP")
    radialAction.add_child_to_standard(attachee, tpdp.RadialMenuStandardNode.Class)
  return 0

and having no check in oncheck or onperform, instead simply setting values?

Code:

def OnPsyStrikeCheck(attachee, args, evt_obj):
  return 0

def OnPsyStrikePerform(attachee, args, evt_obj):
  args.set_arg(0, 1)  # Set to embued
  return 0 

Is this always worse than having check/perform do the handling themselves?

 

I'd say it only matters if you want to allow for a more complex interaction, such as allowing something to interfer with the process.

BTW forgot to say that yeah you can do feat_has.

 

With new feats that have an action file defined, will the game engine know to insert the float text of "not enough time" or "already moved" (forget which) if/when the action requires an amount of a turn (e.g. move action or full round) and you can't fulfill that?

 

Yes.