I'm trying to do this within my equip proc, but it won't let me:
var/tmp/mob/pc/E = usr
set src in E.contents
(Yes, I know I don't need to use temp as a variable, but it makes no difference and this way I know how that variable is used. It's more for me than anything else because as time goes on, I have more and more variables, not to mention similar variables that do different things...)
but it tells me:
MRPGWeapons.dm:10:error:E.contents:unsupported src setting
I end up having to do it:
var/tmp/mob/pc/E = usr
set src in usr.contents
which I don't want to do.
Is there any way I can access the contents without going through usr? I think this makes my code look rough and it drives me nuts :-)
ID:149250
 Jun 10 2002, 2:18 am
|
|
Continuity. I'm using E instead of usr, and I hate the fact that I have to use usr in that one case instead of E.
Continuity is what makes the difference between good code & bad code anyways, in my opinion. So why WOULDN'T I want to use that? I never use usr anywhere else in that block of code ( actually I rarely use it at all now ), so why add it instead of E? It creates continuity errors. | |
ShadowWolf wrote:
Continuity. I'm using E instead of usr, and I hate the fact that I have to use usr in that one case instead of E. That's kind of silly, ShadowWolf. BYOND only supports a limited set of options for constricting src in a verb, so you have to use usr.contents. Anyway I don't see how this affects your continuity. You're using E (which is just usr cast to a specific type) everywhere else, but in the one place you have to use usr, you'd just use that. Trying to force E to fit where it doesn't is absolutely pointless. Continuity is what makes the difference between good code & bad code anyways, in my opinion. You'll probably have to explain what you mean by "continuity"; I think you actually mean "consistency". So why WOULDN'T I want to use that? I never use usr anywhere else in that block of code ( actually I rarely use it at all now ), so why add it instead of E? It creates continuity errors. You're not so much adding it as reverting back to it. Think of usr as one of the primitive values available to the verb; the set src line is one of the primitive settings that constricts the verb. Thus, usr naturally goes with it. I look at all my verbs like this: verb/something() If you put the set src line first, you'll see that this isn't a consistency problem at all; you're using usr the way it was meant to be used, before it gets cast to E, at which point your own code takes over and uses it as if it's a specific type. In Incursion I run into this a lot myself; I have usr at the beginning of the verb, but then I cast it to mob/player/M and use it as M for the rest of the proc. This is hardly inconsistent. You're also making a mistake by referring to this as a "continuity error", even if you were using the correct word ("consistency"). That's not an error--it's a potential problem, or a flaw, but not an error. A much better way to look at it is that if you have a problem, it's because you're casting usr to E before you do the "set src in usr.contents" line. The settings lines can go anywhere, I believe, but by putting them before all your code you avoid that confusion. It's more correct to say that the only consistency problem is that you're putting all your verb-set lines in the middle of your code instead of before it. Lummox JR | |
Yeah, I meant consistancy. Was late.
But what I'm saying isn't silly. When I use any other language, including some altered languages like DM, I can do stuff like that. There's no reason why I should have to do that, and I was just wondering if there was anoter way to address that in which I could use 'E' instead of 'usr.' You, though, attacked my methods and never really gave me an answer. Like I said, there's no PROBLEM with what I'm trying to do. Things like "set" are not pre-control lines. There's no reason to use them before you have to. Now please stop attacking things you obviously don't agree with or simply don't understand or commonly use. I like using structured OO programming by regular standards. Makes life easier, and the order in which things are done is very important as well. | |
ShadowWolf wrote:
Yeah, I meant consistancy. Was late. Well, your methods are mostly the problem; it's your perspective that's really off. A better explanation for why this wouldn't work occurred to me later: BYOND isn't capable of restricting a verb to the contents of an arbitrary object, but only to world.contents or usr.contents. However, when you set E=usr, that's a statement that's evaluated at runtime, not compile-time, so the compiler doesn't know that E is equivalent to usr. At compile-time, however, is when BYOND needs to know how to set up the verb. (The only thing it does at runtime is choose the appropriate list from a limited set of choices; if it was done differently, you could just use anything.) Like I said, there's no PROBLEM with what I'm trying to do. Things like "set" are not pre-control lines. There's no reason to use them before you have to. Pre-control? I'm not sure what you mean by that, but basically they control deep down how the verb functions in the BYOND interface. There is one reason to put them first, though: Cleaner code. In terms of consistency, this would do a lot more for it than replacing usr with E. And there is indeed a problem with what you're doing, because it doesn't work. And the reasons why it doesn't work basically come from the fact that you're not seeing this verb the same way BYOND sees it. Now please stop attacking things you obviously don't agree with or simply don't understand or commonly use. I like using structured OO programming by regular standards. Makes life easier, and the order in which things are done is very important as well. I like using standards too. But you have to remember that BYOND is not C++, or any other language. It's its own language and follows its own rules and conventions. One of the important and more unique ones deals with how you use the set commands in a verb. Set commands are very picky and can only be used in certain ways--this is the heart of your problem. Lummox JR | |
I see now, I didn't realize it was established at run-time. Just me trying to make pressupositions about DM in order to better use it.
I kinda wish it would do more at compile-time, I think it would make BYOND a bit more efficient and faster. At the same token, I'm really not interested in designing my own version of BYOND, creating a website, and developing a community in hopes of making a profit sometime in the distant future, so I guess who am I to complain right? *sigh* I was just moreover wondering if there was a way to workout having to use usr, but probably not if it can't accept an arbitrary value as a substute for a concrete reference eh? | |
*sigh* I was just moreover wondering if there was a way to workout having to use usr, but probably not if it can't accept an arbitrary value as a substute for a concrete reference eh? The point there is that all 'set' commands are encoded into the DMB as constants. The client polls these constants (usr.contents, for example, might arbitrarily evaluate to "5C, 01" in the bytecode), and then uses the client functionality to determine the verb accessibility. I'm not sure if the server double-checks the verb accessibility, though -- I sure hope it does. Otherwise, I wouldn't doubt that people would be able to make a hacked version of the client that always makes every verb accessible. =| | |
Why is this a problem for you? If E==usr, then "set src in usr.contents" will do exactly what you want. The only reason you need the reference to E as a specific type is for code later in the verb. Saying "set src in E.contents" would do exactly the same thing if it worked, so why are you even trying to do it that way?
Basically you're introducing a compiler error for absolutely no reason.
Lummox JR