As many others, i am using Oukachat for hosting my chatrooms. Ouka is primary made for Japanese language, and the total sum of english knowledge about the server in one place, hasn't been that really good.
At first, i decided to make myself a referencefile to get an overview over all the commands, what they did and so on. When it started to grow, others began to ask for more.
This has resulted in me, writing a full featured helpfile for Oukachat. One downloadable chm-file (with search, index and others what you can expect from a helpfile) and a limited online-version.
Since my native language isn't english, i'm aware it might be some bad spelling and typos.
This is why i ask you, to help me finishing this help.
Looks very good so far If there's anything I can do to help let me know.
Under Files and Languages you need to change motd.aat.
It's not just an example file. When you set the MOTD to "/server" the text inside motd.aat will be displayed as the MOTD. It has a limit of 32 lines with 128 characters per line. Any lines starting with /server will not be displayed.
There's another file that you may want to list that hopefully no one will ever see called ExceptRecord.txt. If for whatever reason the server crashes this file will be created and details of the crash will be saved in this file. The server will automatically restart upon crashing. If you have this file you should make sure Ouka sees it
#AdminCmd CrackerBlockOn is a remnant from RCMS. It's function was to block illegal clients who had usernames that were too long for WinMX to handle. (Those who've been around MX long enough may remember the problems with This_is_Cracker000_00000 in RCMS channels.)
I'm unsure if OCS does anything additional to that or not, but that's what it does in RCMS. I'll have to ask Ouka later and see.
Thank you very much!
I will verify and update this info asap.
About the #AdminCmd CrackerBlockOn/Off, as i understand you, the message saying "...A Cracker has been blocked!! [IP:xxx] " has nothing to do with with this setting?
That seems to be one of the big headaces for many, no-one seems to have a good answer to why that message appears.
I was under the impression the "...A Cracker has been blocked!! [IP:xxx] " message was displayed when the same IP trys to connect multiple times, the server assumes its a room flood attempt and blocks it, that said, i havent hosted in quite some time, so im a little rusty
Only good you mention it Nobby. The anti-flood-room would be the MXarms. It would also stop the old chat-attack-tool which made it possible to enter/leave channel in hundreds.
This will give the $ArmsNotify$="MXArms Blocked:"-message.
The crackerblock on/off is the $ClientNotify$="Illegal Client Blocked:.."-message.
The $CrackerBrockNotify$="A Cracker has been blocked!!", i have not been able to find a reasonable explenation for, and it doesn't have a command for switching off (Well, actually, it seems the very newest Oukachat has the ability to turn off the displaying of the message itself, but not the blocking). But still, i would like to know why it happens. I really hope Noam_loves_Nemu comes up with a final explenation for us on this.
but... a lil bug on Ouka version 5.40a.20060227-190000 - when you use "cx" for random colour Ouka change the following character. I believe its a Japanese character. This problem occurs of intermittent form, so the test will have to be made many times to see the problem.
Ouka doesn't read the complete room name with hash.
You can join any room if you have only the hash numbers with the beginning underscore and any character in front of it.
Example:
TRIBO BRASIL SALA 1_3AC906C91A22 (correct room name with hash)
1_3AC906C91A22
xxxx_3AC906C91A22
abc_3AC906C91A22
With any of the upper addresses you can join the room.
That is correct. I assume it's by-design, not an actual bug. Probably to make a second channelname possible. The names is for channel list view only, a cosmetic name if you like. You will see the same symptomes on the FXserver.
A small correction, you can enter a room with any roomname you like, as long as it doesn't exeed 100 characters. If you try to, it will trigger the $CrackerBrockNotify$ (which have several functions and cannot be switched off)
I'm soon to finish up the Ouka Help, but before i do, i will try to add as much as possible of this 'hidden features' not documented anywhere else.
You are right.
I found the same answer for that. The only reason to Ouka let ppl enter the room using any character before the hash is to let hosts setup a second channel name.
This Ouka Help will be great to us. Even more, with these hidden features.
Just wanted to say thank you to all of you giving feedback and helping me on this project. Most are given directly to me, but that does not mean they are just as good as giving it here.
I have reached some kind of "final version", if it can be called that. Ouka keeps up his developement and is giving us the most advanced and updated Chat Server out there. I will try to keep up with his great work, updating the Online Help as it seems natural.
Some of you has also been requested me for new features, and you can keep on requesting and make suggestions. I will see to that Ouka gets this suggestions and requests, and hopefully he is able to implement most of them in newer releases.
Please make them available here too, discussion is only good.
Special thanks to Ouka for listening to the users and keep up developing!
Well done and thanks Unique, i have directed a number of folk to the help. One suggestion, is there anything Ouka can do to sort of the redirecting issue? I know its not much but transfering the room is a pain many dont make it. Just a thought, no biggy
Use the redirectto command to redirect ppl ... every name will then be able to get to the new location but no guarantees if they end up as ghosts, we normally pm the people with the new room name b4 making a redirect and hopefully they can inform us from other rooms if they end up directed in the new room as ghosts so we can kick their ghosts out. (Ghosts for those who don't know r actually redirected names in the new room but the user is physically not there, simply the name is there only)
The redirectto command is this : #usercmd redirectto username newchannelname
At least, we should make him aware of that it really IS a problem. I have had various results with it myself. The 5.30b-series seems to be the most reliable, but that could just be me.
The 5.40a-series seems to have some major issues regarding to the redirects, that might be caused by the new notification-system. So far i have only been able to test it between local computers (from one room to another room hosted on the same local network). It looks like the users are redirected, but on most occations they just appear in the user list, not actually in the room.
Anyway, redirecting is a issue that needs to be done in a better way when it comes to redirecting all users in the room to another. Redirecting a single user seems to be working ok in all newer releases (the redirectto command)
I've been busy again! Finally got some time to make some major changes regarding the new password management introduced in the latest 5.40c versions. I would very much like you all to help me out further, especially when there are bugs/solutions to spesific problems or questions about "how to..." and "how do i...".
Also new from last update is a forum dedicated to provide all sort of OCS related stuff, bugs, solutions, links to other resourses (such as this forum), how-to's not included in the static help files etc etc.
Have a nice chat!
Oh, about the redirect issue, make sure both rooms are running in online mode AND make sure to use the command #AdminCmd ArmsBlockOff before attemting to do a mass redirect, it seems to have great effect on the outcome.
This is my first post on this forum so i just want to say hello to everybody. My name Is Josef i am from LA in USA and i am 16y old . i want to make some online friends...