22 Jun, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
This is from Rom 2.4 in file "db2.c"
Now, i know that it makes sense to have conditions, as far as when you fight in battle, your sword
gets dull, etc.
Because i'm building an offline builder database, i need to know what these characters represent:
EG: P = "Poor"?
G = "Good"?

Does anyone know?

case ('P'):
pObjIndex->condition = 100;
break;
case ('G'):
pObjIndex->condition = 90;
break;
case ('A'):
pObjIndex->condition = 75;
break;
case ('W'):
pObjIndex->condition = 50;
break;
case ('D'):
pObjIndex->condition = 25;
break;
case ('B'):
pObjIndex->condition = 10;
break;
case ('R'):
pObjIndex->condition = 0;
break;
22 Jun, 2009, Sandi wrote in the 2nd comment:
Votes: 0
Feel free to make up your own meanings, the only other place they are used is when they're set to 100% in db.c on load.

My guesses would be, Perfect, Good, Average, Worn, Damaged, Broken, Ruined. :smirk:
22 Jun, 2009, ATT_Turan wrote in the 3rd comment:
Votes: 0
For starters, just looking at this switch statement I see that 'P' gives the item full condition (100%), so it wouldn't be translated as "poor" - perhaps "perfect"? The version of RoM2.4 that I grabbed doesn't have an OLC to provide interpretations, so what the letters represent are up for grabs. If they don't make sense to you, simply change them here and in the saving function, or figure out a progression that makes sense to you. My suggestion would be: perfect, good, average, worn, damaged, broken, ruined.


Edit: Yay for synching with Sandi! You know what they say about great minds…
22 Jun, 2009, David Haley wrote in the 4th comment:
Votes: 0
ATT_Turan said:
Edit: Yay for synching with Sandi! You know what they say about great minds…

What, that Sandi's great mind ninja'd yours? :tongue:
22 Jun, 2009, Skol wrote in the 5th comment:
Votes: 0
You might also change the condition to actually make a difference in game?
I changed mine so that battle can damage them based upon the objects material (like cloth takes more fire damage, slashing vs metal etc). The new objects are usually 100 for condition but if they get down to 0 they're usually dropped to -1 (broken) and then aren't wearable until repaired. Some things aren't repairable etc. Not a perfect system but it provides a drain and isn't too much of a hassle.
22 Jun, 2009, Hades_Kane wrote in the 6th comment:
Votes: 0
I believe I just took condition completely out because it does nothing by default and I (nor my players) seemed interested in a system of equipment being worn down and requiring repair.

There's so much bloat in ROM, and I made a decision to either finish what ROM started or just completely remove the stuff.
22 Jun, 2009, Runter wrote in the 7th comment:
Votes: 0
I had a system for equipment ware based on actual time in combat with it. To the players it was represented by a percent.
The basics of the system were as the object got lower in condition the more chance of degrading permanently. (Item level being reduced by 1)
Item level not to be mistaken with level restriction.

I added oils to maintain items. Applying oil would raise condition.

Then there was a "constitution" stat for objects that also was a percent. This represented the item being broken or not.
When constitution reaches 0 it becomes broken and cannot be worn. Oil had no effect on this stat. Instead you had to have the item repaired.
However, the quality of the oil and the current condition were a factor in how long it would take for the item to need to be repaired.

Internally it was represented by 'hours in combat.' It took hundreds of 'hours in combat' of neglect to actually damage an item, and if taken care of it
only very rarely would require a repair.
22 Jun, 2009, Sandi wrote in the 8th comment:
Votes: 0
Hades_Kane said:
I believe I just took condition completely out because it does nothing by default and I (nor my players) seemed interested in a system of equipment being worn down and requiring repair.


*nod, nod* I actually meant to say, "pObjIndex->condition" is only used in one place.

In my hardly humble opinion, with a 'well-balanced' game it's useless, and annoying to the players - they put the effort in to get the stuff, it shouldn't automatically go bad on them. In a poorly balanced game, then yeh, you might want something to keep players from using that 'super sword of great damage' they got from questing, for the rest of the game.

If you're looking for realism, or an excuse for crafting, Runter's approach sounds pretty good. In such a case, 'better' EQ should wear longer.
22 Jun, 2009, JohnnyStarr wrote in the 9th comment:
Votes: 0
I was thinking about adding Rarity flag to objects,
you know like WoW:

Common
Uncommon
Rare
Epic
Legendary
ETC.

I'm thinking it wouldnt be too hard, i could just add the field
into the object structure, but what i havent thought about is the .are integration,
would i just go into the import routine for objects and add the field there?

any thoughts?
22 Jun, 2009, Sandi wrote in the 10th comment:
Votes: 0
Given the way repops are done and items are stored by players, the TRUE rarity of a game object depends on how many players hoard them. Rather than a perm flag, I'd just count the actual vnums on the fly, so 'rarity' was more accurately portrayed. There's a flaw, though, in that the inventories of offline players won't be counted. If to decide to include them, be sure to only count players who have recently connected.
22 Jun, 2009, JohnnyStarr wrote in the 11th comment:
Votes: 0
Any docs about adding fields to saved structures, and import routines?

Like, say i wanted to add a flag to the CHAR_DATA structure called 'hair color', this would be defined by bit flags:

A - blonde
B - black
C - brown

obviously i could just do this:
struct char_data {
long hair_color;
};


But what about the .are files? How do you add that to the import?
22 Jun, 2009, KaVir wrote in the 12th comment:
Votes: 0
Sandi said:
In my hardly humble opinion, with a 'well-balanced' game it's useless, and annoying to the players - they put the effort in to get the stuff, it shouldn't automatically go bad on them. In a poorly balanced game, then yeh, you might want something to keep players from using that 'super sword of great damage' they got from questing, for the rest of the game.

I've usually seen item damage used in one of two ways:

1) As a way to destroy items over time - not because they're over-powered, but as a way of recycling limited items back into the game, and/or to keep players looking for new gear rather than stopping once they've got everything.

2) As a money sink, so that players have to pay to maintain their equipment. This ensures players have an incentive to keep collecting money, and also provides a reasonable way to get rid of some of the money that players accumulate over time.

However I instead chose to implement item damage as a short-term penalty. Players can simply type 'repair' on their home plane to instantly repair everything they're wearing and carrying, so fixing your gear is no big deal when you're not "in the field" so to speak - but it's certainly possible to break weapons and damage armour during combat as a way of weakening your opponent, comparable in some ways with a wound system.
22 Jun, 2009, Sandi wrote in the 13th comment:
Votes: 0
staryavsky said:
Any docs about adding fields to saved structures, and import routines?

But what about the .are files? How do you add that to the import?


Deja vu! See if this recent thread helps:

Adding stats
22 Jun, 2009, elanthis wrote in the 14th comment:
Votes: 0
KaVir said:
1) As a way to destroy items over time - not because they're over-powered, but as a way of recycling limited items back into the game, and/or to keep players looking for new gear rather than stopping once they've got everything.


KaVir has the gist of it. :)

A perfectly balanced game still needs rewards for players to earn once they hit "the end," and unless you have some kind of strong reason for players to remort and start over, the only way to reward top-tier players without constantly raising the power level is to make them want to earn the same rewards (or similar rewards, at least) over again. Equipment damage and condition is one easy way to do that. Some games force players to keep using skills to avoid having them atrophy for similar reason, or have reputation systems that require frequent high-profile deeds to avoid fading out of a faction's good graces, or so on. One reason I like item condition specifically is because it can keep item crafting and similar skills useful indefinitely, which – assuming you have an interesting and fun crafting system – avoids the usual RPG problem of "do all kinds of fun and varied things to reach top level and then have nothing to do except beat down increasingly big numbe^Wmonsters."
22 Jun, 2009, triskaledia wrote in the 15th comment:
Votes: 0
Sandi Given the way repops are done and items are stored by players, the TRUE rarity of a game object depends on how many players hoard them. Rather than a perm flag, I'd just count the actual vnums on the fly, so 'rarity' was more accurately portrayed. There's a flaw, though, in that the inventories of offline players won't be counted. If to decide to include them, be sure to only count players who have recently connected.

Recently one of my builders brought to my attention the idea of "rare" items loaded to a mob.
In his idea he pointed out the need to bring into the olc a [percent chance] to load items upon area/room reset and setting one to several "rare" items to a mob.
Then from there he proceeded to suggest the idea of adding an [item counter] to the reset, to prevent over loading the "rare" items at one time.
I thought this was a great idea, and I've already kind of got a psuedo-code set up for it, but nothing concrete or implemented. I'm sure others have seen this idea implemented in other places, or discussed - just throwing my thoughts.
–Silence Tyire of Reanimation
23 Jun, 2009, Hades_Kane wrote in the 16th comment:
Votes: 0
On rare items, I've had something in mind for a while I'll eventually get around to coding…

I've been calling it "Legendary Weapons" in my notes, but essentially what I was thinking is that I could assign particular items to be considered "legendary" (maybe an editable table in game or such) that would have various parameters.

1) Rarity (how many can exist at any given time)
2) Reset Method (how the item would be put back into the game)
3) Expiration (what conditions would cause the player to lose the item)

Rarity is a bit self explanatory, but some things for the others I've thought… Reset Method might include things like a pre-determined vnum, a range of vnums, a random spot in the world, on a particular mob, or none at all (immortal ran quest reward and such). Expiration would be things like perhaps some weapons would leave its owner if their alignment got too far from the weapon's, if they died at all, if they died to a PK fight, if they killed another player… all would have a "days without login" thing as well.

As far as the actual mechanics of how to handle this (such as solving the issue of a player that doesn't login after obtaining a one of a kind item)… I figured rather than actually saving the item to the players, I would instead have a table in another file that would be checked when a player logs in and on boot. Let's say JoBob has "Excalibur", next time he logs in, the item wouldn't be loaded on him like other items, when he logs in, the file with the legendary weapon stuff would be checked and if under any of the items' entry he is listed, then the item would be loaded. If on boot, "Excalibur" hasn't been loaded in X amount of days, the player information stored under it would be deleted and next time JoBob logs in he would simply not have the item. The following boot after the player information has been removed, the MUD would check the item table and if there is no player information listed, then it would run whatever "Reset Method" routine that has been set for it.

Like I said, I have yet to start work on this, but it is something I plan on eventually adding in and I think would be a pretty neat system. Also, the PK-Safe flag of anyone with such a weapon would be disabled for the duration of them having such an item, so I think that would be a good way to have rare items that also would have a good chance of continuing to cycle through the playerbase.
28 Jun, 2009, JohnnyStarr wrote in the 17th comment:
Votes: 0
I was thinking about writing a quick routine that would asses the "Rarity" of an item based on the Global Limit of the object. See, with my offline builder i've made in MS Access to avoid most certain Reset Doom i have put a field in the Object portion called "Global Limit" this way if the population needs to be managed, it can be done very easily because each reset added will grab this "global limit".

I am thinking about creating a field called "Rarity" and having the before mentioned rarities but each one has a pertaining value:
EG:
common      -> global limit = 50
uncommon -> global limit = 30
rare -> global limit = 10
unique -> global limit = 1

This way I wont have to reinvent the wheel but at the same time, it will be true to its statement, i mean, how can you call an item Legendary if it has the potential of being replicated 100 times?

EDIT: Oh, hehe, sorry, I posted before reading the most recent reply, its very similar. Well at least i'm not alone in my thinking :redface:
28 Jun, 2009, Ssolvarain wrote in the 18th comment:
Votes: 0
There's a lot of games with sentient weapons whose descriptions indicate that they choose the wielder, rather than the other way around. Unfortunately, I've never actually seen a weapon do this…
0.0/18