ID:164803
 
It won't let me choose the three icons when i log in form the start. What did i do wrong?

//This is a test world created by on .


mob
verb
say(msg as text) //what the usr says is passed into "msg" as text
world << "[usr]: [msg]" //the world sees chatroom-like output
icon = 'person.dmi' //make it so all mobs will be created with the person icon
Login()
icon_state = gender //when a player logs in, make their icon's state
..() //the gender of their key. Then call the parent
turf
grass //defines a "grass" prototype, which is a kind of turf...
icon = 'grass.dmi' //and has an icon named 'grass.dmi'. In single quotes!
world //we set one of our world's characteristics:
turf = /turf/grass //its default turf is the grass turf.

mob
icon = 'person.dmi' //makes it so all mobs will be created with the person icon
Login()
icon_state = gender //when a player logs in, make their icon's state
..() //the gender of their key. Then call the parent!
It doesn't let you choose because you are using the gender of your key. When you create an account with BYOND, it asks you your gender. That is what ZBT means when it says "The gender of their key".

If you want to actually have a choice, you will need to use an input or alert. Theres a thread by Lanzo named "Male of Female?" on this very same page that discusses how to do this.
In response to Zagreus
I know about the other thread and i've read it but i want to do it exactly like this guide says before i move on adn do that stuff and the icon dosent even pop up.
In response to Angelex21
Okay. So the icon doesn't show up at all, and that's your problem? Sorry, from the wording of the original post I thought you wanted to be able to choose from three icon states.

Follow these troubleshooting steps:

Open your person.dmi file.

Does it have three states, male, female, and neuter? Note that they are case sensitive and should be all lowercase.

Are they movement states (has an M next to it)? If so, you need to make normal states for them to show up when they are standing still.

Open up each individual state.

Are they pixmaps or movies (just one icon, or a series of icons for animation/directions? If they are movies and multi-directional, you need to have an icon for each direction or else it will appear blank when the player faces certain directions.
In response to Zagreus
wow..... i usually capaltize things and that what set it
off.
All i needed was to uncapatalize them xD
In response to Angelex21
But now i have another problem:
attack(mob/M as mob in oview(1)) //attack a mob within 1 tile of you
usr << "You attack [M]!" //send this message to the usr
oview() << "[usr] attacks [M]!" //send this message to everybody else
var/damage = rand(1,10) //assign a random # to a new variable
world << "[damage] damage!" //tell the damage to the world
M.HP -= damage //take away the damage from M

This part /\ right above this text the M.HP thing it keeps saying there i an error.
In response to Angelex21
What error? Copy it please
In response to Ripiz
Its the M.HP thing
In response to Angelex21
We need to know what the error says.
In response to XzDoG
Yea, I tried this tuts before.. all you get are proc errors ad run time errors.
In response to LilMain
loading Test World.dme
Test World.dm:12:error:M.HP:undefined var

Test World.dmb - 1 error, 0 warnings (double-click on an error to jump to it)
In response to Angelex21
I always forget if this is nessary or not, but I think you need the attack(mob/M ...) line to be attack(var/mob/M).

Also, use the <-dm><-/dm>(Minus the dashes) tags for code.
In response to Angelex21
I assume it's another capitalization thing. Make sure it's not "hp".
In response to LastTroubadour
I finished the tutorial
In response to Danial.Beta
No it isn't. 'var/' is optional in argument definitions, <small>and is ugly IMO</small> so was the general rising in using it come from thinking its needed? It was probably on purpose just to hurt Kaioken's eyes though. <_< >_>
In response to Kaioken
Well, most people use it because logically it makes sense. If you have a variable, it needs to be defined, no? And since BYOND's way of defining a variable normally is var/variable, it is actually kinda odd that verbs and procs don't require it.
In response to Danial.Beta
OK, most people don't use it actually. :P Just lately (well, um, in the past few months I guess?) I've seen people that haven't, start to use it.

There is understandable logic behind the 'var/' being optional.

Danial.Beta wrote:
it is actually kinda odd that verbs and procs don't require it.

Only in arguments, its an arguments thing (Logic below).

Well, most people use it because logically it makes sense. If you have a variable, it needs to be defined, no?

Well, what I assume is the logic behind this is that arguments, both in verbs and procs, don't origin in the actual proc; they come from outside, from somewhere else; omitting 'var/' is like an indication the variable came from somewhere else, rather than being a normal local var on the proc (which it IS of course, technically!). So theoretically you shouldn't have to define those variables because they already are, on the caller procs; again it indicates they already existed before the actual current proc started.

That logic theory aside, as said, using 'var/' in an argument definition simply seems very out-of-place,ugly,clumsy etc to me. But that is more because thats just the way I feel, just because, even disregarding any logic. >_>
In response to Kaioken
But variables come from elsewhere all the time. var/a=b would set a to something that is defined somewhere else. In proc() the variable we be being defined there, and filled in automatically from whatever other source. Either way, that variable is being created there, when the proc is called, not before.

I understand what you are saying, but I think that it is more important to follow the logic that all variables must be defined than having half needing defining and half not. The one exception would be pre-defined variables like client.key.
In response to Danial.Beta
Danial.Beta wrote:
But variables come from elsewhere all the time.

I strictly refer to 'come from outside the current proc, before it is actually started'. Basically arguments only. :D

var/a=b would set a to something that is defined somewhere else.

'b' could be a hardcoded value.
In proc() the variable we be being defined there, and filled in automatically from whatever other source. Either way, that variable is being created there, when the proc is called, not before.


I understand what you are saying, but I think that it is more important to follow the logic that all variables must be defined than having half needing defining and half not.

It is not 'half and half not'; again, the above logic aside, consider this: The only thing you may do inside a proc's parenthesis is define arguments, so this is simply making it easier on you by making the 'var/' unneeded (and it is, as the compiler knows you're defining a var there as again, thats the only thing you may do there).
Also, you know, its not like this compiler feature is in Dream Maker only. Its about all over the place.

<small>We're kinda going offtopic</small>