24 Oct, 2010, Ssolvarain wrote in the 1st comment:
Votes: 0
I'm not entirely sure where I would start if I wanted to change the gold/silver/copper to a single unit, like credits. I know that mobs use a counter of single units (copper) and it's converted into gold/silver/copper when it's loaded… but that's only because I'm a builder. So, I guess, basically I need to stop it from converting the single units into gold, silver and copper, alter the "score" page to display "Credits" instead, and see about fixing the issue of currency weight. And… the things that I don't know that I need to do ;)

So I'm wondering what sorts of things I would need to change, where they might be, and if this is something I'd be able to pull off without too much trouble?


I just realized that there is no stock bank system. -mutter-
24 Oct, 2010, jurdendurden wrote in the 2nd comment:
Votes: 0
deduct_cost is the function you want to look at. All it does is see if you have enough silver on hand to pay, if not, it uses gold. Only issue though is that it doesn't check beforehand to see if funds are available period.


A bank system is not very hard to set up. There's snippets out there, but the easiest way is just two variables in each pfile (one boolean for whether or not they HAVE an account, and one long integer for keeping track of funds). Then just associate a bank command with it and you're good to go.
24 Oct, 2010, jurdendurden wrote in the 3rd comment:
Votes: 0
Also, the score function is in act_info.c, under void do_score.

And to answer your question, yes, this is fairly easy to change and is a good first step if you are new to coding/rom development, as it will show you some of the basic ideas of how rom works.
24 Oct, 2010, Ssolvarain wrote in the 4th comment:
Votes: 0
Hey, thanks man. I have a vague (but it's there!) idea of how to take care of associating commands from messing around with a snippet before. I'll take a closer look, now that I got something to go off of.

Out of curiosity, why is the boolean for having an account necessary?
24 Oct, 2010, Kline wrote in the 5th comment:
Votes: 0
Ssolvarain said:
Out of curiosity, why is the boolean for having an account necessary?


Will everyone automatically have an account by default? If no, this is a good way to keep track of those who do.
24 Oct, 2010, Atolmasoff wrote in the 6th comment:
Votes: 0
Kinda like Kline said…

Figure you'd want the boolean there for your functions? If you planned on using a bank account system, I'd assume you'd want people to have to set one up. If you just wanted people to have them by default, you wouldn't need it, but with a boolean, you could avoid adding a line or two of code to a player's save file if they don't have one.
Same thing goes for bank related commands. If you didn't have an account, certain commands shouldn't work for you.
25 Oct, 2010, Rudha wrote in the 7th comment:
Votes: 0
Kline said:
Ssolvarain said:
Out of curiosity, why is the boolean for having an account necessary?


Will everyone automatically have an account by default? If no, this is a good way to keep track of those who do.


Generally you can assume that if the account value is 0 (or uninitialised) then they don't have an account.

Maya/Rudha
25 Oct, 2010, ATT_Turan wrote in the 8th comment:
Votes: 0
Rudha said:
Kline said:
Ssolvarain said:
Out of curiosity, why is the boolean for having an account necessary?


Will everyone automatically have an account by default? If no, this is a good way to keep track of those who do.


Generally you can assume that if the account value is 0 (or uninitialised) then they don't have an account.

Maya/Rudha


This, and it wouldn't really save you writing anything to a pfile because you'd have to save the fact that they don't have an account :smile:
25 Oct, 2010, jurdendurden wrote in the 9th comment:
Votes: 0
Either way, boolean or no boolean, you can see that it's pretty simple to set up a banking system.
25 Oct, 2010, quixadhal wrote in the 10th comment:
Votes: 0
Rudha said:
Kline said:
Ssolvarain said:
Out of curiosity, why is the boolean for having an account necessary?


Will everyone automatically have an account by default? If no, this is a good way to keep track of those who do.


Generally you can assume that if the account value is 0 (or uninitialised) then they don't have an account.

Maya/Rudha


Only if you don't allow negative balances. Personally, I like the idea of fees causing you to go negative and then having npc's coming to collect the debt you owe…
25 Oct, 2010, David Haley wrote in the 11th comment:
Votes: 0
Rudha said:
Kline said:
Ssolvarain said:
Out of curiosity, why is the boolean for having an account necessary?


Will everyone automatically have an account by default? If no, this is a good way to keep track of those who do.


Generally you can assume that if the account value is 0 (or uninitialised) then they don't have an account.

If creating an account actually costs something, then you cannot make this assumption. It would be kind of weird if I paid to set up an account, put in 100 credits, and later took them out again, only to have to pay once more to set up the account a second time.

There's also the issue of negative balances that Quix mentioned, which is just another way of getting to an account value of zero.

Also, you should never rely on variables being uninitialized. How do you even tell that they're uninitialized? (Well, you shouldn't fail to initialize data structure variables in the first place.)
25 Oct, 2010, Ssolvarain wrote in the 12th comment:
Votes: 0
Actually, I was thinking it would be more convenient and realistic to be able to take care of your banking no matter where you went.
And instead of actually carrying your money with you, it's just held in the bank and use would be like a debit card.

I'm not interested in an actual system, just something barebones that will work until someone else decides they want something fancy.

I should add that this is for my ROM retheme, so space-age my aim.
25 Oct, 2010, Kline wrote in the 13th comment:
Votes: 0
David Haley said:
Rudha said:
Kline said:
Ssolvarain said:
Out of curiosity, why is the boolean for having an account necessary?


Will everyone automatically have an account by default? If no, this is a good way to keep track of those who do.


Generally you can assume that if the account value is 0 (or uninitialised) then they don't have an account.

If creating an account actually costs something, then you cannot make this assumption. It would be kind of weird if I paid to set up an account, put in 100 credits, and later took them out again, only to have to pay once more to set up the account a second time.


This is the problem with relying on an empty balance. Even if there is no fee to create an account, am I to open a new account just because I withdrew all available funds?
26 Oct, 2010, Rudha wrote in the 14th comment:
Votes: 0
quixadhal said:
Only if you don't allow negative balances. Personally, I like the idea of fees causing you to go negative and then having npc's coming to collect the debt you owe…


Its still trivial to test if a player has a certain field or not.

Maya/Rudha
26 Oct, 2010, quixadhal wrote in the 15th comment:
Votes: 0
Unless you're coding in C/C++, in which case it's part of the player structure and there is no such thing as undefined, because C people hate the numeric value of 0. *grin*
26 Oct, 2010, David Haley wrote in the 16th comment:
Votes: 0
Right… one should not assume that the OP is programming in Python or indeed anything other than C/C++ when one is posting in the DikuMUD/ROM section of the forum. :smile:

In C++ it would be easier to have something like a map from field name to field value, and of course it's possible in C, but it's certainly not how things work in ROM normally.
26 Oct, 2010, Rudha wrote in the 17th comment:
Votes: 0
You guys do realise that python is coded in C, right? :P Its not hard to check if variables exist (though pointers can get dicey at times). If you use MSVC you can just go __if_exists(thing), if not then you can replicate the function fairly easily. Of course that smacks of shoehorning things a bit; I've not looked at ROM code specifically, but you may or may not be saving yourself trouble coding that in, which I suppose would depend on just how much of the code you intend to extend.

Generally speaking, you'd probably be okay to assume that if you have a value of 0 (or unitialised) means that you don't have an account. This only becomes problematic if you have some sort of credit or overdraft system in your banking system, which ups the complexity quite a bit. However, you're only using the bank to store positive amounts of gold, you should be okay doing that.

Maya/Rudha
26 Oct, 2010, Kline wrote in the 18th comment:
Votes: 0
Rudha said:
However, you're only using the bank to store positive amounts of gold, you should be okay doing that.


So I would be unable to withdraw all funds from my account? There is now a minimum balance?
26 Oct, 2010, David Haley wrote in the 19th comment:
Votes: 0
Rudha said:
You guys do realise that python is coded in C, right? :P

Um… yes? I guess Ssol should reimplement a dynamic language using C – it's possible, after all, and must be the right tool for the job! :tongue:

Rudha said:
Its not hard to check if variables exist (though pointers can get dicey at times)

Checking if something is uninitialized is implementation dependent at best, bad practice in the usual case, and outright buggy at worst.

There is a very big difference between a pointer that points to nothing, and a pointer that points to the value zero.

There is also a very big difference between checking the value of some variable, and checking whether or not it actually exists, which brings us to:

Rudha said:
If you use MSVC you can just go __if_exists(thing), if not then you can replicate the function fairly easily.

Since we're asking about what people do realize, you do realize that that tests for existence of a variable at compile-time, and not whether it has a useful value at runtime? __if_exists is a compile-time directive that allows you to exclude code based on the declaration of a variable – clearly, this is not at all what we want for testing the runtime value of a variable.
26 Oct, 2010, Ssolvarain wrote in the 20th comment:
Votes: 0
David Haley said:
I guess Ssol should reimplement a dynamic language using C – it's possible, after all, and must be the right tool for the job! :tongue:


No :(
0.0/48