too much luck a bad thing ????

[Arnie QuickPalm]

I am running 1925 and getting crap killing hiyrus and other high end spawn i find going with 1100 or so gets me better results any one else find this to be true ?

 

[Hanna]

I have found that more luck helps, but only in the "right" combinations. It's like certain number bring worse luck, for example, my mage better with 623 than 750, 1050 than 1150, but better with 1165 better with 1210 and worse with 1250. So I would just try combinations until I got some fairly reliable results. You also have to factor in range.

 

[Lord Sir Scott]

To much luck can be a bad thing, i "Once" had a really nice Luck Suit over 2k
I had colleted parts of it over the years...

When they installed that Lockdown thing in houes, i lost it with a lot of my other neat special things.

So to awnser your Question of the Title of you you Post, Yes....Some times it is.

 

[Richtor Darkbane]

I was having the same problem with a 1600+ luck suit, perhaps there is some sort of 'CAP'?

This is from stratics:

Luck effects one or more of the following:
1.The number of magic items found on a monster.
2.The number of properties on a magic item.
3.The intensity of the properties on a magic item.

Some things to consider about Luck:

*A monster will never drop more than the maximum amount of magic items his loot template allows.
*Luck is determined by the person that did the most damage to a monster.
*When most damage is done by a pet, summoned or provoked creature, the Luck factor of the controller of that creature is used.
*Luck has no effect whatsoever on treasure chests, fished up messages in bottles, town or dungeon chests, or power scrolls.
*Luck has no effect whatsoever when stealing items from monsters.
*Luck cannot make "low" level monsters give "high" level loot. You will still need to kill the toughest monsters to get the best possible loot.

It also says that at 1226.9 luck your chance to get bumped up loot is 52%, that about every other monster, but 1226.9 is the highest the chart goes. All things considered that may have been as high as they thought anyone could go back when the chart was made, or thats the cap. Either way with the Bleue jewelry set being out I expect more players to be interested in luck.

 

[wrekognize]

There’s definitely something wrong with the luck system. My girlfriend and I do levithians together. We’ve done about 40 total, she’s done 20 and I’ve don’t 20. I wear up to 1800+ luck and I’ve received 2 drops. She wears about 800 luck and has received 15 drops (including two ghostship anchors).


...

 

[Harb]

This is really a tough one. I am sure something isn't "linear," and variances/ inconsistences listed are on the money. I've played around with this one, and drops in anti-virtue dungeons, and thus far have been able to draw no consistent theory regarding either. It certainly seems that different creatures have optimal ranges where lower levels of luck yield better results that exceeding whatever the threshold is for each. Yep, for sure, something isn't "right" here.

 

[Maplestone]

Personally I think perhaps sometimes luck is involved in luck.

 

[Bomb Bloke]

Perhaps they're using an incorrect datatype somewhere in the luck calculations?

Numbers take up "space" in a computers memory. When coding, you need to give the computer some idea as to how high a value is allowed to go, so it knows how much memory to reserve for that value. If you try to stick a larger number in the space then is possible, you get what's called an overflow (exactly like what happens when you pour too much water into a cup - you lose some of it, and sometimes it even ends up pouring into places it shouldn't).

Say for example they reserve a single byte to handle luck. That means only 256 different values of luck would be possible (the maximum of which would be 255, the minimum 0), and your effective luck will be the remainder of your total luck divided by 256.

For example, if you had 1800 luck, you would be operating as if you had 8.

On the other hand, with 800 luck, you'd effectively have 32 luck.

Low values either way. But say you had 1000 luck, you would have 232 luck (getting close to the cap), while any real luck score below 256 would be exactly what it read as (if you had 255 luck... you'd have 255 luck).

All conjecture of course. If they allocated at least two bytes, then the cap wouldn't be 255, it'd be 65,535 (and since no one has a suit THAT high none of this would apply). There's no way they'd accidentally use part of a byte.

Edit:

Heh, the maths gets even kookier if they used a signed byte. Without going too far into how the binary system works, this basically means that if (after lowering your luck as described above) it was still over 127, you'd then subtract 256 from that final value.

In which case 1000 luck would end up as -24.

 

[Conrad]

I seem to recall a post YEARS ago where a Dev admitted that nobody that was part of the original coding of UO actually still worked with the team.

That being said, and the fact that numerous Devs have pointed out the sheer madness that is the "Code of UO", it wouldn't surprise me in the slightest that ONE PARTICULAR value of Luck (say, for instance, yours) is borked in some way that is impossible for them to pick up on. It could be something as odd as the fact that you eat fish steaks before you go hunting.

Change up your luck value a small amount and see if your "luck" changes.

 

[Eslake]

Perhaps they're using an incorrect datatype somewhere in the luck calculations?

Say for example they reserve a single byte to handle luck. That means only 256 different values of luck would be possible (the maximum of which would be 255, the minimum 0), and your effective luck will be the remainder of your total luck divided by 256.

That doesn't really fit the problem tough. Since luck cannot be a negative value, can be any whole number value up to - and beyond - 1024, it is either a 3byte custom numeric, or a doubleword. (unsigned)
In either case it means the range for luck is well over 200k so overflow isn't the problem.

IMO it was just poorly planned and poorly implimented.

I seem to recall a post YEARS ago where a Dev admitted that nobody that was part of the original coding of UO actually still worked with the team.

The original team didn't put luck in, the AoS team did.

The "Old code" excuse is really getting old though.

It doesn't exactly scream "competent" when the paid developers working on UO claim something is too difficult to do, when many of those things are offered on free shards run by unpaid Hobbiests.

 

[Conrad]

The original team didn't put luck in, the AoS team did.

The "Old code" excuse is really getting old though.

Yes, but the AoS team had to implement luck into the old code. My point is that none of the current developers understand all the old code, which for the most part, is still in use, and repeatedly modified by later dev members, only compounding the problem. Don't try to tell me that AoS did away with all the old code. If it did, the bugs of the previous condition of UO would have been gone.

Hell, even UO3D and Kingdom Reborn retain some of the original 1996-1998 development code.

Some of the bugs that have NEVER been fixed are still around simply because nobody knows where the problem lies, and researching it all is simply cost-prohibitive.

 

[Eslake]

Yes, but the AoS team had to implement luck into the old code. My point is that none of the current developers understand all the old code, which for the most part, is still in use, and repeatedly modified by later dev members, only compounding the problem. Don't try to tell me that AoS did away with all the old code. If it did, the bugs of the previous condition of UO would have been gone.

Luck wouldn't have anything to do with the "old" code though. It only gets factored in when you kill something, and that part has long since been replaced in the multiple re-drafts of how loot rights are determined.

I know they are still using the original source for the most part. But they use it as an excuse for everything they don't feel like putting any effort into.

Fshards are usually run by individuals (meaning 1 person working on the entire thing) with none of the documentation EA staff has, and no funding whatsoever.
And yet on those you can find sexed animals which can be crossed for characterstics in their offspring, orcs and gargoyles have been playable races since 2000, PvP is actually balanced, and ships are not a hindrance to sea-based gameplay.

If an individual doing it as a hobby can accomplish something with it, why can't an entire team of paid professionals accomplish the same?


Luck though, is not a part of the old game.
It is a new system added outside of what was already there.
The only interraction it should have with previously existing code is where it was tallied-on-equip(which works fine), and appending a check of it to the loot-generator for NPC/monster-kill instance. (which as I said, has been changed several times in recent years so is not part of that Old code)

 

[Bomb Bloke]

Since luck cannot be a negative value, can be any whole number value up to - and beyond - 1024, it is either a 3byte custom numeric, or a doubleword. (unsigned)

For starters, "values up to - and beyond - 1024" require only two bytes (as two bytes can handle 65,536 different numbers). Not that this really matters, just mentioning it.

More to the point, the value you see in the client may not be used for the calculations involved in what it is monsters actually drop. Even if it IS, that doesn't mean an overflow can't occur at some point DURING those calculations, nor does it mean there aren't any problems related to signed values.

I'm not saying my idea is THE cause of what's going on. It's much more likely they threw in some random operators during some random event to keep people with low luck levels from complaining about lack of loot, then completely neglected to document the changes. But your points don't contradict.

There are actually a few places where the mathematical code in UO makes no sense. Try taking a few randomly sized piles of fish, then chop them up. No sense in the results at all. Then go make yourself some fukiya darts using various amounts of wood each time. Same again.

I agree there's no excuse for it. If a bug can be reliably reproduced, it should be fixable. In the case of luck I just don't think they're interested in going out and doing the amount of hunting required to demonstrate that there's a problem (they're not going to take our word for it).

 

[MalagAste]

There’s definitely something wrong with the luck system. My girlfriend and I do levithians together. We’ve done about 40 total, she’s done 20 and I’ve don’t 20. I wear up to 1800+ luck and I’ve received 2 drops. She wears about 800 luck and has received 15 drops (including two ghostship anchors).


...

I'm currious wrek..... is your Girlfriends char a GM fisherman? Are either of you? I was told once that GM fishermen who toss the nets in get an even higher chance of getting the Arties.... beyond even luck... so I'm wondering were either of you fishermen? I've done leviathans with my GM fisherman several times... He has about 400 luck... and he hardly ever gets an artie UNLESS he is doing them "with" someone else... when he's alone I hardly get any at all.

 

[Maplestone]

When a fisherman tosses in a white net, they have a straight 25% chance of getting minor aritifact when the leviathan is killed. (I do not know how this interacts with the odds of a drop if the fisherman all kills the leviathan themselves)

 

[Eslake]

For starters, "values up to - and beyond - 1024" require only two bytes (as two bytes can handle 65,536 different numbers). Not that this really matters, just mentioning it.

More to the point, the value you see in the client may not be used for the calculations involved in what it is monsters actually drop. Even if it IS, that doesn't mean an overflow can't occur at some point DURING those calculations, nor does it mean there aren't any problems related to signed values.

I know a Word is 65,535 in binary, but the game isn't written in assembler. (or I would credit their claims that the code is difficult to modify )
Storage for high-level languages involves additional bits to identify the variable type and scale. In most, a Word-length numeric value takes 3 and is a custom length, and a doubleword is used where a terminator is required (usually a simple ascii(0) zero-stop).

You may be right though, that they threw in some arbitrary bit of nonsence that doesn't hande the potential results accurately.
If, for example, luck is unsigned(most likely) but somewhere in the implimentation of it a signed operator is applied, a carry-bit could easily force a Negative luck value in the procedure.

A 3 byte range holding a binary value of 100010110000 is 2224 luck.
But to a signed operator it is Negative 176 luck.