In response to D4RK3Z3R0
Guys. Whoa, slow down. Indentation should be corrected as follows:

mob
faction1
verb
Donate(n as num)
if(usr.credit<=n)
usr<<"You don't have that much to add!"
return
else
src.funds+=n
usr.credit-=n
FactionMessage("[usr] donated [n]")


However, I think that an important design choice needs to be made before we go too far with this.

If each faction will have virtually identical functions (like each faction will have its own donation verb, and they'll all work the same way), then the better programmming practice would be to program one universal proc that all factions have access to, and then place restrictions within the proc to prevent members of one faction from interacting with other factions.

You would write one verb under a common ancestor (probably just /mob), then add in checks to compare the faction of the source, and the faction of the target, and only carry out the transaction if they match.

All other shared types of functions can be handled this way.
In response to Wissam
Wissam wrote:
Your indentation mislead me.

What are you talking about i simply quoted his code?
Hey guys, one more thing, would it be possible to make some sort of voting system, something like every 60 minutes, each faction has to vote for a new faction leader.
In response to SuperSaiyanGokuX
I see.. something like this perhaps
 mob/
var/faction1funds=0
var/faction2funds=0
var/faction3funds=0//then the verb would be
mob/faction1
verb
Donate(n as num)
if(usr.credit<=n)
usr<<"You don't have enough !"
return
else
faction1funds+=n
usr.credit-=n
Faction1Message("[usr] donated [n]")//then repeat the process for the other factions?
That is sort of the idea, but this is more what I mean:

mob
var/faction1funds=0
var/faction2funds=0
var/faction3funds=0
verb
Donate(n as num)
if(usr.credit<=n)
usr<<"You don't have enough !"
return
else
usr.credit-=n
//here will go a system of figuring out which faction the player belongs to
//and depositing the funds into the matching faction's account
//you can do this check in several ways, but here are two examples:
//1) You can add the players to a list for each faction, then check what list they are in
//2) You can simply give the players a variable that you can set to their faction, then check that
//whatever way you do it, it then boils down to something similar to:
if(//player is in faction1)
faction1funds+=n
Faction1Message("[usr] donated [n]")
if(//player is in faction2)
faction2funds+=n
Faction2Message("[usr] donated [n]")
//and so on


And even further, you can combine all of the faction message outputs into a single universal proc as well, and just pass into that procedure call a new variable that will tell it which faction to output the message to:

FactionMessage(faction as num, message as text)
if(faction==1) //output message to faction1
if(faction==2) //output message to faction2
//etc.


Your Donate verb can then be simplified by adjusting it like so:

    verb
Donate(n as num)
if(usr.credit<=n)
usr<<"You don't have enough !"
return
else
usr.credit-=n
//here will go a system of figuring out which faction the player belongs to
if(//player is in faction1)
faction1funds+=n
if(//player is in faction2)
faction2funds+=n
//and so on
FactionMessage([user's faction],"[usr] donated [n]")
//You would now only need one call to FactionMessage, done at the end of the proc. No need to call it one time per faction, because now this procedure can handle sending a message to whichever faction is appropriate


In the above, note that the use of switch() will be very handy.
Ohh i get ya! so something of this nature
mob/verb/donate(n as num)
if(usr.credit<=n)
usr<<"You don't have that!"
return
else
usr.credit-=n
if(usr.faction1=1)
faction1funds+=n
factionmesssage([faction1],"[usr] donated [n].")//then if usr.faction2=1 i do the same over again.
This would be the perfect time to dive into datums for the factions.
In response to Danny Roe
Could you please elaborate? I'm a new coder so i don't really catch terms like those .
In response to J-Zed
J-Zed wrote:
Ohh i get ya! so something of this nature
mob/verb/donate(n as num)
> if(usr.credit<=n)
> usr<<"You don't have that!"
> return
> else
> usr.credit-=n
> if(usr.faction1=1)
> faction1funds+=n
> factionmesssage([faction1],"[usr] donated [n].")//then if usr.faction2=1 i do the same over again.


Very close to that, yes. I would make a slight improvement to how you're attaching the player's faction, though (and I believe this was mention by another response earlier in this thread)

Instead of giving the players several variables (faction1, faction2, faction3, etc.) and then turning those "on" (by setting their value to 1), it would be simpler to just give the player a single "faction" variable, and just set it to the faction number they are in.

Players in faction 1 will have faction=1, players in faction 2 will have faction=2, etc.
In response to SuperSaiyanGokuX
SuperSaiyanGokuX wrote:
J-Zed wrote:
Ohh i get ya! so something of this nature
mob/verb/donate(n as num)
> > if(usr.credit<=n)
> > usr<<"You don't have that!"
> > return
> > else
> > usr.credit-=n
> > if(usr.faction1=1)
> > faction1funds+=n
> > factionmesssage([faction1],"[usr] donated [n].")//then if usr.faction2=1 i do the same over again.

Very close to that, yes. I would make a slight improvement to how you're attaching the player's faction, though (and I believe this was mention by another response earlier in this thread)

Instead of giving the players several variables (faction1, faction2, faction3, etc.) and then turning those "on" (by setting their value to 1), it would be simpler to just give the player a single "faction" variable, and just set it to the faction number they are in.

Players in faction 1 will have faction=1, players in faction 2 will have faction=2, etc.

I tried telling that to him he just ignored me.
In response to D4RK3Z3R0
You fixed the previous issue and i thanked you for it, and SuperSaiyanGokuX offered another solution with the same concept as yours.
In response to D4RK3Z3R0
Thanks guys, you really helped me out on this one and taught me a new , simpler way of coding.
Hey, no problem! Glad to help.
Learning a lot from this thread right here.
You seem to have everything sorted, but I'll elaborate on my previous comment about using datums to handle this sort of thing. For a much more in-depth look at datums, read Lummox Jr's post Datums Are Our Friends.

I'll comment the code as best I can. First off, we will have to create a list to hold our three factions, then make the actual Faction datum.
//This list will hold of all the current factions
var/list/currentFactions = list()

//This is our Faction datum
Faction
//We have three variables: It's name, list of online members and funds
var
name
list/members = list()
funds

//These are the procs that the Faction will use
proc
addPlayer()
removePlayer()
addFunds()

//When we create a new Faction, we set it's name and add it to the
//currentFactions list
New(n)
name = n
currentFactions += src

There we go, but those procs don't actually do anything yet, so lets sort that out.
Faction
addPlayer(mob/M)
//Check if they are a player and add them to the members list
if(M.client)
members.Add(M)

removePlayer(mob/M)
//If they are in the members list, remove them
if(M in members)
members.Remove(M)

addFunds(amt)
//Add an amount to the fund
funds += amt

Now we have our Faction datums, but we havn't actually created them yet. We should do that when the world starts up, so lets throw that in there. I'm going to call them the Red,Green and Blue factions.
world
//When a new world starts, we will create 3 Factions
New()
..()
new/Faction("Red Faction")
new/Faction("Blue Faction")
new/Faction("Green Faction")

Now the world has started, and the factions are created. Time to work on our mob, we'll to give him some currency so he can donate, and also a variable to keep track of which faction he is in.
mob
//A couple of variables we will need
var
credits = 1000 //our mobs currency
Faction/faction //So we know which faction he is in

Great, now we let him decide which faction he wants to join. We'll do that when he logs into the game. While we're at it, we will remove him from the faction when he logs out.
mob
//When a mob logs in, prompt them to choose their Faction
//from the currentFactions list
Login()
..()
src.faction = input("Which Faction would you like to join?") as anything in currentFactions
src.faction.addPlayer(src)

//When a mob logs out, remove them from their Factions
//member list
Logout()
src.faction.removePlayer(src)
..()

Almost set up now, but the players are generous and would like to donate to their faction, so we'll let them do that.
mob
verb
Donate(var/n as num)
//If they have enough Credits, take if off them and
//add it to the Faction fund
if(credits >= n)
credits -= n
src.faction.addFunds(n)
//Tell your faction members that you donated
for(var/mob/M in src.faction.members)
M << "[src] donated [n] to [src.faction]"
else
src << "You do not have enough credits."


And there you have it, a nice little Faction system. Keep in mind that if you want players to permanently choose a faction when they create a new character, you will only have to let them choose once, and that's when savefiles come into play.
In response to Danny Roe
Wow, i never knew you can have so much from just 1 var. I'll definately be checking out Lummox Jr's guide about Datums now. Thanks for opening my eyes to yet another new way to do thing Danny Roe.
:o Thanks Danny. I'll also check out that guide. Interesting thing, Datums. I just didnt understand why the code [Faction/faction] was put there. Does it enable the mob to utilize the Faction datum?
It does indeed, in the same way that one would use var/mob/Player. Faction (capital F) references the Faction datum, and faction (lower f) is the name of the variable.
Thanks
Datums are great (even though I don't use them as often as I could)

Lummox's guide points this out, but a datum is the most basic data type (in fact, "datum" is the singular form of "data", TA-DA!). All other data types in DM are derived from it, including all of the atoms.

What this means is that a datum has all of the basic capabilities of the more specialized data types (it can have variables and procedures defined on it), but it doesn't have all of the "overhead" that comes with the other types. Every level as you go down has an extra layer of stuff (variables and built-in procedures) tied to it that give it its special properties on top of whatever it inherits from the level above, so since the datum is the base type, it doesn't have all of the baggage.

All of this is just a rambling way to say that a datum is perfect for holding and manipulating abstract data. Anything that doesn't need to carry with it any of the junk that comes with the other types (the movement procs and variables built into movable atoms, or the contents list, etc.) can just be handled by a datum, instead of wasting resources and time on using one of the atom types.

I tend to use /obj for a lot of things that could simply be datums, but that habit goes back to earlier days before I knew better.
Page: 1 2 3