ID:146786
 
Code:
#include <deadron/characterhandling>
#include <dantom/htmllib>
mob/BaseCamp/FirstTimePlayer
FirstTimePlayer()
alert("Welcome to BYOND Life version 1.0")
alert("Please wait while we transfer you to your home. This will be the hotel until:","A. You subscribe for $3 or","B. You buy a house for $2,000,000 in game dollars.")
if(!subscribe)
houseloc="2,2,2"
else
alert("")
return 1
mob
Login()
..()
usr.loc=locate(houseloc)
Logout()
..()


Problem description:
OK. I have looked through the forums a few times, and it gave me some suggestions, but none of them would fix it. For some reason I keep coming up with a black screen no matter what I do.
Well, for one thing, your alert() syntax is completely off.

The other problem: You just created a prime example of usr abuse in both mob/Login(), and FirstTimePlayer(). You see, usr is basically a variable which is equal to the last mob to do something. When you press a hyperlink, you become Topic()'s usr, when you press a verb, you become that verb's usr, when you Click(), then you, the clicker, are the usr of Click(). usr is not a global variable. It only works right in certain situations because it isn't a global variable. If player A presses attack() at the same time as player B, then player A's attack()'s usr is equal to player A, while player B's attack()'s usr is equal to player B.

usr is passed down through the call stack (the area of memory where arguments are passed through) from function to function, so if, from attack(), I call src.Death(), then Death()'s usr variable will be equal to the player who attack()ed.

You'll find that excepting certain instances (usr is commonly needed in client/Topic(), for example, because the src value of Topic() can actually be manually defined by the developer), and also excepting certain functions, such as, for example, Click(), DblClick(), and Stat(), it's unsafe to use usr in procs. That's because when a function is called manually, and not by the player, then the usr variable of that function will not necessarily be equal to the player you want it to be equal to. To solve this problem, use src instead unless you specifically know that you mean usr.

Remember, usr is the default argument for certain verbs such as input(), alert(), view), oview(), range(), and orange(). That's why your FirstTimePlayer() includes usr abuse: usr is the default argument for alert().

One more thing: If the BaseCamp library has anything written for FirstTimePlayer(), then you might want to call ..() for your FirstTimePlayer() if you don't want to override BaseCamp's. Of course, I'm not sure that it does include anything to be overwritten, so you'll have to find out for yourself.
In response to Wizkidd0123
OK. Problem fixed.
In response to Jamesburrow
Not that anyone cares, but Login's super should be called last in almost every situation. This being one of them. If there are any problems with the code you wrote, Login's super will fix it with a default value.

Login()
//Your Login code here
..()


That will help in the future.
In response to Neo Skye
Well, I got theproblem fixed for now, but that may fix future problems. Thanx!
In response to Neo Skye
Neo Skye wrote:
Not that anyone cares, but Login's super should be called last in almost every situation. This being one of them. If there are any problems with the code you wrote, Login's super will fix it with a default value.

What are you talking about? It doesn't matter whether you call ..() at the beginning or at the end of mob/Login().
In response to Wizkidd0123
Wizkidd0123 wrote:
Neo Skye wrote:
Not that anyone cares, but Login's super should be called last in almost every situation. This being one of them. If there are any problems with the code you wrote, Login's super will fix it with a default value.

What are you talking about? It doesn't matter whether you call ..() at the beginning or at the end of mob/Login().

Oh? then try a little experiment for me:

Login()
..()
loc = null


then try:

Login()
loc=null
..()


You'll notice the first one fails to load the map, whereas the second one loads the map with the character in the first available space.

Next time, check yourself before you reach for the bold tag.
In response to Neo Skye
Neo Skye wrote:
You'll notice the first one fails to load the map, whereas the second one loads the map with the character in the first available space.

I'm having trouble seeing why you would manually set the loc to null anyway. There's no difference between:

mob/Login()
src << "You've just logged in!"
..()


and

mob/Login()
..()
src << "You've just logged in!"


You see, the default behavior of mob/Login() is to place the mob at the first available tile if the mob has a null loc. By setting mob.loc to null after you call ..(), you're just undoing the actions of ..(). By setting mob.loc to null before ..(), well, you aren't doing anything: by default atom.loc is null.

Next time, check yourself before you reach for the bold tag.

Next time, check yourself before you give out advice.
In response to Wizkidd0123
Wizkidd0123 wrote:
Neo Skye wrote:
You'll notice the first one fails to load the map, whereas the second one loads the map with the character in the first available space.

I'm having trouble seeing why you would manually set the loc to null anyway. There's no difference between:

> mob/Login()
> src << "You've just logged in!"
> ..()
>

and

> mob/Login()
> ..()
> src << "You've just logged in!"
>

You see, the default behavior of mob/Login() is to place the mob at the first available tile if the mob has a null loc. By setting mob.loc to null after you call ..(), you're just undoing the actions of ..(). By setting mob.loc to null before ..(), well, you aren't doing anything: by default atom.loc is null.


Neo Skye: Exactly what I was saying. If he puts in code AFTER ..(), he risks undoing what the super did! Sometimes, good, sometimes bad. But if he puts ..() last, he can't undo it's actions by accident

P.S. What is your problem with me? I'm just trying to help and give good advice, and despite my making a mistake here and there, I've helped a lot of ppl, so lay off. You've made some mistakes yourself!
In response to Neo Skye
Neo Skye wrote:
Neo Skye: Exactly what I was saying. If he puts in code AFTER ..(), he risks undoing what the super did! Sometimes, good, sometimes bad. But if he puts ..() last, he can't undo it's actions by accident

The only way he can possibly undo what the default mob/Login() does is by manually setting mob.loc to null. That's like saying, "Don't use the / operator at all, because if you divide by 0, then you get a runtime!".

P.S. What is your problem with me? I'm just trying to help and give good advice, and despite my making a mistake here and there, I've helped a lot of ppl, so lay off. You've made some mistakes yourself!

I'm glad that you're so excited to help people: that's great! However, you aren't helping anyone by giving out bad advice.
In response to Neo Skye
Neo Skye wrote:
P.S. What is your problem with me? I'm just trying to help and give good advice, and despite my making a mistake here and there, I've helped a lot of ppl, so lay off. You've made some mistakes yourself!

Hey man, no need for comments like this. There's a chance they might start a flame war or something. >.>

Pager is good for stuff like this.

-Ryan ^.-
In response to Wizkidd0123
It wasn't bad advice, just advice that didn't do much.
In response to Jamesburrow
Jamesburrow wrote:
It wasn't bad advice, just advice that didn't do much.

I'd have to disagree there. Telling somebody that they shouldn't do something when there isn't anything wrong with it is definately bad advice. It would be equivalent to me telling you never to use a for() loop, and to use while() instead.