ID:158384
 
I need to confirm whether an item is in the usr's contents before the person uses is. How would i make the code for it? At first i tried this, and feel free to laugh.
        Click()
if(list.Find(src,usr.contents))
var/people = list()
usr<<"Scan Results:"
usr<<"-------------------------------------"
for(var/mob/player/M in oview(20))
people += M
// usr<<"[M] Level: [M.level], [src.class] Direction: <font color=green>[[dir2text(get_dir(usr,M))]]</font color> PL: [ac(M.powerlevel)]"
if(!people)
usr<<"<font color = green>Theres nobody around you"
usr<<"-------------------------------------"

I'd just like to know how to check if the Scouter is in the usr's contents.
Cyberlord34 wrote:
I need to confirm whether an item is in the usr's contents before the person uses is. How would i make the code for it? At first i tried this, and feel free to laugh.
>       Click()
> if(list.Find(src,usr.contents))
> var/people = list()
> usr<<"Scan Results:"
> usr<<"-------------------------------------"
> for(var/mob/player/M in oview(20))
> people += M
> // usr<<"[M] Level: [M.level], [src.class] Direction: <font color=green>[[dir2text(get_dir(usr,M))]]</font color> PL: [ac(M.powerlevel)]"
> if(!people)
> usr<<"<font color = green>Theres nobody around you"
> usr<<"-------------------------------------"
>

I'd just like to know how to check if the Scouter is in the usr's contents.


if(usr.contents.Find(src))

You were close though. :) 'list' should be replaced with the actual list you want to use find on. I.E:

var/list/ListyList
if(ListyList.Find("stuff")) world<<"STUFF"
In response to AJX
AJX wrote:
if(usr.contents.Find(src))

You were close though. :) 'list' should be replaced with the actual list you want to use find on. I.E:

var/list/ListyList
if(ListyList.Find("stuff")) world<<"STUFF"

Hah, thanks. I thought it might be something around there. I put list.Find because i was researching the Find proc with F1. it said if(list.Find), i guess it meant the actual list, hah.
In response to Cyberlord34
A tip: if you don't want to know the actual position of the item in the list, then you can use the in operator if you just want to test whether something is in a list (which is true in your case). Also, you can replace usr.contents with just usr, since contents is a special list that is implied when you specify just usr.

if(src in usr)
...
In response to Unknown Person
Unknown Person wrote:
A tip: if you don't want to know the actual position of the item in the list, then you can use the in operator if you just want to test whether something is in a list (which is true in your case). Also, you can replace usr.contents with just usr, since contents is a special list that is implied when you specify just usr.

> if(src in usr)
> ...
>


Ahh yes, i used to always use in, i can't believe i forgot about it.
In response to Unknown Person
Unknown Person wrote:
A tip: if you don't want to know the actual position of the item in the list, then you can use the in operator if you just want to test whether something is in a list (which is true in your case). Also, you can replace usr.contents with just usr, since contents is a special list that is implied when you specify just usr.

Other tip: If you are specifically trying to find something a list that you know is a list and will always be a list (not something dynamic that may require the added functionality of 'in') you should whenever possible use List.Find(), as it is considerably faster than using X in List.
In response to AJX
AJX wrote:
Unknown Person wrote:
A tip: if you don't want to know the actual position of the item in the list, then you can use the in operator if you just want to test whether something is in a list (which is true in your case). Also, you can replace usr.contents with just usr, since contents is a special list that is implied when you specify just usr.

Other tip: If you are specifically trying to find something a list that you know is a list and will always be a list (not something dynamic that may require the added functionality of 'in') you should whenever possible use List.Find(), as it is considerably faster than using X in List.

Other tip: when a search routine is called maybe a couple times a minute at most, and it being performed on a list of about 50 elements at most, worrying about how fast it runs is really quite silly.
In response to Garthor
Garthor wrote:
Other tip: when a search routine is called maybe a couple times a minute at most, and it being performed on a list of about 50 elements at most, worrying about how fast it runs is really quite silly.

This is a point I strongly disagree with.

1: I do *NOT* believe you should go around optimizing code that does not need it.

2: I do believe that in practice and when teaching others you should always encourage the use of the proper tools for the job.

This situation isn't one where it requires extra work to do it the most specific way.

In my personal opinion you should always use the most specific set of operations that you can apply to a situation. It is common sense that when you have the choice between hammering a nail with a sledge hammer or a normal hammer, you would use the normal hammer. Sure, the sledge hammer can be used in far more situations than what a normal hammer can, and the sledge hammer can accomplish this job just fine, but it isn't the easiest way to do it.

(Bear in mind when I say 'easiest' I refer to easiest for the computer, not for you. Though in this situation there is no difference in difficulty for you between these two methods.)

Eventually, even if your computer is a huge beastly hulk of a man, using a sledge hammer instead of a normal hammer will tire him out.


Also, I don't believe I said anywhere 'in this situation it is absolutely critical that you use List.Find() instead of X in List.' I actually said, if this situation applies, you should use the more efficient choice, unless of course you are intending to waste resources.

It is a very poor programming practice to use something inefficient just because it wont make 'that big' of a difference. Especially in a situation as simple as this, where the difference in work on the programmers end is literally no different.