Hero.Epic - Page 3

ShadowChemosh · November 29th, 2016, 01:53 PM

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 · November 29th, 2016, 02:54 PM

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 · November 29th, 2016, 03:12 PM

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 · November 29th, 2016, 03:44 PM

Quote:

Originally Posted by Nightfox

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:

Quote:

Originally Posted by FAQ

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 · November 29th, 2016, 05:06 PM

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.

Quote:

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:

Quote:

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 · November 29th, 2016, 05:27 PM

Quote:

Originally Posted by Nightfox

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:

Code:

linkage[helper].field[XXXXXX].value

XXXXX being a field on the cHelpWiz in example.

Nightfox · November 29th, 2016, 08:37 PM

Quote:

Originally Posted by ShadowChemosh

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

Code:

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:

Code:

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 · November 29th, 2016, 08:42 PM

Quote:

Originally Posted by Nightfox

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:

Code:

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 · November 29th, 2016, 08:50 PM

Quote:

Originally Posted by ShadowChemosh

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.

Quote:

Originally Posted by ShadowChemosh

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 · December 2nd, 2016, 12:39 PM

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.

Code:

if (eachpick.field[cIndex].value = 1) then
    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 xClsCnt1
endif
if (eachpick.field[cIndex].value = 2) then
    DO IT ALL AGAIN
    put values in special xClsCnt2
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

Quote:

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:

Code:

var index as number
var id as string
index = eachpick.field[cIndex].value
id = "xClsCnt" & index
blah blah code blah
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:

Code:

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.

Code:

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.