ID:159348
 
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.
There isn't a specific "the code to do X", nor should you phrase your questions asking for it, mind.
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.
In response to Kaioken
But I still don't get how to use screen loc, I guess that was my main problem.
In response to Powerbraclet
obj/onscreen/item
icon = 'item.dmi'
screen_loc = "1,1"

mob/verb/Add_One_Screen_Item()
var/X = input("Please enter the X-Coordinate for the screen item","X-Coordinate") as num|null
var/Y = input("Please enter the Y-Coordinate for the screen item","Y-Coordinate") as num|null
var/I = new/obj/onscreen/item
src.client.screen += I
I:screen_loc = "[X],[Y]"

mob/verb/Add_A_Block_Of_Items()
var/X1 = input("Please enter the X1-Coordinate for the screen item","X1-Coordinate") as num|null
var/Y1 = input("Please enter the Y1-Coordinate for the screen item","Y1-Coordinate") as num|null
var/X2 = input("Please enter the X2-Coordinate for the screen item","X2-Coordinate") as num|null
var/Y2 = input("Please enter the Y2-Coordinate for the screen item","Y2-Coordinate") as num|null
var/I = new/obj/onscreen/item
src.client.screen += I
I:screen_loc = "[X1],[Y1] to [X2],[Y2]"


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).
In response to ArcaneDragonX
Wow, that's great! Thanks!
In response to ArcaneDragonX
mob/verb
Overlayadd()
var/O = new/obj/OVERLAYS
src.client.screen += O
O:screen_loc = "1,1 to 11,11"

obj/OVERLAYS
density=0
layer=7
icon='n.dmi'
icon_state="HO"
screen_loc = "1,1"
New()
sleep(5)
Del()


So any reason why this wont work?
In response to Rushnut
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.
In response to Powerbraclet
No i meant, My one WONT work, and i didnt understand why not.
In response to Rushnut
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
var/mob/M // M has the variables/proc of a /mob available
var/obj/O // O has the variables/proc of /obj available
var/turf/Water/W // W has the variables/proc of /turf/Water available

// Of course you need to make sure that the object is the type you defined for - do not want runtime errors:
istype(X, /type)

istype(O) // If a variable has a path defined, such as /turf/Water for var/turf/Water/W, istype() without the second argument will look for the variable path; meaning this is like saying istype(O, /obj)



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.
In response to GhostAnime
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.
In response to Kaioken
Kaioken wrote:
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.

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).
In response to Ephemerality
Its personal preference, in my opinion. I generally tend to use the : operator when dealing with objects, and that's pretty much it.
In response to ArcaneDragonX
ArcaneDragonX wrote:
Its personal preference, in my opinion.

Except it's not. It's not like putting "src." in front of everything, it be worse!

But I'm not going to repeat the seemingly infinite posts about how bad the colon operator is, so just don't do it.