Messages

16

General Programming / [JAVA] Issue replying to Datagrams

« on: June 22, 2010, 06:49:10 pm »

Some machines on my network are sending datagrams to me and I am trying to reply to them, but I am not sure how to code a datagram listener. The code below works (well, it receives the datagrams), but when I try to get the InetAddress it originated from, it is either null or my own InetAddress (I suppose it varies by what I try, but I always get one of those two results). How can I get the correct InetAddress to reply with another datagram?

Code: [Select]

setSocket(new DatagramSocket(1234)); // Just a setter for a DatagramSocket instance.

...

byte[] raw = new byte[256];
DatagramPacket datagram = new DatagramPacket(raw, raw.length);
getSocket() // Just a getter for a DatagramSocket instance.
           .receive(datagram);

...

datagram.getInetAddress(); // Either null or my InetAddress

Thanks

17

JavaOp Board / Re: Java Op

« on: June 22, 2010, 02:51:13 pm »

We understand what you are saying. The previous lead developer dropped the project so things slowed down activity (and, consequently) development wise. As Joe said previously, it is hard to maintain something when there are no bug reports. The lack of activity really harms the development of the bot to the point where users experience issues like yours. The previous lead developer also still hosts the site, but does not update it (or give access to someone that will). This is pretty much the root cause of the problems you are experiencing.

iago.

Just had to let that out.

18

JavaOp Board / Re: Modularization

« on: June 22, 2010, 02:36:41 pm »

Untangling a large cord is difficult, but it makes it easier to use in the end. Simalarly, Modularization would take a lot of time, but I think in the end, it would probably be worth it. Especially for people like me who have like no experience in whats going on except for a very primitive knowledge of Java.

The amount of time that would need to be invested into untangling is so large that it could instead be used to make something newer and more robust; this time using a framework like OSGi.

19

JavaOp Board / Re: Modularization

« on: June 21, 2010, 11:14:09 pm »

I tried to do this some time ago and failed horribly... It was like trying to untangle a really long cable

If this much needs to be done we might as well just start over and make JavaOp 3

20

JavaOp Board / Re: Java Op

« on: June 21, 2010, 10:16:33 am »

[23:55:31] [william@enterprise ~/Documents/Programming/javaop2]$ svn commit -m 'Using correct syntax for lance'

oh ty

21

General Programming / Re: [JAVA] Packet Joins

« on: June 21, 2010, 08:42:24 am »

Looking through PacketThread now! Thanks

EDIT: Works like a charm! Thanks!

22

General Programming / [JAVA] Packet Joins

« on: June 21, 2010, 12:37:55 am »

Joe brought something interesting up in the JavaOp section:

Because all the packet plugins are loaded by the core, not by the Battle.net plugin, so they'd be getting the raw socket data instead of packets. The only issue with that is that Battle.net is known to send packets in pieces or several packets in one clump, so there'd have to be a non-protocol-agnostic packet thread to pick these apart for parsing, not to mention it's not a good idea to trust TCP connections to have packets split perfectly, even if it's known to in the past.

I am currently working on a program with a (non-bnet) protocol, but have run into this issue. In particular, I have 13000 bytes of data split over a few packets. This is the code I am currently using:

Code: [Select]

public void run() {
while(true) {
try {
Packet buf = new Packet(); //Packet is just a small extension of iago's Buffer class, similar to BNetPacket in some ways.
int size = new Buffer(PacketTools.getInputStreamBytes(in, 4)).removeDword(); //This reads 4 bytes (packet size) into a new Buffer and converts them into an int
buf.addBytes(PacketTools.getInputStreamBytes(in, size)); //Read "size" number of bytes from the InputStream and add them to the buffer
// Do stuff
} catch (Exception e) {
e.printStackTrace();
return;
}
}
}
How can I change this so I can read multiple packets into that single Packet instance (buf)?

Thanks

23

JavaOp Board / Re: Java Op

« on: June 20, 2010, 10:13:04 pm »

I just got an idea for a new sig

24

JavaOp Board / Re: Updating a plugin to javaop 2.1.3 lost in forest

« on: May 17, 2010, 09:29:11 pm »

If the above does not resolve your issue, make sure you have no uppercase letters in your package names. It sounds strange, I know... But, yesterday when I was creating a plugin, I ran into the same problem. Lowercased package names and the error is gone

25

JavaOp Board / Re: Updating a plugin to javaop 2.1.3 lost in forest

« on: May 13, 2010, 10:07:10 pm »

http://code.google.com/p/javaop/wiki/Eclipse

26

General Programming / :<

« on: April 03, 2010, 06:14:19 pm »

:<

27

JavaOp Board / Re: StayConnected Problem

« on: March 02, 2010, 02:41:43 pm »

Something else to note: this is also an issue with all other login errors that disconnect the socket.

28

JavaOp Board / Re: Shaman join throws java.lang.NullPointerException

« on: February 25, 2010, 02:36:24 pm »

Update your SVN and check again. I added a bunch of general bad data checking.

Working great

Thanks!

29

JavaOp Board / Re: Modularization

« on: February 25, 2010, 02:10:47 pm »

I am posting in this thread classes that I think should be moved from the core to plugins so JavaOp is more modular.

I think Battle.net should have its own plugin (named Bnet, possibly making BnetLogin and BnetEventProcess parts of the plugin) to hold the protocol-specific classes. Of course there are plugins that use these classes from the core, but there is nothing wrong with having more than one project on the build path right?

com.javaop.util
BnetEvent > Bnet
BnetPacket > Bnet
BnlsPacket > Bnet
Profile > Bnet

com.javaop.users
Statstring > Bnet
War3Statstring > Bnet

com.javaop.constants
PacketConstants > Bnet (This is heavily based on the Bnet protocol )

com.javaop.bot
PacketThread > Bnet (This class is horribly dependant on the Bnet protocol and needs to be modularized somehow)

Once those are moved, adding IRC functionality and such will be a breeze

I agree entirely, except for PacketThread. PacketThread should be split so that the work directly with the socket remains where it is, but the raw data is sent to the other half of the class in the battle.net code. See, I'm not sure how to handle that though, since that'd require ALL plugins that use packets to have their own packet thread, but if I don't do it, we can't support anything but Battle.net.

It's a rock and a hard place issue. Hopefully I can address it after 2.1.3.

How would it require all packets to have their own packet thread?

30

JavaOp Board / Re: StayConnected Problem

« on: February 25, 2010, 02:07:58 pm »

At least it's catching disconnects, right?

I'll look into it.

Haha I suppose so!

Thanks