[Objects] Changing "Verb" right clicking list in Design Philosophy

Page: 1 2
#20 Feb 5 2011, 8:10 pm
In response to Midgetbuster (#19)
It was just sample code, trying to get across one of my ideas. It was not meant to be implemented as-is. It might not even be practical to do, like you said, but I couldn't think of any other way at the time. Also, in regards to your question, you can override tooltip() to add the current tooltip (before it's erased) to a global list -- that might help you in finding it. In addition, if they don't erase from that list, you can put them in a list like.. list("uid001"="active")
to dictate which are active. However, you might be better suited to just erase them from the list when they're done.

#21 Feb 6 2011, 9:26 pm
In response to DivineTraveller (#20)
Delete + Reposted with edits. to Avoid Double posting.

Well i found the correct window i went into the tooltip proc itself and edited around inside the "tooltip_page" var to output to me all the variables that were being created which showed to me that even though tooltip() proc increased the uid the actual browser ran one uid behind it. Easy enough i guess.

Then it was just a matter of checking if the window existed and either fading it out or removing it entirely which is supplied in the demo anyway.

The original post here had reference to a href problem (sending the links for customized item right clicks) i found the problem of why my HREF's were not working and that was due to the Client/Topic in the demo not calling the parent. So a simple fix there sorted all that out and im yet to fiddle with the hrefs in it yet but ill get to it.

more relevant up to date stuff

Now the thing im faced with mainly is not just allowing the tooltip to show up on passover but actually checking to make sure there hovering over the item/object as opposed to just passing through (which as it stands creates the tooltip with passing through).. The demo is -meant- to do that but the code is in the wrong places mainly cause sleep does nothing for the update mouse (which takes a minimum of sleep/spawn(2) to work) so passing through the object still displays the tooltip.

After i fixed that up the supplied oldx and y work fine.. But as you can guess updatemouse is called as you enter.. and naturally the mouse is going to move a tadbit. so therefore the tooltip never displays unless you position it precisely crossing the border of the atom. now at first hell what if i just allowed a + and - 32 pixel range allowance to display tooltip if they have moved the mouse.. sure that works.

But im a sucker for precision and it has to be spot on for me :p. so basically is there any way to make a nice boundary border i guess for in which it can calculate whether to display the tooltip or not. like "over object" in mousedrag. (best thing i could think of)

~Midget
~~Thanking you aton :D

#22 Feb 7 2011, 12:07 pm
In response to Midgetbuster (#21)
Midgetbuster wrote:
The original post here had reference to a href problem (sending the links for customized item right clicks) i found the problem of why my HREF's were not working and that was due to the Client/Topic in the demo not calling the parent. So a simple fix there sorted all that out and im yet to fiddle with the hrefs in it yet but ill get to it.

Thank you, I've adjusted my demo accordingly to now call the parent in client/Topic -- I hadn't initially thought of that, whoopsies.
more relevant up to date stuff

Now the thing im faced with mainly is not just allowing the tooltip to show up on passover but actually checking to make sure there hovering over the item/object as opposed to just passing through (which as it stands creates the tooltip with passing through).. The demo is -meant- to do that but the code is in the wrong places mainly cause sleep does nothing for the update mouse (which takes a minimum of sleep/spawn(2) to work) so passing through the object still displays the tooltip.

As was told to me, you could offload a loop into the javascript browser, which would continually update the mouse every tick. I don't do that here, because I did not think of it originally (and I may implement it later too), but that is another option for you -- it would update every tick instead of requiring at least two.

After i fixed that up the supplied oldx and y work fine.. But as you can guess updatemouse is called as you enter.. and naturally the mouse is going to move a tadbit. so therefore the tooltip never displays unless you position it precisely crossing the border of the atom. now at first hell what if i just allowed a + and - 32 pixel range allowance to display tooltip if they have moved the mouse.. sure that works.

I have also added this to the demo. It was another oversight on my part, I apologize.

But im a sucker for precision and it has to be spot on for me :p. so basically is there any way to make a nice boundary border i guess for in which it can calculate whether to display the tooltip or not. like "over object" in mousedrag. (best thing i could think of)

If I'm understanding you correctly, you can override MouseEntered(), and after the if() statement, you can add your specialized code there (since it carries a reference to the object there). Let me know if this is what you're talking about.

~Midget
~~Thanking you aton :D

Not a problem -- I'm glad it's working out.
#23 Feb 8 2011, 4:07 am
In response to DivineTraveller (#22)
EDIT: Also see edits at bottom of topic. added some more in on both edits and an additional quoted section.

Thank you, I've adjusted my demo accordingly to now call the parent in client/Topic -- I hadn't initially thought of that, whoopsies..
<haha no worries. i had a bit of a brain scratcher on that one till i actually looked through my environment for "Topic"


As was told to me, you could offload a loop into the javascript browser, which would continually update the mouse every tick. I don't do that here, because I did not think of it originally (and I may implement it later too), but that is another option for you -- it would update every tick instead of requiring at least two.
Unfortunately i think your referring to css or javascript in this case. both of which im mediocre at best at. so im unsure of how i would do that so i just have to settle with a spawn(2)

in regards to boxes:: I have also added this to the demo. It was another oversight on my part, I apologize.
The box idea is very nice, but if you dont use the offloader 1tick method as mentioned by you. you have to use a spawn(2) inside the HasMouseEntered otherwise even if outside the range the tooltip will still display. this could just be me, but those are the results i found. other then that that in range thing works wonders although the 5by5 may be a bit small in retrospect and not having a way to make a precise boundary around an object to read for your in_range proc could eventually be frustrating.
naturally a 5by5 would be reasonable if players dont hover in the center (or updatemouse is stalled a bit on mouseenter to allow time for placement of mouse)
 
        HasMouseEntered(client/c, location, control, params)
            var
                _oldx = c.mouse_x
                _oldy = c.mouse_y

            //wait a bit before comparing it again
            sleep(TOOLTIP_DELAY)

            c.update_mouse()
            spawn(2) //allows the mouse to fully update without a (offloader loop?)
                if(in_range(c.mouse_x, _oldx) && in_range(c.mouse_y, _oldy))
                    tooltip(c, "[c.uid++]", "[name]<br />[desc]", 256, 24*tooltipRows, c.mouse_x, c.mouse_y, 30, TRUE)


i could be wrong in this regard but heh atleast im trying i guess :D

If I'm understanding you correctly, you can override MouseEntered(), and after the if() statement, you can add your specialized code there (since it carries a reference to the object there). Let me know if this is what you're talking about.
This was more or less in regards to making "boundary" boxes for the atom but a more precision boundary as opposed to just a plus and minus from location of first mouse update.


I think you might be able to (and yeah, it makes more sense now). I think you could get away with modifying the verbs list, a lot. Or, you might be able to use my tooltip demonstration to cobble together a list, based on whatever variables you want, and then display that. Obviously, this was only designed for a hover-tooltip, but you could modify it to spawn labels instead of a browser control (or you could use client/Topic and send all your verbs through that, too). The premise is similar, if not the same.

hmm ive had no luck with this so far, using client or mob topics. as far as i can tell i need to send the item itself to the topic as an argument which is easy enough object=[src] on a mouseentered proc should send it off the right way.. the problem is i cant get it to launch the procs of said item when you click the href link to it :(. This will end up being used in Mob right clicking (possibly), item right clicking, skill tooltips to purchase the skill, so this is a main concern currently.


EDIT: i didnt notice the small delayer at first. but i do realize now that it gives time for a "stopper period", Although the spawn(2) is still needed (IMO) before releasing the tooltip just incase they fully move off. otherwise it still displays

EDIT2: also as a minor thing if using just desc and name for outputting on a tooltip, a silly lil way ive done it to auto calc was.. (24+(24*max(1,round((length(desc)/33))))).. 33 being the number of characters 256 lengthwise could hold.. seems to work for the most part i guess lol but pointless considering ill be changing it greatly but heh.

~Midget
#24 Feb 8 2011, 6:36 am
In response to Midgetbuster (#23)
Midgetbuster wrote:
Unfortunately i think your referring to css or javascript in this case. both of which im mediocre at best at. so im unsure of how i would do that so i just have to settle with a spawn(2)

JavaScript, yeah.

in regards to boxes:: I have also added this to the demo. It was another oversight on my part, I apologize.
The box idea is very nice, but if you dont use the offloader 1tick method as mentioned by you. you have to use a spawn(2) inside the HasMouseEntered otherwise even if outside the range the tooltip will still display.

I had noticed this, and I added sleep(TOOLTIP_DELAY/2) and I also made a note of it in the demo itself.

this could just be me, but those are the results i found. other then that that in range thing works wonders although the 5by5 may be a bit small in retrospect and not having a way to make a precise boundary around an object to read for your in_range proc could eventually be frustrating.
naturally a 5by5 would be reasonable if players dont hover in the center (or updatemouse is stalled a bit on mouseenter to allow time for placement of mouse)

I was not sure. I tested it originally with TOOLTIP_BOX_SIZE of 32, then I changed it to 5. It all works alright, and it's not too hard to change.

>       HasMouseEntered(client/c, location, control, params)
>           var
>               _oldx = c.mouse_x
>               _oldy = c.mouse_y
>
>           //wait a bit before comparing it again
>           sleep(TOOLTIP_DELAY)
>
>           c.update_mouse()
>           spawn(2) //allows the mouse to fully update without a (offloader loop?)
>               if(in_range(c.mouse_x, _oldx) && in_range(c.mouse_y, _oldy))
>                   tooltip(c, "[c.uid++]", "[name]<br />[desc]", 256, 24*tooltipRows, c.mouse_x, c.mouse_y, 30, TRUE)
>

i could be wrong in this regard but heh atleast im trying i guess :D

I'm glad you are! It helps me get the kinks out of my demo as well as add new features.

If I'm understanding you correctly, you can override MouseEntered(), and after the if() statement, you can add your specialized code there (since it carries a reference to the object there). Let me know if this is what you're talking about.
This was more or less in regards to making "boundary" boxes for the atom but a more precision boundary as opposed to just a plus and minus from location of first mouse update.

I think I see what you mean now, but in regards to DM, I'm not sure how it'd be done offhand.


I think you might be able to (and yeah, it makes more sense now). I think you could get away with modifying the verbs list, a lot. Or, you might be able to use my tooltip demonstration to cobble together a list, based on whatever variables you want, and then display that. Obviously, this was only designed for a hover-tooltip, but you could modify it to spawn labels instead of a browser control (or you could use client/Topic and send all your verbs through that, too). The premise is similar, if not the same.

hmm ive had no luck with this so far, using client or mob topics. as far as i can tell i need to send the item itself to the topic as an argument which is easy enough object=[src] on a mouseentered proc should send it off the right way.. the problem is i cant get it to launch the procs of said item when you click the href link to it :(. This will end up being used in Mob right clicking (possibly), item right clicking, skill tooltips to purchase the skill, so this is a main concern currently.

Try \ref[src] in the topic string. That's how you pass an object through. Then in topic() you can output the object to verify that you got the right one. Hopefully that will solve that problem.
EDIT: i didnt notice the small delayer at first. but i do realize now that it gives time for a "stopper period", Although the spawn(2) is still needed (IMO) before releasing the tooltip just incase they fully move off. otherwise it still displays

I did just add this in the new version of the demo. Perhaps, instead of sleeping, I could change it to a spawn() and do the checks (boundary, etc) for the tooltip in MouseEntered() instead of HasMouseEntered()? Do you think that would solve it?
EDIT2: also as a minor thing if using just desc and name for outputting on a tooltip, a silly lil way ive done it to auto calc was.. (24+(24*max(1,round((length(desc)/33))))).. 33 being the number of characters 256 lengthwise could hold.. seems to work for the most part i guess lol but pointless considering ill be changing it greatly but heh.

Yeah, you can do that for the default provided CSS -- if you change the CSS that becomes untrue. Especially when changing font or font size attributes. That's why I did it the way I did.
#25 Feb 9 2011, 6:46 pm
In response to DivineTraveller (#24)
Try \ref[src] in the topic string. That's how you pass an object through. Then in topic() you can output the object to verify that you got the right one. Hopefully that will solve that problem.
Arr that works perfectly it sends it to the items topic to which is where its meant to be. sweet :D, i think that pretty much fixes everything i need for the href side of displaying things for now anyway ill have to fiddle with it more.

Just some extra info on my part just me rambling :D
The tooltip demo works pretty much the way it should, what i was just trying to get across is if you wanted a more realistic tooltip that doesn't still display after you say move over an item stop and decide nah i dun wanna look at that, the spawn(2) or using an offloader loop (which i dont know how to do) is needed otherwise passing through the atom, pausing for asec and moving off still displays the tooltip, thats why as ive found everywhere you put Update_mouse. you need to spawn/sleep(2) before moving on. or results vary greatly.. Personally i prefer spawn over sleep so i use that in most cases (unless ofcourse the code dictates needing sleep) but if i can manage with spawn i use spawn

I did just add this in the new version of the demo. Perhaps, instead of sleeping, I could change it to a spawn() and do the checks (boundary, etc) for the tooltip in MouseEntered() instead of HasMouseEntered()? Do you think that would solve it?
Hey its your demo, do it how you wish to display it. I personally have put my tooltip displayers inside the mouseentered procs of the atom itself to reduce overhead

Just a codeview of what im running currently. most likely highly ineffective but for now it does the job =\ since i cant think of a better way to "streamline it"
items
    parent_type     =   /obj

    MouseEntered(location, control, params)
        if(!usr.client.hastt)
            world << "[usr.client.uid]"
            var/client/c = usr.client
            var/oldx
            var/oldy
            c.hastt = 1
            spawn(4)
                if(c.hastt)
                    c.update_mouse()
                    spawn(2)
                        if(c.hastt)
                            oldx = c.mouse_x
                            oldy = c.mouse_y
                            c.update_mouse()
                            spawn(2)
                                if(c.hastt)
                                    if(in_range(c.mouse_x, oldx) && in_range(c.mouse_y, oldy))
                                        tooltip(c, "[c.uid++]", "<font color = red>[name]<br /><a href='?src=\ref[src];action=get'>Grab [src]</a>", 256, 24*6, c.mouse_x, c.mouse_y, -1, TRUE)
                                    else
                                        c.hastt = 0

    MouseExited(location, control, params)
        if(usr.client.hastt)  usr.client.hastt = 0
        if(winexists(usr.client, "_[usr.client.uid-1]_tooltip._[usr.client.uid-1]_tooltip_browser"))
            var/alpha = 200
            while(alpha > 0)
                winset(usr.client, "_[usr.client.uid-1]_tooltip", "alpha=[alpha]")
                alpha -= 50
                sleep(1)
            winshow(usr.client, "_[usr.client.uid-1]_tooltip", FALSE)

only problem is i know the above code is dodgy but not quite sure on how i would better it. to make it more effective in the long run =\ the basic purpose of it is to not display more tooltips then needed. (which arises if you spam entering the atom :p)

> If I'm understanding you correctly, you can override MouseEntered(), and after the if() statement, you can add your specialized code there (since it carries a reference to the object there). Let me know if this is what you're talking about.
This was more or less in regards to making "boundary" boxes for the atom but a more precision boundary as opposed to just a plus and minus from location of first mouse update.

I think I see what you mean now, but in regards to DM, I'm not sure how it'd be done offhand.
Dang what a shame :p ive tried a number of different things aswell all to no success the closest that comes to it is your inrange thing.


#26 Feb 12 2011, 3:04 am
In response to Midgetbuster (#25)
Hmm i havnt had any luck of trying to find a better way of making sure 2 tooltips don't display.

Also as it stands i sometimes get one tooltip that decides it wants to ignore the code and then leave a screwed up tooltip residue that just sits there without being able to be removed which is a pain in the ass.

Havnt heard from you in a bit. been trying to page you but by the looks of things without buying a membership to byond. that doesnt seem like its going to happen. Probs go and buy the membership shortly just havnt decided yet.
#27 Feb 12 2011, 9:38 am
In response to Midgetbuster (#26)
Midgetbuster wrote:
Hmm i havnt had any luck of trying to find a better way of making sure 2 tooltips don't display.

Well, my idea earlier was a list on the client containing tooltips. It could be implemented as so:

client
  proc
    add_tooltip(string)
      if(!tooltips) tooltips = list()
      tooltips += string
    remove_tooltip(string)
      tooltips -= string
      if(!tooltips.length) tooltips = null
  var
    list/tooltips

Also as it stands i sometimes get one tooltip that decides it wants to ignore the code and then leave a screwed up tooltip residue that just sits there without being able to be removed which is a pain in the ass.

I have not had this happen yet, can you elaborate?

Havnt heard from you in a bit. been trying to page you but by the looks of things without buying a membership to byond. that doesnt seem like its going to happen. Probs go and buy the membership shortly just havnt decided yet.

I've added you to my pager, so feel free to drop me a line whenever I'm around, and I'll respond often as possible. If I miss something for >24 hours, it's best to send me an email.
#28 Feb 12 2011, 3:05 pm
In response to DivineTraveller (#27)

I have not had this happen yet, can you elaborate?
Arr ive removed the fading off function. Well its still there but i don't use it for the most part.

As noted by the snippet i gave i use mouseentered on the atom itself to display the tooltip and run a number of if statements which is bad imo. and then i use mouseexit to remove the tooltip. just sometimes, hasnt happened of late since i stuck an if statement inside the mouseexit it leaves the tooltip behind.

so my tooltips are displayed on mouseentering/over. and stay there until your mouse either leaves the boundaries of the tooltip or the item itself which then calls Mouseexited removing the tooltip.


Well, my idea earlier was a list on the client containing tooltips. It could be implemented as so:
so the argument inside the client proc (string) would that be the tooltip id (of the window) so _45_tooltip for example?. There should only really ever need to be one tooltip displaying at a time imo. so thats what im trying to achieve others may have different view on that but thats just me.

I've added you to my pager, so feel free to drop me a line whenever I'm around, and I'll respond often as possible. If I miss something for >24 hours, it's best to send me an email.
Much abliged.
#29 Feb 15 2011, 6:43 am
In response to Midgetbuster (#28)
Midgetbuster wrote:

Arr ive removed the fading off function. Well its still there but i don't use it for the most part.

As noted by the snippet i gave i use mouseentered on the atom itself to display the tooltip and run a number of if statements which is bad imo. and then i use mouseexit to remove the tooltip. just sometimes, hasnt happened of late since i stuck an if statement inside the mouseexit it leaves the tooltip behind.

That'd be why then. You're using MouseExit() to do it -- the setup you have could be acting touchy, and I could understand that it doesn't always remove it then. That's why I opted for an automatic removal -- it takes way too long to create the tooltip to rely on waiting for it on MouseEnter(), then try to remove it on MouseExit().

so my tooltips are displayed on mouseentering/over. and stay there until your mouse either leaves the boundaries of the tooltip or the item itself which then calls Mouseexited removing the tooltip.

Well, I go back to my previous idea, maybe it still applies. If you add it's id to a list, you technically have track of every tooltip that could be created, so on MouseExit(), you could just loop through and manually remove any further tooltips, just in case they're hanging, like in your case.

Well, my idea earlier was a list on the client containing tooltips. It could be implemented as so:
so the argument inside the client proc (string) would that be the tooltip id (of the window) so _45_tooltip for example?. There should only really ever need to be one tooltip displaying at a time imo. so thats what im trying to achieve others may have different view on that but thats just me.

Yes, but this is functionality that should actually be built into the demo anyway -- someone might want more than one, or want to use tooltips for something completely different, and I can't predict every possible usage. I might crack it open later this week or today, depending on how permitting my schedule is, and make that change.
#30 Feb 23 2011, 12:10 am
In response to DivineTraveller (#29)
-Thump thump.. it be alive semi revive of a thread =\-

So yea ive been using the tooltips list (ive added it to the users client since i only usually want one tooltip displayed at a time. whether it be the custom right click using it.. or a hover tooltip)

So yea ive tried using a while loop with sleeps in it to try and output the tooltip using the right timeframes needed to do it but that doesn't seem to like me either.

Just seems the way i want to do things just isn't wanting to agree with me.. =\
#31 Feb 23 2011, 6:40 am
In response to Midgetbuster (#30)
Well, I guess the next best thing you could do is look at Stephen001's EventScheduler library. It lets you queue events and execute them whenever you want. That might help you get the timing part right without the need for all of those sleeps and loops. It's a little bit more complication on something that shouldn't have gotten this complicated, but.. it's worth a shot?
Page: 1 2