New Content - Implemented Two Crazy Random Summer

Veracity said:
Revision 19263 gets rid of the manually inserted "Clownosity" bitmap modifier and replaces it with the desc-parsed "Clowniness" numeric modifier.

The former was 1 or 2 (or 3, although that did not work), whereas the latter is 25, 50, or 75.
You can still maximize for "4 Clownosity".
You can also maximize for "Clowniness".
The green side pane still shows "Clown: 2/4", for example.

Since Clowniness shows up in the item descriptor in TCRS, clown items will now have the appropriate modifier.
(This means I have to manually add "Clowniness" to the appropriate items for all the data files submitted before I submitted this. Sigh.)
Click to expand...

Oddness in Clowniness Maximizer: Playing as Sauceror/Wallaby TCRS:
Or else maybe I don't get the Maximizer...
I tried "100 clowniness" and got +5000, etc. I tried "clowniness" and got actual values. I tried 1,000,000 clowniness and got 50,000,000 clowniness for items...

I don't see this with clownosity, and it seems to interfere with the "stop once you get to 100" part of it...

clownosity_-tie.png
clowniness.png
1000000_clowniness.png
100_clowniness.png
 
Good grief. I'm pretty sure I don't understand the maximizer. Perhaps Darzil would be willing to cast his eyes over this?
If not, I will look at it when I have enough time to dive deep into it...
 
Sounds expected. The number before it is the weighting. So 100 Clowniness means 100x Clowniness.

What you want, I think, is something like min 100 Clowniness. Not sure if right syntax, as away from PC, but check the help
 
OK, right now there's a entry in the default list of maximizer items for 4 clownosity, -tie. Should we replace or augment that with clowniness 100 max, -tie

I did check the help.
Clowniness is different from what's in the help for "Other Modifiers".
The only bitmap modifiers that currently appear useful for maximization are Clownosity and Raveosity, so they are allowed as a special case. 4 clownosity, 7 raveosity are the defaults checked for if no value is given.​

It then talks about Beeosity but not Surgeonosity.

For Clownosity, putting a number in front of the item is interpreted as the max. For Clowniness, the number is unhelpfully multiplied.
X Clownosity = Clownosity X max, equip <Item> (+1)
X Clowniness = Clowniness, equip <Item> (X x 25 per Clownosity).

So it looks like the special case from "-osity" effects isn't being used by Clowniness.

I tried to run it the other way, .01 clowniness max 4, but it looks like it has rounding errors.

When I get there in this new run, I'll look at surgeonosity. At this point in the run, it's not working. I recall it not working when I was in the hospital before, if anyone gets there first...
 
MCroft said:
OK, right now there's a entry in the default list of maximizer items for 4 clownosity, -tie. Should we replace or augment that with clowniness 100 max, -tie
Click to expand...
We could. But we don't have to; I left Clownosity in for backwards compatibility. It's no longer a real "bitmap" modifier, but is derived from the "numeric" modifer, Clowniness. It should work as before.

Clowniness is different from what's in the help for "Other Modifiers".
Click to expand...
Clowniness is not a "other" modifier. It is a "numeric" modifier. Clownosity is now a pseudo-modifier which behaves like a bitmask modifier.

The only bitmap modifiers that currently appear useful for maximization are Clownosity and Raveosity, so they are allowed as a special case. 4 clownosity, 7 raveosity are the defaults checked for if no value is given.
Click to expand...
That is still true.

It then talks about Beeosity but not Surgeonosity.
Click to expand...
Surgeonosity is a numeric modifier, like Clowniness. Therefore, you have to use things like:

surgeonosity 4 min
clowniness 100 in

So it looks like the special case from "-osity" effects isn't being used by Clowniness.
Click to expand...
Correct. Clowniness is a regular numeric modifer. It's a percent, just like Item Drop, Initiative, etc.

When I get there in this new run, I'll look at surgeonosity. At this point in the run, it's not working. I recall it not working when I was in the hospital before, if anyone gets there first...
Click to expand...
Yeah. I just got there. It was already a numeric modifier, but we weren't parsing it out of the item descriptions. That means it didn't get added to the TCRS adjusted modifiers.

I fixed it in revision 19273 and fixed the (22) already submitted class/sign data files.

This is interesting, in that if your local file exists, we will not fetch a new one from the svn repository. That was intended to allow you to have a more recent local file take precedence over one in the repositry, but it's not what we want in this case.

On the other hand, I noticed that Sauceror/Packrat seems to have been generated with a very early version of "derive" which didn't get all the modifiers, due to KoL HTML errors. I'll start a run in that, by and by, and will subnit the corrected file - but after I derive until I submit, I will not want the repository file to overwrtie my file...

So, sometimes the repository file is better (updated) and sometimes the local file is better.

Pondering.
 
Veracity said:
So, sometimes the repository file is better (updated) and sometimes the local file is better.

Pondering.
Click to expand...
The "tcrs" command already supports letting the user make this decision manually.

When you log in to a TCRS run, we'll fetch the appropriate files from the repository - unless you already have them locally. But, you can force the files to be fetched like this:

tcrs fetch Accordion Thief, Blender

This will install - perhaps replacing - the data files for that class/sign into your data file.

If you are currently in the class/sign, you can do this

tcrs reset
tcrs load

To update to the new data immediately. Or, you can log out and log back in.

If you want to try out the new Sureonosity support, fetch the updated files before you need to use that feature.
 
got it and I see how to use the tool the way it works.

I think my confusion is that I'm used to assuming the number in parenthesis is the value of the applied modifier and it's actually the weighting factor for maximization. I checked the docs and it doesn't actually describe the output.

Thanks for the explanation. It helped me understand the output better. I suspect I'm not the only one who doesn't get this, though.
 
Added in revision 19277. Thank you!
(And to everybody who is contributing to this project, as you said!)
 
Example of funkiness in Food panel of Item Manager. Sauceror/Packrat TCRS run

Sort per full by room

#1 is "Hell Ramen, size 4, 4.25 adv/full - which can't be right, since it is "good" and thus gives 3 adv/full, even ignoring adventure cost to craft it.
#2 is blue velvet cake, size 4, 4.00 adv/full - which is correct, since it is "awesome" and thus gives 4 adv/full
 
Another bug:

Middle of the Road™ brand whiskey in this TCRS run is size 4 awesome, but in the Booze panel is is listed as size 2, granting 3.25 adx/full - as well as 4.1 mus, 3.8 mys, 4.1 mox. Considering that all consumables should be "Unspaded" with unknown stat gains, something went wrong applying the TCRS data for that item.

Code: 
[color=green]> ash to_item( 9948)[/color]

Returned: Middle of the Road™ brand whiskey
name => Middle of the Road™ brand whiskey
plural => bottles of Middle of the Road™ brand whiskey
descid => 561291924
image => middlewhiskey.gif
smallimage => middlewhiskey.gif
levelreq => 1
quality => good
adventures => 4-5
muscle => 5-10
mysticality => 5-10
moxie => 5-10
fullness => 0
inebriety => 2
spleen => 0
And yet:

Code: 
[color=green]> tcrs check 9948[/color]

name = aged Middle of the Road™ brand whiskey
size = 4
quality = awesome
modifiers = ''
It does parse correctly from the item desc - and I see it in the data file.
 
Veracity said:
Example of funkiness in Food panel of Item Manager. Sauceror/Packrat TCRS run

Sort per full by room

#1 is "Hell Ramen, size 4, 4.25 adv/full - which can't be right, since it is "good" and thus gives 3 adv/full, even ignoring adventure cost to craft it.
#2 is blue velvet cake, size 4, 4.00 adv/full - which is correct, since it is "awesome" and thus gives 4 adv/full
Click to expand...

Hell Ramen is affected by Saucemaven, which adds +5 adventures if a Sauceror with it, which would account for that difference. Assuming it affects TCRS, of course.
 
Interesting! I'll try out Hell Ramen tomorrow.
The other one is a bug because I was not looking up items using their Data Name.
Revision 19278
 
You must log in or register to reply here.
Back
Top