Clan x86
Technical (Development, Security, etc.) => JavaOp Board => JavaOp Support Archive => Topic started by: iago on April 23, 2008, 06:26:48 pm
-
I can give you an updated version of bnetlogin that supports Warden to a point (can display information about + download Warden modules). It could probably be modified to send back proper responses as well, although I'd put it off by default because it risks a ban.
-
Wouldn't it be better to move Warden stuff to Warden.jar?
I was in the middle of doing that before I got bored and wondered off.
-
I'd say no, because it requires information from the login. It's possible to get that info from another plugin, but it's a little messy.
-
I havn't actually looked at all the data that is exposed to plugins.
Are Client/Server tokens and CDKey exposed?
Thats all you need.
-
Nope, those are all private data.
They can be shared, in a roundabout way, but like I said, that'd be messy.
-
Or, I could go ahead and expose them. I agree with Hdx. Warden.jar should handle SID_WARDEN as Warden isn't part of the logon protocol per-se.
But what it comes down to is that it's your bot. It's up to you.
EDIT -
It'd be simple to enable/disable Warden answering if it were separate, as Warden.jar could just be disabled.
-
In my opinion, most of the Warden stuff should always run, the only thing that shouldn't is responding to 0x02.
Put it wherever you want, but it's already included in the login plugin. I also put all the lockdown code into the login plugin.
-
If you could send me your Warden code via email, that'd be appreciated. :)
-
Sure, email me your address and I'll send it right out.
(That's not supposed to sound sarcastic :P)
-
Sure, email me your address and I'll email you mine.
Actually, I just emailed your skullsecurity one that's in your profile.
-
My solution to turning 0x02 on/off is to not send it if Starcraft.exe doesn't exist in the program folder :)
That way, users have to read the disclaimer to figure out how to turn it on.
-
when is JavaOp43 scheduled to release?
-
As soon as I find a sober weekend to program on.
And a JDK 1.4 package for Ubuntu. Hint hint, guys. :)
-
As soon as I find a sober weekend to program on.
Yeah those Smirnoff Ice's are really fucking you up, huh?
-
No, but three shots of everclear isn't exactly what I'd call light.
-
Support Korean.. :-)
-
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.
-
Thank you Joe for putting my need to your list ^^
-
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
-
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.
-
/me 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.
-
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.
-
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 was also thinking maybe you could do tabs for different profiles or have the option to do that. like the tabs in BNU Bot.
-
And a JDK 1.4 package for Ubuntu. Hint hint, guys. :)
- You should be able to find JDK 1.4 in Sun's archive (https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewFilteredProducts-SingleVariationTypeFilter).
As far as I know, it'll be a Redhat package. You can use Alien (http://kitenet.net/~joey/code/alien/) to create a Debian (Ubuntu) package from it, however.
-
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.
-
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.