05 Feb, 2008, kiasyn wrote in the 1st comment:
Votes: 0
I'm looking to replace the SMAUG object value system, its just not feasible for me to keep using it anymore.

I'm looking for a replacement that will let me use my custom classes as values, anyone have any ideas?

Currently using a cheap hack:
class Value
{
private:
std::string str;
public:
Value() : str() {};
Value( const std::string s ) : str(s) {};
Value( const char *s ) : str(s) {};
Value( int num ) : str() { str = convert<std::string>(num); };
Value( const VnumPair vnum ) : str(vnum.c_str()) {};
Value( const Money m ) : str() { str = convert<std::string>(m.get()); };

Value operator=( const VnumPair &v ) { str = v.c_str(); return *this; };
Value operator=( const std::string s ) { str = s; return *this; };
Value operator=( const char *s ) { str = s; return *this; };
Value operator=( int n ) { str = convert<std::string>(n); return *this; };
Value operator=( const Money &m ) { str = convert<std::string>(m.get()); return *this; };

VnumPair getVnum() { return VnumPair(str); };
Money getMoney() { return Money((char *)str.c_str()); };
int getInt() { return convert<int>(str); };
string getString() { return str; };

std::string toString() const { return str; };
};


but would really like something that doesn't have to convert in/out of strings.
05 Feb, 2008, David Haley wrote in the 2nd comment:
Votes: 0
It might help to say first what you're trying to fix. I can think of a few problems with the object value system, but the biggest one for me is having to map six fairly arbitrary numbers to what those numbers mean for that particular object. You can fix this for building by adding object-type-based fields to commands like oset, e.g. oset sword mindamage 123, but in code you still have those numbers. And yes, you can fix those too by having constants… however, this whole system also has the problem that you can only store numbers as values, and can only have six at most.

Judging from your code it looks like you're angling to fix the value side rather than the key side. One suggestion then might be to make Value an abstract class and then have concrete IntValue, VnumValue and StringValue subclasses that use the appropriate storage. For string values, you really do want to store it as a string; integers should be stored as such; etc. Then you can still convert between strings and so forth if you choose to, but you don't have to do it needlessly when working with numbers.
06 Feb, 2008, kiasyn wrote in the 3rd comment:
Votes: 0
DavidHaley said:
I can think of a few problems with the object value system, but the biggest one for me is having to map six fairly arbitrary numbers to what those numbers mean for that particular object. You can fix this for building by adding object-type-based fields to commands like oset, e.g. oset sword mindamage 123, but in code you still have those numbers. And yes, you can fix those too by having constants… however, this whole system also has the problem that you can only store numbers as values, and can only have six at most.


Thats pretty much it in a nutshell. Especially now my vnums are no longer numbers, a lot of the item values have broken down.

I did actually try the abstract Value class.. I think I had trouble getting it to work, which is probably because I wrote it in the middle of the night. Right now I'm using a class that wraps a union, which seems to be working okay for now.
0.0/3