Automatic Changes to Known Spell/Daily Spell Counts?

[HoloGnome]

I think I saw an issue that seems like it might include a bug, but before trying to pin it down, it would help to know how the ruleset expects things to work...or maybe what it's doing.

The problem is that for the mystic I was building, the ruleset kept changing the spell setup counts to incorrect numbers...maybe whenever I opened the sheet - not exactly sure. And, since I was doing a manual build, maybe something was slightly out of sync. It's obviously using level and stat as a starting point.

The reason I am reporting this issue to you is that it didn't seem like the ruleset was correctly calculating the spell numbers including features that offered additional spells - like connections, etc. And, if when a user sets up their sheet and drags over prefab content, it's fine to try to help them set up the initial numbers of spells known/daily ones, but after that, my preference would be that the ruleset not dynamically change things every time I open it. But, I'm not sure exactly when the change was happening - just that it was.

So...my question is: what is the ruleset doing with respect to dynamically changing spell counts, when does that happen, and are you sure it is taking everything into account? (because I kept ending up with incorrect, automatically adjusted counts in the spell class header) Thanks!

[deer_buster]

Connection spells are in addition to the number of spells known and are not added to the number of spells known (every connection gives an extra spell known at the specified character level, so why wouldn't they just included that number in the table if that was what it was meant to do?) The reason being is that the spells known is the number of spells you get to choose...the connections are predetermined (from all connections I have seen).

If you want to see what it is doing, check the ruleset code yourself (you seem to know code). If there is a confirmed bug, we'll investigate, but I am not seeing it when creating a mystic the way they are meant to be done in FG (i.e. not manual). (e.g. 18 Wis mystic has 3 first level spells per day [2 for 1st level, plus 1 for high wisdom]), the DC is 14 for a 1st level with 18 Wisdom, knows 2x 1st level spells, plus the bonus spell, and 4x 0 level spells. Switching over to Spontaneous caster (clicking the icon next to the class name on the spell tab to change it to a star symbol), allows you to see the spells in Combat mode without "preparing" them.)

Bottom line, I am not able to see a problem with the spells per day or spells known (which doesn't change for anything except with level).

[HoloGnome]

Yes, connection spells increase the number of spells known, so that should be reflected in the count for the class header. And, it is not just +1 spell. As you increase in level and take the next higher one, there is an additional increase of a specified replacement spell at the earlier level that you may not already have. Bottom line: automated code shouldn't constantly try to change spell numbers because it doesn't seem to be doing the right thing.

[deer_buster]

Yes, connection spells increase the number of spells known, so that should be reflected in the count for the class header. And, it is not just +1 spell. As you increase in level and take the next higher one, there is an additional increase of a specified replacement spell at the earlier level that you may not already have. Bottom line: automated code shouldn't constantly try to change spell numbers because it doesn't seem to be doing the right thing.

At level 1 it is +1 for 18 Wisdom. Are you seeing an instance where this isn't the case? Do you have an actual bug to report? And no, it shouldn't be reflected in the count, IMHO, otherwise Paizo would have already done that...

[HoloGnome]

Possibly - as above, I was asking under what circumstance the auto-set or recalculate happens so that I can test for it, specifically. The answer above is for me to check it myself. If you can tell me at what point you are resetting the numbers in your code, then I can help with some more unit testing to try to pin down what I was seeing. I reported this issue so that you could capture it. I don't have the reprocible case. I just noticed that something I was doing was causing numbers to be reset incorrectly.

And, as a user, I want my known spells block, for example, to reflect ALL my known spells, since, as a spontaneous caster, I can can cast any of them. And, as a GM, if I look at a player's sheet to ensure it is correct, I want to see the spell block reflect ALL their known spells, including spells from connections or other abilities that increase any counts. So, I think you are misinterpreting the way the known spell count block should work. If my caster knows a spell, then the number in the block should reflect that, even if it is in addition to the base table.

Also, another problem I saw was that the cantrip counts were incorrect. If you know a cantrip, you can cast it. I think the automated code was changing those values, too. But again, if you can tell me when the number reset happens, then I can try to test for it and should be able to get back to you with whatever I see. Otherwise, I'll try to pin it down in the future when I see it again. It is definitely not correct or optimal behavior for the client.

[deer_buster]

I'd have to search to find it too.

[HoloGnome]

OIC! :D Keep up the good work, SFRPGers! If I have time, I will try to poke around. And, again, thanks for looking into all these issues and for the quick fixes. I have been sequentially going through things and just trying to give you everything I see. I know I am reporting a lot of individual issues, but that is to be expected in newer code.

[deer_buster]

Gotta remember, Samarex took over the rule-set code from someone else, and I started volunteering my time to help him a few months ago...so neither of us wrote the initial code, and we have to plug away at it the best we can. It involves a lot of searching (and Debug statements) to find where things happen and why they happen.

We are mostly working on fixing verifiable (reproducible) bugs and changing the rule-set to accommodate additional official content (such as the Companions from AA3, and now all the changes for COM).

Given that our time is limited, we need to prioritize our time and effort and cannot make every change that is requested by every user, nor run down every question that is asked.

Keep plugging away at testing and making suggestions, and when you find a bug that you can reproduce, please remember to provide the exact steps to duplicate it every time, otherwise it makes it impossible to track down.

[HoloGnome]

Sounds good. I have come along somewhat late to FG SFRPG and wasn't really following too closely before now, but am giving it a try. I didn't know the history - thanks for that info. This thread was mostly a question about where the trigger happened so that I could test it. I didn't realize that you didn't know either. :D Anyway...I will try to track down what I was seeing. I just worked around it, because I *think* the auto-adjust happens when the spell class header name = the primary class name. So, I just don't do that now and the problem has stopped affecting my manual build. :)

[Trenloe]

Gotta remember, Samarex took over the rule-set code from someone else...
Some background details here: https://www.fantasygrounds.com/forums/showthread.php?40667-Starfinder-Conversion-Extension-for-PFRPG&p=362899&viewfull=1#post362899

[Samarex]

@Holognmoe,
I believe alot of the issues you come across is due to what you are trying to do manually.
The system is not set up to manually create a character.
It is set up to manually create any aspect of a character IE Race, Class, Theme , Abilities ect....
Everything can be created thru FG, then use the built in system to create the PC.

[HoloGnome]

Specifically, my reports about not being able to enter class and level are because of manual entry. I don't think the client should be in the way of me manually creating a character. But, I also realize you are trying to synchronize with multiple sources, which is great. But, that shouldn't stop things from being unlocked if the user can manage it. My other reports are mostly bugs. I will track down the spell count issue sometime in the not-too-distant future. I have to find the reproducible case.

[deer_buster]

The ruleset is, in general, meant for the everyday user that wants their stuff automated in FG, not the power user that wants full control over everything. Where it makes sense, and the developers of the ruleset have time, options such as manual entry could possibly be added. But as I have said elsewhere, we have to optimize the time we spend making changes, and are focusing our time on bugfixes to existing ruleset code, and adding features to support official content. While we are in the code making changes, if we see something that is easy to change/add and makes sense for the time it takes to do, some things will be added outside of the boundaries I have mentioned.

Power users can utilize extensions to do whatever they wish, such as override charsheet related code and xml, to allow an option for manual control, or pretty much anything else they want to do within the limits of what FG is capable of. If their extensions are useful and don't break existing code, there is a good chance that they could get incorporated into the ruleset, as I have stated elsewhere. So please, by all means, create extensions that make the ruleset work the way your want it to. If your extension stays within the official content rules, and is useful and well written (read that as easy to understand and implement), then share it and it is possible that it might be implemented.

We appreciate the bug reports, and feature requests tremendously. Keep them coming.

[HoloGnome]

Thanks! And, I appreciate all the rapid bug fixes and the work you guys are doing! I am looking forward to the new version! Where necessary as I am learning the rules and ruleset, I have just been modifying the xml for my manual build process.

Parenthetically (to refer back to an earlier post), I have kind of been getting used to the new CT effect remove function vs. the Remove Extension, which seems best for 1-off effects. The REMOVE effect extension is better when I have applied something to the whole party and want to remove or change it (as I noticed today in a party of 7, plus a bot).

I will keep sending what I find as I go through the rules, and knowing which automation I have to work around is certainly helpful! Keep up the good work!

[Samarex]

Possibly - as above, I was asking under what circumstance the auto-set or recalculate happens so that I can test for it, specifically. The answer above is for me to check it myself. If you can tell me at what point you are resetting the numbers in your code, then I can help with some more unit testing to try to pin down what I was seeing. I reported this issue so that you could capture it. I don't have the reprocible case. I just noticed that something I was doing was causing numbers to be reset incorrectly.

And, as a user, I want my known spells block, for example, to reflect ALL my known spells, since, as a spontaneous caster, I can can cast any of them. And, as a GM, if I look at a player's sheet to ensure it is correct, I want to see the spell block reflect ALL their known spells, including spells from connections or other abilities that increase any counts. So, I think you are misinterpreting the way the known spell count block should work. If my caster knows a spell, then the number in the block should reflect that, even if it is in addition to the base table.


Ok when you create a Spell caster I.E Mystic or Technomancer the system creates the Spell category and sets the Spells Per day to the table from the CRB. This updates when you level as it is tied to the Class Level.
Note: the Auto Update of #Spells/per day and #/Spells known only updates if the name of the Spell Class is the actual Class name. I.E Mystic, so the other created Spell Class sections do not update when you level.


Now for the Mystic that gets extra spells from his connection the way to handle this is Create a second Spell Class and and name it Connection, you can then set the #/Per day and #/Spells Known for that Spell Class. You then put your connection spells in that Spell Class and your Regular Mystic Spells in the Mystic Spell Class.

See attachment for example

Second Option:
If you really want to do all your input for spells manually using the one Spell Class section just change the name from Mystic to I.E-Mystic Spells and the automation for Class Level (in the spells class),Spells per day, and Spell Known will no longer update. but you will have to update them every level.