Skin Problem.

ID:155213
 
Aug 19 2011, 7:06 am
I've been attempting to make a mini-program which works sort of like MSN, it all works up to one point, where there is an input box at the bottom of the window, it's default command is set to the verb which initiates the whole program, however I can't manage to get it to automatically have the target sender set from the first initiation of the verb. This is the code I currently have.
        Send(mob/M,t as text)
            if(t==""){return}
            //if(M==src){return}
            M << output("[usr.name]: [html_encode(t)]", "PMChat.output1")
            M << output("[src]","PMChat.LName")
            winshow(M,"PMChat",1)
            winshow(src,"PMChat",1)
            src << output("[usr.name]: [html_encode(t)]", "PMChat.output1")
            src << output("[M]","PMChat.LName")

Basically, once I enter text into the input bar, it'll call this verb but it won't know who M is and I don't know how to go about it to set it once I already picked the person. If you need further explanation or think you can help, any ideas will be helpful.
Aug 19 2011, 8:04 am
Change it to take both arguments as text. Then, use the first argument as a \ref[] macro result. You can use locate() to convert the \ref back into a reference to a mob.

When you set the command of the window, do:
winset(<player>, <input id>, {"command="Send \ref[receivermob] ""})

This will set the first parameter to be a reference to the mob.
So, your Send would now be:
Send(ref as text, t as text)
    var/mob/M = locate(ref)
    ...

Well, that's one way to do it. I kind of don't recommend that, though, because there are a lot of issues with it. (The ref could now be pointing to a different mob or the mob could no longer exist. Players logging in and out causes problems.)

What I would recommend is the player having a list of mobs they are chatting with stored in a var. Then, the first parameter to the Send can be <code>as num</code> and you use the number as an id (index to the list, perhaps) to get what mob it's supposed to work with. The advantage to this is that if the mob was deleted, you can now detect it, because the entry in the list will be null.

(You'd set the command like this:)
winset(<player>, <input id>, {"command="Send [listindex] ""})
Aug 19 2011, 8:24 am
In response to Complex Robot
Ahhhhh I get it :) Thanks for the help man :) Appreciate the quick replies.
Aug 19 2011, 3:37 pm
In response to Complex Robot
You don't need to be what convoluted about it.
mob/verb/Send(mob/M as mob in world, T as text)
    src << "Sent [T] to [M.name]"
    M << "Received [T] from [src.name]"


Now when you set the command of the input you simply have to do:

winset(src,"mywindow.input","command='Send [send_to] \"'")


With send_to being who you're sending it to, the extra space and quotation at the end make it so you're automatically entering the second argument of Send(). The first argument just needs to point at a player, even entering their name as the first argument will execute the verb as expected -- as long as that player exists in the game.
Aug 19 2011, 6:23 pm
In response to Nadrew
Yeah, but that poses issues.
(Like, what if their name changes.)
And has the same problems I mentioned about the mob getting deleted.
Aug 19 2011, 10:36 pm
In response to Complex Robot
WWell can't you do a check if the client exists, if not then give them a message, close the window, and call the verb to start from the beginning again? However there is a problem to which if the person's name has two names like "Dan Tom" the program will print out ~~ Dan Tom:Tom "Hello ~~ Dan Tom being the person who spoke, and Hello being the message, as you can see it treats Tom as part of the text since it takes only Dan as the mob as well as Dan Tom, the actual mob, however it helped me make some progress so thanks :) Will jiggle around with it for a bit to fix the bugs, once I sort the double name problem.
Aug 19 2011, 10:58 pm
In response to SolarNews
Use a ckey() value instead of the actual name. You can also replace the spaces with -, but that is a bit more of a task than just using ckey().
Aug 19 2011, 11:19 pm
In response to Nadrew
That actually makes sense xD How I did it was initiate the verb with a mob/M then set var/Target as M.ckey, and put Target as the initial command for the first parameter of Send, however it doesn't seem to recognize the clients key, do I need to turn it back into their name after? I keep getting the error Sorry, the following is not valid: solarnews
usage: Send mob "text" probably an easy fix but can't seem to find the right direction, if you can point me there would be a great help too :)
Aug 20 2011, 1:27 am
In response to SolarNews
You can't use "as mob" if you use the ckey. (That will only work with the name of the mob.)
And the way BYOND handles spaces in identifiers of commands is it replaces them with hyphens (-). So, if you still want to do it "as mob" you're going to have to set the command with the spaces in the mob's name replaced with hyphens.
(Which Nadrew mentioned briefly.)

If you want to use ckey, you're going to have to change it to "as text" and then search the clients or mobs in the world to find one with a matching ckey.

I still think it's a bad idea to use the name, unless your game doesn't allow two players to ever have the same name.

Maybe I misinterpreted, but I thought you were designing a system where you could have multiple chat windows at once. I guess I was wrong. (I'm annoyed for trying to help you and my methods being completely ignored. Makes me not want to help. >.>)
Aug 20 2011, 1:32 am
In response to Complex Robot
I was just providing a simple example for a simple chat system, if the system is running in an environment where name changes and things of that nature are common then the locate() + \ref method of doing it is the best one. Handling a player logging out by closing any open chat windows to that player and clearing the values associated with it is the best way to avoid conflict.
Aug 20 2011, 1:54 am
In response to Complex Robot
Noo I haven't ignored your methods at all, it's just when I came on today to reply to your message to try get a better understanding of your method, I saw another way which I understood in a better sense and attempted that one, however, I was planning on going for multiple chat windows but was just going to have them winclone the chat window without any text entered for the new mob, but I never thought into it for much detail. I've realised this system is alot more difficult than I previously thought. I liked your method of setting the players into a list and comparing its index according to the list, it's just that would mean multiple windows would be opened already and just haven't got there yet, I'm just focusing on sending the text across succesfully through the input bar then I'll add a drop down menu or button with the list of people they are talking to and let them choose there by comparing their index in the list and finding the appropriate conversation.
Aug 20 2011, 2:15 am
In response to SolarNews
Yeah, sorry. I'm a little exaggerative sometimes.

Anyways, you might want to try only having one window, but using a tab control to make multiple tabs. Then you can winclone panes to add to the tabs list.
Aug 20 2011, 2:30 am
In response to Complex Robot
It's cool I understand, I just hope you understand I didn't mean to make it seem like I was ignoring your methods etc and I really appreciate your help :) Yeah that makes more sense so it doesn't get so cluttered with windows xD So just clicking on the appropriate tab will bring up the appropriate panes for each window, interesting
Aug 20 2011, 1:15 pm
In response to SolarNews
You can also have a tab-change verb so you know when the player changes tabs, if that's of any use to you.