New Content - Implemented Two Crazy Random Summer

This is close to having the modifiers, for standard items anyway : http://plasticlobster.com/summer/

So we could use to with override in modifiers maybe?

It's random seeded I think (and a Dev might have hinted :) ), so I think populating it from such a datafile would be the way. Ideally one with not just standard for those who break ronin or play after path end, of course.
 
I'm thinking this (this is ASH, but it will be Java):

Code: 
record tcrs
{
        string name;
        int size;
        string quality;
        string modifiers;
};

tvrs [int] tcrsItemMap;
CLI commands usable while you are in TCRS:

tcrs derive

for all items:
Read derscription
Add to map

tcrs save

save the map to Accordion-Thief-Vole.text, a la ASH's map_to_file

tcrs load

read the (appropriate) file into the map

tcrs apply

adjust modifiers and consumable data for every object in the map

tcrs reset

reset modifiers and consumable data to normal

Upon login:

tcrs load
tcrs apply

Upon freeing the king:

txrs reset

---------

Something like that. I have not looked at Ezandora's data yet. If she has saved all the _desc files for various class/sign, I'd be happy to have a command which is the equivalent of "txrs load + tcrs save" do create and save the map from those data.

In any case, after load/apply, I think that the maximizer, green side bar, item manager, etc. should Just Work.

I agree (I think) with lost that having 54 new data files, each with a line for every item, doesn't seem "reasonable". I am curious to see how it bloats the size of our .jar file. But, if we want to make this path pleasent to play with KoLmafia, I think we need to do this. I imagine we could ZIP them.

I'll take a look at load/save/apply later.
 
Oh. Consumables seem to have random (a range?) stat drops and fixed? adventure gain based on quality.
I frank a 10 fullness EPIC drink with Ode and got 60 adventurse - (5 + 1 ) * 10.
We would set appropriate ranges based on quality and size for consumables and the Item Manager would sort your best choices for you, as normal.
 
Revision 19233 is (most of) a proof of concept for this.

tcrs load
tcrs derive
tcrs save

are all present. You can load a map of TCRS data for your current class/sign, "derive" such a map from item descriptions, and write out the data file.

TCRS_Accordion_Thief_Vole.txt is included. It's about 600K, which would make the jar file bloat with all 54 files something north of 32M.

I don't have the "apply" or "reset" functionality in yet, but that's all known technology; we do exactly that stuff when registering new items.
And I think making .gzip (or .zip) files will be a good idea; gzip reduces it to less than a third of its size. Still bloat.
 
Revision 19225 adds the "tcrs apply" command which will update items and consumables as appropriate based on currently loaded/derived TCRS data.

Strikes me that we don't actually have to build in all the 54 data files. They could go perfectly well into a package you can load via the Script Manager, since such can put things in the "data" directory and don't actually need a script in the "scripts" folder. Files in the "data" directory will act as overrides for scripts built-in to KoLmafia's data directory. Both a loaded package and the "tcrs derive" command will put files in the local data directory where they will be found when referenced.

tcrs load
tcrs derive
tcrs save
tcrs apply

Done when you log in will work for anybody in a TCRS run.

tcrs will load a file, if present, otherwise is a no-op.
tcrs derive will look at item descriptions for items it does not already know about - which means it will be a no-op if you previously loaded them alll
tcrs save will write the data to your local directory - which will overrided built-in data, which is no big deal if we don't publish built-in data.
tcrs apply will apply TCRS adjustments to all items.

- the Green Side Pane is correct
- the Maximizer works
- The Food/Booze panels have correct sizes and my guess about adventures work given quality and size.

This is probably all the time I have for at least a week. Looking forward to an easier life in Two Crazy Random Summer. :)
 
Well, after waiting 1,5 hours for tcrs derive to check everything on Sauceror/Packrat (and saving it), it seems to be working very nicely, so thanks for that.

Edit: the maximizer works for equipment, but not for potions.
 
Last edited:
There's a few ways you can reduce file size without compression:

-Store all path data in a single file. Each item's field could be something like, Hot Resistance: +1|Cold Resistance: +1|Monster Level: +25|etc|etc|etc, using a predetermined indexing method like (moon_sign_id * 6 + class_id) or (class_id * 9 + moon_sign_id)

-Omit items that haven't changed - a significant percentage of items are identical in and outside the path.

-Refrain from storing path-specific item names? Better to just use the canonical names in mafia - this is the same situation as pantogram pants, which has a dynamic display name that nobody pays attention to.

Pie in the sky idea: use JSON to store the relevant data. I feel like CSV limits mafia's potential for its data files.
 
Ezandora said:
There's a few ways you can reduce file size without compression:

-Store all path data in a single file. Each item's field could be something like, Hot Resistance: +1|Cold Resistance: +1|Monster Level: +25|etc|etc|etc, using a predetermined indexing method like (moon_sign_id * 6 + class_id) or (class_id * 9 + moon_sign_id)
Click to expand...
This wpuld work best if all the class/sign data is available. Not yet, for me, although you may have it. :)

-Omit items that haven't changed - a significant percentage of items are identical in and outside the path.
Click to expand...
This is good

-Refrain from storing path-specific item names? Better to just use the canonical names in mafia - this is the same situation as pantogram pants, which has a dynamic display name that nobody pays attention to.
Click to expand...
I suppose, although I am finding the path-specific names useful/interesting for spading. For example:

"prompt" -> Adventures: +3
"up-at-dawn" -> Adventures: +5
"of the early riser" -> Adventures: +7
"family-friendly" -> Sleaze Resistance: +1

"spinning", "jittery", etc. are purely cosmetic.

Pie in the sky idea: use JSON to store the relevant data. I feel like CSV limits mafia's potential for its data files.
Click to expand...
I agree that JSON is better. It's not smaller - which my issue with this - but it has a lot of advantages.

I noticed that one thing I have not done yet is to change the sources for various effects and modify the "ways to get this effect" section of status effects appropriately.
So, for each item that causes an effect, add that item to the effect and remove that item from every other effect.
Maximizer will need this.

I don't have to be the one to do this. :)
 
MCroft said:
if you want 600K of data but not the other 26M, why not check it out from SVN once at the begining of the run?
Click to expand...
Veracity said:
Strikes me that we don't actually have to build in all the 54 data files. They could go perfectly well into a package you can load via the Script Manager, since such can put things in the "data" directory and don't actually need a script in the "scripts" folder. Files in the "data" directory will act as overrides for scripts built-in to KoLmafia's data directory. Both a loaded package and the "tcrs derive" command will put files in the local data directory where they will be found when referenced.
Click to expand...
Uh huh.
 
(That was not intended to be snarky.)

So, a possible solution:

- KoLmafia adds a new directory in Sourceforge under the SVN tree which is NOT included when building the JAR file
- This directory contains 54 TCRS data files
- When you start up (or ascend into) a TCRS run, KoLmafia looks in your "data" directory to see if you have an appropriate data file for your class/sign
- If not, we check if the file is available in the SVN directory.
--- Yes, we download it into "data"
--- No, we ask if you want to create the data file by reading up 10,000 item descriptions. This takes a long time.
- (Even if the file exists, we should "derive" to get new items that KoL added since we last created the file. This should be relatively fast)
- (If there is new data found via "derive", we "write" the file to update your local file in "data")
- We "apply" the data to modifiers, consumables, concoctions, effects...

Haven't looked at our SVN code. How hard can it be to lookup a file in the Sourceforge repository and to download it into a local file?
This would also work even with incomplete data. For example, I have exactly one of the 54 files to check in, at the moment.
We can add others as we (or you guys) supply them. :)

I like it. Especially if somebody who already understands our SVN support does that part of it.
 
Last edited:
Revision 10226 adds an ASH proxy field to get the TCRS name of an item.

Code: 
[color=green]> tcrs load[/color]

Read file TCRS_Accordion_Thief_Vole.txt

[color=green]> tcrs apply[/color]

[color=green]> ash $item[ El Sombrero de Lopez ].tcrs_name[/color]

Returned: red sizzling Jim Carey's El Sombrero De Lopez

[color=green]> ash string_modifier( $item[ El Sombrero de Lopez ], "Modifiers" )[/color]

Returned: Monster Level: +25, Hot Damage: +10
With this, you should be able to write an ASH script to figure out what all the new descriptors do.
For that example:

red is cosmetic
sizzling is Hot Damage: +10
Jim Carey's is Monster Level: +25

Perhaps something like this:

Code: 
for all items in $items[]
    if it.name != it.tcrs_name
        if modifers are empty
             all descriptors are cosmetic
        else save item

for all items in saved items
     strip off cosmetic descriptors
     if single modifer
         remaining descriptor grants that modifier
     else if two modifiers and single remaining descriptor
         that descriptor grants both modifiers (HP Regen Min and HP Regen Max, for example)
     else save item

repeat, stripping off all known descriptors and corresponding modifier(s) until nothing else saved.
Something like that.

Trickiness if a single item has two otherwise unseen descriptors.
Trickiness identifying what is a "descriptor".
Trickiness handling which adjectives are removed from standard item names. For example "lucky rabbit's foot" in my file is "huge Usain Bolt's rabbit's foot of Flo-Jo". "Usain Bolt's" is Initiative + 80 and "of Flo-Jo" is Initiative +100

Not a trivial program, but doable.
 
I played with this a little bit in TCRS and it seems to work very well, thank you for your work.

One small thing I noticed is that doing "tcrs apply" seems to strip familiar items with TCRS modifiers of their "equips on" string modifier, causing one to be unable to equip them, other than using the relay browser (li'l unicorn costume is an example item where this happens). There might be other string modifiers where this is relevant, but I'm not sure.

Also, the help string for the "tcrs" command has a unnecessary "list or manipulate your closet." at the end.
 
Yeah, I'll make tcrs apply skip familiar items.
I have also discovered some new forms of bogus HTML in some item descriptions, which results in not parsing correctly.

"of the cougar" is "Moxie: +20"
"gray dark baconstone ring of the cougar" has bad HTML in the description which prevents the enchantment from being picked up.
"tumbling red Xlyinia's notebook of the cougar" does not have the bad HTML.

I'm regenerating my Accordion Thief Vole file now. I'm curious to see how wide-spread the problem is.

I'll submit a fix - and the corrected file - soon. I'll look into including the familiar item and help string. Could have sworn I removed the extra text when I copied it from the "closet" command. :)
 
Revision 19229 does all of that.

- Work around the bad HTML which got incorrect modifiers from literally scores of items
- Regenerated TCRS_Accordion_Thief_Vole.txt
- Do not apply modifiers to familiar equipment
- fix usage string for tcrs command
- Add "tcrs check ###" command to do a "derive" on the specifies item #
 
By the way - I notice that the Item Manager lists the correct sizes for food and booze, but when you try queuing one, it lists the wrong size for total amount queued.
I just freed the King in TCRS so cannot test this now, but I'll ascend again tomorrow and sort this out.
 
I did some work on a TCRS desriptor parser. Here's what I get so far:

Code: 
[color=green]> TCRS.ash[/color]

Using data override: data/TCRS_Sauceror_Wallaby.txt
Read file TCRS_Sauceror_Wallaby.txt
83 adjectives are removed from standard item names
2605 items are unmodified in TCRS and 1646 are consumables and 5796 are modified non-consumables.
29 descriptors provide only a cosmetic effect
1813 non-consumable items have only cosmetic descriptors in TCRS and 3983 have additional descriptors.
2929 non-consumables have additional non-cosmetic prefixes.
203 non-consumables have only suffixes.
851 have both non-cosmetic prefixes and suffuxes.
31 descriptors modify food size or quality
28 descriptors modify booze size or quality
14 descriptors modify spleen toxin size or quality
I have not started working on figuring out which descriptors provide which modifier.
Nor have I figured out exactly how the various consumable descriptors modify size or quality.

But, I present the script as it exists so far, as well as the five data files I have calculated:

removed_adjectives.txt
cosmetic_descriptors.txt
food_descriptors.txt
booze_descriptors.txt
spleen_descriptors.txt
 

Attachments

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