What are you worth? networth.ash will tell you.

Just noticed this in the script:

ivals[$item[vinyl boots]] = 44000;

The price of vinyl boots is hardcoded at 44,000. Because ... um. I don't know. Why, exactly?
 
1 Zinc Delta of Tranquility = 999,999,998.
> ash historical_price($item[zinc delta])

Returned: 0

> ash mall_price($item[zinc delta])

Returned: 0
Yeah... not sure what's going on there. Definitely weird though. I'll take a look.

Edit: Got it... I'd screwed things up horribly when I changed the sort order. If you look carefully above, you might notice that everything is sorted alphabetically. :D Re-included .thing and now it sorts properly. :)
Another issue... the script uses available_amount, which isn't necessarily everything you CAN access, just everything you've told it that you want it to use. The attached versions (networth and networthi) both use explicit inventory checks. Validated that my closet wasn't being counted before and is now.
One more tweak... put the main script-bit into a void main() so you can actually pull out the get_price check. Shouldn't look any different when you're running it, just means if you import the script for get_price uses, you can actually see the information you want.

Edit2: Since speed-wise it's basically a wash, and because it makes Veracity happier, networth/networthi is merged back to a single networth which uses ints. :)
Also, removed the vinyl override.

I'm torn on considering npc_price as a valid alternative to mall_price. If you can buy unlimited amounts from NPCs, it doesn't really matter to much how much people are trolling for in the mall, your item's value is whatever you can replicate it at. Or you have a REALLY easy way to increase your money, either way. Anyways, the thing that makes me leery about including it is daily_specials and other immediately-used items. If the item never makes it to your inventory... *shrugs* Anyways, had put in a npc_price check, removed it again before finishing saving the message. Thoughts?
 
Last edited:
because it makes Veracity happier, networth/networthi is merged back to a single networth which uses ints. :)
Well, whatever, but the reason to use ints rather than floats when you are dealing exclusively with integers and doing nothing but addition and multiplication is because that is "good coding" as opposed to "bad coding".

And, seriously - have you ever looked at zlib's rnum(int) vs. rnum(float)? I really can't say I like either of them, particularly, from either a readability or an efficiency viewpoint, but considering that the latter calls the former and does a bunch of additional cruft, it's hard to understand why you think floats vs. ints is "a wash".

FWIW, I include the equivalent of rnum( int ) that I included in my mmg-utilities.ash:

Code:
buffer pnum( buffer b, int n )
{
	buffer pnum_helper( buffer b, int n, int level )
	{
		if ( n >= 10 )
		{
			pnum_helper( b, n / 10, level + 1 );
		}
		b.append( to_string( n % 10 ) );
		if ( level > 0 && level % 3 == 0 )
		{
			b.append( "," );
		}
		return b;
	}

	if ( n < 0 )
	{
		b.append( "-" );
		n = -n;
	}
	return pnum_helper( b, n, 0 );
}

string pnum( int n )
{
	buffer b;
	return pnum( b, n ).to_string();
}
 
I used my tracktime alias to check how many milliseconds it took...
tracktime ashq int currenttime = gametime_to_int(); try{cli_execute("%%");}finally{ int posttime = gametime_to_int(); print_html("Time: " + (posttime - currenttime));}
Using that, it said it averaged the same period of time to run with floats v. ints, though ints had more variance... both faster and slower. You're right though (as you know :)), since we're just dealing with positive integers and don't have any decimals, and we shouldn't have anything bigger than a long int, it is better coding practice to stay there. When I changed, I initially briefly forgot that change had been made, and as such (and for people still using the 'stable build' or stuff even older) was thinking that floats would actually allow for full-number accuracy.

Guess we can try to have Donavin change from floats back to ints in Omnivore for the next version, since he'd updated that before mafia changed...
 
I think you may find that the profile command is far more useful.

Edit: So thanks to profile I can tell you that your slowest operation (aside from price checking) is this one:

visit_url("storage.php?which=5")

Maybe you could freq a native my_storage_meat() ASH command that doesn't require a server hit each time?
 
Last edited:
Yes/no. Depends on both luck and how it actually executes. Much more useful is
tracktime ashq for x from 1 to 10 CLI_EXECUTE(\"call networth.ash\");
<lots of text>
Time: 3158
tracktime ashq for x from 1 to 10 CLI_EXECUTE(\"call networthf.ash\");
<lots of text>
Time: 3418
First result tossed, due to more thinking going on and lookups and the like. Interestingly, as before, floats gave a much more 'standard' result, with all 5 executions staying within 100 of 3400. The 5 executions of the int version varied from 2900-4000. Weird.

But as I said, multiple executions provide different results. Run profile networth 3 times and...
10 .000001973 0.000001973 my_meat()
10 .000003552 0.000003552 my_meat()
10 .000001579 0.000001579 my_meat()
3 different timings for the same function, which gets called in both scripts, but can make things appear less accurate. That's why I prefer larger, fully-timed comparisons. :) When possible. My original plan was to run it a thousand times, but I didn't feel like bloating my session log that much, but... fine. Let's do it. A thousand executions of each... :)

tracktime ashq for x from 1 to 1000 CLI_EXECUTE(\"call networth.ash\");
<way more text>
Time: 253869
tracktime ashq for x from 1 to 1000 CLI_EXECUTE(\"call networthf.ash\");
<way more text>
Time: 289467
So yeah... ints faster, taking on average 253.869ms per execution compared to 289.467ms for floats. On my system, at least. :)

Sidenote: changed from print to print_html, since personally, I don't log html entries. :)
 
Changing floats to integers is still not going to save you as much time as figuring out a way to remove that visit_url() :)
 
have you ever looked at zlib's rnum(int) vs. rnum(float)? I really can't say I like either of them, particularly, from either a readability or an efficiency viewpoint, but considering that the latter calls the former and does a bunch of additional cruft, it's hard to understand why you think floats vs. ints is "a wash".

Yes, rnum(float) is definitely more expensive than rnum(int). The present form of rnum(int) is:

PHP:
string rnum(int n) {
   return to_string(n,"%,d");
}

I'd say it's hard to get more readable or efficient than that. On the other hand, rnum(float) does have some additional "cruft":

PHP:
string rnum(float n, int place) {
   if (place < 1 || to_float(round(n)) == to_float(to_string(n,"%,."+place+"f"))) return rnum(round(n));
   return replace_all(create_matcher("0+$", to_string(n,"%,."+place+"f")),"");
}

Not particularly readable, but since I'm the only person maintaining my script that's not a high priority for me. As far as efficiency goes, if Veracity (or anyone) has suggestions for improving the efficiency of this function while retaining the functionality I'd be very happy to hear them.
 
As far as efficiency goes, if Veracity (or anyone) has suggestions for improving the efficiency of this function while retaining the functionality I'd be very happy to hear them.

Hi zarqon. I made some unpublished improvements to the trim_zeros function in ROFL, your rnum function could be less "crufty" if you did something like this:

PHP:
string trim_zeros(string myString) {
  if(myString.index_of(".") == -1) {
    return myString;
  }
  return replace_first(create_matcher("\\.?0*$", myString), "");
}

string rnum(float n, int place) {
  return n.to_string("%,."+place+"f").trim_zeros();
}

It is also slightly more efficient for you to pass the place parameter as a string instead of an int (the int is being cast as a string in the context of the function anyway).

Edit: After looking at things a bit more, really your "cruftiest" part is this:
PHP:
to_float(round(n)) == to_float(to_string(n,"%,."+place+"f"))
If there's more than 1 place you're doing so much stuff just to figure out if you need to trim the zeros or not, it's cheaper for you to just try to trim the zeros anyway (even if there's none there).

I mulled it over and boiled things down to this function. It balances performance between people who want 0 places and those who want more. It also keeps everything in the one ASH function (so it's more efficient but has less reused code).

PHP:
string rnum(float n, int place) {
  if (place < 1) return n.round().to_string("%,d");
  return replace_first(create_matcher("\\.?0*$", n.to_string("%,."+place+"f")), "");
}
 
Last edited:
1 Cheshire Bitten = 999,999,998
1 hippopotamus skirt = 999,999,998
1 flaming juggler's balls = 999,999,998

... Umm... no.

My knowledge of scripting sucks so I can't help out by saying what's gone wrong, but there's no way those are right. Bug or feature?

Still correcting that manually... it's good to know I'm worth 962,501,896.
 
Last edited:
1 Cheshire Bitten = 999,999,998
1 hippopotamus skirt = 999,999,998
1 flaming juggler's balls = 999,999,998

... Umm... no.

My knowledge of scripting sucks so I can't help out by saying what's gone wrong, but there's no way those are right. Bug or feature?

Still correcting that manually... it's good to know I'm worth 962,501,896.

It has been mentioned many times before in this thread, but I can't be bothered linking. The script is acting on the information according to the 5th cheapest mall item, sometimes that happens to be max priced.
 
Yeah, networth just shows what mall_price knows. If you don't like the price, put 5 of them into your shop at the right price. Whatever you want the price to be. :)
 
A couple quick bugfixes

I've made a couple fixes to this so that I can use it.

1. If you're out of ronin, it double-counted everything in hagnk's. I fixed this with an if statement. (I know I don't have 2 boris's helms.)
2. If you have no meat in Hagnk's, it crashes with an index out of bounds trying to find out how much meat you have in hagnk's. Fixed this with another if statement.

I've attached my fixed version.

Things that are still sorta bugs: It doesn't count Loathing Legion foldables other than the (tradable) knife. Could special case that, but can't be bothered right now.
Also, 7 days of historical data is a bit much -- I suggest changing it to 1 (but didn't in my attached version). That makes a million meat difference in the price of my misfit teddy bear.
A feature I'd like: Something to count the cost of buying all the familiars you have, if you didn't have them yet. That'd put me over 200M net worth, easily (I'm at 130M but have a mimic)

PS.
Liquid meat (eww): 6,798,549 (would have been more but I just bought some bear arms)
Total: 111,235,717 -- Not bad considering how many times I've quit playing! Oh, and I've a bunch of junk in my display case...

Total: 131,406,221 -- WOO! Except that's too much for the misfit teddy bear.
Setting the cut-off for historical price data to 1 instead of 7...

Total: 130,508,621. I'll take it. Also, the display case wasn't slow at all for me -- I think that's only an issue for people without display cases.
 

Attachments

Here is the version I currently use. It grabs prices from the pricegun data file, so it runs very fast.

The bug with available_amount() double counting closet and storage amounts depending on the various autoSatisfy preferences had already been fixed in the latest versions in this thread.

I also added something to account for foldables : the price of the cheapest tradeable form is used.

EDIT: I switched some logic around and fixed accounting for prices of foldables.
 

Attachments

Last edited:
1. If you're out of ronin, it double-counted everything in hagnk's. I fixed this with an if statement. (I know I don't have 2 boris's helms.)
Fixed in the version attached to 183.
A feature I'd like: Something to count the cost of buying all the familiars you have, if you didn't have them yet. That'd put me over 200M net worth, easily (I'm at 130M but have a mimic)
Already included in the version attached to 183.

Edit: Noticed that I'd accidentally thrown 2 mall_price into the familiar check though we'd already done and saved get_price on it. Bah! Fixed version attached... 1 less server-hit if you're using historical data for a familiar. Suppose I'll throw in the version of slyz's rather-more-awesome networth_pricegun with familiar price-checking as well.

You'll probably like the results of regular-networth more for boasting, since with me at least, it puts me 4 billion richer. Glass gnoll eyes? Not a lot in the market. :)
The pricegun version is more accurate though. :)
 
Last edited:
Fixed in the version attached to 183.Already included in the version attached to 183.

Whoops, I hadn't realized there were updated versions. Maybe someone should make a new thread, because I just used the version from the first post and I'm sure I'm not the only one.

Can't wait to try this once I'm out of zombiecore and have access to all of my familiars.
 
A feature I'd like: Something to count the cost of buying all the familiars you have, if you didn't have them yet.
I know it's a feature of the original pricegun, but it never made any sense to me. In any case, if you want to track your familiar "worth", you might want to do the same for skills.
 
I know it's a feature of the original pricegun, but it never made any sense to me. In any case, if you want to track your familiar "worth", you might want to do the same for skills.

I comment that section out too, actually I freaked out today when I tried the new version and it said I had "1 x suspicious stocking", I thought all my Crimbo's had come at once.

It should probably say "1 x stocking mimic" but, I commented it out, so it doesn't matter.
 
Just found a bug with networth_pricegun.ash -- it doesn't count liquid meat stored in Hagnk's.

I think this is because storage.php now defaults to the miscellaneous section (or at least it did for me); changing it to "storage.php?which=5" gets it to Hagnk's page, with the meat listed.
That still isn't enough, though, because "have " appears in a comment prior to the meat amount. Changing that string to "You have " makes it work.

In short, I changed
storage_meat = excise(visit_url("storage.php"),"have "," meat").to_int();
to
storage_meat = excise(visit_url("storage.php?which=5"),"You have "," meat").to_int();
and that fixed it. I haven't uploaded the file since I know a lot of people comment out the familiar stuff and I haven't done that.
 
Back
Top