I know a while back Deadron was asking for a way to force one of the user's panels to the front... was that ever implemented?
Z
ID:138332
 Oct 26 2000, 11:45 am
|
|
Whoa, quick response. Another thing... I'm having problems getting prompts to the right players. Suppose I'm in this hypothetical proc:
mob Challenge(defender) src << "Asking the defender if the challenge is accepted..." I want to be able to prompt the defender. But farming it out to some defender:Challengeme() proc and prompting there always makes it prompt the challenger, not the defender. Prompt would be much more powerful if it were a built in mob proc, and we could prompt mobs at will. Obviously programmers could then create games in which players could annoy by interrupting each other with something that prompts them, but I don't think that matters. I would like the ability, as a coder, to prompt someone other than usr. Z | |
On 10/26/00 3:53 pm Zilal wrote:
Prompt would be much more powerful if it were a built in mob proc, and we could prompt mobs at will. Obviously programmers could then create games in which players could annoy by interrupting each other with something that prompts them, but I don't think that matters. I would like the ability, as a coder, to prompt someone other than usr. The first (optional) argument to prompt is the promptee, which defaults to usr. Example: prompt(someothermob,"Who's your daddy?") as text | |
On 10/26/00 3:58 pm Tom H. wrote:
The first (optional) argument to prompt is the promptee, which defaults to usr. Example: Dantom is so far ahead of us today! I also wanted to mention that when I asked about forcing the statpanel forward (which does work using Tom's method) that already existed even at that time, so I don't get any credit for making it happen. Screenshots, now, I'll take credit for... | |
On 10/26/00 4:33 pm Deadron wrote:
On 10/26/00 3:58 pm Tom H. wrote: Ah... I knew there was another argument there, but I thought it was... I dunno, default, not optional. So I never tried it. See what happens when you assume (part 2)? Now this makes a zillion things much easier... Screenshots, now, I'll take credit for... Poor Deadron. I wonder what the "greatest" implemented feature each of us suggested is? Z | |
I wonder what the "greatest" implemented feature each of us suggested is? Mine's popup prompts! It doesn't matter if Dantom was already planning on implementing it... it was my feature request! =) | |
On 10/26/00 3:46 pm Tom H. wrote:
I believe that you can set client.statpanel = "your_panel", but I don't know if I've ever tested it. Tell me if it works! Though Deadron asserts that this works, I can't get it to. I'm confused about how exactly to access client values when you're dealing with the mob anyway. Hehe... dealing with the mob. proc Betting(player1,player2) player1:statpanel = "Betting" Doesn't work. Actually, now that I check, even accessing player1:statpanel turns up nothing. What's the right way to do this? Z | |
On 10/28/00 1:48 pm Zilal wrote:
On 10/26/00 3:46 pm Tom H. wrote: Like this: player.client.statpanel = "Build" // Force Build panel forward. Remember this is a client thing...so if you are dealing with the mob you need to get its client first. [edit] Oh and you really really should avoid all the : referencing -- it will be the cause of bugs and keeps the compiler from helping you. In cases like this, to be a good little programmer, you should define things like so: Betting(mob/player1, mob/player2) player1.client.statpanel = "Betting" Another approach that is helpful in some cases (like when you know that usr is a player mob and you want to call a player mob proc): var/mob/player/this_player = usr this_player.PlayerProc() Yeah, I know you've heard it from me before, but it IS: [Deadron coding annoyance #732] | |
On 10/28/00 1:51 pm Deadron wrote:
Like this: I was wondering if that was it, but I didn't check. I had looked at the mob.client variable in the reference and somehow it convinced me it wasn't what I was looking for. [edit] Oh and you really really should avoid all the : referencing -- it will be the cause of bugs and keeps the compiler from helping you. I know that "should"... but I do it anyway, since if it causes bugs they're usually easy to find, and I keep a close watch on what gets passed into which procs. But also holding me back from the . operator was the fact that I didn't know you could do the above... put in "mob/" in front of my argument. I had no idea. Hey, if you guys can be oblivious about using ! to expand things in your command history, I can be oblivious about this. (By the way, !!-expand will go two commands back, and so on.) Z | |
On 10/28/00 2:13 pm Zilal wrote:
But also holding me back from the . operator was the fact that I didn't know you could do the above... put in "mob/" in front of my argument. I had no idea. Ah, well that would explain a lot of how you got into this habit! Yes, it's always wise to specify the type of the parameter when you know what it will be. I should do like W3.org does for HTML, and put up a utility that will scan BYOND code for breaking the Deadron rules. The world would be a happier place. Well, not really, but *I* would be happier, and that's what matters. | |
I believe that you can set client.statpanel = "your_panel", but I don't know if I've ever tested it. Tell me if it works!