Group Bank Accounts

Page: 1 2
Apr 2 2015, 6:08 am
That should be O.bankAccount.addYen(...)

Note that O.bankAccount is the /Account. It has a var called yen, and a proc called addYen(). You cannot call O.bankAccount.yen.addYen because O.bankAccount.yen is a var, not another object.
Apr 2 2015, 6:14 am
In response to Mightymo
One big problem, Mightymo:

mob
    player
        var
            yen
            Organization/organization
        verb
            deposit(var/amount as num)
                if(yen >= amount)
                    yen -= amount
                    organization.bankAccount.addYen(amount)

Because you didn't make the organization var tmp, it will save with the mob. That's bad news because it will save an outdated copy of the organization. Whenever you're working with shared atoms or datums like this, it's crucial to be aware of what might accidentally save along with your mob.

What you should do instead is make that /tmp and check, on load, which organization that player belongs to.
Apr 2 2015, 6:16 am
Yes, definitely.
Apr 2 2015, 6:30 am
There's a Check() proc that runs when loading your character and loops every so often while logged in. I use the organization var pretty heavily in this system, so in the Check(), I was going to make a check along the lines of if they're a part of that organization, then it'll automatically update their organization var with the latest copy of the organization.

That would work, no?
Apr 2 2015, 6:32 am
In response to Mightymo
That's what it was, and it kept changing the bankAccount from a number to "/Account"
Apr 2 2015, 7:04 am
Maybe you should post all the code you have as it currently is which is relevant to either organisation or account constructs in any way (saving/loading/checks etcs), so we can know exactly how you have things setup?

This is just to double check you're not doing something wrong somewhere; i'm thinking that you're possibly incorrectly applying some of new information you've needed to process, in order to change your approach -only slightly, but still- so i think seeing exactly how you've set things up now in code will show much clearer where your issues might or might not be/ where to go from there with your other questions.
Apr 2 2015, 9:52 am (Edited on Apr 7 2015, 2:55 am)
Alright, so here is your issue. It appears that you have created an instance of the Account 'datum' by executing
bankAccount = new()

whenever a new organisation is created. However, you don't actually have the New() procedure defined within the Account datum setup itself. That needs to be present, as it is what is used whenever DM looks to instantiate an instance of something.

So to demonstate, what you'll need to do is have your Account datum modified to something like:
Account
    var
        yen

    New(amount)
        ..()
        setYen(amount)
    proc
        addYen(var/amount)
            yen += amount
        setYen(var/amount)
            yen = amount

Another possible problem, as i think about it, might have been trying to use the addYen(), not setYen() proc to make the starting balance equal to 50000. Since yen is null before you try to apply a += operation on it, that statement would work out as null += 50000 right? So perhaps the evaluation of that statement is something the DM compiler has an issue with?

Eitherway, as long as you have a New proc defined within the datum, even if you simply make y = 0 within it, you could keep your current system the same. I would suggest my example approach as the more intuitive way of going about that though: that way there'd be no need to go back in from outside to set the initial yen value after the account had already been made.


Edit: Decided to remove the tips section. Since no response was made to it i guess it went unappreciated, if that's the case i might as well not have it there greatly increasing the post's size.
Apr 6 2015, 6:33 pm
Don't restructure anything, don't over complicate the simple goal with multi-layered datums... unless you want to learn about datums.

If you want a system that works so you can prototype quickly, be efficient.
var
    bank_acct = list(
    "Org. 1" = 0,
    "Org. 2" = 0,
    "Org. 3" = 0)
    
mob/verb
    deposit(t as num, x as anything in bank_acct)
        bank_acct[x] += t
        world<<"[bank_acct[x]]"
        
    withdraw(t as num, x as anything in bank_acct)
        if((bank_acct[x] - t) < 0) return
        
        bank_acct[x] -= t
        //add money to player
        world<<"[bank_acct[x]]"
Apr 7 2015, 2:38 am (Edited on Apr 7 2015, 1:31 pm)
In response to Suicide Shifter
"Don't restructure anything"
Why? Are you more interested in what you would have done as opposed to what the better options are?

To add on, nothing was 'over-complicated'.
I was going to say that if you noted the various ways he was looking to interact with the Organisation constructs, and the operations etc. associated with them, you would see the reasoning behind the suggestion that Apophis approach his system using datums*. However, it seems he has since removed the additional code he'd posted -but apparently without responding to my attempt to help him with the error... i'll just be assuming he got it fixed somehow. Nevertheless, you should have been able to see that what he required was beyond simply having a list of strings associated with a list of values >.<.

As for 'prototyping quickly', i don't see what that has to do with anything, it certainly doesn't justify the bare bones snippet you provided -which you seemed to equate to efficiency, although it is more a cosmetic solution than anything in this case.
If, as the OP, i was to ditch using datums for the kind of approach you've modelled, what i'd end up having to do is spend extra time** fiddling/reworking it so it was fit for use for my game specifically, and that it clicked nicely with other related aspects of the game logic. This, in comparison to using datums wherein you'd find no such extra considerations to be necessary, is not ideal at all.

A lot of what i could say can be summed up in saying it is a better approach because you're providing your constructs (and yourself) a central place within which any special behaviour can be encapsulated, no roundabout methods necessary.
Apr 7 2015, 5:15 am
In response to Suicide Shifter
Turboskill is right; the accounts need to be datums.

While a single associative list could hold the amounts of the multiple accounts, it could not keep track of who had legitimate access--which is obviously relevant to the problem at hand. An account is an entity that extends beyond a name and a number, including information about who can access it and at what level, and possibly what its history is. For that reason, a datum is very much called for.

Datums are sensible for organizations as well, since an organization is also a distinct entity, containing not just a name and a list of members but also any number of other bits of information--including, in this case, a reference to its account.

Knowing when not to use datums is as important as knowing when to use them, it's true, but this is a clear-cut case where it's better to use them. This does not violate the KISS principle, because form follows function. Oversimplifying as you suggest would not allow for access controls, and in any case would prohibit further expansion of the system without switching back to datums anyway.
Apr 7 2015, 6:31 am (Edited on Apr 7 2015, 6:39 am)
Apophis0 wrote:
Problem description:

What I'm trying to do is create a joint bank account for organizations coded into this specific game. The var for money is Yen, and Organizations have already been set up, The Organization Bank var can't be tied to the mob/leader, because it needs to be something anyone can contribute to at all times.

My snippet solved the problem. There are two ways to look at this. If OP is learning about the language, isn't trying to get a playable version completed quickly, then by all means restructure your core mechanics with datums.

Turboskill wrote:
As for 'prototyping quickly',i don't see what that has to do with anything,

But if OP is trying to prototype, which means that he is creating something workable in order to test it out, then why? Why restructure the core of your game to be able to expand possible functions which haven't been created yet or you might never use? So many programmers fall into that trap. Get something playable and testable, then if you must, restructure.

"what i'd end up having to do is spend extra time** fiddling/reworking it so it was fit for use for my game specifically,"

I'm not sure what you mean, but surely it can't take too long to 'fiddle' with a feature that took 5 minutes to write.

Lummox JR wrote:
While a single associative list could hold the amounts of the multiple accounts, it could not keep track of who had legitimate access
Then we can simply add another list, no harm done.
var/list/access_list = list(
    "Org. 1" = list("bob", "brianna"),
    "Org.2"   = list("ray", "sam"),
    "Org.3"   = list("jay", "steve"))
proc
    check_access(name, organization)
        .=0
        if(name in access_list[organization])
            .=1
        return


My point is that if OP just wanted the system to test it out and decide if he actually wants his gameplay to have joint accounts for his organizations, he can quickly get a working version and test it.

But he could decide a short way down the road he wants to scrap the idea entirely, what then? A lot of wasted time (unless his end goal is to learn about the DM language).
Apr 7 2015, 7:59 am
In response to Suicide Shifter
Suicide Shifter wrote:
My snippet solved the problem. There are two ways to look at this. If OP is learning about the language, isn't trying to get a playable version completed quickly, then by all means restructure your core mechanics with datums.

The OP asked a specific question about implementing something in his game, not about learning the language. Your snippet was only meaningful as an example of how associative lists could store numbers in this way, but almost any real-world solution to this issue would call for a datum. This one did.

Turboskill wrote:
As for 'prototyping quickly',i don't see what that has to do with anything,

But if OP is trying to prototype, which means that he is creating something workable in order to test it out, then why? Why restructure the core of your game to be able to expand possible functions which haven't been created yet or you might never use? So many programmers fall into that trap. Get something playable and testable, then if you must, restructure.

But the OP didn't say he was prototyping. He said he was implementing. This wasn't a trial run--he actually wanted code for a specific purpose that he intended to use going forward.

And what you're saying about prototyping and restructuring doesn't make sense. Start simple, refactor later sounds nice in theory, but in practice refactoring is never taken seriously until a project gets unwieldy. Yes, there is a time to go bare-bones as simple as possible when just trying something out as a proof of concept. But in this case it was readily apparent that datums would end up being part of the final design; there's no sense avoiding that, then.

"what i'd end up having to do is spend extra time** fiddling/reworking it so it was fit for use for my game specifically,"

I'm not sure what you mean, but surely it can't take too long to 'fiddle' with a feature that took 5 minutes to write.

To put this gently: You have no idea.

Lummox JR wrote:
While a single associative list could hold the amounts of the multiple accounts, it could not keep track of who had legitimate access
Then we can simply add another list, no harm done.
var/list/access_list = list(
    "Org. 1" = list("bob", "brianna"),
    "Org.2"   = list("ray", "sam"),
    "Org.3"   = list("jay", "steve"))
proc
    check_access(name, organization)
        .=0
        if(name in access_list[organization])
            .=1
        return

Oh good gads no. When you're using multiple lists to access multiple properties of the same thing, that's when it's obvious that a datum is called for. This kind of design is easier to break if the lists get out of sync. And this is the trap you end up in if you try to use the wrong feature for rapid prototyping instead of starting closer to the end goal. It's important to recognize when you'll only ever be working with a scalar value like a number, vs. when you might need more detailed info all tied together, like a datum.

My point is that if OP just wanted the system to test it out and decide if he actually wants his gameplay to have joint accounts for his organizations, he can quickly get a working version and test it.

But he could decide a short way down the road he wants to scrap the idea entirely, what then? A lot of wasted time (unless his end goal is to learn about the DM language).

But the OP didn't just want to test and decide--he wanted a system to do this. That's what he said. Also, and this is important, when savefiles are involved you can't necessarily switch designs very easily right in the middle of things.

I speak from experience: You waste far more time going too simple and having to expand than thinking out the design first and implementing something closer to the final design. (Or if you suspect your design only needs to be simple but you aren't 100% sure, going for extensibility is a huge timesaver in the long run.) Even if a feature's inclusion is tentative, it often makes more sense to start closer to a finished result than to go with the absolute bare minimum that works.
Apr 17 2015, 10:34 am
 
Organization.ID=rand(1,999999)


I just want to interject. If you are actually generating organization IDs in your game like this, it's not a good idea. Presumably you want different organizations to have different IDs. Due to something called the birthday paradox (http://en.wikipedia.org/wiki/Birthday_problem), if in the entire history of your game there are 1000 organizations there is a 40% chance that two of them will have the same ID. Considering that some of the more popular BYOND games (http://www.byond.com/games/Lizard_Sphere_X) have several hundred players on a daily basis, it isn't impossible that over the course of history of your game 1000 organizations will be created.
Apr 17 2015, 10:37 am
In response to Toadfish
Oh, good catch there. I didn't even notice the ID thing. Yeah, a string ID is probably for the best, with uniqueness enforced. It could be as simple as requiring no two organizations have the same ckey name, which would make handling their savefiles easy.
Page: 1 2