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!
ID:164803
Apr 13 2007, 6:15 am
|
|
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> |
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.