Temple+ Modding Question

I thought music proficiency is tied to the perform skill?

 

No in 3.5 ability to use such things as Inspire Competence is tied to bard level providing the bard has sufficient skill in perform. Basic usage per day is 1 per bard level.

 

The bard stuff ia hardcoded in cpp (and it has no sneak attack fumctjonality).

What exacrly are you trying tp do?

 

Thank you for your reply.

Sorry sneak attack was just there as an example of an independent section of code in the papyrus you wrote for the rogue that I can duplicate successfully in another class.

What I am trying to do is produce a prestige class that advances bardic musical ability (and ideally bardic knowledge) e.g. the Fochlucan Lyrist from Complete Adventurer. I was and am assuming that bardic music was hard-coded as otherwise the Fochlucan Lyrist would appear to be a relatively straightforward development of Mystic Theurge.

 

I would be up for trying to add the ability to increase a character's effective bard level if you write the rest of the Fochlucan Lyrist class.

 

It appears to me that the saving throw values for new classes aren't working properly. The character inventory screen does not display the added values when you click on the number next to reflex, will, or fort, that would have come from the new classes. I'm only seeing gains there from the vanilla game classes show up. Confirmed with prestige classes as well as my class.

Also, saving throws may be broken in general from what I see in image 3.

Image 1: My character should be gaining 2 additional points to reflex from his class. He is not showing it. I even did a console command and stat level get for the save doesn't add the points from the new class.

Image 2: Curiously, I put print statements in the new class saving throw hooks to verify. All of these functions ARE being called and the values they give are the correct calculation. However it isn't being added to the character for some reason!!

Image 3: It appears that the saving throw values of critters are not being added in as part of the roll. My character has 5 points of fortitude and rolls being made for fortitude include only the dice.

I stepped through temple+ debugging on the saving throw and the dispatch call was returning 0 in the bonus list for all kinds of throws when my characters clearly had non zero values for each of their throws.

Ok it looks like this was my fault and happening on my branch, specifically as a result of this commit.
https://github.com/GrognardsFromHell/TemplePlus/commit/6cbe5180a93bb0f1339b6aa62b3f617873040ce5
I wanted to add the ability to get DC of a saving throw in the dispatch call, because it's SUPER useful to know that information and in the case of autohypnosis, necessary in order to function for the poison save. I'd guess this addition, benign as it looked to me, broke the saving throws in game because I was modifying the data packed in that struct and vanilla expected a specific order...

So yeah, I can take out my commit to fix what I broke, but then it takes out a very valid feature I need, and could be useful to other modders. So my question to Sitra/Darkstorm would be, how can I get the save DC of a saving throw like in my commit in that dispatch call in a way that won't break the game?

 

Thank you for your offer Doug. I was planning to start with the papyrus files for Mystic Theurge and modify them a requirement / ability at a time. As I see it the ability to cast druid spells in metal armour would probably have to be attached to the druid class rather than the Fochlucan Lyrist Class. I am afraid I have no idea how to reverse extract? these papyrus files into Temple+ proper....

 

Ok I think I fixed it by putting the DC variable at the end of the defined variables in that class, I'm seeing saving throws back to normal now. My theory about the byte data packing was correct, so since I kept from the start to the end all the original values and the newly added one is past what vanilla would look for, it shouldn't affect anything the game was already doing.
On another note, I enticed a shop map chest into combat with me..

Edit:
Another thing that caught my ear. There is no hit sound for a sickle hitting a fire elemental. Whatever comes out of the following function doesn't make ANY noise when I attack a fire elemental with a sickle.

Code:

    // weapon hit sounds (encoded data)
   if (soundId & 0xC0000000) {
       static auto getWeaponHitSound = temple::GetRef<int(__cdecl)(int, char*)>(0x1006E440);
       return getWeaponHitSound(soundId, filename);
   }

Any thoughts?

 

Hi Doug, I have arbitrarily decided to use Class099 as a working identifier for Fochlucan Lyrist. As I threatened I have hacked the Papyrus files for Mystic Theurge substituting the requirements (more or less) , BAB and saving throws of the Fochlucan Lyrist from Complete Adventurer for those of the Mystic Theurge. In addition to Bardic Music the Fochlucan Lyrist increments Bardic Knowledge but this does not seem to be a level dependent ability in ToEE? I have noticed that the function in the druid class that makes a character in metal armor non-proficient which I was hoping to make conditional on lack of Fochlucan Lyrist Level so as to effect part of the Unbound class feature also appears to be hard-coded in ToEE.
Please find attached 2 untested papyrus files which reflect limited progress to date.

 

Cool. I'll take a look at it before too long. Hopefully I will have some thoughts for you this week. Have you been able to test the class as it is now with temple+?

I don't think it would be hard to add an option to disable the druid armor restriction. I should be able to do that.

 

No I am afraid I will have to find out how to add classes first - I considered overwriting the Mystic Theurge in overrides but decided against it...

 

This is not a good idea, since vanilla code won't have that field, so you might be trying to access junk data in some cases.

In general you should never modifier original game structs unless you replace all their usages 100% or are otherwise very confident in how they're handled in the game code.

 

So how can I implement it then?

 

Fudge the rules

 

It is working in game by reordering the variable to the end so that vanilla ToEE wouldn't mess up its byte addressing in that struct. If I have a working solution I'm not going to sacrifice accuracy to the source material.

I'm very confident in the solution. Based on my observations, the issue was plainly byte packing of the variables contained in the dispatch struct. The compiled code turned "struct.var1" into something like "struct address + offset". If you introduce a new var from Temple+ between the original var1 and var2, now var2 when attempted access by DLL code will improperly be handled as expected, breaking the code as I saw. However, adding the new var after the rest of the originally defined variables so it is packed in past the end will ensure the game isn't going to hit addressing problems based on that accessing, because DLL code would never have tried to access out of bounds addresses of a struct it knew the size of to begin with. The struct size increases in the var, but the increased size when called through dispatch functions would only take up more local stack space. Unless we are in danger of a stack overflow there should be no issue, and I would very much doubt this to be a concern. I tested in game yesterday and encountered no issues, with it fully working.