ID:150176
 
This is so erksome, I could scream. An example is the get_step() proc. The reference clearly states that this proc returns a location. It does not. From what I can gather, it returns a turf. Another example, istype() has this for an exmple:

var/mob/M
M = new/mob/ugly/duckling()
if istype(M,/mob/ugly) //<-- this doesn't work
usr << "M is ugly!"

not to mention that if I want to see if duckling is a certain type, I have to ask:

if(istype(M,/mob/ugy/duckling))

just asking if it's /mob/ugly or /mob/ugly/ returns false. and if there were 20 ugly mobs, and I wanted to see if a mob is ugly, I would have to check that mob against each and every ugly mob to see if it matches. I know, I've had to do it. luckily, there were only 9 objects to compare the object to...

I'm sure there are more examples, but I'm not about to spend the next 3 hours digging them up. If you could work on this after the your through with 307, I would be very pleased, as I turn to the reference for guidence all the time. Newbies are encouraged to refer to the reference before posting, and it pains me to see such errors in code and information.

If someone has a solution to the two examples above that I have missed, I am in desperate need of them. Perticularly the get_step proc. I need what the reference says it provides, the location of the mob's destination.

Thank you,

~Xooxer

Xooxer wrote:
An example is the get_step() proc. The reference clearly states that this proc returns a location. It does not. From what I can gather, it returns a turf.

That's right. A location is a turf. A turf is a location. What exactly do you mean by location if you don't want a turf? If you want the x,y,z coordinates, just do something like this:
var/turf/t = get_step(usr, SOUTH)
usr << "step is at ([t.x], [t.y], [t.z])"


var/mob/M
M = new/mob/ugly/duckling()
if istype(M,/mob/ugly) //<-- this doesn't work
usr << "M is ugly!"

This works for me.
mob
verb/test()
var/mob/M
M = new/mob/ugly/duckling()
if (istype(M,/mob/ugly)) //<-- this does work
usr << "M is ugly!"
if (istype(M,/mob/ugly/duckling))
usr << "M is an ugly duckling!"
del(M)

ugly
duckling
In response to Air Mapster
what I mean by location is well, I didn't want to do this, but here is my code:

area/library
antiwarp = 1 //no warping out of the library
Exit(mob/M as mob)
var/D = get_step(usr,usr.dir)
var/list/DESTINATION = new(D) //<-- I need a list of D's contents, namely the area D is...
var/lib_area = 0
var/libitems = 0
for(var/E in DESTINATION)
if(istype(E,/area/librarian))
lib_area = 1
for(var/obj/Q as obj in usr.contents)
if(Q:library)
libitems ++
if(lib_area != 1 && libitems > 0) usr << " The librarian scorns, 'And where do you think your going? You must check library items out before they can leave the library!'"
return 0
else
return ..()

area/librarian


it's supposed to prevent the mob from exiting the area if he has library books in his possesion, unless he exits into the librarian area.
In response to Air Mapster
Air Mapster wrote:

This works for me.
> mob
> verb/test()
> var/mob/M
> M = new/mob/ugly/duckling()
> if (istype(M,/mob/ugly)) //<-- this does work
> usr << "M is ugly!"
> if (istype(M,/mob/ugly/duckling))
> usr << "M is an ugly duckling!"
> del(M)
>
> ugly
> duckling
>


Yes, that works, becuase you modified the code. Namely, you put the istype() proc in parentheses, as it should have been. The parent type thing does not work for me, again, here is my code...

mob/proc/donatestuff(obj/O as obj in usr, mob/npcs/librarian/L as mob in oview())
set name = "Donate an Item to the Library"
set category = "Librarian"
if(L.shelving)
usr << "The librarian is busy right now, please wait for her to finish."
else
if(O.suffix != "\[library's]")
if(istype(O,/obj/message/old_book) || istype(O,/obj/message/journal) || istype(O,/obj/message/silver_bound_book) || istype(O,/obj/message/fur_bound_book) || istype(O,/obj/message/jewel_encrusted_book) || istype(O,/obj/message/scroll) || istype(O,/obj/message/pamphlet) || istype(O,/obj/game/card_game_board) || istype(O,/obj/game/dice_board))
if(!istype(L,/mob/npcs/librarian))
usr << "You can only give library donations to the librarian!"
else
O.Move(L)
O.suffix = "\[library's]"
O:library = 1
usr << " The librarian says warmly, 'Thank you for your generous donation. It's always a pleasure to know that there are people that still value sharing!'"
else
usr << " The librarian says coldly, 'The library has no use for such things.'"
return 0
else
usr << " The librarian says, 'Nice try, but you cannot donate a library item to the library. You may, on the other hand, return it anytime.'"
return 0

I had to do it like that, becuase if I checked to see if(istype(O,/obj/message)) or even if(istype(O,/obj/message/)) it always returned false.
In response to Xooxer
Ah, I see what you're doing. get_step() always returns a turf because it inherently only applies to spaces (or locations) on the maps, which must be turfs. However, you want to check the area that the mob may be going into. To do that, use the resulting turf's loc var, which is the area it's in. Atoms may have non-turf locations, but get_step() only returns locations that are turfs.

I'd modify your code as follows:
area/library
antiwarp = 1 //no warping out of the library
Exit(mob/M as mob)
var/turf/D = get_step(usr,usr.dir)
var/libitems = 0
for(var/obj/Q as obj in usr.contents)
if(Q:library)
libitems ++
if(!istype(D.loc, /area/librarian) && libitems > 0)
usr << " The librarian scorns, ...(etc)"
return 0
else
return ..()

This is of course untested, but I think it should work.
In response to Xooxer
Xooxer wrote:
Yes, that works, becuase you modified the code. Namely, you put the istype() proc in parentheses, as it should have been. The parent type thing does not work for me, again, here is my code...

Right, I had to add the parentheses so that it would compile. But that doesn't change the execution of the code at all. Honestly, I'm not sure why your code isn't working if what you posted does work. Checking istype() on the parent type should always return true if the child type does as well, just as in the example I tested. I'd have to see the exact code you tried with if (istype(O, /obj/message)) because that ought to work.

The only thing I can think of is that if O was some other type, but I'll bet you already tested that thoroughly. I'd put in a debugging statement that prints out O.type to be absolutely sure. It's also possible that you found some obscure BYOND bug, but I'd test it some more. I've had numerous times where I was convinced I'd found a BYOND bug, only to come back to my code later and discover it was my fault after all.

Anyone else see something I didn't?
In response to Air Mapster
Air Mapster wrote:
Anyone else see something I didn't?

No but as someone who uses the reference many times a day, I rarely find problems with it.

If you find a problem, mention it in Bugs and it will get fixed. But I don't think there is some need for a general sweep through the reference.
In response to Air Mapster
Yes! It works exactly as it should now! Thank you Air Mapster! I've been banging my head against this code block for a day and a half! Sorry if I sounded a bit harsh earlier, frustration can do that to a person...heh

~X :-)
In response to Air Mapster
I'll run some extensive testing, adding in ouputs of the variables and such. It may have been a simple typo, but I won't know until I check it all out... Yes, the code I posted works as it is intended, although it is unsightly, and very wasteful, IMO...

~X

[EDIT] heh, just changed it to check the parent type... it works, guess it was a typo... sorry for the hassle...
In response to Air Mapster
Air Mapster wrote:

Right, I had to add the parentheses so that it would compile.

I'm guessing at least part of the point would be that examples given in the reference should not have syntax errors in them.

flick()
In response to Xooxer
Xooxer wrote:
I'll run some extensive testing, adding in ouputs of the variables and such. It may have been a simple typo, but I won't know until I check it all out... Yes, the code I posted works as it is intended, although it is unsightly, and very wasteful, IMO...

~X

[EDIT] heh, just changed it to check the parent type... it works, guess it was a typo... sorry for the hassle...

Actually, I'm pretty sure that this would not have worked a few versions ago. Wasn't this a recent fix in BYOND?
In response to Flick
Flick wrote:
Air Mapster wrote:

Right, I had to add the parentheses so that it would compile.

I'm guessing at least part of the point would be that examples given in the reference should not have syntax errors in them.

That's true, and like any other bug should be reported and fixed.

But I didn't want to let a trashing of the reference go by without me mentioning that I find the reference an excellent resource that is quite useful and I haven't found many problems with it.
In response to Deadron
Deadron wrote:

That's true, and like any other bug should be reported and fixed.

But I didn't want to let a trashing of the reference go by without me mentioning that I find the reference an excellent resource that is quite useful and I haven't found many problems with it.

Agreed! Did not mean to imply otherwise.

flick()

In response to Flick
Well, as a newb, (or semi-newb) I may not fully understand some of the concepts expressed in the reference, but it doesn't help to have errors in it either.

Yes, the refernce is a wealth of knowledge, and it has helped me more than anything else on BYOND. I guess I was just a bit frustrated to see that is is not 100% accurate. I know nothing is perfect, and noone will ever write the perfect reference for DM. (I don't have the blue book....yet, so I can't comment on it)

Newcomers to BYOND are refered to the reference, and they should at least be given error-free examples....

I'm not harping on Dan and Tom, becuase I know they are working their fingers to the marrow. I appologise if I seem a bit ungrateful, this is not the case. I'm just trying to help make BYOND as great as it can be, for newbies and oldbies alike...

~X
In response to Xooxer
Xooxer wrote:
I'm not harping on Dan and Tom, becuase I know they are working their fingers to the marrow. I appologise if I seem a bit ungrateful, this is not the case. I'm just trying to help make BYOND as great as it can be, for newbies and oldbies alike...

No problem. The best way to help is to register a bug (in the Bug forum) without too much heat attached. A bug is a bug, they will always exist, and Dantom will always be happy to get rid of them.