the setting Channel context => IRC => Auto open dialog windows turned off has a nice impact on tuxserve.
If there is no opened dialog/query window for a user all output will be sent to the active channel window and spammed into the channel itself.
I got myself a nice ban for that move :+
Also with 0.0.8+patch I can't get a directory listing once connected to the fserve.
It seems to get stuck in the ~/.xchat2/ dir and shows: ERROR: You do not have permission to view this file
I have a pretty strict set of permissions on my homedir but I am the owner of that dir so that should not be a problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The first problem has been known for a while and is explained in the help/FAQ section of the site - sorry if it caused you problems. There's not really much that can be done about that with TuxServe (except making TuxServe override the users settings - which is something I'm not going to do, as most people wouldn't like this). With the next version I may include a feature that, if the user activates it, will override some of the settings to make XChat more TuxServe friendly.
The second problem is a weird variation (that I've not come across) of a known bug. First of all, check that the "trigger_dir"s for the triggers are set correctly - open the config file (~/.xchat2/tuxserve/config.cfg) in a text editor/viewer and make sure the path ends in a "/". If you miss that character off the end of the directory path for trigger_dirs it can cause this problem.
With the latest patch to TuxServe (20040816) it disables the code which does this automagically. So, if you left TuxServe to add the "/" (like the help docs say it will), it will cause problems - this is a known bug and is in the process of being resolved.
If that doesn't fix the problem then either post a reply here, or find me on IRC. I'll try my best to fix this.
Aypok...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just one more thing, currently your using xchat_commandf() to send commands to xchat. This means everything that happens on the fserve will be vissible in the client itself.
I'm not planning on being a watchdog to see if users are using my fserve properly so this is very annoying.
Instead of relaying every command through xchat you could use the /raw command. This way you don't have the trouble of finding the correct context (apart from the server) and all messages will be sent behind xchat's back. There is no need to find the correct tab/window.
Perhaps there is a reason why you chose this behaviour, or it is something for future releases. But it would be nice to have a option to seperate the fserve from the GUI.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"But it would be nice to have a option to seperate the fserve from the GUI." Yep - my thoughts exactly - that's what I'm working on with the new version :)
About the usage of raw over xchat_commandf(): I'd never considered that this could be a problem - that's basically the only reason I use xchat_commandf() (well, that, and the simplicity of it).
I'll definatly look into using raws. I'll admit now that my knowledge of them is very limited - but give me a few days :) I'll probably post my opinions on them and their usage in TuxServe in the news section of the main site within the week. Thanks for the idea - as I said, I'd never considered them until now - that's why I like feedback :)
Aypok...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the suggestion about the query - I'll impliment that in the unstable version for sure - I'll try and encorporate it into the next version of the stable release, too.
Also, thanks for the raws link :)
/me adds "hagar81" to the "Thanks" page :)
Aypok...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That suggestion of yours on using a "query" instead of having to have auto_open_dialogs on has now been implimented - and works fine :) Thanks again for that.
Aypok...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another good idea :) One which I've implimented and uploaded to the CVS. Although, with slight alterations. I imagine that not everyone will want the dialogs closed when the user quits, so I've made it optional by usage of the "auto_close" setting.
Just adding in a "close" command caused a slight problem (due to the fact that plugins gets the data before XChat) where, after the window was closed and the data was passed back to XChat, it sees the message from the user, and creates another dialog for it. Which was kind of self defeating :) But that's been fixed - if the dialog windows was closed by TuxServe, it won't pass the "quit" message from the user back to XChat.
Also, about using raws instead of doing everything through XChat: this will be in the unstable release (whenever that's done), but I'll try and add it into the current version too. Again, it will be optional (set the same was other TuxServe settings are) - but will default to using raws over XChat stuff.
Once again, thanks for the help :)
Aypok...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using raws for "notices" has now been implimented (as well as the ability to revert back to letting XChat handle them). That's on the CVS.
Is it only notices you think should be sent by raws? I thought about using them for PRIVMSGs too, but didn't see the benefit (not that TuxServe sends many). If you think I should use raws for other things, please let me know (along with a quick reason) and I'll look into it :)
Aypok...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the raw implementation misses a colon before the actual message
like this:
send_privmsg(...)
xchat_commandf(ph, "raw privmsg %s :%s", to, message);
otherwise the message will be cut off at the first whitespace.
assuming you use xchat (doh), you might want to keep the rawlog window open to check what happens behind the scenes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wasn't aware of that, so thanks for pointing it out. That function is redundant at the moment, however, becasue (as i said) no privmsgs are sent via raw (yet). I wrote that function before realising I didn't need it, but left it in the code incase I came across a use for it :) I've added the colon anyway, incase that function is needed.
I just did a test using that function as it is (without the colon) and it works fine. Same with the notices. Infact, it gives the same result as if it had a colon (I tried both ways) - the only difference that I saw was that the colon showed up in the raw logs when I put it in.
I've left the colons in (I put one in the notices section too, as it seems to act the same way as the privmsg function) as I assume the colon is there for some compatability reason (or something).
Aypok...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the setting Channel context => IRC => Auto open dialog windows turned off has a nice impact on tuxserve.
If there is no opened dialog/query window for a user all output will be sent to the active channel window and spammed into the channel itself.
I got myself a nice ban for that move :+
Also with 0.0.8+patch I can't get a directory listing once connected to the fserve.
It seems to get stuck in the ~/.xchat2/ dir and shows: ERROR: You do not have permission to view this file
I have a pretty strict set of permissions on my homedir but I am the owner of that dir so that should not be a problem.
Hi,
The first problem has been known for a while and is explained in the help/FAQ section of the site - sorry if it caused you problems. There's not really much that can be done about that with TuxServe (except making TuxServe override the users settings - which is something I'm not going to do, as most people wouldn't like this). With the next version I may include a feature that, if the user activates it, will override some of the settings to make XChat more TuxServe friendly.
The second problem is a weird variation (that I've not come across) of a known bug. First of all, check that the "trigger_dir"s for the triggers are set correctly - open the config file (~/.xchat2/tuxserve/config.cfg) in a text editor/viewer and make sure the path ends in a "/". If you miss that character off the end of the directory path for trigger_dirs it can cause this problem.
With the latest patch to TuxServe (20040816) it disables the code which does this automagically. So, if you left TuxServe to add the "/" (like the help docs say it will), it will cause problems - this is a known bug and is in the process of being resolved.
If that doesn't fix the problem then either post a reply here, or find me on IRC. I'll try my best to fix this.
Aypok...
The paths were missing the ending /
Just one more thing, currently your using xchat_commandf() to send commands to xchat. This means everything that happens on the fserve will be vissible in the client itself.
I'm not planning on being a watchdog to see if users are using my fserve properly so this is very annoying.
Instead of relaying every command through xchat you could use the /raw command. This way you don't have the trouble of finding the correct context (apart from the server) and all messages will be sent behind xchat's back. There is no need to find the correct tab/window.
Perhaps there is a reason why you chose this behaviour, or it is something for future releases. But it would be nice to have a option to seperate the fserve from the GUI.
Hi,
"But it would be nice to have a option to seperate the fserve from the GUI." Yep - my thoughts exactly - that's what I'm working on with the new version :)
About the usage of raw over xchat_commandf(): I'd never considered that this could be a problem - that's basically the only reason I use xchat_commandf() (well, that, and the simplicity of it).
I'll definatly look into using raws. I'll admit now that my knowledge of them is very limited - but give me a few days :) I'll probably post my opinions on them and their usage in TuxServe in the news section of the main site within the week. Thanks for the idea - as I said, I'd never considered them until now - that's why I like feedback :)
Aypok...
For more information on raw commands the RFC's are a must
http://www.irchelp.org/irchelp/rfc/
oh and for the Auto open dialog windows turned off you could issue a /query <nick> to open a new window/tab no matter what it is set to.
Usage: QUERY <nick>, opens up a new privmsg window to someone
Hi,
Thanks for the suggestion about the query - I'll impliment that in the unstable version for sure - I'll try and encorporate it into the next version of the stable release, too.
Also, thanks for the raws link :)
/me adds "hagar81" to the "Thanks" page :)
Aypok...
Hi,
That suggestion of yours on using a "query" instead of having to have auto_open_dialogs on has now been implimented - and works fine :) Thanks again for that.
Aypok...
You can do the reverse for users that exit the fserve.
I've had this running for a few days now and it works very well.
--- tuxserve-0.0.8alpha.orig/dcc.c 2004-04-25 17:58:43.000000000 +0200
+++ tuxserve-0.0.8alpha/dcc.c 2004-08-20 02:31:19.000000000 +0200
@@ -486,6 +486,7 @@
set_context(ph, sender);
xchat_commandf(ph, "say %iToodle pip.", fs.colours[4]);
xchat_commandf(ph, "dcc close chat %s", sender);
+ xchat_command(ph, "close");
user_left_fserve(ph, sender);
}
Hi,
Another good idea :) One which I've implimented and uploaded to the CVS. Although, with slight alterations. I imagine that not everyone will want the dialogs closed when the user quits, so I've made it optional by usage of the "auto_close" setting.
Just adding in a "close" command caused a slight problem (due to the fact that plugins gets the data before XChat) where, after the window was closed and the data was passed back to XChat, it sees the message from the user, and creates another dialog for it. Which was kind of self defeating :) But that's been fixed - if the dialog windows was closed by TuxServe, it won't pass the "quit" message from the user back to XChat.
Also, about using raws instead of doing everything through XChat: this will be in the unstable release (whenever that's done), but I'll try and add it into the current version too. Again, it will be optional (set the same was other TuxServe settings are) - but will default to using raws over XChat stuff.
Once again, thanks for the help :)
Aypok...
Hi,
Using raws for "notices" has now been implimented (as well as the ability to revert back to letting XChat handle them). That's on the CVS.
Is it only notices you think should be sent by raws? I thought about using them for PRIVMSGs too, but didn't see the benefit (not that TuxServe sends many). If you think I should use raws for other things, please let me know (along with a quick reason) and I'll look into it :)
Aypok...
the raw implementation misses a colon before the actual message
like this:
send_privmsg(...)
xchat_commandf(ph, "raw privmsg %s :%s", to, message);
otherwise the message will be cut off at the first whitespace.
assuming you use xchat (doh), you might want to keep the rawlog window open to check what happens behind the scenes.
Hi,
I wasn't aware of that, so thanks for pointing it out. That function is redundant at the moment, however, becasue (as i said) no privmsgs are sent via raw (yet). I wrote that function before realising I didn't need it, but left it in the code incase I came across a use for it :) I've added the colon anyway, incase that function is needed.
I just did a test using that function as it is (without the colon) and it works fine. Same with the notices. Infact, it gives the same result as if it had a colon (I tried both ways) - the only difference that I saw was that the colon showed up in the raw logs when I put it in.
I've left the colons in (I put one in the notices section too, as it seems to act the same way as the privmsg function) as I assume the colon is there for some compatability reason (or something).
Aypok...