Valhalla Legends Archive

It seems rather wasteful to design a massive GUI just to configure a bot.  Just document the configuration file format and tell them to use a text editor.

Quote from: Kp on August 10, 2004, 09:34 AM
It seems rather wasteful to design a massive GUI just to configure a bot.  Just document the configuration file format and tell them to use a text editor.

Who said anything about a massive GUI?, a few dialog's massive? lol

Thats what windows is based on windows messaging//GUI interface i.e the purpose of GDI//user32.dll ( Assuming the bot is targeted for windows, if not then well then it wont apply to 90% of users around the globe )

Configuration files are real user friendly , why not just get the user to write a help file for you while hes at it?

Then you have the potential for file format errors caused by the user entering the data wrong, as apposed to using a self validating user friendly GUI let the people decide

If we follow your logic why does'nt windows or IE just use configuration files that the user must edit directly instead of a clean easy to use self validating GUI?

Configuration files are easy, and many times I prefer them over a GUI setup form.

If they can't fill out a username, password, server, cdkey, and channel without messing it up, they shouldn't be using the bot anyway.

Also, if this is like the console based JBBot, it has input boxes when the bot starts.

What does Windows have to do with it? Java is cross-platform, and a lot of this bot was designed/tested on a Linux operating system. If people can't figure it out they can go back to using the kiddie-friendly Stealthbot.

Quote from: OnlyMeat on August 10, 2004, 08:38 AM

Quote from: iago on August 07, 2004, 04:12 PM
JavaOp is cooler.  I don't care why.  

http://www.valhallalegends.com/iago/javaop.jpg -- ain't it sexy? It looks even cooler now, but I don't feel like Screenshotting a console

<edit> what the hell:
http://www.valhallalegends.com/iago/javaop2.jpg

Not heard of the new revolution? it's called GUI

Quote from: iago on August 07, 2004, 04:12 PM
Dynamically loaded event and packet handlers is sexy.  You can add stuff to the bot without touching my code

Why not just add scripting support?

Because native java code is faster, and instead, he could write a scripting plugin that is dynamically loaded, so you kill 2 birds with 1 stone.

hismajesty and others already answered this, but eh?

For configuration, I use java.util.Properties.  It generates a file that looks like this:
debug=false
cdkey=
trigger=%
port=6112
server=63.240.202.130
username=iago
homeChannel=op e1-
returnPing=true
password=
loud=false
game=warcraft iii

If you can't figure out to edit that, kill yourself.

Next, I want it to run as what Windows people would call a "service".  That is, run in the background when the computer starts.  If I have a console like the one you see, I can redirect stdout to a file and thus, I have a log file.  If I had a gui, I would have to write seperate stuff for running it headless.

Finally, it's going to have a client-server model.  What you're seeing is the server, and the client doesn't exist yet.  The client can be programmed in your favourite language for that platform and interface with the server either locally or remotely.  This offers the flexibility of a strong Java back end with a pretty gtk or vb front end.

And I screenshoted the console, yes, and it looks nicer than yours.  So owned!

New screenshot:
http://www.valhallalegends.com/iago/javaop3.jpg

So not a working link!

Quote from: Soul Taker on August 10, 2004, 01:07 PM
So not a working link!

That's because jbbot3 doesn't exist.

http://www.valhallalegends.com/iago/javaop3.jpg

Quote from: hismajesty[yL] on August 10, 2004, 01:16 PM

Quote from: Soul Taker on August 10, 2004, 01:07 PM
So not a working link!

That's because jbbot3 doesn't exist.

http://www.valhallalegends.com/iago/javaop3.jpg

It exists, it's just not maintained anymore.  JavaOp is its successor, using much of the same code.

And I edited/fixed the link.

Quote from: $t0rm on August 10, 2004, 11:30 AM

Because native java code is faster, and instead, he could write a scripting plugin that is dynamically loaded, so you kill 2 birds with 1 stone.

Correct me if im wrong but is'nt java compiled to a pseudo//Byte code format that uses a JIT at runtime to provide native support?

Which means both java and scripting ( and if you encode activex scripts they produce the same sort of byte code output ) are interpreted at runtime?

If they are both interpreted at runtime how can native java be faster ? java is never really native when the code actually runs it;s just interpreted exactly the same as scripting.

Your second point - if you are going to add scripting support why is their a need for dynamic loading? scripting support would be loaded at the start of the program, and if you want it to be some kind of plugin why not just use loadlibrary??, infact if you are making some kinda of server scripting it should really exist in a completely distinct process for safety reasons as you dont want the scripting to cause a gpf while injected into your main process.

Quote from: OnlyMeat on August 10, 2004, 09:21 AM

Quote from: hismajesty[yL] on August 10, 2004, 09:11 AM

Why does a moderation bot need a GUI?

For the user to configure it in the first place?, Unless your bots autoconfigure themselfs :p

My bot reads my mind.

Quote from: Myndfyre on August 10, 2004, 07:33 PM

Quote from: OnlyMeat on August 10, 2004, 09:21 AM
For the user to configure it in the first place?, Unless your bots autoconfigure themselfs :p

My bot reads my mind.

That would cause some major configing issues with 90% of your bot users.

Quote from: OnlyMeat on August 10, 2004, 07:02 PM

Quote from: $t0rm on August 10, 2004, 11:30 AM

Because native java code is faster, and instead, he could write a scripting plugin that is dynamically loaded, so you kill 2 birds with 1 stone.

Correct me if im wrong but is'nt java compiled to a pseudo//Byte code format that uses a JIT at runtime to provide native support?

Which means both java and scripting ( and if you encode activex scripts they produce the same sort of byte code output ) are interpreted at runtime?

If they are both interpreted at runtime how can native java be faster ? java is never really native when the code actually runs it;s just interpreted exactly the same as scripting.

None of your points make sense... Being able to dynamically load classes at run time gives you the power of the language you are using, so why would you need a scripting language? Why waste time interpreting a language with a language that is already interpreted...

QuoteYour second point - if you are going to add scripting support why is their a need for dynamic loading? scripting support would be loaded at the start of the program, and if you want it to be some kind of plugin why not just use loadlibrary??, infact if you are making some kinda of server scripting it should really exist in a completely distinct process for safety reasons as you dont want the scripting to cause a gpf while injected into your main process.

What exactly are you arguing about? It sounds like you haven't heard a thing anyone has said so far...

Quote from: OnlyMeat on August 10, 2004, 07:02 PM

Correct me if im wrong but is'nt java compiled to a pseudo//Byte code format that uses a JIT at runtime to provide native support?

That is correct.

Quote from: OnlyMeat on August 10, 2004, 07:02 PM
Which means both java and scripting ( and if you encode activex scripts they produce the same sort of byte code output ) are interpreted at runtime?

If they are both interpreted at runtime how can native java be faster ? java is never really native when the code actually runs it;s just interpreted exactly the same as scripting.

No, it's not *exactly* the same as Scripting.  Java's bytecode is much closer to low-level language, *AND* because it's binary, you don't need to worry about "tokens," which are the text words and operators used in a high-level language.

Also, in script environments, variables are type-evaluated at runtime.  Which means, while Java decides types at compile-time, JavaScript has to worry about making sure methods exist on a variable before calling that method on a variable.

Quote from: OnlyMeat on August 10, 2004, 07:02 PM
Your second point - if you are going to add scripting support why is their a need for dynamic loading? scripting support would be loaded at the start of the program, and if you want it to be some kind of plugin why not just use loadlibrary??, infact if you are making some kinda of server scripting it should really exist in a completely distinct process for safety reasons as you dont want the scripting to cause a gpf while injected into your main process.

Since you missed, JavaOp is written in Java, and since it's meant for cross-platform compatibility, it can't rely on platform-specific functions such as LoadLibraryA and LoadLibraryW.

Quote
Correct me if im wrong but is'nt java compiled to a pseudo//Byte code format that uses a JIT at runtime to provide native support?

Correct

Quote
Which means both java and scripting ( and if you encode activex scripts they produce the same sort of byte code output ) are interpreted at runtime?

Correct

Quote
If they are both interpreted at runtime how can native java be faster ? java is never really native when the code actually runs it;s just interpreted exactly the same as scripting.

Well, if your interpreter is written in Java, it's going to be running "java-speed." Thus, your interpreter will be running at "java speed" + "interpreter speed", which is slower than just native java bytecode.

Quote
Your second point - if you are going to add scripting support why is their a need for dynamic loading? scripting support would be loaded at the start of the program, and if you want it to be some kind of plugin why not just use loadlibrary??, infact if you are making some kinda of server scripting it should really exist in a completely distinct process for safety reasons as you dont want the scripting to cause a gpf while injected into your main process.

This is java my friend...we don't get GPFs

Why not implement scripting as a plugin? Then you get the best of both worlds, with zero drawbacks?

To add to MyndFyre's point, not only does it not have to worry about processing tokens, it can also arrange the code in a tree of sorts (in a logical order for the processor) instead of in an order that is logical for the human writing it.  

I timed CheckRevisions on my computer:
War2/starcraft: 60ms
War3 700ms (the first time, to load the file) and about 150ms after that.  

Compare that to how long it takes in Visual Basic or Perl, and you'll find that Java is considerably faster.
 

<edit> if any mods of this board are still reading, can you move this over to my forum?  This has turned into a discussion about my bot