Bug - Fixed Remove certain unnecessary functions from ASH's runtime library

zarqon said:
Because if I were a new scripter, I would find it perplexing that to_int() works for some types and not others.
Click to expand...
What's the to_int() of a string, to pick an example of a "simple" type that doesn't have such a conversion.

The rule is simple: if KoL itself assigns numbers to enumerated types and you need that number to interact with KoL, either in URLs you submit or in HTML that you parse from pages it returns, we provide functions to go back and forth between the enumerated type and an integer. Which is to say, the only scripters who NEED to understand and use those functions are those who write visit_url() calls. That probably rules out a large majority of scripters (including me), whether they are "new" or experienced.

Because those numbers exist already, and it's inefficient to add functions to a library script to construct them again. I want to make use of something that exists, not build a slower copy of it and then use that.
Click to expand...
This is the ONLY argument I've seen which sways me a little.

That script is only run in aftercore, and usually only by classes with buffs.
Click to expand...
I see. You show me a code sample which KoL just broke by introducing a new class, and when I point that out to you, you say that you will never execute in a context where the bug is visible.

Will that run faster than my "tricky" code? It's certainly longer.
Click to expand...
Is that your priority? Speed trumps maintainability? Interesting. I have the opposite priority: it is essential that the code be readable and understandable, for the benefit of people coming to look at or change my code later - including myself a year from now. If I have to study code for 5 minutes and write things down and make diagrams in order to understand what is happening, I consider the code to have failed.

I must admit, I quite like the brevity and the fact that it saves declaring a placeholder variable, but it is hackish. Perhaps to your chagrin, I've noticed Bale is using that technique increasingly frequently as well, perhaps for the same reasons I do.
Click to expand...
I am very glad that I do not need to maintain your code - or Bale's, if what you say is true.

So now we need to build maps to replace the heretofore built-in indices you're removing?
Click to expand...
I don't care how you do it. I looked at that code and I started writing down notes to try and understand what it was doing and I gave up. It was not important that I understand what calculation it was performing, so I didn't feel the motivation to come up with a clearer way to express it. But let's see. You want to take a skill, find which class it belongs to, and come up with the mainstat of that class.

Code: 
stat [class] mainstat;
mainstat[ $class[ seal clubber ] ] = $stat[ muscle ];
mainstat[ $class[ turtle tamer ] ] = $stat[ muscle ];
mainstat[ $class[ avatar of boris ] ] = $stat[ muscle ];
mainstat[ $class[ pastamancer ] ] = $stat[ mysticality ];
mainstat[ $class[ sauceror ] ] = $stat[ mysticality ];
mainstat[ $class[ disco bandit ] ] = $stat[ moxie ];
mainstat[ $class[ accordion thief ] ] = $stat[ moxie ];

skill s = $skill[ entangling noodles ];
print( mainstat[ s.class ] );
yields

> ztest

Mysticality
Click to expand...

Yeah. That looks pretty clear. And it works for the Avatar of Boris, unlike your "tricky" example. I would actually probably add a Proxy Record for the "class" type - I'm surprised we don't have one - and eliminate the map, so that I could just do

skill s = $skill[ entangling noodles ];
print( s.class.mainstat );

...but even in the absence of that, I'll take the map over the tricky-arithmetical-calculation-which-fails-for-Boris, any time.

In more comprehensible code:
PHP: 
float[stat] substatsgained;
string input = "1|0|0";
string[int] parts = split_string(input,"\\|");
foreach index,value in parts {
   substatsgained[to_stat(index+1)] = to_float(value);
}

If you have a faster way of doing this, I'm all ears.
Click to expand...
Easily done.

Code: 
stat [3] stats;
stats[0] = $stat[ muscle ];
stats[1] = $stat[ mysticality ];
stats[2] = $stat[ moxie ];

int index = 2;
print( stats[ index ] );
print( to_stat( index + 1 ) );
yields

> ztest

Moxie
Moxie
Click to expand...
Taking an array index and referencing an array is faster than adding one to the index and doing a function call with it.

Adding replacement int <--> type functions to ZLib would be a step in the "slower" direction, methinks.
Click to expand...
Whatever.

I'm quite sure if you asked any KoL player what order the stats go in, they would tell you Muscle -> Mysticality -> Moxie. That's certainly the expectation that all coders -- the people who use ASH -- would have.
Click to expand...
Of course - but you don't need those numbers to actually interact with KoL; there is no url that you submit that has "Muscle = 1" (or Muscle = 0), so we don't really know what it is internally to KoL.

I am SO tempted to make a little commit to KoLmafia which will change the order of the stats in the Green sidepane from Mus/Mys/Mox to Mys/Mus/Mox - and also to munge the charpane in the Relay Browser to match - but ONLY for userid = 1406236. :p

That is irrelevant. Status effects are numbered as they are added
Click to expand...
Obviously effects are numbered as they are added, but bullshit it is irrelevant. You showed me "tricky" code which depends on a particular order for stats. Interestingly. I showed you an example right from KoL where assuming that stat-related things always come in that order failed.

Further, if you are normal, the order of those status effects bugs you -- because the order they were added is out of order!
Click to expand...
Yes, it bugs me.

I still claim that stats have an official order -- one nicely congruous to the six original classes -- and that order should be reflected in ASH.
Click to expand...
You have yet to convince me that it "should be reflected in ASH", since you do not need that official order anywhere in order to interact with KoL.

You mean besides the charpane?
Click to expand...
I don't see anything in the HTML of the charpane that requires Muscle to be #1 (or #0). Show me somewhere where you need to know that Muscle is #1.

(you show me the pool table).

That's got the 1-2-3, but doesn't actually spell out the stats.
Click to expand...
Of course not. It is numbering choice options, not stats. The choice options refer to your "Aggressive" or "Strategic" or "Stylish" stance. Just so happens that the buff you get from choosing those correspond to stats, but you are not choosing a stat. You are choosing a stance, which gets you an effect, which helps a stat.

The shower is also in the correct order, but that's even more implicit.
Click to expand...
Uh-huh. You are selecting a "Cold Shower" (option 2), a "Lukewarm Shower" (option 3), or a "Warm Shower" (option 4) to get boosts to Muscle, Mysticality, and Moxie, respectively. Obviously, we should number Muscle/Myst/Moxie as 2/3/4!
 
The one use I could personally see using to_int(stat) in is constructing a URL for pvp with "stance="+my_primestat().to_int(). Not something I really care much about either way, but it seems easier in that case than having to make my own array.
 
Veracity said:
I would actually probably add a Proxy Record for the "class" type - I'm surprised we don't have one - and eliminate the map
Click to expand...
Done and updated with 10705.

That leaves whether we should add another version of split_string that returns a compile-time determined 'type' rather than a statically determined type. Dynamic return types aren't on my personal roadmap of things it'd be cool for ASH to have, but they do have the potential to be useful.

Fluxxdog said:
Actually there's a FReq for class proxy information along with ideas for the fields: http://kolmafia.us/showthread.php?8032
Click to expand...
I'm going to accept the part where you call it 'primestat' instead of 'mainstat', but the other fields seem sketchy at best, so I've rejected the feature request.
 
Last edited:
If you rearrange them, I'd suggest Moxie/Muscle/Mysticality to make them alphabetically arranged. :) Would satisfy my OCPD desires a little more. ;)
 
I am not REALLY going to pick on zarqon, but your suggestion does have merit. Hmm. I could do it for user id = 2087365... ;)
 
Personal code for me? How exciting! :D

Eh, whatever. It's just when we talk about rearranging them randomly, that's the only order that seems to make sense if you're ordering them arbitrarily for some reason. But following that one series of effects is just as valid as alphabetic, or the order that they appear in the charpane... if one of the actual KoL devs wanted to expose the internal stats somehow authoritatively, then it makes sense. As it stands, it seems like we're reaching the point where a lot of these seem like they're best met in personal scripts, not mafia itself.
 
With the addition of the primestat proxy field for classes, I have no examples of code where I need to use to_int(stat). Since I no longer have horses in the race, and there have been threats of harassment to my KoL experience simply for politely disagreeing, I hereby divest myself of this discussion.
 
You must log in or register to reply here.
Back
Top