Senior Member
Join Date: Dec 2011
Posts: 100
|
As an additional note, the same "set" can be given to multiple companions, or none, and can be changed daily (as part of preparing your spells). Each companion can only have one "set" at a time. I therefore want the "sets" on the hero, and have a select-able script on the companions to choose which "set" (if any) they get that day.
at least that is the theory |
#11 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,243
|
So this needs to be operating on the familiar/animal/eidolon, and then looking up the spellbook list on that character's master. That vastly increases the complexity of this project.
You've seen in the code that we have separate tables for the spells for spellbook casters and other casters. The table setup needs to be different in each case. Yes, configurables have three spell tables, but none of them are set up to support spellbook spellcasting. Plus, even if this mechanism was available on configurables, it could not look up the spells on the master from within a minion - not in a way that would restrict the list of spells to show to those that are in the master's spellbooks - that could only work within a single character. The cfgAllwSp1 field has a size limit of 5000 characters, so it won't work to just list all the tags of the spells the character knows - by around 10th level, the character count needed to list all the tags for every spell in a wizard's spellbook will exceed that space, and it'll start generating syntax errors. So, what I would do here is to still use the configurable spellcasting tables, and set that up so that it gives you the proper list of spells to select from, but the overall list of what the master's class could possibly cast. Then, once that's working, begin phase 2 and figure out how to report an error if the user selects a spell the master doesn't know. I just tried for 15m and couldn't come up with a solution for how to accomplish that. I'd need to study the project in more detail. |
#12 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,243
|
Sets of spells mirrored from the master to a minion are not an approach I would recommend trying to accomplish until you are an expert at HL's code. I'd start out implementing a simple version of all this that just adds the spellcasting capability directly to the minions, and trust the user to validate against their spellbooks for now, and users will have to just edit the list each day if they want to change it, the same way a normal spellcaster works.
|
#13 |
Senior Member
Join Date: Dec 2011
Posts: 100
|
the problem is i don't trust
I'd like the list on the PC with a validation check on the minion. That would seem to be the easiest way to avoid ... mistakes? ... accidents? ... yeah, we'll go with that, because I'm absolutely sure no one would deliberately switch abilities to something more advantageous or add to more creatures than they can link. I don't think we'll need a full spellcasting tab on the creature, it could be handled entirely within the InPlay tab I think (it is very limited after all). But I want to make sure that they don't have more creatures linked than their limit, and they don't have more sets than their limit. If I leave the table list to BaseSpell and class, is there a way to do a validation check to make sure that the selections are in their spellbooks, and throw up some red text if not? note: one of the exploits I've already seen is someone who is going to be able to have 6 beasties in their link but only two sets. I kind of want to make sure they don't "accidentally" mix and match spells, or give a spell that isn't even on a set. Last edited by Nightfox; March 7th, 2024 at 05:19 PM. |
#14 |
Senior Member
Join Date: Dec 2011
Posts: 100
|
Do bootstraps get added at a specific time?
If tags are added to bootstraps, are they added the same time as the bootstrap, or do they have a later timing? |
#15 |
Senior Member
Join Date: Jul 2010
Posts: 3,151
|
Bootstraps are added immediately unless there's a condition. For various timing reasons, conditions usually have to be early (First/500ish). Any tags added to bootstraps are immediately applied. If you need a tag added later, you'll need to do that as a script.
|
#16 |
Senior Member
Join Date: Dec 2011
Posts: 100
|
New approach.
Creating an empty "ability" for each of the spells that could be utilized (limited list) that could be selected from the configurable tab that wouldn't necessarily apply anything to the PC but give a list list and tag that we can reference later. I've tried creating an ability with a custom tag and using an expression on the configurable to show items with that tag. ~ worked great... popped right up without even having to add the ability to hero beforehand... but we want to limit it to only after it is "on the hero" Ok, so try removing the tag and using an eval script to re-add the tag to the ability. ~ doesn't work. (suspect the eval script doesn't run if the pick isn't actually on the hero) Next try setting up a dummy spell with with ability bootstrapped. ~ (1) with tag already on the ability, it shows ... but it showed without the bootstrap, so no good. ~ (2) with tag applied by eval scrip, the tag shows on the floating window, but the ability does not show on the configurable table. Next try adding the tag to ability during bootstrap. ~ as above, the tag shows on the floating window, but the ability does not show on the configurable table. I was really hoping there was a timing issue, but based on what you've said, that does not appear to be the case. |
#17 |
Senior Member
Join Date: Jul 2010
Posts: 3,151
|
It would help if you could supply the script you're using. It's very difficult to debug something without seeing it.
|
#18 |
Senior Member
Join Date: Dec 2011
Posts: 100
|
Right now I have one solution that ... works?... which is to show everything and use Expr-reqs to grey out selections that aren't valid, but I really want to see if it is possible to actually adjust the tables to show only valid.
There is a lot going on and many different approaches being tried, so here are the different bits of code. This is mostly being tested with fake "things" until I find something that works. I really don't want to make a bunch of entries until I figure out what will and will not work. on the configurable: Code:
Post-levels 11000 field[cfgAllow1].text = "Custom.LinkSrg" field[cfgAllow2].text = "SpecGroup.LnkSrg" Created "abilities" (first tab under General in editor. Tried using simple but those apparently are not valid selections). If I give it the "Custom.LinkSrg" or "SpecGroup.LnkSrg" on the items already they always show, but as mentioned above, I would like to limit it so only certain selections are shown based on if they are in the character's book. Tried removing the tags from the ability: Result: ability does not show in either table on configurable Created a fake spell and bootstrapped the ability to the fake spell with the tags "Custom.LinkSrg" and "SpecGroup.LnkSrg". Result: The ability shows as something on the hero (floating window) and shows the tags, but the ability still did not show in either configurable tables. Created Eval scrip on fake spell Code:
Pre-levels 1000 perform hero.childfound[abSrgBlend].assign[Custom.LinkSrg] perform hero.childfound[abSrgBlend].assign[SpecGroup.LnkSrg] perform hero.childfound[abSrgBlend].delete[Helper.Helper] Also tried the script on the ability Code:
Post-levels 100 If (hero.childfound[spFakeBlend].tagis[Spellbook.cHelpWiz] <> 0) then perform assign[Custom.LinkSrg] perform assign[SpecGroup.LnkSrg] perform delete[Helper.Helper] endif Right now, my only guess is that the configurable table is looking only at initial tags and not at any tags added or removed by eval scrips. Last edited by Nightfox; March 12th, 2024 at 04:00 PM. |
#19 |
Senior Member
Join Date: Jul 2010
Posts: 3,151
|
Quote:
Code:
component.Ability & Custom.LinkSrg & !Helper.Helper & !Helper.Obsolete I did the following as a test: 1) Created configurable which I bootstrapped to a homebrew adjustment to get it on a character. I set the fields as follows (no script, just directly assigned): Code:
cfgAllow1: component.Ability & Custom.LinkSrg & !Helper.Helper & !Helper.Obsolete cfgMax1: 1 Result: Ability appears in the configurable selection menu. Last edited by Sendric; March 13th, 2024 at 04:51 AM. |
|
#20 |
|
|