Jump to content

  •  

Equipment breaks system


  • Please log in to reply
50 replies to this topic

Poll: Equipment break system (67 member(s) have cast votes)

What should be down about how equipment breaks? (must read Notes before answering)

  1. Add item quality (46 votes [68.66%])

    Percentage of vote: 68.66%

  2. Add one or more items in a degrade tree (3 votes [4.48%])

    Percentage of vote: 4.48%

  3. Other, read in comments (4 votes [5.97%])

    Percentage of vote: 5.97%

  4. I don't know (6 votes [8.96%])

    Percentage of vote: 8.96%

  5. Leave it alone (8 votes [11.94%])

    Percentage of vote: 11.94%

What priority is this?

  1. Very important, make everything else wiat (3 votes [4.48%])

    Percentage of vote: 4.48%

  2. More important then Attribute/Combat (3 votes [4.48%])

    Percentage of vote: 4.48%

  3. Less important then Attribute/Combat (38 votes [56.72%])

    Percentage of vote: 56.72%

  4. I don't know (4 votes [5.97%])

    Percentage of vote: 5.97%

  5. Not very important, get to it eventually (19 votes [28.36%])

    Percentage of vote: 28.36%

Vote Guests cannot vote

#41 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 16 October 2012 - 06:13 AM

View PostInfamous, on 15 October 2012 - 08:39 PM, said:

View PostKorrode, on 15 October 2012 - 01:56 PM, said:

View PostInfamous, on 15 October 2012 - 01:19 PM, said:

it's like that cause the procentages are high, it doesn't happen that fast with greatswords etc cause they have a low breakrate.

With the current system, a great sword can still break on the first hit. At least with these systems you can guatantee more than that. Even if it was a guatantee of only 10 hits, that's still 10 times more reliable, no?

depends, the breakrate would increase so you'd have more chance to degrade it 10 times and poof it, where-as on the other side with just lower breakages you'd have small chances your item degrades, then have an attempt for Tankel to fix/break it.

in either situation shit can happen, one has 10 "back-ups" and high breakrate, the other low breakrate and a gc sink/uncertain back-up repair.

besides with just decreasing breakrate he could fix that quickly and focus on the attribute system and maybe later think about this instanced break system, while we still enjoy lower breakrates in the meantime.
rather then think about this instanced breakrate system now and have him focus on either 1 of 2 things while we still have high breakrates in the meantime.

Atm weapon type is determined by an 8bit value that presently uses 68 out of a possible 255 slots. That leaves 187 slots that could be used immediately to  implement an instanced quality system. If you also vary the quality graduations so as lower end items have fewer, and higher end items more, a rough calc suggests you could cover all weapons under the present system right away (particularly if you are intending limiting the overall choice to exclude some of the el weapons). Bear in mind the system is even easier to apply to shields, as very few of the slots are currently utilised, ditto helms etc.

As far as breakage factor is concerned, it makes sense to retain both that and a degradation factor for each weapon as it gives a greater choice and variety of weapon characteristic, ie :

1) Weapons that don't degrade but have an increasing break rate.
2) Weapons that don't degrade but have a constant break rate.
3) Weapons that degrade with reducing characteristics, but only break at the lowest value
4) Weapons that degrade with reducing characteristics, with increasing break value throughout
5) Weapons that degrade with reducing characteristics, with a constant break value throughout
6) Weapons that degrade but retain a constant characteristic, but only break at the lowest value
7) Weapons that degrade but retain a constant characteristic with increasing break value throughout
8) Weapons that degrade but retain a constant characteristic with constant break value throughout

I'd suggest the coding effort in applying the above would be relatively simple, as it wouldn't affect storage, trading or the comms protocol. The only thing that would need to be changed client-side would be the defines in client_serv.h, plus maybe some of the graphics links. On the server-side, (I should imagine) there would be no time-consuming changing of data types or comms protocol or much else, simply the implementation of a structure to hold breakage/degrade values and some straight forward changes to the existing subs to implement that characteristic.

Yup, in the long term, it will be necessary to implement a 16bit data type to hold weapon values, particularly if it is intended to extend the range. However, that can take place gradually in the background without significant impact on delivering features that deal with more immediate gameplay issues.

#42 Learner

Learner

    God

  • Administrators
  • 2661 posts

Posted 16 October 2012 - 06:35 AM

I'm not sure what you are calling Weapon type used to identify . There is a value for where a weapon, armor, clothing is worn, and a value that uses bits says what is stackable, usable, wearable, mixable, etc or not. All those bits sent to the client are in use, and where worn can't be used for this either.

Not sure where you are getting the 68 from. Still, it would still require in the server one unique item for each grade of quality, since those values from from the item definition, not the actual item in your inventory. The only thing the item in your inventory has is type # & quantity. That's why Storage and Trading would suddenly become such a pain because you would have to look at 10 identical graphics to get the text description to see what you have. Yes one work around is to create a whole bunch of graphics, but that's a pain, and then the quality concept isn't easily extended to non-weapons

Please try to avoid using the term Instances since that can cause confusion with EL

#43 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 16 October 2012 - 08:29 AM

View PostLearner, on 16 October 2012 - 06:35 AM, said:

I'm not sure what you are calling Weapon type used to identify . There is a value for where a weapon, armor, clothing is worn, and a value that uses bits says what is stackable, usable, wearable, mixable, etc or not. All those bits sent to the client are in use, and where worn can't be used for this either.  

Not sure where you are getting the 68 from.
I was referring to the #defines 1-68 given in client_server.h which relate to an 8 bit value for each weapon and which are used in the ADD_NEW_ENHANCED_CLIENT message, but I think I see what you're getting at, ie those are only used for wearing items, not for inventory or trade. If the inventory/trade items are all used then, yup, that's a problem lol. Not that I can come up with an easy solution for that, but could you plz point me in the right direction of where the right values are actually held ty

Learner said:

Still, it would still require in the server one unique item for each grade of quality, since those values from from the item definition, not the actual item in your inventory. The only thing the item in your inventory has is type # & quantity. That's why Storage and Trading would suddenly become such a pain because you would have to look at 10 identical graphics to get the text description to see what you have. Yes one work around is to create a whole bunch of graphics, but that's a pain, and then the quality concept isn't easily extended to non-weapons.

Instead of manually individually each graphic, would it be possible to run a batch process (maybe using something like the facilities in php) to overwrite the weapon graphic to indicate the degrade level. Something not too intrusive, like a simple Roman numeral could then be inserted in the corner. That would take a lot of the pain an effort out of the process and make creating larger amounts of degrade less arduous.

Not sure I understand why the quality concept isn't easily extended to non-weapons. What am I missing Learner ???

Learner said:

Please try to avoid using the term Instances since that can cause confusion with EL
Agreed. I was simply repeating the terminology already used in the thread so to avoid confusing anyone. But yes, I think a more distinct terminology would be desirable, (if someone would like to suggest)

#44 Learner

Learner

    God

  • Administrators
  • 2661 posts

Posted 16 October 2012 - 08:49 AM

I think the one your looking at goes up to 72 now, and is used to determine what model needs to be used when an item is equipped. We have lots of unused inventory type items, I just consider it a pain to make multiple items to simulate quality of any type.

Have you looked at how the icons are stored for EL/OL? It's a 2D matrix with multiple items & type of items in each group/ So even if an automated process is used, that's still a lot of changes as well as properly identifying each one. That;s why a possible protocol & client change might make more sense.

#45 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 16 October 2012 - 09:51 AM

View PostLearner, on 16 October 2012 - 08:49 AM, said:

I think the one your looking at goes up to 72 now, and is used to determine what model needs to be used when an item is equipped. We have lots of unused inventory type items, I just consider it a pain to make multiple items to simulate quality of any type.

Have you looked at how the icons are stored for EL/OL? It's a 2D matrix with multiple items & type of items in each group/ So even if an automated process is used, that's still a lot of changes as well as properly identifying each one. That;s why a possible protocol & client change might make more sense.
Yup can understand that argument. It's possible to cut the individual icons from the matrix amend and then recombine them* but, although i've seen examples of that kind of thing in code, i've never tried doing anything myself like that myself. Personally, I agree that the protocol/client change route is far more robust and amenable to future development, it's just that I don't envy you the amount of work involved. However, rather than further side-track discussions on this thread (apologies to all for already having done so), if/when we get the coding sub-forum, it would interesting and maybe useful to take up a separate discussion on your specific ideas for implementing the protocol changes.

*see the php GD library (imagecopy, imagecopymerge)

#46 Learner

Learner

    God

  • Administrators
  • 2661 posts

Posted 16 October 2012 - 09:53 AM

I'm already with using the GD library in PHP :) I've used it to create one graphic file per icon, and change the black background to transparent as well.

Not if, when on the subforum.

#47 Infamous

Infamous

    Member

  • Full Member
  • PipPip
  • 104 posts

Posted 16 October 2012 - 10:01 PM

so can a temporary quickfix of lowering breakrates get into place while working on this suggestion?

#48 PandemiC

PandemiC

    Advanced Member

  • Full Member
  • PipPipPip
  • 628 posts
  • LocationLondon, United Kingdom

Posted 17 October 2012 - 05:05 AM

Don't be so cheap and spend your money on manuers infamous :P It's the way the world turns :D


But yes, less breaks for certain items (like those of iron plate stuff, serps, tit longs) should be lowered, the other low end stuff should remain as it is imho (as a temp fix).

#49 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 23 October 2012 - 01:58 AM

What do others think of implementing a dynamic break system where break chance varies in line with the amount of gc being created in-game? Having this kind of sink might avoid the need for so many static sinks that inhibit game-play, ie non-manufacturables items.

#50 Bat17

Bat17

    Member

  • Full Member
  • PipPip
  • 340 posts

Posted 23 October 2012 - 04:05 AM

I like the idea of dynamic responses in the game but it should extend further than just break rates. Crit Fails in mixing should be affected as well and possibly an automatic adjustment to NPC prices as well

Bat17

#51 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 23 October 2012 - 06:41 AM

Yup, fully agree with that. Would be great to see it also reflected in NPC pricing.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users