Split from: Changes / bugfixes requested for beta43.

[Korean]

Support Korean.. :-)

[Camel]

As soon as I find a sober weekend to program on.

And a JDK 1.4 package for Ubuntu. Hint hint, guys.

Why do you need a 1.4 JDK? Just use javac -source 1.4 -target 1.4; or, in eclipse, you can set the project/global properties for this under the Java Compiler page.

[h4x0rz88]

Thank you Joe for putting my need to your list ^^

[BoBbY)eD(]

think it would be possible to put it a couple tabs for friends list channel and Clan? like in SB and make it so you ccan invite ppl into clans

[Joe]

Good call, Bobby. Added to the list.

This is looking more and more like a JavaOp3 than a JavaOp2b43 though. Which isn't necessarily a bad thing.

Whoever is in charge of JavaOp3, or whatever is being done for that, please get a hold of me.

[Hdx]

* HdxBmx27 still doesn't understand why you do not simply SVN the code/jars and write the core to list/download plugins in realtime from the svn server.

Makes it a lot easier then having a general rev # could just have each plugin w/ its own version.Only problem with that is the non-x86 users who write plugins will still have to distribute them the old fashioned way.

[Camel]

Designing an application to be modular enough to update major components (which is what javaop "plugins" really are) is a pretty incredulous task, and I'm not even referring to the part where you implement the action of downloading dependencies. To avoid going in to technical details, I'll just give an example: firefox plugins. When a new version of firefox comes out, plugins often break and need to be updated. I'm not convinced that the JavaOp project is large enough to justify that level of control; it makes more sense to distribute it the way it's done now, and just keep all the plugins in svn in sync with trunk's head.

As an aside, trunk's head sounds pretty dirty.

[Hdx]

To be honest, isnt the only things of javaop you need the core.. and the command line configure? No plugins persay.
As for dependencies you really dont need ANY as it's java. All your deps are held in the jvm...
The few things you *might* need are image, which can be packaged into the plugin's jar.

Ugh, I need time, I have 2 major projects i'm working on, [RPG with friends, and JBLS re-write]

Anyways, since when is the core of JavaOp changing? Its a good solid layout as is, you have an interface, you implement it. simple as that.
Meh just thinking out loud about what I think would be a good idea. It does not need to be re-designed. You know... I could probably write a PLUGIN to do the svn control.....

[BoBbY)eD(]

i was also thinking maybe you could do tabs for different profiles or have the option to do that. like the tabs in BNU Bot.

[michealPW]

And a JDK 1.4 package for Ubuntu. Hint hint, guys.

- You should be able to find JDK 1.4 in Sun's archive.

As far as I know, it'll be a Redhat package. You can use Alien to create a Debian (Ubuntu) package from it, however.

[Camel]

To be honest, isnt the only things of javaop you need the core.. and the command line configure? No plugins persay.
As for dependencies you really dont need ANY as it's java. All your deps are held in the jvm...
The few things you *might* need are image, which can be packaged into the plugin's jar.

Ugh, I need time, I have 2 major projects i'm working on, [RPG with friends, and JBLS re-write]

Anyways, since when is the core of JavaOp changing? Its a good solid layout as is, you have an interface, you implement it. simple as that.
Meh just thinking out loud about what I think would be a good idea. It does not need to be re-designed. You know... I could probably write a PLUGIN to do the svn control.....

I don't know about what JavaOp has for dependencies, but I know my bot has a bunch of dependencies. I use a lot of code that isn't part of the JRE - Apache Cayenne is the ORM framework I use to abstract away the database, for example.

I only distribute two images with my bot: one for the tray icon, and one for the dock icon (OSX only). I get the channel icons from Icons.bni, which the bot downloads via BNFTP when it connects.

[drt1245]

Handle Diablo 2 usernames the same way usernames are parsed for other games.
As it is, usernames are handled the same way they are in game (which is understandable). i.e.: CharName(*Username)
It'd be really nice if they were handled as they are for other games (or at least there was an option to do so, if not the default behavior).

Would make things significantly less confusing, especially if using multiple bots.