I have a proc Run() that has stuff in it that wont work.
Run()
chancetorun = usr.agility - src.agility + rand(-20,20)
if(usr.diseased == 1)
usr << "You are too weak to run!"
Battle()
if(chancetorun >> 0)
usr << "You start to flee..."
sleep(10)
usr << "You successfully run away!"
usr.islocked = 0
src.islocked = 0
usr.lib = 0
usr.battle = 0
if(usr.attup >> 0) <--
var <--
attd = usr.attack / usr.attup <--
if(usr.defup >> 0) <--
var <--
defd = usr.defense / usr.defup <--
if(usr.lukup >> 0) <--
var <--
lukd = usr.luck / usr.lukup <--
if(usr.aglup >> 0) <--
var <--
agld = usr.agility / usr.aglup <--
if(usr.intup >> 0) <--
var <--
intd = usr.intelligence / usr.intup <--
if(usr.attackdoubled == 1) <--
usr.attackdoubled = 0 <--
usr.attack -= attd <--
if(usr.defensedoubled == 1) <--
usr.defensedoubled = 0 <--
usr.defense -= defd <--
if(usr.intelligencedoubled == 1) <--
usr.intelligencedoubled = 0 <--
usr.intelligence -= intd <--
if(usr.luckdoubled == 1) <--
usr.luckdoubled = 0 <--
usr.luck -= lukd <--
if(usr.agilitydoubled == 1) <--
usr.agilitydoubled = 0 <--
usr.agility -= agld <--
else
usr << "You start to flee..."
sleep(10)
usr << "The enemy cuts off your escape route!"
NPCDeathCheck()
Now, plz, i know about the not to use usr thing, but unless thats the problem plz dont fix it.
okay, i have the problem in <-- so check it out.
All the code lines in <-- are the bug, i want it to define the var if u have a certain other var above 0, but when i compile, it says the var isnt used, and the same exact var (agld for example) isnt defined. What did i do wrong?
ID:148241
 May 14 2003, 12:39 pm
|
|
Because usr doesn't work in procs, fixing that will probably fix the bugs in your code.
| |
I realize that this isn't what you wanted to hear, Metroid (I wasn't the one who deleted your post, but it did need deleting), but it's the truth.
You don't "know" usr isn't the problem because in fact it is, or at least it's a big part of it. You've got it everywhere in your code, and putting it where it doesn't belong is a sure-fire path to disaster. The fact that your code isn't working now, and there's a rather obvious thing you can do to improve code stability, ought to clue you in to the fact that maybe you should fix that after all. As a matter of fact, even if usr wasn't your problem, drastically misusing it like this proves you know so little about DM that you couldn't conclusively rule it out. If nothing else, it obscures your code and makes any other errors hard to spot, because people have to wade through a million "usr" references when it should have been src and therefore could have been left out completely. And not closing your HTML tags or putting <dm> around your code doesn't help either. So calm down. You've been told a problem (actually two, but one is with presentation) and you were given a fairly easy solution to fix it. That's not bad! It might not solve all your problems but it's at least a good solid first step, and it's something easy that you can apply with very little trouble. So do it, and if you still have problems then post your updated code (properly) and say what's going wrong, and we'll be better able to help you out. Lummox JR | |
Well, since u people decided not to help me and just complain about how i use usr "when i shouldnt" i ended up fixing it myself without changing all my code, so leave me alone about the usr crap. Please, just delete this damn fourm plz, im getting sick of listening to u complain, and while ur at it, y dont u delete everything of mine cause ur basically saying "start over ur code cause I said to not use usr so do it!".
| |
You aren't supposed to use usr because if you do you could end up with bugs that are INCREADIBLY difficult to track down. Say you have a proc that when called does something to usr(ie, changes an icon randomly). If you have non player objects(like NPCS) that call the proc expecting to change their own icon the last player who used the proc will have lots of random icon changes. Usr is the last player who called the proc/verb.
| |
But you see, U dont know my whole code, i dont have usr everywhere like u people seem to think, and ive only had one big bug before and i tracked it down easy, and this is only anthoer one that has NOTHING to do with usr. I just wanted it to be fixed, but now i dont need that, i did it myself. I didnt want u people to point out that usr was used too much or i shouldnt use usr, I DONT CARE WHAT YOU HAVE TO SAY ABOUT USR, LEAVE IT ALONE. I'll deal with the "bugs" when I get em, if i dont, then it dont matter anyway. Now, just delete this fourm cause its completely useless now.
| |
Metroid wrote:
Well, since u people decided not to help me and just complain about how i use usr "when i shouldnt" I did help you. Gads, will you listen to what you're saying? The usr crap is wrong in your code, needs fixing, and is responsible if not for the bug you have now then for some future bug that will pop up later. This is beyond any doubt. You must, must, must remove usr from your procs. i ended up fixing it myself without changing all my code, so leave me alone about the usr crap. No. I'm glad you found a fix for the current bug, but you'll just have future bugs because of your misuse of usr and I won't quit hounding you to change it. It complicates your code and it's totally out of place where you have it, so get rid of it. You'll be grateful you did later, when bugs don't happen that would have. Please, just delete this damn fourm plz, im getting sick of listening to u complain, and while ur at it, y dont u delete everything of mine cause ur basically saying "start over ur code cause I said to not use usr so do it!". I never said to start over. I said to change usr to src in that proc (and in other procs, where you likely have the same problem). How freakin' hard is that? For a few minutes' effort you could not only likely solve several existing bugs but also nail future bugs before they even pop up. You don't have to completely recode your program from scratch to do that--you just have to apply a very very easy repair to the code you're using now. Copping this attitude gets you nowhere, Metroid. At the end of the day your code is still deeply flawed and is poised to crash when you go multiplayer. You don't have to be ornery about it, or get all huffy because someone had the sense to offer an easy solution to an army of bugs. All you really have to do is apply the fix, which does not involve starting over. A little bit of find and replace will go a long way if you'd just drop the nasty disposition and go do it. Lummox JR | |
I cant use src if u did look at my other code when i posted it. Src is used for the monster. So I cant use usr. Thats how i know u said to start over my battle code cause if i cant use usr or src cause thats my monster, than i have to revise the WHOLE code. And you know what? dont reply to this, cause i dont care anymore, I dont know y i ever thought of coding in the first place. Its not like anyone will like the stuff a loser like me can make, it wont be worth it.
| |
What you can do is have proc/Run(mob/M)
Then whenever Run() is called pass it whatever var the player is. In your code you can then replace all the usr's with M | |
Metroid wrote:
But you see, U dont know my whole code, i dont have usr everywhere like u people seem to think, and ive only had one big bug before and i tracked it down easy, and this is only anthoer one that has NOTHING to do with usr. You may not have usr everywhere in every proc, but you had it everywhere in this one, and it was highly inappropriate there. How do you know your bug had nothing to do with usr if you don't even know not to use it in a proc? The answer is you didn't know, and still don't. I just wanted it to be fixed, but now i dont need that, i did it myself. I didnt want u people to point out that usr was used too much or i shouldnt use usr, I DONT CARE WHAT YOU HAVE TO SAY ABOUT USR, LEAVE IT ALONE. No, Metroid, because it's wrong. It's not that it's used too much, it's that it's used almost constantly in the wrong place: a proc. It has no place there. If it wasn't responsible for this bug then it will just cause others that are even harder to track down. And we don't need to see the rest of your code to know that. What I really don't get is why you're so adamant about doing things the wrong way, to the point of strongly ruling out the most likely solution to 95% of BYOND bugs. You posted a snotty "don't reply just to say not to use usr" message originally, and now that you've been told just that you've practically gone into a rage. Calm down! I'll deal with the "bugs" when I get em, if i dont, then it dont matter anyway. Bugs matter, whether you deal with them or not, and it's just plain stupid not to fix an obvious problem in advance but wait for it to bite you in the butt later on. Laziness isn't much of an excuse. Deliberately sticking with a bad practice is even worse. And attacking people who tell you the obvious way to fix most of your problems is completely out of line. Now, just delete this fourm cause its completely useless now. I think you mean thread, not forum. The forum itself is useless to you, anyway, while you continue to scream at anyone who tries to help you and totally ignore their advice. This thread however will remain a good example of how not to ask for help, and how not to fix obvious bugs. Don't count on anyone helping you in the future if this attitude is the best you can do. We try to help the people who are actually willing to fix their mistakes, let alone be polite to the people who are helping them. The rudeness you've fired off in this thread is uncalled for. Lummox JR | |
Metroid wrote:
I cant use src if u did look at my other code when i posted it. Src is used for the monster. But usr is still wrong regardless. Remember, I had trouble looking at your code because you never closed your HTML tags or put it in <DM> tags, which makes reading it a witch. The correct way to handle these situations, when src is one mob and you want to work with another mob, is to pass the other mob as an argument to the proc (as Jon88 already suggested):
proc/Run(mob/M)
So I cant use usr. Thats how i know u said to start over my battle code cause if i cant use usr or src cause thats my monster, than i have to revise the WHOLE code. I still never said start over; stop putting words in my mouth. Part of the confusion involved was that you didn't in fact make your code clear enough to analyze properly. If you'd said in the first place that src was the monster and usr a player, then we could have quickly told you the correct way to change it. Since it was too difficult for us to wade through your code will all the blue text all over the place, instead we offered the simplest and most obvious solution: Get rid of usr, since it doesn't belong in a proc. If you wanted to know how to get rid of usr and still keep the proc mostly intact, all you had to do was ask. It's really an easy fix. The way to fix it is very easy: Add an argument to the proc, change the way you call it, and change all your usr references to M. (Similarly, things like view() that default to view(usr) should be changed to view(M), and so on.) And you know what? dont reply to this, cause i dont care anymore, I dont know y i ever thought of coding in the first place. Its not like anyone will like the stuff a loser like me can make, it wont be worth it. You can make a good game if you apply yourself. Just stop beating up on yourself, and especially stop beating up on the people who want to help you. No one's calling you a loser. I can see that you're frustrated, but you're frustrated because you're not willing to listen to what people tell you and will therefore never be able to work through problems like this on your own. Lummox JR | |
proc/Run(mob/M)
So. I'm listening to u. And it dont work. the battle freezes the second i encounter a monster | |
That freeze means you have another bug in your code somewhere. Probably a very long loop or something that keeps calling itself.
| |
If all you did was change the mob/M thing, you've got some thinking to do. Perhaps if you wanted us to find the porblem, you could POST the code thats troubling you.
| |
Metroid wrote:
proc/Run(mob/M)
Then M is the correct thing to use, not usr. When you call Run(), you call it with Run(themob) instead of just as Run(). You're missing the big picture here: By making the change, you've taken a step in the right direction--one you would eventually have to take anyway. If another bug has been exposed, that's all the more opporunity to move in the right direction. For one thing, you can apply the same kind of change to other procs. What does your Run() proc look like after the change, and the one that calls it? Lummox JR | |
Here: Dont yell at me or complain if i did something wrong.
mob proc Battle(mob/M) M.lib = 1 M.battle = 1 if(M.defend == 1) M.defense /= 2 M.defend = 0 switch(alert("[src] encountered! Command?",,"Commence Battle","Defend","Run")) if("Commence Battle") CommencedBattle() if("Defend") M.defense *= 2 M.defend = 1 NPCDeathCheck() if("Run") Run() That calls it Heres the Run() proc Run(mob/M) chancetorun = M.agility - src.agility + rand(-20,20) if(M.diseased == 1) M << "<font color = blue>You are too weak to run!" Battle() if(chancetorun >> 0) M << "<font color = blue>You start to flee..." sleep(10) M << "<font color = blue>You successfully run away!" M.islocked = 0 src.islocked = 0 M.lib = 0 M.battle = 0 if(M.attup >> 0) attd = M.attack / M.attup if(M.defup >> 0) defd = M.defense / M.defup if(M.lukup >> 0) lukd = M.luck / M.lukup if(M.aglup >> 0) agld = M.agility / M.aglup if(M.intup >> 0) intd = M.intelligence / M.intup if(M.attackdoubled == 1) M.attackdoubled = 0 M.attack -= attd if(M.defensedoubled == 1) M.defensedoubled = 0 M.defense -= defd if(M.intelligencedoubled == 1) M.intelligencedoubled = 0 M.intelligence -= intd if(M.luckdoubled == 1) M.luckdoubled = 0 M.luck -= lukd if(M.agilitydoubled == 1) M.agilitydoubled = 0 M.agility -= agld else M << "<font color = blue>You start to flee..." sleep(10) M << "<font color = blue>The enemy cuts off your escape route!" NPCDeathCheck() | |
Duh! Yes it's a problem, and yes you have to fix it. Even if it wasn't causing any of your troubles now, it'd be crucial to change it so you wouldn't have any later.
But it's more crucial at this point that you close your HTML tags, and put <DM> tags around your code.
Lummox JR