Alright, so again with the questions, hopefully I can get the hang of this stuff...
right now I'm working on making on sreeen text for my game, rather than alerts. And so, I need to place objects using the "set src in usr.client.screen" function. However, the DM reference doesn't give me enough insight in how to use this code effectively. I was wondering if someone could tell me the exact code used to put an item on the usr's screen.
ID:159348
![]() Mar 27 2009, 11:51 am
|
|
obj/onscreen/item I thought it was pretty self-explanatory when it comes to the screen_loc. Place it on the screen and then specify the X and Y coordinate(s). |
mob/verb obj/OVERLAYS So any reason why this wont work? |
Well, because I've never done this before I'm not sure which will work better for my needs; I'll test it, but I'm pretty sure as is I've got enough to work with.
|
1) Don't abuse the : operator - if you changed/removed a variable and it was trying to access that (or you named the variable wrong), you wouldn't know until a runtime error appears - and it'll be hard tracking it down in some cases!
The problem can be solved by giving the variable "O" a type path, letting DM know what type of object (object != /obj) it is: var/X // Treated as a non-type 2) Do not call Del() directly, call del(src) (del() != Del()). 3) Make sure in the Del(), you check if it is in the client.screen; if it is, remove it. |
GhostAnime wrote:
1) Don't abuse the : operator - [...] (or you named the variable wrong), you wouldn't know until a runtime error appears [...] This paragraph is partly somewhat of a myth - the : operator isn't that unsafe that it'll let you just put anything you want as the proc/variable name and it'll compile. The compiler is smart enough not to accept symbols that were never defined throughout the project, and so it knows they don't exist on any object and are invalid. So if you accidentally type, say, JP instead of HP, unless you have an actual 'JP' var defined somewhere, it won't compile and you'll catch the error. That's almost all of the limited checking that operator does though, and it can get fooled easily into compiling (which is what it exists for). In the above example, if you had a global var named 'JP' it'd actually compile, even though it's not even an object var. It is of course preferable to use . instead most of the time, keeping : only for special cases, though those can usually be avoided as well. 3) Make sure in the Del(), you check if it is in the client.screen; if it is, remove it. When an object is deleted in DM, all references to it anywhere are automatically cleared (value is reset to null), including in lists. In a normal list you'd have a leftover null element - in a built-in one, like screen, which only accepts specific values (movable atoms in this case), this isn't the case and you don't need to even worry about getting rid of the remaining null. It seems you've relied too much on his logic being correct when looking for the problem ;) - the problem is the presence of the deletion itself. An object can't be displayed if it's deleted, and he deletes the object before he even attempts to display it anyway due to the order of execution: similarly to this topic, when new() is called the caller (the verb) waits until it and New() finish before continuing. |
Kaioken wrote:
GhostAnime wrote: There have been sooo many threads discussing the : operator and countless posts warning against it. You're definitely right, but the subject is slightly more advanced than a lot of people seem to be capable of understanding... so I prefer to leave the newbies with a "colon bad, dot good" mindset and leave it up to them to learn about it when the time is right (or never). |
Its personal preference, in my opinion. I generally tend to use the : operator when dealing with objects, and that's pretty much it.
|
Screen objects don't anything have to do with the src setting; that's a verb property, not related to the displaying of the object, which simply dictates the condition for the verb to be available. Objects are displayed on the screen by setting their screen_loc var to the coordinates on-screen they should appear at, and adding them to a player(s) screen list. You could easily find this out by a few quick searches in the forum and the resources.