Hero.Epic

[ShadowChemosh]

Another note about class and class helper. The Class Helper has 99% of the information anyone will want when dealing with the class (BAB, Saves, Skill Points, Feats, Languages, custom abilities, Spell per day, spells known). The only thing that is helpful on the Class pick is the hit points that where at taken each level.

 

[Nightfox]

The problem with using the cHelper pick is that it has the totals. What we need is a subset of that based on an arbitrary point in history that is only monitored (as far as I can tell) by the cClass picks.

for example, lets say we have a 40th level hero as follows: Fighter 20, Wizard 20. Based on the cHelp picks we would have a BAB of 30:
Fighter: 20
Wizard: 10

However we want the total BAB this hero had at 20th level. Based on the cHelp we know how many total levels of the class we have, when we took our first level and when we took our last; but we do not know when we got those levels. That is why I was looking at the cClass instead of the cHelp to start with. As you mentioned, the hero above would have 1 cHelp for the fighter class, but 20 cFighter listings. Each of the cFighters indicate what level the character was at the point the cFighter level was added.

I have not really looked at timing yet, but it has to run after BAB would be calculated, but before it is used in other calculations. We want to change the BAB [tAtkBase] to match the 20th level value we calculate and add an epic attack bonus [tAtkEpic] that would add to our to-hit, but not to our number of attacks. Therefore the total number of attacks the character would have would be stopped at 20th level.

Back to our example above, HL would currently give the character 4 attacks on a full attack action (same in pathfinder). This is fine if the character had taken at least 12 levels of fighter before taking his 21st level (12 Ftr + 4 Wiz = 16 BAB). However if the hero did not take at least 2 levels of fighter he would only have 2 attacks a round (1 Ftr + 9 Wiz = 10 BAB)

There is a change for the saves as well, but I do not think there are any timing issue with them.

 

[ShadowChemosh]

Well I do appreciate finally getting the 'problem' you are having. LOL it makes it much easier to try and find a solution!

My next step here is I would have to read up on Epic level rules to even figure out what the expected result is for a character that goes above level 20.

Then with "both" of those I maybe able to tweak something in d20 to give an easier result that the "community" could implement then. Something that would prevent the need of 7 foreach loops.

One quick thought would be just stopping HL from adding values to saves & BAB once it reaches level 21+. Then in "concept" all the community would need is some logic to "increment" the values once past level 20. Sorry "no" promises but at least I know what to look at.

 

[ShadowChemosh]

Erin, Illyahr, Sendric, AND ANYONE ELSE INTERESTED

I've started working on a rough bit of script and I wanted to check something with you and the community. From what I can find of the Epic rules there is a little bit of ambiguity. Everything is fine if you are playing one of the base races with standard classes for 1-20th, but it gets a little foggy when it comes to non-standard races and templates that may add hit dice or level adjustments. Therefore I wanted to ask what people think:
When should the epic progress start?

a) ECL > 20
b) HD > 20
c) Class(tag) > 20 (includes racial HD+LA and class, but not templates)
d) something else​

The last 3.5 FAQ printed 6/30/08 has this to say:

When is a monster character considered epic level? Do you “go epic” when your total class levels equal 20 or when your total Hit Dice equal 20? Is a monster character eligible for epic-level feats (such as Epic Toughness) when its character level is 21+ or when its ECL is 21+?

A monster becomes an epic-level character when its character level hits 21, just like any other character. A monster’s character level equals its racial Hit Dice + class levels. (See the second sidebar on page 25 of the EL.)

A creature’s ECL has no effect on when it becomes an epic character, although once it becomes an epic character, its ECL continues to affect how much experience it earns and when it can add a new level.

As that is the last official word from WotC if I do any work on Epic rules that is what i would go by as the official rule.

 

[Nightfox]

Thanks Shadow. I was hoping to get something loose that could be made available to the community files, but soooooo many ugly foreach statements /__\. I just really wanted a way to avoid those first. Also, I'm sure many people either do not play epic tier or do not use the 3.0/3.5 epic rules so I wanted to make it something people could choose to use for their character, or choose not to.

As that is the last official word from WotC if I do any work on Epic rules that is what i would go by as the official rule.

you know, I looked all over the place, but didn't even think of checking the faq.

It still has the issue of whether hit dice added by a template, such as the lycanthropes would be counted as racial hit dice. I personally would think so, but again, I'm not sure. At this time though, HL does not appear to treat them that way. There is a listing in the SRD:

In addition, a lycanthrope’s character level is increased by the number of racial Hit Dice the base animal has.

If these do count as racial HD then it could add a level of complexity to the work. After all, HL does account for these add HD, but it adds them in one lump sum. A 19th level character who is bitten could suddenly have 21 or more levels/HD.

I had a thought while I was looking over the response on the other thread. I've seen some examples of code where, if I understood it correctly, when using a variable as a string you copy a portion of a tag in order to identify another relevant pick or tag. I can see a way of going from the cHelp to the cClass like that. Is there a way to go in the other direction? That might be a way of eliminating many of those foreach loops if we cannot get to the cHelp from the class array index.

 

[ShadowChemosh]

I can see a way of going from the cHelp to the cClass like that. Is there a way to go in the other direction? That might be a way of eliminating many of those foreach loops if we cannot get to the cHelp from the class array index.

If you are on the BaseClass componet (ie cWizard) you can get to the class helper cHelpWiz by using a linkage:

linkage[helper].field[XXXXXX].value

XXXXX being a field on the cHelpWiz in example.

 

[Nightfox]

If you are on the BaseClass componet (ie cWizard) you can get to the class helper cHelpWiz by using a linkage:

linkage[helper].field[XXXXXX].value

XXXXX being a field on the cHelpWiz in example.

That gets me fields. Can we use linkage[helper] to get tags as well?
If we can, we may be able to get this down to a single foreach loop and use this cool new (to me) toy to pull the tags for the calculations. The sample above appears to start from within the pick.
For example:

if (eachpick.linkage[helper].tagcount[cAttack.Good] <> 0) then
elseif (eachpick.linkage[helper.tagcount[cAttack.Medium] <> 0) then
elseif (eachpick.linkage[helper.tagcount[cAttack.Poor] <> 0) then
endif

or is that linkage[helper] a processing nightmare as well?

 

[ShadowChemosh]

That gets me fields. Can we use linkage[helper] to get tags as well?
If we can, we may be able to get this down to a single foreach loop and use this cool new (to me) toy to pull the tags for the calculations. The sample above appears to start from within the pick.
For example:

if (eachpick.linkage[helper].tagcount[cAttack.Good] <> 0) then
elseif (eachpick.linkage[helper.tagcount[cAttack.Medium] <> 0) then
elseif (eachpick.linkage[helper.tagcount[cAttack.Poor] <> 0) then
endif

or is that linkage[helper] a processing nightmare as well?

Need a ] at the end of the word helper but that should work. To be honest never tried but logically it works.

And yes you can do tags or fields against a linkage and a linkage is very low CPU.

 

[Nightfox]

Need a ] at the end of the word helper

Realized I missed the brackets after I hit submit, but right now I'm too hyped with the thought of cleaning my code to go back and fix it.

but that should work. To be honest never tried but logically it works.

And yes you can do tags or fields against a linkage and a linkage is very low CPU.

WOOT!
OK, I'll spend this evening retooling the code and see if I can cut it down and make it manageable.

Hopefully I can have something to share (at least for testing) tomorrow.

 

[Nightfox]

Help!!!
Ok, I've gotten the code down to one foreach loop, but as Shadow pointed out, the loop doesn't search in any particular order and we really do need the values in order for them to be meaningful. I wrote out the code in a text editor and tried to copy it into HL for testing, but only a small portion of the code would fit in the eval script. I've spent the last couple days trying to shrink it down, but even without information lines (~) it is still well less then half of what I want.

I have two thoughts, but I'm not sure if either of them are viable.

First:
What is making the Foreach soooooo long is the level of redundancy. There is a block of code that is repeated at least 20 times with only a very slight variation based on a value in the eachpick.

if (eachpick.field[cIndex].value = [COLOR="Red"]1[/COLOR]) then
    [I]using values on the eachpick and linkage[helper]
    calculate values for what the increase to bab and
    saves as well as HD progression (typically 1 for classes,
    but may be more for race or template) and put these
    values into various value fields in special [COLOR="Red"]xClsCnt1[/COLOR][/I]
endif
if (eachpick.field[cIndex].value = [COLOR="Red"]2[/COLOR]) then
    [i]DO IT ALL AGAIN[/I]
    put values in special [COLOR="Red"]xClsCnt2[/COLOR]
endif
etc
etc

I was originally doing all the calculations and such at the bottom of the script, but when I first started trying to trim things, it made sense to store the data someplace else so I could run a second eval scrip for those calculations.

The last entry on the Mathias thread for using math is from Adoxon

Why doesn't something like this work?

var id as string
hero.childfound[id].field[cGiveSpec].value+=1

but there is no followup, and I cannot find anything else about this. Is there a way to use variables in location codes? I could remove this redundancy, or at least the code side of it (the foreach is going to look at everything already ) if I can pull the value of the cIndex and use it to define where to save the data.
Example:

var index as number
var id as string
index = eachpick.field[cIndex].value
id = "xClsCnt" & index
[I]blah blah code blah[/I]
hero.childfound[id].field.... = data
nexteach

I thought I had come across a solution like this before, but I cannot find it now so maybe it was just wishful thinking.

Second:
While trying to find a solution to that id problem above I found lots of references for "findchild". I know foreach is bad for the cpu but what about findchild? If it is not as bad, then running a findchild in each of the specials might be a better way to go:

hero.findchild[ClassList,fieldval:cIndex = X].setfocus

my problem with testing this is that the test expression appears to only look at tags. Is this true?
One possible work around I was thinking was to use a foreach to search through all the ClassList and assign a user tag to everything.

var index as string
index = eachpick.field[cIndex].value
index = "cIndex" & index
perform eachpick.assign[User.(index)]

However the code above does not work, and this solution would only be viable if the findchild has very low cpu usage, which I am dubious about.

 

[ShadowChemosh]

I will take a look maybe this Sunday. Just won't have time before then. Sorry.

Allot of what I see is small syntax issues that would cause HL to freak out on. The "concept" I think is ok but the code syntax is off.

This:

hero.findchild[ClassList,fieldval:cIndex = X].setfocus

Needs to become this:

hero.findchild[ClassList,"fieldval:cIndex = 1"].setfocus

This script. I have no idea what your trying to do. SORRY! It looks like you trying to change a field into a tag and assign that as a string to the pick? If that is true you can't do that.

var index as string
index = eachpick.field[cIndex].value
index = "cIndex" & index
perform eachpick.assign[User.(index)]

findchild[] is almost as bad as foreach loop. The only difference is that you only ever get back "ONE" Pick instead of many. So the first Pick you get back better be the one you need.

 

[ShadowChemosh]

Thanks for the reminder about this. I was able to build a proof of concept that would cause HL to "stop" adding in BAB/Save values once it hit 21+ Class Hit Dice.

I would need to talk to Colen to see how or if I would be allowed to add this. I think "maybe" if there was an option to turn this feature on/off. My fear is that if I stopped this cold after 12 years of d20 always adding BAB/Saves after level 21 I will break peoples stuff.

But if this was an Option you could turn on/off then maybe I could get it in. So its a "good" news sort of thing.

 

[Nightfox]

I will take a look maybe this Sunday. Just won't have time before then. Sorry.

no worries, with what you've given me here, I'll post a file shortly to test.
* WARNING * it will be ugly and incomplete, but it will be a start for the rest of us.

Allot of what I see is small syntax issues that would cause HL to freak out on. The "concept" I think is ok but the code syntax is off.

This:

hero.findchild[ClassList,fieldval:cIndex = X].setfocus

Needs to become this:

hero.findchild[ClassList,"fieldval:cIndex = 1"].setfocus

Of course I missed something, I wouldn't be me if I didn't
I'd been playing with that particular concept since yesterday. I was fairly certain I had to use fieldval, but I couldn't get it to work. Quotes, so simple and yet so important.

This script. I have no idea what your trying to do. SORRY!

No worries, it just seemed like one of these things I had to try. And yes, it was trying to assign a User tag based on a value in the Pick.

findchild[] is almost as bad as foreach loop. The only difference is that you only ever get back "ONE" Pick instead of many. So the first Pick you get back better be the one you need.

Since the cIndex is unique it should only return the desired pick. However if it is that bad of a process suck, then the single foreach loop would be better then a bunch of findchilds.

I'll move forward with my findchild solution for the short term to share and post it here. Hopefully we can use variables to define paths and picks. if so, I'll offer a foreach version which will probably be easier on the system then the findchild.

 

[Nightfox]

Finally something to put up to test.

The attached file will add a source
Epic Level Handbook - Leveling

A condition "Epic Leveling" will be made available on the Adjust tab for the character. There will be no obvious changes until the hero has 21 or more Hit Dice from race and classes. The Hero.Epic tag should automatically be applied to the hero at that point (no need to check the box).

If you check the condition though, a series of eval scripts will run to determine the hero's BAB and Saves at the 20th HD and apply the epic progression for attack and Saves for all levels after that.

Known Limitations:
This setup assumes the hero will achieve 21 HD within 30 class picks. I know it seems obvious, but one of my current characters did not get to 21 until the 27th class pick. Templates can be a convenient way to add home brew campaign bonuses to your hero, but they count as class picks as well. If you find that your hero may not reach epic until after 30 picks, let me know and I'll expand it out further.

In addition, I am unsure how well this will handle HD added from sources other then the base race and class leveling. Again, if you notice problems let us know. I cannot guarantee to be able to solve it, but it is likely someone on the forum will be able to find a solution or workaround.

One last point, this uses a bunch of "findchild" statements. I did only light testing so far and my home computer is decently powerful so I did not notice lag. Your mileage may vary.