ID:262561
 
Code:
        DblClick()
..()
var/lol
var/torp = locate(/obj/items/torpart1) in usr.client.screen
for(var/obj/items/O in usr.client.screen)if(O.equip==usr.hand)lol=O
if(istype(lol,/obj/items/welder)&& torp)
if(lol:fuel < 1)
usr<<"You don't have enough fuel to weld the torpedo parts together."
return
else
lol:fuel -= 5
usr<<"Please don't move while you're welding the torpedo parts together."
var/locater = usr.loc
sleep(30)
if(usr.loc == locater)
new /obj/items/torpart2(src.loc)
del(src)
del(torp)


Problem description:
Everything else works except del(torp), the other torpedo part is deleted, and the new one comes into place. I don't know why it doesn't delete it.

1.) You should use a period when accessing object's vars. I know for a fact that you will get compiler errors right now, so go ahead and fix those real fast and post back.
In response to Audeuro
The : operator works right here, it's accessing something not directly being stated about in this segment. I said "everything works" so people won't go on about my use of the : operator.
In response to Justin Knight
Justin Knight wrote:
Um dude I would have definitely posted errors if I got them.

No, you wouldn't get compiler errors with that code. ":" is like a shortcut as well as a bad habit. Using the colon, you will get runtime errors rather than compiler errors if you made a mistake. Colons don't have typechecking, so it doesn't even care about it at compile time, but come runtime, when dreamseeker finds the error, it'll throw you a runtime.
In response to Audeuro
I already edited the post, check back. There are no runtime errors, the : operator works fine.
In response to Justin Knight
You didn't fix it. It's still has the colons for accessing vars. Try this:

        DblClick()
..()
var/lol
var/torp = locate(/obj/items/torpart1) in usr.client.screen
for(var/obj/items/O in usr.client.screen)if(O.equip==usr.hand)lol=O
if(istype(lol,/obj/items/welder)&& torp)
if(lol.fuel < 1)
usr<<"You don't have enough fuel to weld the torpedo parts together."
return
else
lol.fuel -= 5
usr<<"Please don't move while you're welding the torpedo parts together."
var/locater = usr.loc
sleep(30)
if(usr.loc == locater)
new /obj/items/torpart2(src.loc)
del(src)
del(torp)


You WILL get errors, probably having to do with fuel not belonging to "lol"
In response to Audeuro
Dude, help me with my problem. Not with my use of the : operator. Everyone harasses me with my use of the : operator. THAT IS NOT MY PROBLEM. The problem is that it won't delete the torpart1 in the person's inventory. Inventory is in a HUD, so that's why is locates it on usr.client.screen.
In response to Justin Knight
Justin Knight wrote:
Dude, help me with my problem. Not with my use of the : operator. Everyone harasses me with my use of the : operator. THAT IS NOT MY PROBLEM. The problem is that it won't delete the torpart1 in the person's inventory. Inventory is in a HUD, so that's why is locates it on usr.client.screen.

Why should I help you if you aren't going to listen? I've told you ( I think ), I believe your problem will become clear if you replace your colons with your periods.
In response to Audeuro
No you don't understand the problem if you're telling me to do that. del(torp) has nothing to do with taking away fuel from the welder.
In response to Justin Knight
No one knows what's wrong with del(torp)?
In response to Justin Knight
delete it BEFORE you delete src. Since it's src's proc, once you delete src the proc stops.
In response to Audeuro
        DblClick()
..()
var/lol
var/torp = locate(/obj/items/torpart1) in usr.client.screen
for(var/obj/items/O in usr.client.screen)if(O.equip==usr.hand)lol=O
if(istype(lol,/obj/items/welder)&& torp)
if(lol:fuel < 1)
usr<<"You don't have enough fuel to weld the torpedo parts together."
return
else
lol:fuel -= 5
usr<<"Please don't move while you're welding the torpedo parts together."
var/locater = usr.loc
sleep(30)
if(usr.loc == locater)
new /obj/items/torpart2(src.loc)
var/a=src
src=null
del(a)
del(torp)

That should work.
In response to DarkCampainger
Thanks a lot Dark! I knew it was something stupid like that, it was really pissing me off, you helped me out a lot. Ol'Yeller, I don't really understand what you did there, and I don't think it will work if you delete src first.
In response to Justin Knight
Justin Knight wrote:
No you don't understand the problem if you're telling me to do that. del(torp) has nothing to do with taking away fuel from the welder.

He's telling you to fix the more obvious problems before working on the less obvious ones. How in the world do you expect to debug code that's bandaged together with coat hangars and tape?

Never ever use the : operator in the way you're using it. Change that to . right away, and fix your var definition.

Clearly var/lol is wrong. That should be var/obj/items/welder/lol instead. By giving your var the right type in the first place, you can use the . operator which will move potential runtime errors to compile-time where you can deal with them more easily. It also lets you use the short form of istype(), which would be istype(lol).

Lummox JR
In response to Ol' Yeller
Augh. Crappy solution, that. You failed to fix the : problem and you picked the most convoluted way to fix the last few lines. Why not just put del(src) last instead of setting src=null? Don't screw with src if you don't need to.

Lummox JR
In response to Lummox JR
Yes, I understand what you're saying, Lummox. Although, after using DarkCampaigner's advice, the coding worked fine.

I know that : can cause runtime errors if you use it in the wrong fashion, but in this case it works. As a matter of fact, I copied related stuff from other code segments in the .dme that I knew worked and changed the item names around.

I totally appreciate you guys trying to help, but I just think that if the code already works, why go out of my way to fix it? It's an example of "If it's not broken, don't fix it."

In response to Justin Knight
Justin Knight wrote:
Yes, I understand what you're saying, Lummox. Although, after using DarkCampaigner's advice, the coding worked fine.

I know that : can cause runtime errors if you use it in the wrong fashion, but in this case it works. As a matter of fact, I copied related stuff from other code segments in the .dme that I knew worked and changed the item names around.

Nope, you don't understand what I'm saying at all. The way you're using the : operator is the wrong fashion, because in every place you've used it you could've simply set up your vars with the correct type from the beginning.

The : operator should only be used when you have definite types for your vars, only the types are disparate and access the same var or proc. Now this is basically a minor design flaw, but it's livable. Changing this sort of thing is something best left for later in a project. (This sort of situation is analagous to putting usr in a proc or using goto. The sorts of situations where this is actually a good idea are so complex as to defy example.)

The way you're using the : operator is as a crutch, substituting the wrong operator in place of giving your vars types or type-casting. This is exactly the sort of "wrong fashion" that causes those runtime errors.

I totally appreciate you guys trying to help, but I just think that if the code already works, why go out of my way to fix it? It's an example of "If it's not broken, don't fix it."

One thing you need to grasp about programming is that code that works fine today may not work fine tomorrow unless it's robust. Typically one bug will break brittle parts of the code elsewhere, causing a whole cascade of small errors which may be difficult to detect. Brittle code is something you should avoid at great cost, because robust code will make debugging easier and allow fewer small bugs to become large ones.

The way you're misusing the : operator is extremely avoidable, and what's more, extremely easy to fix. It's worth the negligible effort to do so.

Lummox JR
In response to Lummox JR
Lummox, for crying out loud, the problem was fixed. For one, you're posting on a topic in "Code Problems" when this more belongs in "Design Philosphy." Your giving me a speech about the : operator when I don't need it.

Let's try to get things straight:

1) I started coding about 3 weeks ago.

2) I started coding because my coder wasn't producing any kind of code output. We were expanding on "Deadly Waters," fixing bugs, adding new features, etc.

3) I really was just supposed to be the iconist for the game, but I wound up owning the game after a while.

4) I am editing Officer Falcon's and Phoenix Man's code from a while back. If you want someone to complain to about the : operator, complain to Officer Falcon. His code is strewn with "misuse of the : operator." I talked to him about it, he basically said he used it because it was the lazy way out.

5.) Negligible effort to do so would involve me changing probably 100+ instances of ':' in the code to '.', many errors would arise, I expect. Remember, the : operator works in 95% of the cases it's used in the code.

6.) I definitely understand that robust coding is the best way to go, but i'm no coder like you. I'm really just doing smaller things, new items, bug fixes, etc. The stuff I coded works, and i've been trying to use the . operator more, because it will bring out errors earlier.
In response to Justin Knight
Justin Knight wrote:
Lummox, for crying out loud, the problem was fixed. For one, you're posting on a topic in "Code Problems" when this more belongs in "Design Philosphy." Your giving me a speech about the : operator when I don't need it.

But you do need it. This blind insistence on continuing to do things wrong will get you nowhere. And operator abuse isn't a design philosophy issue; it's a code issue.

Let's try to get things straight:

1) I started coding about 3 weeks ago.

Fair enough. But learning as you go along is always a good thing. You've learned something new with the : operator. Now's the best time to put it into practice and learn how to do without it.

4) I am editing Officer Falcon's and Phoenix Man's code from a while back. If you want someone to complain to about the : operator, complain to Officer Falcon. His code is strewn with "misuse of the : operator." I talked to him about it, he basically said he used it because it was the lazy way out.

Which ought to be a clue that it was a bad idea. Now that you know, it's best to fix it.

5.) Negligible effort to do so would involve me changing probably 100+ instances of ':' in the code to '.', many errors would arise, I expect. Remember, the : operator works in 95% of the cases it's used in the code.

100+ instances is truly nothing. All you have to do is change the type of each var you're using it with. That's hardly a significant amount of effort.

6.) I definitely understand that robust coding is the best way to go, but i'm no coder like you. I'm really just doing smaller things, new items, bug fixes, etc. The stuff I coded works, and i've been trying to use the . operator more, because it will bring out errors earlier.

You should use the . operator exclusively, so that you learn how to avoid relying on the : operator. Fixing the existing cases of : will also be an invaluable learning tool to that end.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
100+ instances is truly nothing. All you have to do is change the type of each var you're using it with. That's hardly a significant amount of effort.

Could you give me an example of how to change the type of each var you're using it with?
Page: 1 2