ID:146402
 
Code:
obj/planet
DblClick(O)
if(src:owner=="nobody")
if(usr:settlers>0)
usr:settlers-=1
usr.z=src:Z1
usr:planets+=1
src.owner=usr
usr<<'bom.wav'
usr<<"You settled [src]."
src.name=input("What name do you want to give your new planet?","name?") as text
else
usr<<"You can't settle more than one planet."
else if(src:owner==usr)
usr.z=src:Z1
src.owner=usr
usr<<'bom.wav'
else
if(usr:selected)
walk_to(usr:selected,src,1,20)
if(usr:selected in oview(1))
var/damage
var/damage2
var/watchers=list(usr,src:owner)
start
sleep(10)
damage=0
damage2=0
for(var/obj/ship/S in usr:selected:ships)
damage+=S:str
watchers<<"[usr]'s fleet attacks [src] for [damage] damage."
var/target
var/damager
hurt
sleep(10)
target=null
for(var/obj/ship/S in src.fleet)
if(S:HP>0)
target=S
goto goon
goon
if(!target)
usr<<"You conquered [src]!"
src:owner=usr
for(var/obj/building/B in world)
if(B:z==src.Z1)
B:owner=usr
src:owner:planets-=1
for(var/obj/planet/P in world)
if(P:z!=3)
if(P:owner)
if(P:owner!=usr)
if(P:owner!="nobody")
return 0
world<<"<font color=blue size=+3> [usr] won!"
world.Reboot()

return 0
damager=damage
damage-=target:HP
target:HP-=damager
if(target:HP<=0)
if(damage>0)
goto hurt
for(var/obj/ship/S in src.fleet)
damage2+=S:str
watchers<<"[usr]'s fleet attacks [src] for [damage2] damage."
usr:selected:damage1(damage2)

if(!usr:selected)
return
damage=0
goto start


Problem description:It changes the HP of all the ships in src.fleet, not only of the target.

You're abusing the : operator. Don't do that. You shouldn't use this one unless you really know what you're doing and are willing to convert a compiler error to a runtime error. Furthermore, using src:var is absolutely ridiculous and you should never do that ever. It should be src.var or just the var name itself.

You also need to stop using goto. Its only place is in very very complex loops, which you don't have here. Instead you could use while() loops, and commands like break and continue, and clean the whole thing up.

Until those items are cleaned up you have little hope of properly debugging your problem.

And why set owner to "nobody" instead of just null, which is vastly more sensible?

Lummox JR
In response to Lummox JR
I expected an answer and not the things I do wrong...
Anyway, what's wrong about the :? Everybody says i should only use it, when I need it, but noone says why...
Oh and it would look stupid, if it tells you, the owner is " "
In response to CIB
if(!M.owner)
src<<"The owner is no one"
else
src<<"The owner is [M.owner[."


Yeah I don't even know why but it's become like an evil trend to use : I don't use it myself, and probablly never will.
In response to CIB
CIB wrote:
I expected an answer and not the things I do wrong...

If you want to debug your problem, you need to start with the obvious problems first so they're not in the way.

Anyway, what's wrong about the :? Everybody says i should only use it, when I need it, but noone says why...

Actually they're wrong if they tell you that. You shouldn't be using it at all. The : operator is bad mojo in the hands of a newbie, and should only be used by an intermediate programmer who knows when it's better to use it--or rather, who knows when not to use it.

You definitely should not be using src:var, because there not only is the : bad, but you don't even "need" it in the first place.

Oh and it would look stupid, if it tells you, the owner is " "

That's why you use something like "The owner is [owner ? (owner) : "nobody"]." Or you can put this in an if() statement that says something nicer like "This has no owner."

Lummox JR
In response to Lummox JR
I don't need it? You confuse me... If I'd write usr.selected it would give an error, because not all usr have the selected var. What should I write then?
OK, slowly I understand you(my english is not very good...). Could you tell me please, when to use it and when not?
In response to CIB
CIB wrote:
Oh and it would look stupid, if it tells you, the owner is " "
obj
var/owner
Click()
usr<<"[src]'s owner is: [owner?owner:"nobody"]"


There, it won't display the owner as " ". :P
In response to CIB
CIB wrote:
I don't need it? You confuse me... If I'd write usr.selected it would give an error, because not all usr have the selected var. What should I write then?

You should either be type-casting usr to a var with a more specific type, or you should make the selected var common to all mobs. The latter is probably a better choice.

Or, you could make selected a client var, and use usr.client.selected. Problem is then you have to be sure at each step (at the beginning, and later if any sleeping is done) that the client is valid.

OK, slowly I understand you(my english is not very good...). Could you tell me please, when to use it and when not?

If you don't know when not to use the : operator, you shouldn't be using it at all.

Lummox JR
In response to Ol' Yeller
Ol' Yeller wrote:
CIB wrote:
Oh and it would look stupid, if it tells you, the owner is " "
obj
> var/owner
> Click()
> usr<<"[src]'s owner is: [owner?owner:"nobody"]"

There, it won't display the owner as " ". :P

It also won't compile right because you need parentheses around the owner var in the middle. (Otherwise DM thinks the : operator is trying to access a var or proc.) Another way to do this is to use owner||"nobody" instead.

Lummox JR
In response to Lummox JR
Tell me when not to use it then... or give me a demo or something i really want to know.
In response to CIB
CIB wrote:
Tell me when not to use it then... or give me a demo or something i really want to know.

That's easy: When not to use it is always, until you know more about what you're doing. Once you've lived with working around it for a while, you'll realize the workarounds are much better (and safer) form, and you'll hardly ever have the desire to use the operator. When you do, and there are no easy workarounds, that's usually a signal that you need to change your design.

Lummox JR
In response to Lummox JR
You still didn't tell me what is so bad about the : operator... I mean, if I use usr:var instead of usr.var what does that do?
In response to CIB
CIB wrote:
You still didn't tell me what is so bad about the : operator... I mean, if I use usr:var instead of usr.var what does that do?

you know what? Stop bugging Lummox, but do this:

first start up Dream Maker, hit F1, look the :operator up.
read that text 4 or 5 times.
and if you don't understand after that then come and ask again

O-matic
In response to O-matic
This is the runtime search operator. It is used to access a property of a var that is not explicitly prototyped. If the variable doesn't have the specified variable, a run-time error occurs.

This doesn't help, because it doesn't say there, that and why you shouldn't use it, does it?
In response to CIB
CIB wrote:
This doesn't help, because it doesn't say there, that and why you shouldn't use it, does it?


http://www.byond.com/docs/ref/info.html#/operator/:
read it again , its very clear to me.

Anyway you dont need to to use that operator like lummox said don't use it if you dont know when to use it .


go into the DM-reference and look up the .operator that'll give you enough info for the .operator and compare the : and .operator maybe that'll help.

O-matic
In response to CIB
CIB wrote:
You still didn't tell me what is so bad about the : operator...

Yes, I did. Among other problems, you defer compile-time errors into runtime errors, which are much harder to debug. It also ensures you never have any reason to design properly, which will bite you in the butt later.

I mean, if I use usr:var instead of usr.var what does that do?

The fact that you don't know why the : operator is bad means you shouldn't be using it. It may look self-explanatory as an operator, but it's not something to use lightly.

There are 3 major gotchas of DM programming, which are:

  • usr abuse
  • : abuse
  • goto abuse

    Every one of those items has a use, but they're also vastly abused. Newbies are advised to steer clear of all three; as for usr it should only be included in verbs. These items, if abused, will inevitably lead to code that's buggy and difficult to fix. Besides, they discourage you from learning how to do some important things properly.

    Abusing usr shows that you don't understand how and when to pass more information to a proc. A simple example is DeathCheck(), where Joe Newbie puts in usr as the killer. This proc is supposed to take at least one argument, which is the killer, and should not use usr at all.

    Abusing : shows you don't know how to give your vars the right type, or how to use types in general. This is one of the keys of DM, so glossing this over early on will only screw you up.

    Abusing goto shows you don't know how to use loops at all, which is very very bad. Anyone who does not grasp how to use for(), while(), continue, and break should not go on with their game until they learn.

    The abuse of each of those is a crutch for the ignorant, and keeps them from learning. Just because you don't know a better way to do something doesn't make it right. In your case you were abusing : not only in places where you could somewhat justify it (though good design would make it moot), but also with things like src:var which were just ridiculous.

    Lummox JR
In response to Lummox JR
In Regex, didn't you show a proper use of goto, though? :p
In response to Lummox JR
I think I understand now, and I'm going to learn about these instead of goto things, cause I never used them.
I also replaced all : with . where possible and the src.var with var. Thanks for your advice(I have fixed the actual problem, which I posted already...)
In response to CIB
Perhaps you should read YMIHere's article on type casting. It would help. =)
In response to Ol' Yeller
Ol' Yeller wrote:
In Regex, didn't you show a proper use of goto, though? :p

I wouldn't so much say "proper", inasmuch as there's no elegance to its use, which is almost a given any time you use goto. It's certainly not meant to be a demo, so it doesn't really set out to show how to use goto, either. It does however use loops complex enough to justify it. There is one case where goto could probably be replaced with a labeled loop, although that's a pain in the butt, and there's at least one case where goto allows the same code to be used for multiple purposes.

Where Regex does display elegance and a good way to do something is in datum control. The datum is constructed as a set of linked lists such that if the parent datum is "let go", the others hanging off of it will be deleted.

Lummox JR
Page: 1 2