1
2
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() 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: Go test this out then: verb/Change() 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() 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() 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() Actually equates to this: Login() 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: > > verb/Change() this only works because its a client verb, which keeps the client referenced through the use of it. or so I think <.< 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 screwyWorse, 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: 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? Consider this: client 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? 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 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() |
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 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.... |
1
2
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.