New Temple+ Available

Does a short video demonstrating the issue help Sitra? I can upload the log as well if you like.

What I do for testing the flanking issue: Start a new game, create a bard and someone else, level the bard to level 2 spawn a gnoll, set fudge dice rolls to 1.

Start combat, I hit two rounds with both combatants (of course they always miss) but I can see the +2 flanking bonus. As soon as I start to change this setup by casting a spell that adds a condition like undersong, which isn't even combat related, I start not getting the flanking bonus nor do I provoke AoO with the bard, if I start moving around the gnoll.

EDIT: I took a short video for demonstration purpose, though I forgot to demonstrate the AoO issue in the clip.

 

Here is a save game Sitra, thank you for looking into this, hopefully you can find something.

 

Your callback for EK_Q_Critter_Has_Spell_Active always returns 1, without checking the spell enum.
Of course, the real criminal here is @_doug_ from whom you copied this error... tsk tsk!

Oh, to clarify, the game engine is checking whether the spell Sanctuary is active to determine whether Flanking is possible, and the spell is always returning 1 regardless of the actual spell enum, so the game thinks so.

 

Ok ty so much for pointing this one out to me! Ok, so I simply have to add a check for the spell_enum and everything is fine? Or shall simply remove the hook?

Another question I stumbled on is how do I add spells to the assassin prestige class? I've tried to edit the assassin spell list in rules\char_class\class021_assassin.py but then the game crashes and log tells me unknow spell, presumably cause custom spells get loaded after the classes though maybe I just tried to add them at the wrong spot.

 

Yeah you should check if evt_obj.data1 is equal to the spell enum before setting return_val = 1.

As for the Assassin, to recognize the new spell enum (presumeably you defined it spell_yadda_yadda), it should be added to constants.py in tpdata\templeplus\lib\templeplus. You can do so manually for now, and I'll add it to the next release once you're done. This has to be done centrally anyway so as to avoid conflicts between different mods.

 

Sorry about that! I'll have those spells fixed shortly.

 

There is for sure a better way to do this, but here is what I've done for every spell that adds arguments:

Code:

spellEnum = (str(spell)[str(spell).index('(')+len('('):str(spell).index(')')])

spellTarget.obj.condition_add_with_args('sp-Critical Strike', spell.id, spell.duration, int(spellEnum))

and then in the tpModifier:

Code:

def critStrikeHasSpellActive(attachee, args, evt_obj):
    if evt_obj.data1 == args.get_arg(2):
        evt_obj.return_val = 1
    return 0

Edit: To clarify, the idea behind this was, as you pass already the spell.id and the duration, it seemed logical to me to pass the spell_enum as well. I hoped that the enum is simply passed to python by spell.enum but after I took a look into spell.cpp I noticed that's not the case. So now I convert the return of pyObject spell to a string, cut the enum number (which is luckily stored between () , else it would be more complex to do it) and convert it to an integer and pass it as the 3rd argument.

 

Modifier args are generally meant for dynamic quantities, such as spell IDs, particle sys IDs, obj handles etc. Spell enum is static and known in advance, so no real reason to store it there.

 

Oh that's totally fine Sitra, I was just hoping for an easy solution

I was looking for the nauseated condition, as a few spells I want to implement just add that condition. According to this link https://github.com/GrognardsFromHell/DllDocumentation/wiki/Scripting-API#d-specialspell-conditions it does not work out of the box, so I took a look at the feat Pain Touch and how this feat handels it. I noticed it is just added as an effect directly in the feat, something I do not want to do with every spell, so I wrote a new tpModifier: nauseated-condition.py. I hope this is fine. I've attached it, if there is interest.

 

On the begin round func, you assumed the number of rounds being ticked down is 1. This is not always true. See pain_touch.py.

Also, the tricky thing with spell sub-modifiers is making sure they are removed on spell end. I'm guessing that's why doug bundled it with the spell condition itself.

 

Hey Sitra, thanks for pointing out the tricky remove condition on spell end problem. I've noticed that problem already while trying to get the spell Critical Strike working. I've applied the spell keen edge as a secondary condition to apply the keen effect, but when the spell ends, keen edge wasn't removed from the weapon. I have not found a solution to this problem yet and assumed the problem was because I used an existing spell that presumably doesn't use the Temple+ template but I admit I haven't looked into that.

On the plus side, my testing with nauseated haven't shown such problems yet, but I will keep an eye on it.

Yeah I've noticed that in pain touch is not simply counted down by one each round, but I could not think of a situation where I would want to count down more than by one in a round counter. But I changed that line to simply subtract evt._obj.data1 no problem

Thanks for your feedback, I really appreciate it. I still have a lot to learn regarding Temple+, but I am really happy it exists and gives me the opportunity to modify the game in such a great way.

I've noticed that alot of spells, I want to implement are swift actions (https://www.d20srd.org/srd/combat/actionsInCombat.htm#swiftActions), which are like free actions, but you can perfom only one per round and you do not provoke AoO. Do you have any plans to implement those in Temple+? I've ruled them as free actions atm, but I noticed they still provoke AoO. I assume I could suppress those, leaving me with the one per turn problem.

 

It can count down by more than 1 for example when resting (so the time delta reflects the fact that hours have passed). In general it's best to stick with the examples and not make simplifying assumptions unless you're 100% sure of it.

Regarding spell end, this is unfortunately a big convoluted mess in ToEE, which also goes to explain why players often run into spell permanency issues. Even I don't have the full picture in my head right now, I suppose it needs to be thoroughly mapped out and documented. I'll add that to my list since it seems to be getting more relevant lately.

I've had a vague desire to add swift actions for a long time now, since various splat book Classes make use of them. Not sure yet how hard it'll be, depends on how rigid ToEE's state keeping is. I think it should be easy to at least add a placeholder swift action that will behave as free action until it gets implemented, and you may even be able to add it yourself. Something to keep in mind is that ToEE isn't 100% accurate with action economy anyway (e.g. reloading xbows) so I wouldn't make a huge deal out if it.

 

Great work guys. Been playing this game since the train wreck release in 2003 and drop back over here every couple years and am always thrilled to see all the new content that keeps this great game alive! Loving the new classes/feats/build option.

Couple questions and I hope this is the right place:

1) Where can I find descriptions of the new armor crafting attributes? I saw that a lot of this is non core but I'm not even able to find it anywhere online. Any help would be much appreciated.

2) Is rapid-metamagic not implemented properly? As I understand, it should make adding a meta-magic feat to a spontaneously cast spell a standard action but it does not work for either my bequiler or favored soul. I did recently update from 1_0_75 to the latest one .84 in mid-game (for some reason auto update wasn't working properly) so is it possible that the recent addition(rapid-matamagic, if it was) didn't take?

 

I am trying to get a slider radial menu entry to work. This is the c++ code I was looking up:

Code:

RadialMenuEntrySlider::RadialMenuEntrySlider(int combatMesLine, int _minArg, int _maxArg, void* _actualArg, int combatMesHeaderText, uint32_t _helpId): RadialMenuEntry()
{
    type = RadialMenuEntryType::Slider;
    text = combatSys.GetCombatMesLine(combatMesLine);
    maxArg = max(0, _maxArg);
    minArg = 0;
    actualArg = reinterpret_cast<int>(_actualArg);
    if (combatMesHeaderText != -1)
        field4 = reinterpret_cast<int>(combatSys.GetCombatMesLine(combatMesHeaderText)); // the popup title
    helpId = _helpId;
    callback = (BOOL(__cdecl*)(objHndl, RadialMenuEntry*))temple::GetPointer(0x100F0200);
}

and this is what I tried to do:

Code:

sliderSetBonusAmount = tpdp.RadialMenuEntrySlider(5103, 0, improvisationBonusCap, bonusToAdd, -1, 0)
sliderSetBonusAmount.add_as_child(attachee, improvisationRadialId)

but it does not work, what I am missing? (I did add combatMesLine 5103 in combat.mes).

 

1) @_doug_ just added tooltip descriptions to the crafting UI. Will be available next version. (BTW, you should probably add wiki entries as well)
Until then you can use this site: https://dndtools.net/

2) Huh, looks like it only works for Quicken. It looks like I forgot to address the full round -> std action case, I guess because it's less impactful... oh well.

@Sagenlicht It's not supported currently. It needs to be added to python_dispatcher.cpp, todo...