Morgoth1145
Member
So, it's not giving the correct options for bejeweled cufflinks. According to The Well-Tempered Anvil (http://anvil.bewarethefgc.com/), it can be pulverized, but I don't have any pulverize option.
OCD Inventory control
- Thread starter Bale
- Start date
Morgoth1145
Member
Ah. Thanks!
AFAIK latest versions of everything.
I deleted my OCDData file and ran the script. It found uncategorized items as expected although there were things missing - the paper strips and the artifacts from the 'new' steel quest being ones that I remember. I characterized things using the relay script. I did a simulate and then an actual run and autosold some meatpaste which is all I expected to happen.
I then ran zarqon's PAtoOCD script. It found the items noted above, and perhaps others, that were not noted by the relay script. I ran the relay script to confirm/verify the categorizations. I note that a number of items were marked for pulverization although in the relay script all of the items to be pulverized showed up with an action of uncategorized and the only drop down option was Keep All.
I ran OCD_Inventory_Control in sim and real mode and listed a few things to be pulverized. However wadbot replied "You need to send items if you want me to smash something." and it was indeed true that the copy of the sent message indicated nothing had been sent.
I have had similar cases where the script was supposed to send items to kBay but failed to do so. blue flashing lights was one, but there were several others.
While there is always the chance that this is operator error I wonder if it might be due to an unexpected account setting of mine or an edge case. Is there anything I might do to provide more information that might help resolve this?
The OCD file is attached, just in case.
I deleted my OCDData file and ran the script. It found uncategorized items as expected although there were things missing - the paper strips and the artifacts from the 'new' steel quest being ones that I remember. I characterized things using the relay script. I did a simulate and then an actual run and autosold some meatpaste which is all I expected to happen.
I then ran zarqon's PAtoOCD script. It found the items noted above, and perhaps others, that were not noted by the relay script. I ran the relay script to confirm/verify the categorizations. I note that a number of items were marked for pulverization although in the relay script all of the items to be pulverized showed up with an action of uncategorized and the only drop down option was Keep All.
I ran OCD_Inventory_Control in sim and real mode and listed a few things to be pulverized. However wadbot replied "You need to send items if you want me to smash something." and it was indeed true that the copy of the sent message indicated nothing had been sent.
I have had similar cases where the script was supposed to send items to kBay but failed to do so. blue flashing lights was one, but there were several others.
While there is always the chance that this is operator error I wonder if it might be due to an unexpected account setting of mine or an edge case. Is there anything I might do to provide more information that might help resolve this?
The OCD file is attached, just in case.
Bale
Minion
Latest mafia jar has correct data for bejeweled cufflinks so that should work now.
Hmm... I've tried revamping my list and now I'm having issues.
Before, I would run the list and I would get the attached error log dumped while trying to run in sim mode. So I tried to run it in non-sim mode and it causes mafia to just sit there. And that leaves me with no way to escape out of the routine (mashing escape gives the typical message, but issuing another command results with the appending to queue message). And ever since I did that, now sim mode does the same thing. Attached is the debug log and my data file.
Running my old list after that messup, it still works, which makes me think I've borked my list. Jstacking mafia while it's running shows the only non-waiting threads as the relay browser (expected) and the awt thread looks like it's waiting for a queue item. (I never saved the jstack so I can't post, but I can repost if I recreate it tomorrow).
Before, I would run the list and I would get the attached error log dumped while trying to run in sim mode. So I tried to run it in non-sim mode and it causes mafia to just sit there. And that leaves me with no way to escape out of the routine (mashing escape gives the typical message, but issuing another command results with the appending to queue message). And ever since I did that, now sim mode does the same thing. Attached is the debug log and my data file.
Running my old list after that messup, it still works, which makes me think I've borked my list. Jstacking mafia while it's running shows the only non-waiting threads as the relay browser (expected) and the awt thread looks like it's waiting for a queue item. (I never saved the jstack so I can't post, but I can repost if I recreate it tomorrow).
Last edited:
It looks like this get_ingredients() is causing a stack overflow error. Since clover are ingredients in some of the items you wish to craft in your data file (Lucky Surprise Egg for example), my guess is that the culprit is this function:
There is a protection for dough, but there are other circular items: clovers and the charrrms. For info, this is a function in my Familiar Feeder script that does the same kind of thing. It was more or less inspired by Price Advisor:
I'll let Bale decide how he wants to implement the infinite recursion protection. Hard-coding the exceptions is simple, but figuring out a robust way to deal with it is fun 
PHP:
int count_ingredient(item source, item into) {
int total = 0;
foreach key, qty in get_ingredients(into)
if(key == source) total += qty;
else {
if(key == $item[flat dough]) return 0;
total += count_ingredient(source, key);
}
return total;
}
PHP:
boolean[item] currently_considering; // prevent infinite recursion
// return all the 'to keep' items (and associated quantities) used to craft item itm
int[item] items_to_keep_used( item itm ) {
int[item] to_keep_used;
int[item] ingreds = get_ingredients(itm);
currently_considering[itm] = true ;
foreach ingred in ingreds {
if ( currently_considering[ingred] ) continue ;
if ( keep[ingred] != 0 ) to_keep_used[ingred] += ingreds[ingred];
currently_considering[ingred] = true ;
foreach it,q in items_to_keep_used(ingred) {
if ( currently_considering[it] ) continue ;
to_keep_used[it] += q;
}
remove currently_considering[ingred] ;
}
remove currently_considering[itm] ;
return to_keep_used ;
}
Last edited:
I tested this on my mall multi. I ran OCD Manager with only this line in the data file:
It did result in a debug log because of a stack overflow, but a different one. I guess my post above won't fix all of shazbot's issues (unless the difference in debug logs is caused by the change in r9370 - I was running r9371).
Code:
cocoa egg MAKE 0 lucky surprise eggBale
Minion
Thanks slyz, you're pretty awesome. I'll implement a fix.
Now, if you could only figure out why Sputnik1 gets a use link for the spectre scepter. that seems incomprehensible to me.
Unfortunately Inventory Manager is in the middle of rewrites to implement softcore item stocking. (Damn this Valhalla revamp!) I'll have to work around that.
Fixed that infinite recursion bug for shazbot.
Now, if you could only figure out why Sputnik1 gets a use link for the spectre scepter. that seems incomprehensible to me.
Unfortunately Inventory Manager is in the middle of rewrites to implement softcore item stocking. (Damn this Valhalla revamp!) I'll have to work around that.
OCD Inventory Control Updated!
Fixed that infinite recursion bug for shazbot.
If you add a key in under_consideration before checking if under_consideration contains that key, the check won't mean much
I remember it would be a good idea to also add "into" in "under_consideration", although I can't really remember why. I can't think of any item that has itself as one of its ingredients, other than those circular ones.
And since "under_consideration" is outside of the scope of count_ingredient(), and will be used by different calls of count_ingredient(), it's a good idea to remove keys once you are done.
I remember it would be a good idea to also add "into" in "under_consideration", although I can't really remember why. I can't think of any item that has itself as one of its ingredients, other than those circular ones.
And since "under_consideration" is outside of the scope of count_ingredient(), and will be used by different calls of count_ingredient(), it's a good idea to remove keys once you are done.
PHP:
boolean[item] under_consideration; // prevent infinite recursion
int count_ingredient(item source, item into) {
int total = 0;
under_consideration[into] = true;
foreach key, qty in get_ingredients(into)
if(key == source) total += qty;
else {
if(under_consideration contains key) continue;
under_consideration[key] = true;
total += count_ingredient(source, key);
remove under_consideration[key]
}
remove under_consideration[into]
return total;
}
Last edited:
Bale
Minion
If you add a key in under_consideration before checking if under_consideration contains that key, the check won't mean much
I'm sure I couldn't have done anything that monumentally stupid. If you download the file again you'll definitely realize that I did not make such an amateurish mistake.
Bale
Minion
OCD Inventory Control Updated!
This is a new feature release! OCD Inventory now handles stocking items for softcore runs. After you inform the dB manager in the relay script what items to stock, OCD will keep those items in inventory, even if it would otherwise sell off those items. This means you can keep a stock list separate from OCD's item dispersal information and OCD will integrate the two lists for you.
This is just the first phase. I am going to be adding special TPS handling for stocking, for people who have a TPS. I'm also adding a feature to deal with expensive items in case someone wants to buy things over the item price limit.
Please tell me anything I did wrong. I'm sure there will be negative comments as this feature is still new.
I may have to upgrade and start running this again. Normally I run this daily in aftercore, but I am now on my 3rd SC run and I have not run it in 10 days or so specifically because I don't want it to sell or dispose of things I need to keep in Hagnk's.
Whoah. Does this mean this script will now buy things to stock up, rather than simply not selling them? Sweet! I definitely do need to start using this...
Bale
Minion
It ignores stuff in either Hangks or the closet. (Unless you tell it to empty your closet -- that's an option.) SO it is easy to hide stuff from OCD's eye.
This is the only time it will take a look at the closet. On the theory that stuff in your closet will go into Hangks where it is available to be pulled during softcore, I include the quantity in the closet as stuff that does not need to be stocked.
Speaking of which, I should also check storage_amount() against the amount needed to be stocked.
That'll cease to be an issue as soon as rollover happens. Though if you read the fine print you'd have seen something about what to type in the CLI to make the unfortunate error go away immediately.
Oh I was just making sure it wasn't an issue with the version system... Weirder bugs have happened.
Also Quick question about the stock feature. Lets say I have my OCD currently set to mall after 5 of an item, but since I have hundreds of items under the mall tab I missed fixing it. So missing this one item, lets say I setup stock to acquire 25 of said item. If I run OCD, will stocking said item override the mallsell feature, or will I mall my surplus before/after buying the number I desire, or would I happen to mall sell after making sure I have the requisite number of items?
Also Quick question about the stock feature. Lets say I have my OCD currently set to mall after 5 of an item, but since I have hundreds of items under the mall tab I missed fixing it. So missing this one item, lets say I setup stock to acquire 25 of said item. If I run OCD, will stocking said item override the mallsell feature, or will I mall my surplus before/after buying the number I desire, or would I happen to mall sell after making sure I have the requisite number of items?
Bale
Minion
It works exactly the way it should.
Nothing will get sold/displayed/gifted/etc that you want to have in stock. In that example it will only mall if you have more than 25. If you then remove that item from your stock list, it will then sell off 20 of them and keep 5. You don't ever have to worry about coordinating the two things since OCD knows how to coordinate it for you.
My current unreleased version has an indication on the add dialogue if an item is there for stocking so that I can ignore categorizing it. You won't even get a popup when you run OCD while having items that aren't categorized since it knows they are on your stock list.
That's why this is better than having a separate stock script in addition to OCD.
That is a parameter to ocd_control. I don't know if your script is ash or cli. If you are running a cli script you'd call my script like this:
Code:
ashq import <OCD Inventory Control.ash>; ocd_control(false);If your script is ash, then I'm sure you know how to convert that. (Remove the "ashq" and put the import part as the first line in your script with ocd_control(false); anywhere you like.)