Vary Effectiveness of items within QL

[Slavor]

You are probably wondering exactly what this means.

I think it would be useful to add another dimension to identify an item. Currently, the QL level really equates to the "level" of the item. Since it is probably too difficult to change this, just leave the QL as is, and add a second metrix to the item to itentify it's real "effectiveness/quality".

Why?

This would add more variety to items, and allow certain items of the same QL to be more valuable. For example, there could be two rare, level 200 items. One could be of average quality, and the other could be of perfect quality. Obviously, the higher the quality of the item, the better its bonuses would be, above and beyond what is typically received.

Just an idea to add more variety and value to items.

[locomdenom]

Nice idea, but (there's always a but, I know), would probably require a re-write of the database, and as such is pretty unlikely.

[Slavor]

actually this could be implemented by simple adding another attribute to the item...

I assume that there is something like an "ITEMS" table, which contains a UID, item_type, QL, and other metadata. This could be accomplished by simply adding one more numeric column to such a table (3 decimals should be sufficient).

[Rugger807]

Actually most of the old school weapons do increase in effectiveness with QL. Not to mention damage increases. Most of the old weapons will get a lower speed rating as QL increases. Take a look at a Q1 Seburo c-99 vs a Q200

[Slavor]

I covered this in my original post.

The idea I had was to add even more variability to an item, such that two items of the same QL could actually behave differently, based on how "good" that particular weapon is (average, perfect, poor).

In such a model, the current Quality of the item would become its "Level". Then new measure that defines how "good" an item is of a particular level would be the "new" Quality metric. Hence, each item would have both a Level, and a QL rating. This would allow a Level 175 gun with an extremely high QL rating to actually be more effective than, say, a Level 190 gun with an extremely low rating.

[locomdenom]

Originally posted by Slavor_MoK
actually this could be implemented by simple adding another attribute to the item...

I assume that there is something like an "ITEMS" table, which contains a UID, item_type, QL, and other metadata. This could be accomplished by simply adding one more numeric column to such a table (3 decimals should be sufficient).

That's a database re-write, and is more work than it sounds like.

Otherwise, why couldn't they just add a "Custom Name" field to every item so we could rename bags, something they've said was probably too much work?

[speardancer2]

Not only would it be adding an extra field to the database, but re-writing the code that reads the database to evaluate that new field.

Besides, isn't the point of having different QL of items in the first place the same thing as what's being suggested?

In alot of other games, you just have "Item x", which has it's stats.

We already have "item X"QL1 thru "Item X" QL 50, for example.

the QL 1 item is "worn"

the QL50 item is "overcharged" or some such line.

instead of having 200 possible QL's of an item, now you want more? I don't see this ever hapaning, it's already in game.

[Jayde]

Here's the problem...

As it stands, items are merely references to database Hi/Low/QL, then the client and server figure out the stats of the weapon.

Right now, there are no individual values given to that reference. So, to work within the existing system...you would need to duplicate all the items in the DB for all the different "types." This would be a gargantuan process, considering there are almost 90,000 items in the database right now.

Of course, one way to possibly do this is to make the contained "references" extensible and able to store individual data.

So, each item "instance" on the server would contain: HiID, LowID, QL, MetaData

Unfortunatly, however...this would probably involve a rewrite of all code regarding the handing and transfer of items. (Mostly the transfer code.) And also probably the storage of item instances on the server.

Personally, I would like to see this myself, as it would allow "naming" and other things, but I highly doubt it will happen any time soon. Large blocks of the network transfer code would have to be modfied, as well as the event handlers for tarsnferring and references item instances...and, of course, possibly major overhauls to the server instance storage--depending on how it's set up.

Trying to do this via the database would be very unwise, IMO..simply due to the massibe size increase it would bring.

Also, another reason I find this unlikely in happening, is if FC wanted to do this they would have done so long ago. Why? Well, Implants would have been able to have been handled much better with metadata tracking, and wouldn't required tens of thousands of database entries. However, this didn't stop Funcom for adding over 35,000 new implant database entires while phasing in the "Refined" and "Jobe" implants. If metadata contexts were in the cards, I doubt they would have done that much work at that time.

-Jayde

[locomdenom]

Thanks for saying what I was trying to say, Jayde, only much less clearly so it was far more impressive.

Which is good, as the amount of work required to do this would indeed be impressive, and I wasn't conveying that.

[Kuro]

Actually Jayde didn't have to say all that. THe best reason I can think of for not doing something like this would be:

OT Shopping 1 - 50: WTB QL 150+ Mausser Chemical Streamer with Effectiveness >= 85 and Quality >= 65...Anyone? Anyone seen one of those?

Shopping would be hell. Even if you couldn't tell the actual effectiveness of a weapon, people would be going through 5-10 of the same weapon trying to eyeball their effectiveness/quality.

I'd rather be circumcised with a belt sander than making item shopping more painful

[Slavor]

Belt sander! rofl! That's the funniest thing I've read all week.

Thanks for the feedback, Jayde. I was not familiar with how AO actually *works* as far as the client-side item database goes. But I understand your point of why the db size would grow to an enormous size so that every Level+Quality combination is defined... The implementation they have is then quite inflexible as far as customizations go...

I wonder if AO could work with a "vault" concept, similar to Neverwinter Nights. The items would be retrieved from the server when a user logs in, or "saved" to the server as needed... This would essentially remove the client-side db so that all items would me memory resident until persisted. One thing that would probably have to change with a vault, because of scalability issues, is item persistence -- items would not persist at time of death, but from the last save to the vault... Which would really blow! Of course, we'd be talking a ton of work to switch to a vault architecture. So, all items in a players inventory would exist in memory (unless a secure local persistence mechanism were added to AO) while playing. The contents of a chest would be retrieved from the server and sent to the looting client. Which I'd imagine would add to network overhead.

Although, one way to reduce the bits going between the client-server would be to implement a metadata language for communicating item description/definitions. The metadata would then have to be parsed out to derive the real numeric values for the item.

The changes should not ripple into the rest of the application, though, if FC used anything resembling a MVC (model-view-controller) design approach. A good amount of rework in the data layer, some minor changes to object definitions to add a new attribute that's loaded by the data adapters.

[eaze]

Originally posted by Slavor_MoK
You are probably wondering exactly what this means.

I think it would be useful to add another dimension to identify an item. Currently, the QL level really equates to the "level" of the item. Since it is probably too difficult to change this, just leave the QL as is, and add a second metrix to the item to itentify it's real "effectiveness/quality".

Why?

This would add more variety to items, and allow certain items of the same QL to be more valuable. For example, there could be two rare, level 200 items. One could be of average quality, and the other could be of perfect quality. Obviously, the higher the quality of the item, the better its bonuses would be, above and beyond what is typically received.

Just an idea to add more variety and value to items.

I don't get it, what's the point with this? Just to add another entity to the database?

[didymus]

Hmm ..

Reading these posts, there are too many good reasons not to do this .. With the work and all, but mostly, I can't see the point in it myself. I mean, I'm quite sure that if I could have two things at the same QL with different effectiveness .. I wouldn't be any happier at all. Rather, it would make things more complicated.

All in all, I don't care much for items. There are so many other things to fix first.