give_cash(mob/M as mob in world)
How can I make it so the user of this verb will not be shown in the list?
ID:163324
 Sep 9 2007, 5:44 pm
|
|
How can I make it so the user of this verb will not be shown in the list? | |
|
Sep 9 2007, 5:49 pm
|
|
Ter13
   |
You gotta do this manually.
|
give_cash() Well here is what I did with the code you said would work. and this is what I get back Full Moon Fantasy.dm:826:warning: it is recommended that you use an object filter or 'anything' when combining constant input types with lists | |
This is why copying and pasting instead of actually looking at it and learning doesn't get anywhere.
Go back and look at Ter's code. Figure out what it does, and try and implement it yourself. | |
mob/verb/Give_Cash() lets try not to confuze people now ter =P your code is somewhat advanced, and far outside the necesary requirements for something as simple as this lol | |
course u could also do something as simple putting
if(M==usr) return on the first line of the verb but what fun would that be =P | |
Uh, right, aside from that thing where I can give negative amount, fractions, and even more money than I have.
Here's how I'd do it: mob/verb/give_money(mob/M as mob in world.contents-usr,amount as num) // no need for a for() loop for that! | |
DivineO'peanut wrote:
Uh, right, aside from that thing where I can give negative amount, fractions, and even more money than I have. > mob/verb/give_money(mob/M as mob in world.contents-usr,amount as num) // no need for a for() loop for that! That how I'd do it as well. But that way will let players enter decimals provided that its greater than zero and less than one, and if done correctly, can seriously screw up money. I've had instances with that on my game. So unless he wants decimals like that, you're better off doing amount < 1 rather that amount <= 0. Granted decimals can screw it up anyway, but decimals without a whole number present can do worse damage. | |
If he is too obstinate to learn from it, that's his problem. Not mine. This is an overly simple operation to which I had no intent of making an end-all beat all solution.
Don't mean to be cocky, but I'm in a rush. Anyway, I'll see y'all later tonight. | |
I'm not writing his game for him. That's his responsibility. All I was showing him was all he asked for, how to exclude the user from a list.
Sure, your way is more complete, and more helpful for him later on, but I'm not here to GIVE him all the answers. I'm here to show him a way to do something he specifically asked for. =/ Or am I just being a jerk? I don't think I am, but I think it's a little pointless to nitpick at me when my snippet answers the question posed, and is correct, and does work. | |
Ter13 wrote:
Or am I just being a jerk? I don't know, but I do know I am: mob/verb/give_cash() -- Data | |
And once again, a less specific example of what I gave him.
He asked how to give money to other players. Yours give it to any mob. Mine actually checks if they are a player. Second, my snippet wasn't advanced as all. Associative lists are rudimentary concepts. input() functions are rudimentary concepts. for loops are rudimentary concepts. indentation is a rudimentary concept. adding and subtracting are rudimentary concepts. accessing arrays is a rudimentary concept. creation of variables are rudimentary concepts. I don't see one complex thing in there at all. You can read a basic BYOND tutorial, or even the first few chapters of the Blue Book, or DM guide and understand all of that. Maybe I should have taken him through it step by step, but Falacy, your example only removes the associative strings in the lists, and a single if(). If that makes all that much easier to understand, I'll print the blue book, and eat the entire thing. By your argument, my example is only marginally harder than yours is. Instead of taking issue with me, why not tell him to look at his indentation? Why not ask him what he doesn't understand about it? So... Yeah, I'm gonna go ask him why he's not understanding my snippet, and try to be helpful. | |
associative lists are definetly harder to understand then just pointing directly to something
and arrays are a pretty basic programming concept, but considering the fact that because byond has a list type variable u practicaly never need to use a real array so yes, maybe for a C++ programmer these things are "rudimentary" (lol somebody likes big words =P) but for someone using byond it can be a whole lot simpler then that and theres no need to complicate it here and you could easily add that check for a client into the same if that check if theyre the usr, not all that big of a deal o.O | |
What part are you having trouble understanding? I can give you a step by step.
Our example: give_cash() First, we need to create a list to store all the players in the world to. var/list/L = list()
Next, we loop through all the mobs in the world, and check if they have a client, and are not the one who is giving the money. If they have a client, that means they are a player. for(var/mob/M in world) //loops through every mob in the world EXAMPLE What we actually do, if the mob is a player, and is not the user, is adding to the list. We are using a special kind of list for this, it's called an Associative list. It associates a string, in this case, the player's name, with a value. Normally, when accessing a list like this one: var/list/L = list("jim","bob","tom") By getting values from their position in the list. I.E.: L[1] == "jim" L[2] == "bob" L[3] == "tom" But if we want our names to also be associated with their ages in the same list, rather than create a second list, we can just put a second value in the list: var/list/L = list("jim"=21,"bob"=20,"tom"=40) This is exactly the same as the last list, when it comes to getting the values, 1, 2, and 3 will all return "jim", "bob", and "tom", but you can get their ages by using the names. L[1] == "jim" L[2] == "bob" L[3] == "tom" Also: L["jim"] == 21 L["bob"] == 20 L["tom"] == 40 Therefore: L[L[1]] == 21 L[L[2]] == 20 L[L[3]] == 40 Associative lists are very good for input() procs, as you can use a human readable string to represent an object, or another piece of data that may be harder for a human to understand in text/numerical form, like a color. Next, we need to actually allow the player to choose from a list. input() has a nifty little tool you can use to tell the input box what kind of data to expect. This is the 'as' keyword. Since anything can go in a list, BYOND will warn us if we use anything other than 'anything'. You can list multiple types of data by separating them with a vertical bar '|' (I say 'or', when I read this aloud). There is another useful type you can add to anything to add a cancel button to your input box: 'null'. This means the player can choose to not answer, and just select cancel instead, returning null. Note though, that anything must always be the right-most type, meaning null must come before anything. var/choice = input("Give cash","Give cash") as null|anything in L Two strings are in this function, text that will be displayed above the list, and text that will be displayed above the title of the input box that pops up. Also, note the use of the 'in' keyword. This means that you are selecting from a list. In this case, you are selecting from our associative list we made earlier, 'L'. Next, we have to check if the user selected cancel, or if the player we chose is still in the world, as time can pass between when the list was made, and when the input was answered, and we cannot account for what happens between that. if(!choice||!L[choice]) We are forcing the verb to stop running if either value is null. Remember that choice is a string here, as what we actually selected was something like: "tom", and the value of L["tom"] will actually be equal to tom himself, and not just his name. And last, we have to just get the mob we chose from the list: var/mob/M = L[choice]
After this, you just write in your code to give the money to the other players. | |