Feature - Implemented Include variable/scaling monsters in monster stat functions

Ah... that makes a bizarre logic. Makes buffing all the more useful. So that would make the above bit
Code: 
Monster    HP: min((my_basestat($stat[muscle]) + monster_level_adjustment()) * .75, 150) Def: min(my_basestat($stat[muscle]) + monster_level_adjustment(), 200) Atk: min(my_basestat($stat[moxie]) + monster_level_adjustment(), 200)

Anyways, the question's still there... do we want our monster data lines that long, do we start mangling Modifiers.expression, or do we make our own version of it at the expense of another 20-40k of mostly duplicated work?
 
That's not the right syntax you're basically passing in a float, the input would get resolved before the call to eval happens. modifier_eval takes in a string, it's probably going to need to be modified to accept more functionality in that string.

Who cares how long a line in monster data is I don't see how it's even an issue, and I wouldn't make a new version of modifiers.expression what would be your argument for doing so?
 
Last edited:
modifer_eval returns a float. I don't care about modifier_eval though, except in using it as a tip for how to call Modifiers.Expression.

Regarding it being a float, I'd just do (int) Modifiers.Expression.eval() and then the result should be the proper result...
 
No I mean you're passing a float into modifier_eval, it's just converting it to a string.
 
Rinn said:
Who cares how long a line in monster data is I don't see how it's even an issue, and I wouldn't make a new version of modifiers.expression what would be your argument for doing so?
Click to expand...

The length of the line becomes an issue when pasting new updated entries into the forum starts to break lines oddly... as it likes to do. Quote was breaking my example, which is why I changed to use the code tag.

The reason for making a new version of modifiers.expression would be because the only information we want it to use is about the only information it doesn't currently have... we can get location, zone, current familiar, main hand, preferences, min, max, blood effect, inebriety, fullness, grimacite effect, hobo power, test for festival of jarlsberg, get level, moonlight, reagent potion duration, speen usage, check turns remaining of an effect, telescope upgrades, familiar weight, and character gender.
Nothing about stats in any form, nothing on ascensions.

M is already used by moonlight (and we have 3 Ms anyways if we go that way), so we can't use that.
A isn't used, so that could be set to check ascensions... one down, 3 to go.
We could go bizarre and just pick 3 letters next to each other. N-Q are all available. That's also the only location where we have at least 3 contiguous letters.
Can't use DnD letters of S/C/I, as S is spleen usage... C and I are open though.
If we wanted to pick an alternate letter for S, we can use A/?/C/I as our 4 letters. Available letters: EKNOPQUYZ.

Edit: I'm only passing in a float if I've already done the calculations. If I've already done the calculations, then there's no reason to evaluate it...
 
The NS blocks spells/items less after each of your first four losses to her.

Edit: Woo, another page I missed! Heh.
 
Last edited:
What I'm saying is you just passed in the float 67.0 to modifier_eval because the other functions resolved before modifier_eval does, which was converted to the string "67.0" by the ash parser for you, which then returned the float 67.0. You wanted to pass in the string "min(my_basestat($stat[moxie]) + monster_level_adjustment(), 200)" which would cause syntax errors.

You can get ascension count from pref(knownAscensions). As for stats maybe add another function stat(text)? The single upper-case letter syntax is pretty limiting.
 
Last edited:
Ah... so bascially, the part where it actually worked, didn't, and we're going to need either our own function to do the conversions before handing it over to modifiers for the min/max bits (since that's the only part especially useful for us) or to add the proper letters into modifiers... currently thinking of making it N for Nuscles. -_-
 
Theraze said:
Anyways, the question's still there... do we want our monster data lines that long, do we start mangling Modifiers.expression, or do we make our own version of it at the expense of another 20-40k of mostly duplicated work?
Click to expand...
Or do we do something else. For example, extract the bulk of the expression evaluator into a new class, subclass it for Modifiers, with modifier-specific features, and subclass it for Monsters, with monster-specific features. With that, we don't care whether M means "moons" in modifiers and "muscle" in monsters. (Although, considering that muscle, mysticality, and moxie all begin with M, it's not obvious that M SHOULD mean Muscle as opposed to any of the others...)

"Make our own version" with "mostly duplicated work" is almost never the right solution.
 
Yes exactly. I'm curious if it would be complicated to make the eval accept words instead of upper-case letters, I get the feeling it was only doing that because of legacy reasons when there were only a few parameters that would need to be resolved.

Additionally I completely agree with Veracity, if you ever find yourself copy and pasting code you should probably be considering a better way to go about whatever you're doing.

As long as we're doing subclasses it might be worth making one that could handle in some form or another what Zarqon is doing with his combat damage maps, I feel like those should be included in the core mafia instead of maintained separately, but that would involve a whole slew of new functions and is a separate issue.

I should really just muck around with the source instead of talking about it, maybe after I get back from my company christmas party and recover from the awful vegas bender-induced hangover that is gonna go come along with it.
 
Last edited:
I'm open to suggestions on how to try to make this work, in a way that the developers will actually like the final result... the problem is that they (you) are busy people, and I'm the sort of person who wants to make things work. I get a goal in mind, I'll try to figure it out, if it's possible in any way. Problem with that is that if not given direction on what to avoid, I'll make use of any possible direction in how to make things work, which often goes in somewhat bizarre (but working) ways. :)

Anyways, with A for ascensions, C for constitution, I for intelligence, N for nuscles, and P for persnickityness, I can do the following:
Code: 
[COLOR=#808000]> ash (modifier_eval("min(C+min(A*3,12),200)"))

[/COLOR]Returned: 86.0

[COLOR=olive]> ash (modifier_eval("min(N+min(A*3,12),200)"))[/COLOR]

Returned: 98.0

Don't have any sort of high stats yet on this character, as ascension was a day or two back. Anyways, once we figure out how we want to do this, I think we should be fine for parsing through modifiers...

Whether we want to split off the matching subsystem or integrate, either way we can move forwards and it should be able to handle it with minimal affect to current data...
 
If we go with letters, maybe... checking into the possibility of allowing basestat/buffstat as a leadin meaning you're giving it a stat.
 
Theraze said:
I'm open to suggestions on how to try to make this work, in a way that the developers will actually like the final result.
Click to expand...
I told you what I would like. I want a general evaluator which is subclassed or specialized for modifies and monsters.
 
Okay... so this project starts by tearing the modifier evaluator apart and making the evaluation part its own function that can then be used in other contexts, before I can move back into making new things work. Got it. :)
 
Well, I tore the evaluator out of Modifiers and put it into its own Evaluator file. Then, I added types to it... currently EVAL_NONE for nothing special, EVAL_MODIFIER for classic functionality, and EVAL_MONSTER for new monster evaluator. Next, I made it compile properly. Next, I just need to make the letters unique between 'types' of eval... Don't think we need any of the uppercase letters to evaluate on the 'none'.

Okay, EVAL_NONE returns 0 for all uppercase letters, EVAL_MODIFIER uses classic letters, EVAL_MONSTER uses OUY for stats as suggested above, along with A for ascensions and L for monster level adjustment.
 
Last edited:
Using single letters is a bit nasty for mus/mys/mox as there will never be a good mnemonic scheme.

I haven't looked at the code in depth, but can you add some code to Expression.value() something like:
Code: 
if ( this.optional( "mus" ) )
{
        this.stack[ this.sp++ ] = <player.buffedMuscle()>
        this.text = this.text.substring( 3 );
        return String.valueOf( (char)( '0' + this.sp - 1 ) );
}

This would be more flexible than using single letters for everything, though using A for ascensions seems straightforward enough.
 
The point is that these are only used in the monsters.txt data file... What the letters actually are don't matter so much as having them read properly and work in a non-hate manner. Yes, we could make muscle and the other stats have override words, but Veracity shot down the easy answer and now I'm almost done with mangling it together for new joys.

Sidenote: I severely heart (and yes, I'm using braindead language with a purpose) unexpand. Taking a file from 31415 bytes to 16029 bytes in about 30 seconds including spinning up Cygwin and testing how to use the command was so much better than spending 3 hours manually trying to take them all out.
 
Okay, here's a patch. Creates a new file named Evaluator that includes evaluating by type. Haven't included any monster file with it yet, because it'll take approval from Veracity or Jason before any further progress can happen. If I'm wandering in the wrong direction, I should correct now, not after I've demolished my files even more...
 

Attachments

You must log in or register to reply here.
Back
Top