arfer,
I don't suppose you've thought of implementing support for the eggdrop language files themselves?
If you're comfortable with GPL, you could pretty much rip the lang-support straight out of the eggdrop source. Otherwise, it would'nt be too hard to backport support for it either.
This is the new home of the egghelp.org community forum.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
Eggdrop Telnet Client
It certainly crossed my mind nml375. I suppose the reality is that I don't really need to. There are three areas that I need to deal with. First, and most important, those relatively few messages the client needs to capture in order to function correctly. Login username prompt, password prompt etc. Secondly, the few words the client echos to the console in response. Finally, the client user interface needs to be translated for the convenience of users from other geographical areas. The latter two issues have nothing to do with the Eggdrop language files directly. Thereafter the user will see in the partyline whatever language their Eggdrop is set to. There is no need to translate.
CrazyCat, I have hopefully resolved the first of the above (urgent) requirements. Namely, translation of captured messages. I have uploaded version 1.1.2.105 to http://defero.ircspeed.org .. I wonder if you would be good enough to give it a try with your French bots. Uninstalling the old version will not lose the connection strings you have already set up.
I don't suppose their are Danish, Finnish and German users keeping abreast of this thread that could test the client with their bots? I have made bots in all 5 languages so I'm fairly confident but confirmation would be good.
CrazyCat, I have hopefully resolved the first of the above (urgent) requirements. Namely, translation of captured messages. I have uploaded version 1.1.2.105 to http://defero.ircspeed.org .. I wonder if you would be good enough to give it a try with your French bots. Uninstalling the old version will not lose the connection strings you have already set up.
I don't suppose their are Danish, Finnish and German users keeping abreast of this thread that could test the client with their bots? I have made bots in all 5 languages so I'm fairly confident but confirmation would be good.
I must have had nothing to do
Eggdrop community
French IRC networkThanks crazyCat.
However, all is not perfect yet. I am still having difficulties with the consistency of the nick login prompt with some users bots.
Sometimes the prompt is :-
'Please enter your nickname.'
This is from core english file 0x53e
My client is coded to capture and respond to this prompt
Sometimes the prompt is :-
'Nickname.'
This is from core english file 0x540
My client is not coded to capture and respond to this prompt
I have not yet been able to discern where and why there is a difference. I would prefer to understand it before adding code, if anybody can assist please.
However, all is not perfect yet. I am still having difficulties with the consistency of the nick login prompt with some users bots.
Sometimes the prompt is :-
'Please enter your nickname.'
This is from core english file 0x53e
My client is coded to capture and respond to this prompt
Sometimes the prompt is :-
'Nickname.'
This is from core english file 0x540
My client is not coded to capture and respond to this prompt
I have not yet been able to discern where and why there is a difference. I would prefer to understand it before adding code, if anybody can assist please.
I must have had nothing to do
I think I know what you are getting at nml375.
My main immediate concern has been to allow the client to perform as expected irrespected of the Eggdrop's language setting. At the moment this involves capturing and reacting to relatively few prompts/messages. In fact so far only 3, though I expect this will grow a little as i develop the software.
The added problem is that a multilingual user might be perfectly happy with the English interface yet still quite rightly expect the software to connect to their chosen language bot. Hence, whatever the software interface language setting might be (when I add this function), it must still check the incoming data stream for the few prompts/messages in all eggdrop languages.
This is a trade off. I can't afford to analyse the data stream for too many items because of the likely overhead, yet I have to at least automate the login process to make the software worthwhile.
I do not need anything more from the core language files, other than the exact wording of these few prompts/messages.
My thought have already turned to the interface language. This simply concerns the button captions, menu item captions etc. Clearly, I can have more interface languages than the 5 Eggdrop languages - if I can find willing helpers. The programming environment I am using provides ready made components for software settings/options. I could additionally add things like default font color etc. I'm just trying to decide on the logic. Things like - should the user be permitted to change settings while connected - should I go with a drop down box for languages or radio group or ...?. The detail.
I hope I have understood your suggestion but please clarify if I have not. I am rather reliant on suggestions.
My main immediate concern has been to allow the client to perform as expected irrespected of the Eggdrop's language setting. At the moment this involves capturing and reacting to relatively few prompts/messages. In fact so far only 3, though I expect this will grow a little as i develop the software.
The added problem is that a multilingual user might be perfectly happy with the English interface yet still quite rightly expect the software to connect to their chosen language bot. Hence, whatever the software interface language setting might be (when I add this function), it must still check the incoming data stream for the few prompts/messages in all eggdrop languages.
This is a trade off. I can't afford to analyse the data stream for too many items because of the likely overhead, yet I have to at least automate the login process to make the software worthwhile.
I do not need anything more from the core language files, other than the exact wording of these few prompts/messages.
My thought have already turned to the interface language. This simply concerns the button captions, menu item captions etc. Clearly, I can have more interface languages than the 5 Eggdrop languages - if I can find willing helpers. The programming environment I am using provides ready made components for software settings/options. I could additionally add things like default font color etc. I'm just trying to decide on the logic. Things like - should the user be permitted to change settings while connected - should I go with a drop down box for languages or radio group or ...?. The detail.
I hope I have understood your suggestion but please clarify if I have not. I am rather reliant on suggestions.
I must have had nothing to do
On second thoughts nml375 I didn't really get what you were suggesting. It has just dawned on me.
You are suggesting another field in on the 'Defero New Connection' form. One where the user selects from say a fixed list the language that this specific bot uses. This would be a very good idea because it would mean the code needs only to search for a single text match per prompt/message rather than five.
There is just one serious drawback. It is easy to change language. Simply edit the .conf file and restart. The user would have to be sufficiently aware and concientious in editing the connection string in Defero to reflect the change in language. Otherwise this renders the software inoperable again.
Nonetheless, I think I'll keep hold of your suggestion. If the software develops to capturing further messages that are not critical then this would perhaps be to way to go.
Presently, though 5 possible text variants are checked, there no noticeable effect on performance. In part this is because the incoming data is only parsed for nickname/password prompts when the user is not on the partyline.
You are suggesting another field in on the 'Defero New Connection' form. One where the user selects from say a fixed list the language that this specific bot uses. This would be a very good idea because it would mean the code needs only to search for a single text match per prompt/message rather than five.
There is just one serious drawback. It is easy to change language. Simply edit the .conf file and restart. The user would have to be sufficiently aware and concientious in editing the connection string in Defero to reflect the change in language. Otherwise this renders the software inoperable again.
Nonetheless, I think I'll keep hold of your suggestion. If the software develops to capturing further messages that are not critical then this would perhaps be to way to go.
Presently, though 5 possible text variants are checked, there no noticeable effect on performance. In part this is because the incoming data is only parsed for nickname/password prompts when the user is not on the partyline.
I must have had nothing to do
Which programming language is it written in?
Have you thought about releasing the source code?
I'd be interested to know how you redirected the partyline.
I'd be rather interested to add encryption, if possible.. (Just quick and dirty, my own fixed key compiled into the bot and the telnet client..)
Have you thought about releasing the source code?
I'd be interested to know how you redirected the partyline.
I'd be rather interested to add encryption, if possible.. (Just quick and dirty, my own fixed key compiled into the bot and the telnet client..)
eggdrop running on Android powered mobile phone - Yes, it is possible! - Very reliable.
The programming language is Delphi 2010 Win32 with some 3rd party addons/components :-
Overbytes sockets
http://www.overbyte.be/frame_index.html ... s/ics.html
Component based regular expressions
http://www.regular-expressions.info/delphi.html
Several components and enhanced functions from Jedi Code Library and Jedi Visual Component Library
http://www.delphi-jedi.org/
Sorry, but I'm not entirely sure what you mean by 'redirected the partyline'. All of the incoming socket data is parsed for various things, including prompts and messages already discussed, Eggdrop's very limited use of telnet protocol etc. The bulk of the work (initially done by regular expressions) concerns translation of text attributes to RichText format. RichText controls are the only form based components that permit different text attributes on the same line. The data is also parsed for '<nickhere> joined the party line.' after connection up until that message is detected. This message is always in English irrespective of the Eggdrop language. Once the data has passed through all these various routines is is simply added to the RichText control. Did I answer your question?
I have not looked into encryption of the data stream but anything is possible. If you are using a standard algorithm then you could use the ready made component from Jedi Visual Component Library to encrypt/decrypt output/input on the client side. The component has several diffent cipher types. I use such a thing to encrypt passwords before storing connection strings in the .xml file. You will be able to see this by looking at the file manually (stored within a subdirectory of your documments folder). My thinking is that encryption/decryption of ALL the data may be an unacceptably large performance overhead.
I have no particular objection to releasing the source code (at least the .pas code files) with the exception of anything relating to the encryption mechanism for obvious reasons. It has the cipher key. I don't think the code would be overly difficult to follow in terms of logic structure, even if you have not encountered Object Pascal before. It might be a good idea to let me finish the code commenting first. I'm very lazy in that respect.
Overbytes sockets
http://www.overbyte.be/frame_index.html ... s/ics.html
Component based regular expressions
http://www.regular-expressions.info/delphi.html
Several components and enhanced functions from Jedi Code Library and Jedi Visual Component Library
http://www.delphi-jedi.org/
Sorry, but I'm not entirely sure what you mean by 'redirected the partyline'. All of the incoming socket data is parsed for various things, including prompts and messages already discussed, Eggdrop's very limited use of telnet protocol etc. The bulk of the work (initially done by regular expressions) concerns translation of text attributes to RichText format. RichText controls are the only form based components that permit different text attributes on the same line. The data is also parsed for '<nickhere> joined the party line.' after connection up until that message is detected. This message is always in English irrespective of the Eggdrop language. Once the data has passed through all these various routines is is simply added to the RichText control. Did I answer your question?
I have not looked into encryption of the data stream but anything is possible. If you are using a standard algorithm then you could use the ready made component from Jedi Visual Component Library to encrypt/decrypt output/input on the client side. The component has several diffent cipher types. I use such a thing to encrypt passwords before storing connection strings in the .xml file. You will be able to see this by looking at the file manually (stored within a subdirectory of your documments folder). My thinking is that encryption/decryption of ALL the data may be an unacceptably large performance overhead.
I have no particular objection to releasing the source code (at least the .pas code files) with the exception of anything relating to the encryption mechanism for obvious reasons. It has the cipher key. I don't think the code would be overly difficult to follow in terms of logic structure, even if you have not encountered Object Pascal before. It might be a good idea to let me finish the code commenting first. I'm very lazy in that respect.
I must have had nothing to do
Great. Thanks for your answer. I do not know Delphi. Only TCL and some C++. As a student I will have to learn a lot languages and probable hacking the code won't be that hard.
The overall idea of your client is great! I always disliked the idea that I have to join irc and to dcc chat or ctcp chat the bot in order to join partyline and the Windows console telnet client, come on, let's don't talk about this method, it's only good for emergency but very uncomfortable. External partyline client is a breakthrough.
I am not sure yet if I am able to use your client. (My bot will be only reachable using IPv6 (running on 3g, see my signature).)
Does your Eggdrop Telnet Client support IPv6?
And as for encryption.... I also never comprehended why we the eggdrop partyline is cleartext (where you can execute shell command while everything else is fine (encrypted botnet, SSH to shell, SSL to irc).
Imho the encryption of the configuration file is not needed. Security through obscurity is never good. Gives only false feeling of security. I'd rather recommend anyone who wishes to have that file encrypted to use whole disc encryption. Not really a task for the individual applications.
The overall idea of your client is great! I always disliked the idea that I have to join irc and to dcc chat or ctcp chat the bot in order to join partyline and the Windows console telnet client, come on, let's don't talk about this method, it's only good for emergency but very uncomfortable. External partyline client is a breakthrough.
I am not sure yet if I am able to use your client. (My bot will be only reachable using IPv6 (running on 3g, see my signature).)
Does your Eggdrop Telnet Client support IPv6?
And as for encryption.... I also never comprehended why we the eggdrop partyline is cleartext (where you can execute shell command while everything else is fine (encrypted botnet, SSH to shell, SSL to irc).
Imho the encryption of the configuration file is not needed. Security through obscurity is never good. Gives only false feeling of security. I'd rather recommend anyone who wishes to have that file encrypted to use whole disc encryption. Not really a task for the individual applications.
eggdrop running on Android powered mobile phone - Yes, it is possible! - Very reliable.
desired, I have had a brief look for IPv6 functionality in Overbyte ICS sockets but I can't find anything reliable as yet. Almost seems like the author has buried his head in the sand. I was leaning towards changing the socket component anyway, probably to IP*Works which is supplied free of charge in newer Delphi versions. Up until then, I'm sorry but I can't provide IPv6 support. I'm not exactly sure when I can achieve this objective but it is now on my ToDo list.
One of my longer term goals is to be able to launch another form from Defero, from which the user can open an SSH conection to the bots shell. This puts me closer to having an 'all in' Eggdrop application. This is the reason I was thinking of changing the socket technology. IP*Works also does Delphi VCL SSH socket components, though these are far from free. I have already done some quite successful experimental work along these lines with a trial version of the aforementioned SSH sockets. It is possible to automate the login sequence using password authentication rather than the normal keyboard authentication. I did however eventually hit a brick wall. I can't find a robust and reliable form based vt100 emulator component for Delphi.
One of my longer term goals is to be able to launch another form from Defero, from which the user can open an SSH conection to the bots shell. This puts me closer to having an 'all in' Eggdrop application. This is the reason I was thinking of changing the socket technology. IP*Works also does Delphi VCL SSH socket components, though these are far from free. I have already done some quite successful experimental work along these lines with a trial version of the aforementioned SSH sockets. It is possible to automate the login sequence using password authentication rather than the normal keyboard authentication. I did however eventually hit a brick wall. I can't find a robust and reliable form based vt100 emulator component for Delphi.
I must have had nothing to do
I am of course not demanding it, I am just very curious about it.
What do you think about encrypting the telnet connection (the bot's party line)? (to encrypt the connection which includes the stuff which you can see here http://defero.ircspeed.org/images/defero3.png)
Do you think that's possible?
Would it need changes to eggdrop's source or a module or would a tcl script be sufficient?
I am curious about all this because I am thinking about implementing the eggdrop partyline into xChat (tcl). Just questionable for me how to encrypt the telnet connection.
What do you think about encrypting the telnet connection (the bot's party line)? (to encrypt the connection which includes the stuff which you can see here http://defero.ircspeed.org/images/defero3.png)
Do you think that's possible?
Would it need changes to eggdrop's source or a module or would a tcl script be sufficient?
I am curious about all this because I am thinking about implementing the eggdrop partyline into xChat (tcl). Just questionable for me how to encrypt the telnet connection.
eggdrop running on Android powered mobile phone - Yes, it is possible! - Very reliable.