Wanabe wrote:

proc name: Wander (/mob/Monsters/proc/Wander)
source file: Ai_Demo.dm,38
usr: the two (/mob/Monsters/two)
src: the two (/mob/Monsters/two)
call stack:
the two (/mob/Monsters/two): Wander()
the two (/mob/Monsters/two): New(the turf (3,10,1) (/turf))a

i get this error when it trys and read line 38 (Yes im making a demo for people)

You didn't actually include the error message; you just gave us the call stack.

if(M in oview(20) && !M.leader)//line 38

Two problems here: First, you need a set of parentheses around "M in oview(20)", because for whatever reason the "in" operator has an extremely low precedence.

The other problem is that that absolutely has to be oview(20,src), because usr (the default point of reference) has no place in an AI proc--or pretty much any proc.

var/list/l = new()//make a new list
for(var/mob/M in view(20))//check mobs in oview

That should be view(20,src).

l+=M//add it to list
if(M.leader)//if allready a leader
l-=M//minus it
var/mob/k = pick(l)//pick a var called k
k.leader=1//make k's leader one

This loop doesn't make much sense. The k section really shouldn't be in that loop at any rate, and it seems you could save some effort by doing the if() check before ever adding M to the list. Likewise since this is AI, you should also be checking among monster mobs, unless the monster is supposed to follow players too.

ps: Can i some how only make it check if theres a 'leader' in the oview and if there is create one,
if you help me its not only me youll be helping :-)

To check if there's a leader in view, just break out of the loop when a suitable M is found. If M is null after the loop, it means the loop finished without finding a leader, so then you can assign one.

I hate to discourage you, but this should not be a demo. These are the basics that you're learning yourself, so you're not in a position to teach anybody yet. The point of a demo or tutorial (technically this is more of a tutorial, since a demo is more of a proof-of-concept) is to explain how to do something to someone who doesn't know. If you don't know the material well enough (backwards and forwards) to teach it, then it's just the blind leading the blind. Don't make a demo or tutorial right now.

What you should do instead is continue to develop the code, and keep commenting it generously and making it as adaptable and user-friendly as possible while still suiting your purposes. Keep working on it, and eventually when you have a much, much better grasp on BYOND itself (not just this particular code), you'll know when it's time to release a tutorial.

And in any event you should ditch the Nadrew-style commenting. Put at least a space or two between your code and the // comment. It helps whenever possible too to get the comments to line up on tab boundaries, but that's more of a guideline.

Lummox JR

Wanabe wrote:

lol "Nadrew style commenting?" I comment like that cause its easyier to read (Unless the programming on that line is aultra aultra long)

It's not at all easier to read a comment that's not separated from the code just before it; you're mistaken. For readability purposes, it is absolutely crucial to add spaces or preferably tabs. (Nor is this a matter of opinion; it's like saying it's easier to read text without any spaces between words at all. You may be able to do it well, and for reasons of your own you might like it better, but it's not easier. Anything that more clearly shows where one thing ends and another begins makes reading easier. Preference does not equal ease.)

Lummox JR