I must say, I've made lots of custom procs wich were ALL filled with user. Only 2 gave me runtime errors, wich were indeed caused by the "usr" in the proc.
Today, it took me around 45 minutes changing all "usr" to "src" in procs. The effect... Bam. Simply bam.
Nothing worked anymore, the procs wouldn't 'activate'.
I've heard you guys discussed what's the best to use in procs, and came to the conclusion that "src">"usr", but after this I'm just sticking to my own usr abusive procs now...
Any of you had this? :/
ID:152767
 Oct 30 2005, 11:05 am
|
|
Are they mob procs or procs for other things?
| |
Ugh, no replace usr with src for no reason. You might need to type cast. Also, show us the code.
| |
Though your problem has already been addressed in [link], I'd like to add that it would probably behoove you to read the usr lecture if you haven't yet done so.
| |
It is quite true that src > usr. Of course, using quite elementary logic it can be extrapolated from this fact that src != usr, so duh it's going to give you errors if you just replace one with the other.
It's quite possible to create fully working code using usr inside of procs, but just because it works doesn't mean it's just as good as any other implementation. Good code is robust, which means you can call up a proc any time, any where without it screwing up. Using usr does not lead to robust code, though. For example: suppose you've got your RPG and you've got a basic inventory system. You can pick up items, drop items, yadda yadda yadda, and all your inventory management functions use usr to refer to the player who's handling the item. A player puts in a command to "drop sword", the drop function looks and sees that this player is usr in this situation and drops their sword. Works fine, eh? But now suppose that you've got a disarm attack that makes an enemy drop their weapon. You've already made a function to drop items, so it would be handy to just make your disarm function call up the drop function for the other player, wouldnit? But you can't do that if the drop function uses usr: your player puts in "disarm goblin", the disarm command calls the goblin's sword.drop() function... except that in that drop function, usr is now equal to the player instead of the goblin. So now you have to either rewrite your drop function in a robust manner (such as passing in an argument instead of relying on usr), or recode a seperate dropping function from scratch (which takes time and makes it a huge headache if you ever want to change the drop function, because now you have to update two different functions every time you want to make a change). | |
1 - It's "No put usr in proc, ungh"
2 - Don't just replace usr with src. Use an ARGUEMENT. 3 - If something had the same speed as it had mass, by sheer coincidence, would you then use mass instead of speed in all the pretty formulas to work out stuff? Would you use the mass of the object instead of speed when working out how far it will travel in a particular time? No, of course not. That's stupid. Usr abuse is equivalent. | |
From what I got out of your post, Leftley, is that robust code is not necessarily better for the person, but better for the coding entirely? All of the problems I have seen with "usr" usually involve the fact that you will have AI or NPC players in your game. What if there are no AI or NPC mobs in the game? A lot of the arguments for robustness usually involve it being general or interchangeable, being able to work in any situation. Isn't that really preference though, and also depends on the game itself?
When we are talking about no usr in proc we mean when we define something as a proc right? Isn't the usage of procs up to the developer a lot of the time? I personally wouldn't use a proc for something like dropping an item, I would use a verb or a HUD button. However, if dropping an item a rare occurance and is something that the player does not need to easily do, I might use a proc. Shouldn't you mold the coding to work with the game, instead of molding the coding to work interchangably? | |
But it's very helpful to be able to call these sorts of things with a modular nature. Leftley's disarming example is a good one.
Quite simply, usr isn't what you want. a*b = a if b = 1, but you still wouldn't use a where you meant a*b, even if b will generally be 1. It's a question of being accurate. | |
Yeah, you should pay more attention to what usr and src actually point to in an proc.
Its like any open source thing, if you alter someone's code, dont complain when it doesnt work :P | |
A lot of the arguments for robustness usually involve it being general or interchangeable, being able to work in any situation. Isn't that really preference though, and also depends on the game itself? No. =) Lummox is one of the best programmers in the BYOND community and he says "no usr in proc"- and to be entirely honest, what he says goes. He knows what he is talking about, and if you can't accept what he says, then you'll pay the price later. :p When we are talking about no usr in proc we mean when we define something as a proc right? Isn't the usage of procs up to the developer a lot of the time? I personally wouldn't use a proc for something like dropping an item, I would use a verb or a HUD button. I'd make a drop proc, then make the verb use that proc. Then you coud use it for loads of things- saving time and effort, and space. It's better programming practise. Seriously. It'll save you eons of work later on. No usr in proc! | |
Elation wrote:
Lummox is one of the best programmers in the BYOND community and he says "no usr in proc"- and to be entirely honest, what he says goes. He knows what he is talking about, and if you can't accept what he says, then you'll pay the price later. :p well, its a six word abbreviation for a lengthy explanation. in chopping the whole spiel down to those six words, some (most? all?) important information is sadly lost. luckily wizkidd0123 put together a bwicki page with some of this information, with links to pages with more about usr. http://bwicki.byond.com/ByondBwicki.dmb?UsrLecture | |
Lummox is one of the best programmers in the BYOND community and he says "no usr in proc"- and to be entirely honest, what he says goes. He knows what he is talking about, and if you can't accept what he says, then you'll pay the price later. :p Those who obey orders without questioning thier motives are shallow minded. You cant just say "no usr in proc" and expect people to obey, you have to explain why and give examples. Thats why were called programmers and not copy-paste artists :) | |
Ireus wrote:
Those who obey orders without questioning thier motives are shallow minded. You cant just say "no usr in proc" and expect people to obey, you have to explain why and give examples. Sure, but for those that can't be bothered (you know the type) to read long articles about the evilness (or lack thereof, as many would argue) of usr, who are most often the perpetrators of said abuse, should memorise the rule. It's the 11th commandment, you know. Take Justin Knight. He didn't seem the point in abstaining from usr in proc because he reasoned that in some cases you'd never use the proc in a way that usr would go wrong. But that's wrong, since it's always a good idea to make your code flexible. Who knows what will come of it later on? Someone else might continue development after you pass away/get a job/get bored, and might not know your line of thinking (that of "Let's restrict what my procs can do, make my code less flexible and make more work for me to do later on"). It's just a good idea to remember: "no usr in proc, ungh". Just like thy shalt not kill, sort of. Other than that, there's nothing really to be questioned. Usr is bad in procs, therefore, don't use it in procs. | |
Ireus wrote:
You cant just say "no usr in proc" and expect people to obey, you have to explain why and give examples. this is why we have the wiki entry that OFD mentions, plus the BYONDscape article as well. | |
Indeed, handy articles. I agree that usr shouldnt be used in procs, but its a lil tricky for some people to see why, or see any effect.
I learnt DM from the guide and various tutorials, so I understand why not to use DM... just dont like the idea of ordering noobs not to do something and they blindly obey :P | |
Ireus wrote:
Indeed, handy articles. I agree that usr shouldnt be used in procs, but its a lil tricky for some people to see why, or see any effect. for the way most newbies use usr, they should be using src. but, if a case comes up where they aren't sure if they should use usr, by this rule, they shouldn't use usr. when, in some procs, usr is correct. its more complex to understand how usr works and be able to decide if you should use it, but thats a lot better than remembering a rule which is isn't always right. | |
Click() and so on are more verbs in nature than they are procs, since they're always called by the client. I can't think of any examples where usr would be good in a proc, could you give me an example please? :)
| |
Elation, quite frankly I don't think you saw where I was coming from with that post. I was responding to Leftley's post, questioning 'robustness' and also stating that the way in which you want to code is up to you. I wasn't replying to the topic in general.
Lummox is one of the best programmers in the BYOND community and he says "no usr in proc"- and to be entirely honest, what he says goes. He knows what he is talking about, and if you can't accept what he says, then you'll pay the price later. :p If I was replying to the topic in general, I would say this: You can code whichever way you like with usr in a proc, but don't ask for help in code problems if you are trying to prove a point that usr works in many situations, src is usually the way to go with procs. Code problems is infested enough with people drilling into other peoples' heads "No usr in proc, ungh." Quite frankly, because of the fact that Lummox Jr is regarded in such a high position, people follow his advice without question. Anyone that questions his guidelines for coding in DM will most likely be shot down with people arguing about 'robustness' of code. There really are exceptions with the things that people get drilled into their heads, as some people have shown here in this thread, and this is where most people will falter. Because of the fact that they will avoid what told not to do completely, they will probably make workaround methods without even knowing it. These workaround methods could possibly be more 'robust' though, I don't want to start a discussion about this. I'd make a drop proc, then make the verb use that proc. Then you coud use it for loads of things- saving time and effort, and space. It's better programming practise. You just reinforced my point that the way you code procs are your preference, because I don't really see the point in calling a proc from a verb if you can just code it right there for the verb. | |
Elation, quite frankly I don't think you saw where I was coming from with that post. I was responding to Leftley's post, questioning 'robustness' and also stating that the way in which you want to code is up to you. I wasn't replying to the topic in general. Why the hell would you question robustness? Robustness is GOOD. Full stop. Sure. You can glue together an aeroplane using stick-tape. It'll work and it'll fly okay and do all the things you want it to. But after a while you'll see it start to crumble apart and then you'll end up falling to your death. Why not glue it together with industrial welding tools? More effort, more expensive and glue does the job, right? Code should NOT be up to the person when it comes to writing code robustly and in a good way. It's like punctuation; two-thirds rules, one-third style. Every programmer writes stuff in a different way, goes about a problem in a different way. That doesn't mean they should write crappy code. There are set rules you must follow before you go about doing things your own way. You just reinforced my point that the way you code procs are your preference, because I don't really see the point in calling a proc from a verb if you can just code it right there for the verb. Because then you can call it any time for a variety of reasons. Say you have an attack verb- but later on in the game you realise you want to have an option so players wil automatically attack back. Then just calling the right attack proc, the same one the verb calls, is a lot easier and easier to understand later. Having a bunch of verbs scattered about the place with various functions is *confusing*. That's why we write segmented code these days, with seperate functions! I seriously don't get you at all. What are you, questioning something that is objectively good? How could you possibly say that robust code that will work in *every* circumstance is a bad thing? Robust code, stuff like not abusing usr, is something you should not question. It's just good, for obvious reasons. Quite frankly, because of the fact that Lummox Jr is regarded in such a high position, people follow his advice without question. No duh? People wouldn't follow his advice if he was a dumbass who wrote crappy code that broke down at every hurdle. People follow his advice because *he gives the best advice*. He writes articles on why usr abuse is a bad thing. He write s articles on how to write good, proper code. This isn't like some cult where we're blinded to the truth and a big brother style guy feeds us terrible code and we don't know the difference. This community, as you'll know, is quick to criticise someone if they do something wrong. It has free-thinking and intelligent members who pick up on mistakes easily. People find mistakes in the Blue book all the time. If someone in a high position who we respected started writing and teaching bogus code, we'd point it out. But so far that code is good and robust, and that's why we don't put usr in proc. I don't know how you can question something that is so intrinsically good. <=| | |
That Deathcheck() code might work if the person doing the killing is a player. If it's an NPC, however, there will be runtime errors. Changing usr to src results in the following:
src is killed by src? That can't be right. :P The Deathcheck() procedure needs more information. It needs an argument telling it who the killer is. That might look something like this:
Now, every part in the code that used to call something.Deathcheck() needs to instead call something.Deathcheck(killer), with killer being a variable holding the mob that is doing the attacking and killing.