UDP output

[TriggerHappy]

Ok, I slogged through code, learned a fair deal of C++ (from knowing nothing) and got the general sense of how SHOWEQ works-- enough to find places in the code where I can output inofrmation I want to the printf stream. And it works.

Now I want to use QSocket and Qsocketdevice to send that information to another machine.

I understand what these services do, but am having problems finding the info to make Qsocketdevice work properly (Trolltech has the general info of course, but implementation of QSocketDevice comes with no examples from which I can learn-- I slogged through the book on GUI interfaces from O'Reily and done a zillion Google searches as well to no avail). I got QSocket to work great, but the TCP packages are not as easy to accept on the EQ client as I want as can be the UDP messages.

Can anyone help me with an implementation of UDP via QSocketDevice Datagrams? I just need to know how to set up the QObject correctly and I can adapt from there.

[TriggerHappy]

Well, wrote an app that accepts incoming TCP on windoze. Not as hard as I thought. So I am fine.

Would still like some pointers on QSocketDevice if any mavens out there.

[Cryonic]

What exactly are you trying to program SEQ to send to EQ? From previous posts you make it sound like you are trying to create an EQ bot that it is either autonomous or a follow/helper bot.

[TriggerHappy]

Yes, I was doing that. I have found a couple of places and written the code to send info on my position (loc and heading) and the position/heading of the targetted/considered mob. I compiled it and it works great. Since I was asked not to post the exact information by Zaphod perhaps I was being too vague here out of respect for not upsetting any apple carts.

I am sending the information to a macro program on the client machine-- there are a couple of these that work, not just Xylobot. The main purpose is to frankly keep the tank targetted while I work the scene with a healer or other Player Character.

So, I can get that info to the desktop rather easily now through printf output. I just need to redirect the printf to a different output. I have a few options from here:

1. Use a receiving API/GUI on the EQ client that receives TCP from QSocket. I have written a small GUI that can send this via TCP and can fairly readily incorporate this into SEQ. I have a receiving Windows GUI that writes to info to disk now but it's a bit clunky having it access the disk all the time. By writing to the disk it allows the macro program to access the information.

2. Configure the linux box to write to disk (either the linux box or the EQ client) and have the macro program access the info from a file there. Just got to get my linux box on the microsoft network somehow. Have not looked into this but probably not hard.

3. Have the macro program directly access the UDP datagram. Since the more sophisticated of the macro programs only accepts UDP, it seems, in it current incarnation I was trying to get a direct output to the macro program through datagrams.

Option (2) is the easiest to implement, requiring no socket messing. Option (1) needed me to learn more about programming-- not a bad thing and it was easier than I thought. Just a language uplink to brain thing. Option (3) is the most elegant solution and dammit, of course, the hardest.

Though I will settle for what I have with (1) and (2) so I can finish programming the targetting macro for the tank (this is super-easy) I wanted the elegant solution as an option should I decide I want to start sending MORE information in the future (spells on player(s), HPs of PCs and NPCs, nearby mobs).

Cryonic, if you can help with a QSocketDevice (type = Datagram)procedure for me-- even with some general notions I would be appreciative.

[casey]

man socket
man sendto

if thats not enough, then play EQ like a normal person~

[Pyzjn]

Hey Trigger (Drowconjurer) if its not being to cheeky can ya give me some pointers as to the mods you did to the SEQ source ? I aint a C programmer (yet) but I am working on it. My email addy is on my profile on the xylobot board.



I dont wanna p**s anybody off so its prolly best if you contact me if you can help and I wont post about this here again.

[TriggerHappy]

Casey:

Please define normal in the world of ShowEQ~

:)

Thanks for the tip. I think I got it figured out now anyway, but your input is appreciated and I will look into that. From the looks of it it seems from what you are suggesting I was going overboard on the approach.

[who_me_use_seq]

I don't know if I can contribute anything to this conversation. The people in this forum tend to be more knowledgable than I am.

But if what you need to do is pass SMB traffic to and from a Linux box, Samba is a fairly standard tool with which to do that.

Sorry if I misunderstood the nature of your requirement.

--------------------------------------------------------------------------------------------------------------------

Comic book colors on a violin river
crying Leonardo words
from out a silk trombone
I rang a silent bell
beneath a shower of pearls
in the eagle wing palace
of the Queen Chinee -- Robert Hunter

[high_jeeves]

This conversation has nothing to do with SMB, it has to do with writing an application to transmit using UDP.

--Jeeves

[TriggerHappy]

Samba yes could do it simply to write to the file-space but I am trying to get beyond file-writing issues-- too much data to send/read and I don't want the overhead it causes.

I have found the way to do it with QSocket and QTextStream-- it still sends only TCP packages at present but I have a converter app written on the PC now that faithfully converts. I wrote a litle app that works on the linux box as a stand-alone. I am rewriting it now as a QObject to hook into the signal/slot mechanism of SEQ so it calls a routine to send data when appropriate emits are done.

I am still messing a bit with QSocketDevice but its trickier. I figure I will stick with what works, get the main parts written with the QSocket and go from there.

Looking up the send and sendto and socket requirements (base classes for QSocket and QSocketDevice) was quite helpful in figuring this out for me-- sockets are a messy business indeed, especially when converting the IP4 addresses to appropriate byte order for the socket connections.

[casey]

Looking up the send and sendto and socket requirements (base classes for QSocket and QSocketDevice) was quite helpful in figuring this out for me-- sockets are a messy business indeed, especially when converting the IP4 addresses to appropriate byte order for the socket connections.

socket() and sendto() are standard library functions, not classes (classes do not even exist in C). byte order is not messy.

ntohs()
htons()
ntohl()
htonl()

these are all in the form of

(network | host ) to (host | network) (short | long). Just remember to convert to network byte order when sending, and convert back to host when you recieve. recvfrom() is the matching call to sendto() to recieve data. You will also want to take a look at bind() so you can set a port and ip for the socket to listen to (so your sender knows where to send to).

messing with the QT classes is overkill, especially since the process using the QSocketDevice class is pretty much the same. QSocketDevice::bind(), connect(), readBlock() and writeBlock(). Not really much easier to use, since this class is really just rehashing the functions i've told you to look at, making a couple calls easier (QSocketDevice::setBlocking() vs a call to setsockopt() for example). And pure socket calls are just slightly less portable than the QT stuff to windows, windows can use BSD sockets (the functions ive been talking about) with only a single extra call to WSAStartup() or something like that.

[TriggerHappy]

I have it all working perfectly now. Those last pointers worked great Casey.

:)

Very happy camper indeed.

Thanks for all the help Casey and everyone. I was hooting and hollerin' last night when it all worked.