Locked: Need this feature!! in BYOND Discussion

Page: 1 2
ID:259254
 
Oct 30 2000, 9:57 am
In the current line-of-sight system of Byond, the turfs not in sight are completely hidden. Even if you wanted to put image() there, it wouldn't show up until the turf can be seen. There should be some kind of override, if you always wanted the image to be seen, no matter if you're blind or not in LOS.

That feature is essential in my next game. Can it be done?

/Andreas
#1 Oct 30 2000, 3:16 pm
On 10/30/00 9:57 am Gazoot. wrote:
In the current line-of-sight system of Byond, the turfs not in sight are completely hidden. Even if you wanted to put image() there, it wouldn't show up until the turf can be seen. There should be some kind of override, if you always wanted the image to be seen, no matter if you're blind or not in LOS.

That feature is essential in my next game. Can it be done?

I'll put in on The List. As I mentioned to Deadron, we need slightly better control over images and layers, and your sugestion fits in there. We'll come up with something, but I can't promise you anything immediate, as we have bugs to fix.
#2 Oct 30 2000, 9:17 pm
In response to Tom H. (#1)
On 10/30/00 3:16 pm Tom H. wrote:
I'll put in on The List. As I mentioned to Deadron, we need slightly better control over images and layers, and your sugestion fits in there. We'll come up with something, but I can't promise you anything immediate, as we have bugs to fix.

Whatever happened to whoever's idea about an "elevation" variable that determined what got displayed on top of what? Whenever more than one thing was on the same spot, there'd be a check to see if they had different elevation values, and the highest would be displayed on top, on down. If things had the same elevation values, the current system would take care of what got displayed on top (whichever thing was put there last, is it?).

Z
#3 Oct 30 2000, 9:32 pm
In response to Zilal (#2)
On 10/30/00 9:17 pm Zilal wrote:
On 10/30/00 3:16 pm Tom H. wrote:
I'll put in on The List. As I mentioned to Deadron, we need slightly better control over images and layers, and your sugestion fits in there. We'll come up with something, but I can't promise you anything immediate, as we have bugs to fix.

Whatever happened to whoever's idea about an "elevation" variable that determined what got displayed on top of what? Whenever more than one thing was on the same spot, there'd be a check to see if they had different elevation values, and the highest would be displayed on top, on down. If things had the same elevation values, the current system would take care of what got displayed on top (whichever thing was put there last, is it?).

Z


That is an interesting thing that I've also been a requestor of in the past, for supporting overhanging geography (which, thankfully, ebonshadow and others have shown is actually possible with the current system if not ideal).

Just for sake of clarity, I'll mention that it is different than what I was talking to Tom about. That concern was over the fact that an image() turns out not to apply to the top of the object it is associated with, but rather is drawn on top of everything on the turf. So if you add an image() to an object that is in the middle of the stack (say, a chair), that image will draw over everything else, including images for objects on top of that chair.

This is workaroundable, but requires that you know what all the images are in the turf and remove and redraw them in the order you want them to display.
#4 Oct 30 2000, 10:26 pm
In response to Zilal (#2)
Whatever happened to whoever's idea about an "elevation" variable that determined what got displayed on top of what?

Well, I'm called "Spatz", "Spuzz", "Spuzzum", "Jeremy", "Spuzzoli", "Spuzzman", and miscellaneous cusses not appropriate to repeat. Now I add "whoever". =)

According to the very simple ordering,

Area.elevation = 1
Turf.elevation = 2
Object.elevation = 3
Mob.elevation = 4

preserving regular order and allowing overrides as necessary. Tom said he'd consider it, but I guess we both forgot! =)
#5 Oct 30 2000, 11:16 pm
In response to Deadron (#3)
On 10/30/00 9:32 pm Deadron wrote:
Just for sake of clarity, I'll mention that it is different than what I was talking to Tom about.

Oh, I see. Now I'm expected to read forum posts before I reply to them...

Z
#6 Oct 31 2000, 9:28 am
In response to Tom H. (#1)
On 10/30/00 3:16 pm Tom H. wrote:
That feature is essential in my next game. Can it be done?

I'll put in on The List. As I mentioned to Deadron, we need slightly better control over images and layers, and your sugestion fits in there. We'll come up with something, but I can't promise you anything immediate, as we have bugs to fix.

That's great, thanks. Actually after a bit of thinking and coding, I fixed it in a nice way. But it would still be good, especially to be able to click on a turf that's out of sight.

/Andreas
#7 Oct 31 2000, 6:16 pm
In response to Deadron (#3)
On 10/30/00 9:32 pm Deadron wrote:
On 10/30/00 9:17 pm Zilal wrote:
On 10/30/00 3:16 pm Tom H. wrote:
I'll put in on The List. As I mentioned to Deadron, we need slightly better control over images and layers, and your sugestion fits in there. We'll come up with something, but I can't promise you anything immediate, as we have bugs to fix.

Whatever happened to whoever's idea about an "elevation" variable that determined what got displayed on top of what? Whenever more than one thing was on the same spot, there'd be a check to see if they had different elevation values, and the highest would be displayed on top, on down. If things had the same elevation values, the current system would take care of what got displayed on top (whichever thing was put there last, is it?).

Z


That is an interesting thing that I've also been a requestor of in the past, for supporting overhanging geography (which, thankfully, ebonshadow and others have shown is actually possible with the current system if not ideal).

Just for sake of clarity, I'll mention that it is different than what I was talking to Tom about. That concern was over the fact that an image() turns out not to apply to the top of the object it is associated with, but rather is drawn on top of everything on the turf. So if you add an image() to an object that is in the middle of the stack (say, a chair), that image will draw over everything else, including images for objects on top of that chair.

This is workaroundable, but requires that you know what all the images are in the turf and remove and redraw them in the order you want them to display.

I don't know... I kind of like that fact, because then overlays take priority over the regular icon, and you can overlay terrain over top of those overlays. If the turf.elevation var is ever implemented, though, it'd avoid all of that unnecessary trouble, so overlays would be almost obsolete, one way or another.
#8 Oct 31 2000, 6:29 pm
In response to Spuzzum (#7)
On 10/31/00 6:16 pm Spuzzum wrote:
I don't know... I kind of like that fact, because then overlays take priority over the regular icon, and you can overlay terrain over top of those overlays. If the turf.elevation var is ever implemented, though, it'd avoid all of that unnecessary trouble, so overlays would be almost obsolete, one way or another.


Oh no, overlays will be used a lot for character graphics -- the backpacks and such being used now show that pretty conclusively.

And provide a good example of the layering issue here...say you have an overlay intended to hang over the turf and the mob such as an archway. The character puts on a backpack. Now the backpack is on top of the archway.
#9 Oct 31 2000, 6:36 pm
In response to Spuzzum (#7)
I don't know... I kind of like that fact, because then overlays take priority over the regular icon, and you can overlay terrain over top of those overlays. If the turf.elevation var is ever implemented, though, it'd avoid all of that unnecessary trouble, so overlays would be almost obsolete, one way or another.

I dunno if we're talking about exactly the same thing, but I see distinct niches for image(), overlays (and underlays), and elevation. If elevation were implemented as I imagine, I'd still use overlays.

Z
#10 Oct 31 2000, 6:39 pm
In response to Deadron (#8)
On 10/31/00 6:29 pm Deadron wrote:
On 10/31/00 6:16 pm Spuzzum wrote:
I don't know... I kind of like that fact, because then overlays take priority over the regular icon, and you can overlay terrain over top of those overlays. If the turf.elevation var is ever implemented, though, it'd avoid all of that unnecessary trouble, so overlays would be almost obsolete, one way or another.


Oh no, overlays will be used a lot for character graphics -- the backpacks and such being used now show that pretty conclusively.

And provide a good example of the layering issue here...say you have an overlay intended to hang over the turf and the mob such as an archway. The character puts on a backpack. Now the backpack is on top of the archway.

My brain has become befuddled by this discussion!

Just to be sure, we're not talking about the overlays[] list at all, right? IMHO, the backpack-on-a-player should be implemented as a member of mob.overlays rather than as an image, since it will preserve the layering order and also be managed much more efficiently than image(). That's why overlays[] exist in the first place.

On the other hand, you are correct about the arch. That should also be done with overlays[], but without Spuzz's layering idea, it won't work properly, so one must currently resort to image(), which has the side-effect of layering on top of everything else.

Bottom-line: yes, we should support this elevation parameter for objects. When that is in place, image() should only be used when sending icons to specific targets.

And, to remedy Deadron's problem, image() itself should also probably take an elevation (defaulting to the elevation of the attached object). Then everyone will be happy, no?

#11 Oct 31 2000, 6:52 pm
In response to Deadron (#8)
Oh no, overlays will be used a lot for character graphics -- the backpacks and such being used now show that pretty conclusively.

That was a typo. I meant images. =)
#12 Oct 31 2000, 6:54 pm
In response to Zilal (#9)
I dunno if we're talking about exactly the same thing, but I see distinct niches for image(), overlays (and underlays), and elevation. If elevation were implemented as I imagine, I'd still use overlays.

Again, that was a typo. I meant images. Though now I see that there might be uses for images after all.
#13 Oct 31 2000, 6:55 pm
In response to Spuzzum (#11)
On 10/31/00 6:52 pm Spuzzum wrote:
Oh no, overlays will be used a lot for character graphics -- the backpacks and such being used now show that pretty conclusively.

That was a typo. I meant images. =)


NOOOOOO! DragonSnot depends on image() for the buttons to send each player a unique image based on the trench that is avialable to them.

I imagine many arcade/puzzle-like games will do the same.
#14 Oct 31 2000, 7:15 pm
In response to Deadron (#13)
NOOOOOO! DragonSnot depends on image() for the buttons to send each player a unique image based on the trench that is avialable to them.

I imagine many arcade/puzzle-like games will do the same.

Much like DragonSnot, Cribbage will rely on image() to make sure players can't see each other's cards.

#15 Nov 1 2000, 1:24 pm
In response to Tom H. (#10)
On 10/31/00 6:39 pm Tom H. wrote:
Bottom-line: yes, we should support this elevation parameter for objects. When that is in place, image() should only be used when sending icons to specific targets.

And, to remedy Deadron's problem, image() itself should also probably take an elevation (defaulting to the elevation of the attached object). Then everyone will be happy, no?

Speaking of image, is there a better way to do this:<pre> var/tmp/I switch(Dir) if(1) I = 'trail1.dmi' if(2) I = 'trail2.dmi' if(4) I = 'trail4.dmi' if(8) I = 'trail8.dmi' if(5) I = 'trail5.dmi' if(6) I = 'trail6.dmi' if(9) I = 'trail9.dmi' if(10) I = 'trail10.dmi' var/tmp/Img = image(I,Loc)</pre>
I can't come up with anything better, since the icon state can't change unless it's attached to an object. Also, if icon names supported embedded expressions, I could replace all this with just:
<pre>var/tmp/Img = image('trail[Dir].dmi')</pre>
/Andreas
#16 Nov 1 2000, 1:29 pm
In response to Tom H. (#10)
On 10/31/00 6:39 pm Tom H. wrote:
And, to remedy Deadron's problem, image() itself should also probably take an elevation (defaulting to the elevation of the attached object). Then everyone will be happy, no?


Well not necessarily. The stupid kids upstairs make too much noise all night and leave garbage around everywhere.

Oh, you mean happy with this solution...why yes!
#17 Nov 1 2000, 2:05 pm
In response to Gazoot (#15)
My desired improvement would be a better way to set icon states for the images being shown. Rather than:

var/obj/O = new /obj
O.icon = 'arrow.dmi'
O.icon_state = "up"
var/showarrow = image(O,locate(1,1,1))
usr << showarrow

I'd like something a little smoother...

var/showarrow = image('arrow.dmi',locate(1,1,1),"up")
usr << showarrow

Z

#18 Nov 1 2000, 3:02 pm
In response to Zilal (#17)
On 11/1/00 2:05 pm Zilal wrote:
My desired improvement would be a better way to set icon states for the images being shown. Rather than:

var/obj/O = new /obj
O.icon = 'arrow.dmi'
O.icon_state = "up"
var/showarrow = image(O,locate(1,1,1))
usr << showarrow

I'd like something a little smoother...

var/showarrow = image('arrow.dmi',locate(1,1,1),"up")
usr << showarrow

Z

That's what functions are for, Z!

proc/Zimage(I,loc,state)
var/obj/O = new
O.icon = I
O.icon_state = state
var/ret = image(O,loc)
del O // important! Don't keep a bunch of objs around
return ret

var/showarrow = Zimage('arrow.dmi',locate(1,1,1),"up")
...


Admittedly we should just support states in the image() command, but right now is a bad time to be making feature requests. Too much work to do, so little time (er money, er both)
#19 Nov 2 2000, 9:27 am
In response to Tom H. (#18)
On 11/1/00 3:02 pm Tom H. wrote:
That's what functions are for, Z!

I thought that's what feature requests were for!

del O // important! Don't keep a bunch of objs around

Now... here's something I don't know... if I do the following:

var/obj/O = new /obj()
O.loc = usr.list_of_things
usr.list_of_things.len = 0

First, does O really get put in the list, or just a reference to O? Second, does O get deleted when the list length is set to 0?

Z
Page: 1 2