UO Second Age

I wouldn't mind seeing this created, either. Even if it is approximated, it would make the shard more era accurate...

Just giving this a friendly little bump, to see if anyone has any new info perhaps

Just giving this a friendly little bump, to see if anyone has any new info perhaps

I've started working on this recently, extracting the code from the demo. I've located the code that calculates the pricing for weapons, so it's a start. If in a year I haven't finished this though, bump again

Bumpin again.

i dont play anymore, but i had an inclination to come back and check the forums. yearly bump required.

Bump, because I had a dream about uo recently.

Welp. See ya Next year.

Unfortunately, as you might imagine, this isn't something that we can properly implement right now.

Batlin, who is the main person that we relied on for deeper insights into the demo, hasn't worked on anything relating to UO in quite some time, and the VDP code is buried in the demo core itself, which requires extremely good technical knowledge to extract (e.g. Ability to use a disassembler). As a result, we have no way of knowing how this particular value is calculated, and by extension, we can't really implement something to replicate it because we don't know what factors in to the calculation of this kind of value.

To make matters worse, it really isn't advisable to simply simulate the maximum values as they are represented in the VDP guides posted earlier in the thread. What little we can tell from outside the demo core about an item's value comes from the getValue function call which shows that the values on the demo are very different than those reported in the linked threads, meaning that we need to understand at least some type of base calculation before we can begin to extrapolate what the total value of an item is. Unfortunately, max values don't really tell us all that much in that regard, and since we don't have a base equation to start from, we can't play around with that equation to see how it may have been changed to give us the numbers reported in the many links provided. So, if we do attempt something, it would be a literal shot in the dark.

Finally, let me provide some updated links as a sort of aggregate of the many links provided early on in this thread. The posting structure of stratics has changed since it was sold off, and I had to hunt down the links themselves, but all of the information is still there. I also have updated links to the archived pages using their new archive url, just in case the old ones go dead:

http://stratics.com/threads/why-item-id ... ost-106908
http://stratics.com/threads/why-item-id ... ost-107766
http://wayback.archive.org/web/20010117 ... lity.shtml
http://wayback.archive.org/web/20010414 ... eapons.htm
http://wayback.archive.org/web/20001011 ... weapon.htm
http://stratics.com/threads/why-item-id ... ost-111434

I'm writing this up because UOSA was the main reason I spent time looking into this, and all this info was researched from the demo which wouldn't have been possible without Derrick, Kaivan, Batlin and others who worked to make the UO98 project a reality. I'd have posted it over at JoinUO.net/UO98, but those forums have long since gone down. This has also been a long running topic on the UOSA forums, so who better to share this info with? I spent lots of time working on the demo the last few days and added numerous modifications in the GM cheat script to adjust various item properties, in an attempt to crack the formula for item values.

Warning: incoming WALL OF TEXT!

To start with I wrote scripts that could do the following in the demo:

• Adjust the damage of a weapon
• Adjust the max and current hit points of weapons.
• Create items that are techically made from "nothing" (they have no metal/resource in them).
• Generate mass resources/gold for further testing.
• Report the current value of the item by use of the core function "getValue" - which is the one used by ItemID.
• Report on other properties of the item, such as damage, armor value, current/max hit points, speed, etc.

The first part of the research involved testing how durability affected the value of the item. The demo will allow you to have a weapon of a durability between 0-255. By testing several items at both ends of the spectrum, it became obvious that the value is linearly affected by CURRENT durability, and is not affected at all by MAX durability. The formula for working out how much an item is worth by durability is CurrentDurability/6.0.

First part of the formula:
value = (Unknown) + CurrentDurability/6.0;

The second part of the research was on how "metal" - or resource - affects the value of an item. I created scripts to create weapons that did not contain any metal - there is a function to do this in the core called "createNoResObject". I added a GM cheat script to do this, and then a GM cheat script which added 1 metal at a time to the object. The value for metal would never increase for the first "piece of metal" that was added to the object, but then would increase by 2 every time after that. I then cross checked these values by creating weapons via blacksmithy and purchasing them from blacksmith vendors, and the values checked out vs the required amount of resources to smith the item.

Second part of the formula:
value = (Unknown) + (ReqdIngots-1)*2 + CurrentDurability/6.0;

The third part of the formula was very hard to crack, but when the final answer was revealed, seemed much more obvious. I suspected this had something to do with weapon DPS (and could confirm that changing the DPS affected the value), but nothing I could come up with lined up with the expected values. I tried all sorts of things. Eventually I used a brute force method by taking 2 objects that had the same initial value, applying exactly the same weapon template to them (speed and damage), and then checking the value of the item. Sure enough, they lined up to have exactly the same reported Item Identification value. From here, I first tried setting the damage of the weapon to 0, and it indeed made the damage part of the formula worth 0 gold. I tried the same with speed and got 0 gold again. Then I set the damage of the weapon to a set amount and set the template values for the weapon to 10 speed, 20 speed, 30 speed, etc. I did this all the way up to 200 speed. Once this was complete, I started again, but doubled the damage. Shockingly, damage played no part in the value of the item. The only exception to this was when the item had 0 damage. Instead speed was the only factor in the value of the weapon. Again, this proved to be a linear formula.

Third part of the formula:
value = (Unknown) + (Speed*0.125) + (ReqdIngots-1)*2 + CurrentDurability/6.0;

Using this formula got the values close, but offset by seemingly random values. They were generally off by 5-15 gold still. So I mapped these differences into an excel spreadsheet to try and find if there was any common pattern. I had already worked out that none of the following made any difference: damage, weapon class (eg slashing, bashing), weight, handedness (1h or 2h). Finally I turned to UO Fiddler to see if there was anything in the client files that might hold a clue. The final piece of the puzzle was there: the absolute base value of an object in UO is determined by the item flag called "Stacking/Offset Value". By adding 2 to this value, it always lined up perfectly.

Working Formula
value = 2 + [Stacking/Offset Value] + (Speed*0.125) + (ReqdIngots-1)*2 + CurrentDurability/6.0;

Using this formula will produce perfect results for every single weapon type I tried vs the demo, and match extremely close with the tables that Kaivan has linked to (eg: 51 max value for a katana that has 108 hit points - 2 + 10 + 55*0.125 + 7*2 + 1.2*90/6 = 50.875 gold, rounded up to 51. I do find it odd that this value is rounded up, rather than cast to an integer, but the formula does indeed work against every weapon type in the demo.

Note that although these values do not match perfectly with what is listed here: http://wayback.archive.org/web/20010414 ... eapons.htm The values are always within +-3gp. And though the formula is so slightly off against the weapons in this link, the formula matches 100% with the weapons that are found in the demo. Remember that the link above was roughly 3 years after the demo, and it is possible that speed/hit point/ingot costs may have been slightly changed during that time for some weapons. For instance, the bardiche and executioners axe both have different speed values in the demo vs stratics, and the damage levels are ALL massively different.

Footnotes:
There is no "bonus" in an item's value for being GM crafted. The only value bonus that comes from a GM crafted weapon is a 20% durability bonus, boosting the max durability of say, a katana, from 90-108.

(ReqdIngots-1) is not actually correct in that part of the formula. I later worked out that the formula actually looks like this:
value = [Stacking/Offset Value] + (Speed*0.125) + Math.Max( 2, ReqdIngots*2 ) + CurrentDurability/6.0;
This means that the "resource value" of an object is ALWAYS at least 2, even if no resources exist in the object. This means that itemids found in the client that have no value, and no value in game, are always worth 2gp when identified with the ItemID skill. If you run around the demo using itemID on random things, they're mostly all worth 2gp. I found this out while working out the values of tailored objects, where cloth is only worth 1gp per resource and not 2.

When applying to armor/clothing, replace the part of the formula which says: (Speed*0.125) with ((int)ScaledArmor*4.5). ScaledArmor meaning armor after it has been scaled by quality, but NOT scaled by durability. It must be casted to int before being multipled by 4.5, or the values are slightly off on exceptional armor. The most likely reason it needs to be casted to an int, is because the demo stores ScaledArmor rather than calculating it on the fly like RunUO does. This can also be observed in the fact that GM quality (and vanq) weapons have their dice offset adjusted in the demo on creation, rather than adding 4 at damage calculation time. This may also explain why OSI routinely bungled up their weapon values and patch notes commonly state that "prepatch weapons will be bugged", since things like an "exceptional" property did not truly exist.

When dealing with items that are made from cloth, change ReqdIngots*2 to ReqdCloth*1. The cloth resource is only worth 1gp per. It should be noted that cloth items NEVER gain armor from being exceptional in the demo - in fact exceptionally made cloth items can not be made at all.

BaseJewels on the other hand, appear to always be slotted with a resource that is equal in value to 20, giving every type of basejewel an ItemID of 21. The only thing that can affect the value of a BaseJewel is having charges on it. It was confirmed that BaseJewels are indeed "slotted" with some kind of resource worth 20, because when a BaseJewel with no resource is created, it is worth 3 (stacking/offset value of 1).

I have not yet tried this for items created with carpentry or tinkering, but there is probably nothing different about the formula. In fact, items do not appear to be "typed" in the demo at all, and instead all items have properties such as "damage", "hit points" and "durability", even if the item does not use those properties. They are usually set to 0 or -1 in those cases. So an all-purpose formula for item value in UO would be:

value = [Stacking/Offset Value] + (Speed*0.125) + ((int)ScaledArmor * 4.5) + Math.Max(2, ReqdResource*ResourceCost) + CurrentDurability/6.0;

Taking care to make sure none of those variables are ever less than 0.

And there you have it. Items in UO are never defined by a hardcoded value, other than what is found in the item data in the client files. They instead linearly scale with properties of the item, and every item in UO has a property called "resource" which contains a list of the resources that were used to create the item (this is done by the function transferResource in the core). The items that sit in an NPC blacksmith's inventory, interestingly, are real items and have already had their durability level generated. As such, you'll find that different NPC blacksmiths in the demo sell a katana for varying amounts, and also, items in an NPC shopkeeper's sell window can be identified, arms lored, etc (but not stolen).

Another note on the demo while doing this:
The blacksmithing skill is extremely bugged. When an item is created, the demo checks for whether the crafted item should be exceptional. The demo does not apply any flag to an exceptional item, but instead increases its durability by 20%, and then *tries* to apply an increased dice offset to the newly created weapon. It's interesting to note that the demo does not give a flat +4 dice offset to every exceptional weapon, but instead, the demo calculates the additional offset based on the existing damage of the weapon. For an exceptional halberd, 4 is added to the offset (sound familiar?), but for a katana, only 1 is added to the offset (partially since the demo katana is only 1d16). The major bug is that the new offset is not applied to the newly created weapon, but is instead applied to the smith hammer that was used to create it. This means that if you make 10 GM halberds with a smith hammer, the smith hammer will go from being 4d6+0 to 4d6+40. If you make 20, the smith hammer will be 4d6+80. This means you can create godly smith hammers in the demo and one shot other players/creatures with them.

This would obviously have been fixed, but the interesting part of that to me was the difference between a halberd and a katana's offset. It seems like katanas should not be given +4 damage on an exceptional craft, but rather only 1 additional damage. This would, however, be a major blow to crafting, as any katana that is might or above would now be better than a crafted one.

Very nice!

How does your own extrapolated formula for VDP compare with the skill-Item-Identification function(s): how much cross-over is (not) there? Otherwise, regarding Item_ID (functions), did you ever/were you able to quantify any randomizer(s); can we, lowly, users default to using GM Item-ID as a "poor man's VDP"?

When you shoehorned-in "add 2 to Stacking/Offset value", are you indeed suggesting that the OSI code included this precise modification/base value; or is there still the possibility of a 'dangling', unidentified variable? Of course, "I don't know" is a valid answer: your speculations I would value, though.

Reported VDP values might not match perfectly with your formula for a variety of reasons: some reports may be unreliable, through human error/dishonesty, or simply because a "perfect full-durability VDP value" had never been isolated and (faithfully) reported; as this sort od thing would necessarily vary on a case-by-case basis, there is no way that the precision of the reported-VDP-list can be evaluated; taken as a composite, however, it provides a useful pointer, which seems to commute with your work. I am satisfied that the correlations are strong enough to be considered useful.

Thanks for remarking on (some) of the demo code, particularly that "the demo is not God": I know that Derrick, Batlin, Kaivan & Co. know that even demo-code needs to be scrutinized in terms of provenance, but I imagine that a lot of others might not appreciate the niceties of such distinctions.

Cripes, but I was glad to see this! Again, very nice! Ten-million-tons of thanks for doing ten-million-tons of work!

SS

How does your own extrapolated formula for VDP compare with the skill-Item-Identification function(s): how much cross-over is (not) there? Otherwise, regarding Item_ID (functions), did you ever/were you able to quantify any randomizer(s); can we, lowly, users default to using GM Item-ID as a "poor man's VDP"?

On the demo, Item ID gives a 100% accurate value of VDP. They use the same core function to get the value, "getValue". But if you mean on UOSA - this formula has not been implemented so ItemID on UOSA is probably meaningless for VDP.

When you shoehorned-in "add 2 to Stacking/Offset value", are you indeed suggesting that the OSI code included this precise modification/base value; or is there still the possibility of a 'dangling', unidentified variable? Of course, "I don't know" is a valid answer: your speculations I would value, though.

This is answered later in the post. 2 is the "minimum resource value" of an item, when the item has resource that costs less than 2 (or no resource at all). I figured this out because cloth as a resource is only worth 1gp, so the formula had to be adjusted.

The final formula is:
value = [Stacking/Offset Value] + Speed*0.125 + Math.Max( 2, ReqdIngots*2 ) + CurrentDurability/6.0;

Reported VDP values might not match perfectly with your formula for a variety of reasons: some reports may be unreliable, through human error/dishonesty, or simply because a "perfect full-durability VDP value" had never been isolated and (faithfully) reported; as this sort od thing would necessarily vary on a case-by-case basis, there is no way that the precision of the reported-VDP-list can be evaluated; taken as a composite, however, it provides a useful pointer, which seems to commute with your work. I am satisfied that the correlations are strong enough to be considered useful.

Agreed. The fact that this formula works perfectly against all the items I checked in the demo, I believe this is either the exact formula, or may only be incorrect by 1gp in some cases where rounding matters. I did not find any cases where it was off by even 1gp, though.

Nice, nice, nice.

Sorry about the Stacking/Offset question: (obviously) I missed the connection (but I am glad that you pointed that out!).

Re: UOSA's implementation of the Item-ID skill, you seem to be re-iterating my question, but (I guess) pointing-out that any 'randomizer' is not part of "getValue", whether or not it is any (significant) part of UOSA's implementation of Item-ID ... No spoilers; eh? Drat.

Thanks again.

SS

Re: UOSA's implementation of the Item-ID skill, you seem to be re-iterating my question, but (I guess) pointing-out that any 'randomizer' is not part of "getValue", whether or not it is any (significant) part of UOSA's implementation of Item-ID ... No spoilers; eh? Drat.

There is no randomization of value in the demo. At GM itemid, any 2 items with the same properties will always return the same value. Is that what you mean?

It's only before GM itemid that the value can be incorrectly reported, and that is not done within the getValue function.

Yes, we are saying the same thing, and I am sure that I am the only person who is confused.

When you mentioned Item ID in the context of demo v. UOSA, I misinterpreted what you were saying: I thought you meant that demo-Item ID would return true values at all levels of skill-development, or something (some whatever that was distinctly different from what is live at UOSA) ...

So, still a little confused, what is it that UOSA has not implemented? I'm also thinking about the research that was done to confirm blacksmithing-difficulty on certain items vis-à-vis weapon-speed ratings (iirc, specifically the katana): doesn't UOSA use "getValue" for that (or, rather, derive getValue from item-creation, which is derived, in turn, from item-behavioural-properties ...)?

SS

From what I'm aware, UOSA uses relatively hardcoded values for the values returned by item identification. The reason being the formula for item value was unknown up to this point.

As for blacksmithing, unfortunately the demo is not a good go-to for the values there, in my opinion. Craft systems in general in the demo appear to have been work in progress. The minimum value to craft are far off what they are on Stratics, and there are patch notes in 98/99 which state that some blacksmithing values have been changed. However the demo does say that the formula: avgDmg * speed is used to determine the min/max values for crafting.

I have, however, "decoded" what a lot of the variables in blacksmithing mean and plan to completely decode that script when I have more time. You can see the code here, it's WIP:

https://github.com/jackuoll/uodemo/blob ... ith.uosl.q

That repository will be updated with latest findings from the demo.