In response to Falacy
Falacy babbled:
Libraries are made for prefab situations, and if you were
a half decent coder in the time it'd take you to figure
out how to use somebodys library you could write your own
code to do whatever you needed to do


libraries, when well written, speed up development by allowing the programmer to concentrate on stuff that does not exist yet. a 'half-decent coder' should never need to re-invent the wheel.

why would anyone spend an hour on a large piece of code, when it would take 5 minutes to implement a library that provides the needed functionality, is BYOND me! :p

plus, using a good library means that is one less chunk of programming that could go wrong.

if i spent my days retyping the lengthy php-form validators and database abstraction classes i use for every project i'm involved with, it would take twice as long to complete those projects.
In response to Garthor
Really? I've been doing that in quite a few games, I never have a problem. Maybe I added a spawn() before the del src.mob, but I've never had a disconnect.
In response to Garthor
Garthor wrote:
What? No, that's totally wrong, and what you are suggesting would just disconnect the player.

It shoudlnt disconnect, that code sets up a seperate mob "character" which it applies all the input to and then at the end it switches your mob to the "character" mob. Deleting src deletes the original mob which you should no longer be attached to
In response to Falacy
It has 'del src.client.mob' (ridiculously silly), and only tries changing the mob after that instruction, which isn't going to run as src is deleted (which also disconnected the player).
In response to digitalmouse
digitalmouse wrote:
why would anyone spend an hour on a large piece of code, when it would take 5 minutes to implement a library that provides the needed functionality, is BYOND me! :p

That wasn't very punny :(

And I totally agree with you, I use Lummox JR's SwapMaps library a lot and I would rather not make something from scratch to have the same effect.
In response to Kaioken
Kaioken wrote:
It has 'del src.client.mob' (ridiculously silly), and only tries changing the mob after that instruction, which isn't going to run as src is deleted (which also disconnected the player).

Not true. Here's a code example from a demo I've been working on which has no problems whatsoever.
verb/Change()
switch(alert(src,"What do you want to be?","Type?","Square","Triangle","Circle"))
if("Square")
del src.mob
src.mob=new/mob/PC/Square
if("Triangle")
del src.mob
src.mob=new/mob/PC/Triangle
if("Circle")
del src.mob
src.mob=new/mob/PC/Circle
src.mob.name=src.key

src=client
In response to Garthor
Why don't you actually try the code, instead of espousing the views of someone who's a better programmer than you in the hopes of gaining geek points.
In response to Rockinawsome
Rockinawsome wrote:
Why don't you actually try the code, instead of espousing the views of someone who's a better programmer than you in the hopes of gaining geek points.

putting src.client.mob is basicaly a loop back to itself, its pretty pointless
and hes right, deleting src.client.mob there would disconect the player
I must have just skipped over reading that line since its oddly tabbed in, which would cause a compile error there
In response to Falacy
Falacy wrote:
Rockinawsome wrote:
Why don't you actually try the code, instead of espousing the views of someone who's a better programmer than you in the hopes of gaining geek points.

putting src.client.mob is basicaly a loop back to itself, its pretty pointless
and hes right, deleting src.client.mob there would disconect the player
I must have just skipped over reading that line since its oddly tabbed in, which would cause a compile error there


Go test this out then:
verb/Change()
switch(alert(src,"What do you want to be?","Type?","Square","Triangle","Circle"))
if("Square")
del src.mob
src.mob=new/mob/PC/Square
if("Triangle")
del src.mob
src.mob=new/mob/PC/Triangle
if("Circle")
del src.mob
src.mob=new/mob/PC/Circle
src.mob.name=src.key


The above belongs to client of course. The reason I believe this works (and I could be wrong), is that the symmetry between mob and client aren't that tight as some believe. This is possibly due to the fact that client.mob has to change in some instances. So what happens to the mob once it's being changed?

*Edit, and have you ever tried programming a mud in BYOND and using just the client to start off with, and then eventually adding a mob to the client? Much the same idea.

*Edit 2, the formmating changes when you copy and paste code from byond into the forum. It will almost always generate a compiler error.
In response to Rockinawsome
Rockinawsome wrote:
Go test this out then:
> verb/Change()
> switch(alert(src,"What do you want to be?","Type?","Square","Triangle","Circle"))
> if("Square")
> del src.mob
> src.mob=new/mob/PC/Square
> if("Triangle")
> del src.mob
> src.mob=new/mob/PC/Triangle
> if("Circle")
> del src.mob
> src.mob=new/mob/PC/Circle
> src.mob.name=src.key
>
>


this only works because its a client verb, which keeps the client referenced through the use of it. or so I think <.<

The above belongs to client of course. The reason I believe this works (and I could be wrong), is that the symmetry between mob and client aren't that tight as some believe. This is possibly due to the fact that client.mob has to change in some instances. So what happens to the mob once it's being changed?

We werent refering to the above code so that doesnt really matter

*Edit, and have you ever tried programming a mud in BYOND and using just the client to start off with, and then eventually adding a mob to the client? Much the same idea.

Sounds like a pretty foolish plan to me. All these "MUD"s on byond where you just randomly fight stuff in a text based combat system shouldnt even count as MUDs... multi user DUNGEONS... there should be a world of some sort... not just multi user text based combat systems

*Edit 2, the formmating changes when you copy and paste code from byond into the forum. It will almost always generate a compiler error.

It converts tabs into spaces, it doesnt add random ones
In response to Rockinawsome
Rockinawsome wrote:
Go test this out then:
> verb/Change()
> switch(alert(src,"What do you want to be?","Type?","Square","Triangle","Circle"))
> if("Square")
> del src.mob
> src.mob=new/mob/PC/Square
> if("Triangle")
> del src.mob
> src.mob=new/mob/PC/Triangle
> if("Circle")
> del src.mob
> src.mob=new/mob/PC/Circle
> src.mob.name=src.key
>
>

The above belongs to client of course. The reason I believe this works (and I could be wrong), is that the symmetry between mob and client aren't that tight as some believe.

Falacy touched on this, and I'll elaborate as to why this works and why your mob/Login() code doesn't.

In mob/Login(), the statement del src.client.mob is the exact same thing as del src, except it generates a runtime if you set src.client.mob to something else and src no longer has a client. The moment you call del O, any procs running under O (i.e., src's Login() proc when you call del src), are terminated.

So your Login() proc, programmed as such:
     Login()
var/charactername = input("Hello, Pick a name for your character, something you wish for people to call you in the game.","Character Name?")
switch(input("Below pick one of the following backgrounds you wish for your character to be. It determines what skills you get in the game.","Character Background?") in list("Warrior","Cleric","Magician"))
if ("Inuyasha")
character = new /mob/PC/Warrior()
if ("Kagome")
character = new /mob/PC/Cleric()
if ("Sesshomaru")
character = new /mob/PC/Magician()
character.name = charactername
del src.client.mob //you need to delete the current mob, otherwise you'll continue to call Login() from this mob as well
src.client.mob = character
// ...

Actually equates to this:
     Login()
var/charactername = input("Hello, Pick a name for your character, something you wish for people to call you in the game.","Character Name?")
switch(input("Below pick one of the following backgrounds you wish for your character to be. It determines what skills you get in the game.","Character Background?") in list("Warrior","Cleric","Magician"))
if ("Inuyasha")
character = new /mob/PC/Warrior()
if ("Kagome")
character = new /mob/PC/Cleric()
if ("Sesshomaru")
character = new /mob/PC/Magician()
character.name = charactername
del src //you need to delete the current mob, otherwise you'll continue to call Login() from this mob as well

This is because execution of all of src's procs (including src's Login() proc) end as soon as you call del src, and so you only ever call del src if you want to end the proc early, or at the end of a proc.

Because Login() ends abruptly when you del src, it never gets to the point where you assign a new value to src.client.mob, and so no new value is assigned.

In the code you posted this time, the proc belongs to the client, and thus isn't terminated instantly when you delete the mob. Therefore the verb can continue and assign the new mob.
In response to Falacy
Falacy wrote:
Rockinawsome wrote:
Go test this out then:
> > verb/Change()
> > switch(alert(src,"What do you want to be?","Type?","Square","Triangle","Circle"))
> > if("Square")
> > del src.mob
> > src.mob=new/mob/PC/Square
> > if("Triangle")
> > del src.mob
> > src.mob=new/mob/PC/Triangle
> > if("Circle")
> > del src.mob
> > src.mob=new/mob/PC/Circle
> > src.mob.name=src.key
> >
> >

this only works because its a client verb, which keeps the client referenced through the use of it. or so I think <.<

The above belongs to client of course. The reason I believe this works (and I could be wrong), is that the symmetry between mob and client aren't that tight as some believe. This is possibly due to the fact that client.mob has to change in some instances. So what happens to the mob once it's being changed?

We werent refering to the above code so that doesnt really matter

*Edit, and have you ever tried programming a mud in BYOND and using just the client to start off with, and then eventually adding a mob to the client? Much the same idea.

Sounds like a pretty foolish plan to me. All these "MUD"s on byond where you just randomly fight stuff in a text based combat system shouldnt even count as MUDs... multi user DUNGEONS... there should be a world of some sort... not just multi user text based combat systems

I wasn't really referring to those. I was talking about a real mud. You do can do a lot of stuff with just the client if you don't use a map file. It's fairly complicated, but I built a system which completely subverts the standard BYOND building system for MUDs. I use custom room datums.

It converts tabs into spaces, it doesnt add random ones

It was totally copied and pasted.
In response to Falacy
I think I just figured out why we havn't been on the same page. I was assumming the original poster was posting code that belonged to a client.

src.client.mob should still take us to the client's mob, correct? So isn't that the same as calling src.mob from within the client datum? Or does BYOND do something really screwy?
In response to Rockinawsome
Rockinawsome wrote:
I think I just figured out why we havn't been on the same page. I was assumming the original poster was posting code that belonged to a client.

You were wrong, get over this. Maybe you ought to calm down and stop being condescending yourself. You were not assuming the code belonged to a client. The code was clearly under mob/Login(); the code you've added yourself is del src.client.mob with a comment, which shows you know 'src' is a mob (although you're still being ridiculous using Mob.client.mob to reference a mob instead of referencing it by Mob, despite it being pointed out already).

src.client.mob should still take us to the client's mob, correct?

'src.client.mob' is going to simply take you to 'src', and only if the mob 'src' has a client. You're accessing the mob's client, then using it to check the client's mob. Even if you're going for a 'largest code' contest, it's quite a... bad way to go about doing it. Might as well use Mob.client.mob.client.mob.

So isn't that the same as calling src.mob from within the client datum?

First, you don't 'call' variables. And it isn't the same, since in the other situation you already have a reference to the mob and are going roundabout, and doing something-
<small><s>Or does BYOND do something</s></small> really screwy
Worse, it seems you may think 'del src.client.mob' has a different effect than 'del src'.

Oh, and the forum doesn't magically alter formatting in posted code either, by the way. There are bugs in the DM tag, but they only occur in its first line.

EDIT: Also, I don't think you can do with clients not having any mobs, either, regardless if you have a map or not. Mobs are quite tied to players, I doubt everything would work properly for a player (client) without a mob.
In response to Kaioken
Kaioken wrote:
Rockinawsome wrote:
I think I just figured out why we havn't been on the same page. I was assumming the original poster was posting code that belonged to a client.

You were wrong, get over this. Maybe you ought to calm down and stop being condescending yourself. You were not assuming the code belonged to a client. The code was clearly under mob/Login(); the code you've added yourself is del src.client.mob with a comment, which shows you know 'src' is a mob (although you're still being ridiculous using Mob.client.mob to reference a mob instead of referencing it by Mob, despite it being pointed out already).

The funny thing about this is, that you seem to think being right or wrong is all that matters. And for some reason you've decided to lump me in with your group. The problem is I wasn't following what you were saying because I thought you were talking about a different post. The fact that you're SOOOO emotional over a silly post cracks me up.

src.client.mob should still take us to the client's mob, correct?

'src.client.mob' is going to simply take you to 'src', and only if the mob 'src' has a client. You're accessing the mob's client, then using it to check the client's mob. Even if you're going for a 'largest code' contest, it's quite a... bad way to go about doing it. Might as well use Mob.client.mob.client.mob.

Consider this:
client
var/mob/mob


Let's say this is how BYOND set up the client. Now why would it make any difference if I used src.client.mob
or if I called mob from client. Look, I'm just trying to understand what's going on. You don't have to get all defensive over nothing.

And another thing: prefixing stuff in byond with src or usr, or M, or anything else is just a good habit to get into, it makes it easier to know what belongs to what.


So isn't that the same as calling src.mob from within the client datum?

First, you don't 'call' variables. And it isn't the same, since in the other situation you already have a reference to the mob and are going roundabout, and doing something-
<small><s>Or does BYOND do something</s></small> really screwy
Worse, it seems you may think 'del src.client.mob' has a different effect than 'del src'.

I was thinking it should have the same effect as del src.mob from the client. As for 'call' or reference, or jimmy-jimmy-bang-bang the variable, I could care less. I know that doesn't earn me any geek points, but cry me a river.

Oh, and the forum doesn't magically alter formatting in posted code either, by the way. There are bugs in the DM tag, but they only occur in its first line.

Again, I was thinking you were talking about a different post. That post I added a comment that said it was *UNFORMATED*. Clearly, it wouldn't be too hard to format the single line of code I interjected visa-vie the forums.


EDIT: Also, I don't think you can do with clients not having any mobs, either, regardless if you have a map or not. Mobs are quite tied to players, I doubt everything would work properly for a player (client) without a mob.

You just have to code everything yourself. But it is easier to connect to a mob.
In response to Rockinawsome
Okay, here's what it should have been. Sorry for the confusion. I was just mixing up client and mob.
The below code is just an example. It should be fairly simple to implement what I'm doing in your own. I tested this code so I know it works.

//this verb belongs to a mob
verb/Change()
switch(alert(usr,"What do you want to be?","Type?","Square","Triangle","Circle"))
if("Square")
var/mob2del = usr.client.mob
usr.client.mob=new/mob/PC/Square
del mob2del
if("Triangle")
var/mob2del = usr.client.mob
usr.client.mob=new/mob/PC/Triangle
del mob2del
if("Circle")
var/mob2del = usr.client.mob
usr.client.mob=new/mob/PC/Circle
del mob2del
usr.name=usr.key


Comment out the del portion of the code and use the snippet below and you will find 2 mobs in the world. This should verify what you see visually anyway. So the del portion is in fact deleting your old mob.

verb/check()
for(var/mob/M in world)
usr<<M
In response to Rockinawsome
Rockinawsome wrote:
The problem is I wasn't following what you were saying because I thought you were talking about a different post. The fact that you're SOOOO emotional over a silly post cracks me up.

Really? Your inability to accurately measure emotions cracks me up, I'm afraid. You may want to know this isn't always possible from a simple clump of text; you'd need some kind of hint, like someone being overly defensive, making pointless excuses, attempting to divert the topic and falsely accusing, etc. No offense, but you're not nearly important enough for me to care much personally about your posts, let alone get emotional about. Well, not more than a chuckle or two.

Let's say this is how BYOND set up the client. Now why would it make any difference if I used src.client.mob
or if I called mob from client.

Yes, like I said (you've clearly missed everything I've said, but I'll give it a try), there isn't any difference if you've used src.client.mob.client.mob.client.mob either. Might as well use it then.

And another thing: prefixing stuff in byond with src or usr, or M, or anything else is just a good habit to get into, it makes it easier to know what belongs to what.

I've said nothing about that, so I don't why you've brought this up. You may have missed the point even byond the expected. I actually support using full syntax, but you don't even make sense because you must specify 'usr', 'M', or any object reference variable other than 'src'.

I was thinking it should have the same effect as del src.mob from the client. As for 'call' or reference, or jimmy-jimmy-bang-bang the variable, I could care less. I know that doesn't earn me any geek points, but cry me a river.

You ought to re-learn programming then (I'm also referring to the fact using different ways to obtain the same argument will result in the same operation taking place, as the argument IS the same value). Or you continue to earn stupid points. Yes, I'm sorry that using wrong terminology makes you look not-so-smart (not to mention wrong and harder to understand), and that people correct others for being wrong. It's not me who decided that, so complain to someone else, God, perhaps.
By the way, saying you could care less is an opposite form of attempting the saying. It means you do care.

Again, I was thinking you were talking about a different post. That post I added a comment that said it was *UNFORMATED*. Clearly, it wouldn't be too hard to format the single line of code I interjected visa-vie the forums.

Again, silly excuse. Keep making those up and accusing me of being defensive; it doesn't even matter what post this was about. You said:

*Edit 2, the formmating changes when you copy and paste code from byond into the forum. It will almost always generate a compiler error.

Which is wrong, regardless of what post it possibly relates to. Therefore, people corrected you. This isn't the end of the world, as you see, you're still alive, albeit possibly with a hurt ego since you've felt the need to still babble about all this after being corrected by several people. =\

You just have to code everything yourself. But it is easier to connect to a mob.

I think some of BYOND's functionality probably relies internally on there being a mob - I may be wrong, but it's probably unintended for a player to keep playing without being tied to a mob. For one I can see info panels are broken after losing a mob, despite being available for a client. There is of course the side effect of not conforming to common DM programming practices that rely on a mob as well.
In response to Kaioken
Kaioken wrote:
I think some of BYOND's functionality probably relies internally on there being a mob - I may be wrong, but it's probably unintended for a player to keep playing without being tied to a mob. For one I can see info panels are broken after losing a mob, despite being available for a client.

I would say there would probably be other unintended side-effects, and I don't know if clients can even exist without a mob (at least, not once all client procs stop running), but I don't think Info panels in particular should break any more than if you set client.statobj to null, and I don't believe that messes them up at all.
In response to Kaioken
there isn't any difference if you've used src.client.mob.client.mob.client.mob either. Might as well use it then.

I must be developing some strange disorder. This cracked me up way more than it should have....
Page: 1 2