small feature requests for chat servers

[sIrMoOn]

#co# - "outer" color.  in a text replace, #co# would restore the color that was in effect before any color codes in the text replace.  in a username, it would restore whatever color the server was using before it encountered a color code in the username.  in a motd, it can just set color 6, in a notice color 8, and in normal text the user's normal text color.

in the case of a text replace or a username, one of these may optionally be assumed to be at the end, preventing the color from bleeding out (config option).

#c11.12# - alternating colors, like yahoo im.  "#c11.12#hello" would display like "#c11#h#c12#e#c11#l#c12#l#c11#o".  could use any colors supported by the server, (including #c?# and #co#) and could support more than just two (#c11.12.13.14.15#).  besides making special color effects much easier, this would also help with various problems in various contexts where lots of color codes cause a length limit to be hit really early.  if we need an arbitrary max number of colors to alternate... eight?

strip color codes from /topic?

[KM]

not sure why you'd have colour codes in a topic, as they don't show up coloured anywhere...

but anyway...

the #co# thing does sound like a good idea - or perhaps #c0# would perhaps be more suitable? as there is no possibility of a colour 0, so it is currently an unused code

the alternating colours thing though wouldn't get around the limit, it would just make it even harder to stay below the limit (because you'd still have to send a colour code for every single character)... however a similar syntax for random colours but with a limited choice may be useful instead (before i finished reading it when i saw the syntax my first thought was that), so #c1,2,3# would be random between 1 2 or 3 for example

[Josh]

https://www.winmxunlimited.net/programs/


look for rainbow text maker.

[sIrMoOn]

#c0# would work just as well for "outer" color.

no disrespect josh but the point of native multi-color support in a server would be not needing extra programs.  also the #c12.13# syntax would be the only way to use different colors to display your username, without actually putting them in the name itself - which imho is a terrible practice.  we've all seen those users with names like #c11#S#c12#i#c11#r#c12#M#c11#o#c12#o#c11#n - wouldn't it be better to just be SirMoon, and have #c11.12#$NAME$ in the format?

i agree that there's no need for color codes in ?topic= so nothing should be lost by taking them out.  but if your topic is set by a bot, and that bot gets its topic from user input, having the color-stripping in the server could save you code in your bot.  so nothing lost, and some things easier to do, right?

[sIrMoOn]

oh wow km already added #c0# - that was fast, heh.  wcs officially has an awesome feature that i want for my room...

i used to use wcs, back when fx was pathetic - then i got a wcs auto-update that crashed every time i started it, so i had no choice but to switch.  and fx was pretty cool.  now fede's gone and km is adding cool stuff...

me wonders if there is an easy config converter -_-;;

[Max™]

Hi SirMoon,
that auto-update that crashed was probably wcs advanced, it was a good idea, but sadly unstable, so String shelved it.

i find the only thing fxs has over wcs is the co-host level that can not be kicked, so no1 can kick me or the bot.

[KM]

sort of like the admins in the winmxworld room, they can't kick other admins or the bot...

* KM wonders why the "great things fxserve does that WCS doesn't" that people use as the reason for "this is why i use fxserver" are all things that WCS does do... in many cases better

[sIrMoOn]

no, i've never run any extension programs for wcs - i'm talking about the plain vanilla you-can't-do-anything-but-look-at-the-log wcs.  it updated and then crashed, and crashed the next time i ran it, and after watching it crash a couple times all i could really think to do was find something else.  i know i could've (maybe should've) blocked updates with a hosts file, but once it was updated i didn't really have any idea where i could get a previous one.

anyway, some things i've liked about fx that i couldn't seem to do in wcs, when i ran it:

* block colors in usernames but allow them in text
* edit the configuration by gui (without half-ass extension programs)
* create unlimited formats fixed i'm told
* set almost any config option using a /command - this is awesome when combined with a bot; the room almost runs itself
* $NAME$ and $TEXT$ fixed i'm told
* minimize to tray fixed i'm told
* add & remove specific letters from an access instead of just replacing the whole thing

my list does seem to be getting shorter, and since km's development seems to be more active currently, i may just have to make sure i disable to auto-update feature to prevent a repeat of last time.

heh, since i seem to have the attention of an extremely talented developer whose server i've enjoyed for a long time (even if i'm not running it atm) - i had a couple other little ideas : P

#1 - how about a / permission?  the idea being, if any user (bot) has / permission, /commands are forwarded to that bot.  when a user enters a command the server doesn't understand, the server can pass the command to the bot instead of just printing "unknown command".  so:

* !playcheckers becomes /playcheckers (host-defined commands integerate better with the room)
* commands aren't displayed on other users screens, reducing noise in the room, and allowing secrecy

#2 - being able to /message user /notice (or other equivalent syntax).  this has lots of uses on its own (mostly with admin bots probably) but is especially useful in conjunction with #1.  since the server isn't printing "unknown command", the bot has to let the user know if they typed something wrong.

[cord73]

the new wcs is good but the AllowMulit= doesnt work with it i cant get over 4 in with same ip as ive got me,my gf and 4 bots that i use for my pics so yeah other then that new wcs works good

[KM]

AllowMulti does work but if you also have JoinFlood=1 then it'll stop more than 3 joins in a row from the same IP Address, so you'd have to disable that if you wanted them all to join at once (or just don't all join at the exact same time) - that's the most common issue people have when they say it doesn't work, they didn't think of the impact of other settings

* block colors in usernames but allow them in text

the way WCS handles the coloured text it wouldn't be possible to do, except perhaps stripping the colour codes entirely from the name (ie. removing the #c?# itself)... but i think most rooms either want colours, or don't (or don't, but have to anyway because everyone bitches if they don't allow them... heh)

* edit the configuration by gui (without half-ass extension programs)

but that means writing a complex GUI... i hate GUIs (in case you hadn't noticed from just about every program i've ever released... lol)

* create unlimited formats fixed i'm told

yep, a text format per login if you want

* set almost any config option using a /command - this is awesome when combined with a bot; the room almost runs itself

that's left out simply because of the number of people who open rooms without bothering to read anything about how to actually set them up... although on second thoughts perhaps those people deserve to have their rooms screwed up...

* $NAME$ and $TEXT$ fixed i'm told

yep

* minimize to tray fixed i'm told

was a pain, but yes it was done eventually once i figured out by pure chance the fact that lcc only uses resource files with the same name as the project (could do with putting it in the help file!)

* add & remove specific letters from an access instead of just replacing the whole thing

the accesses are so complex that i don't think it would really be too practical, with WCS one problem with the access system is is is so complex that it's probably best left setting it up when you set up the room, then leaving alone for risk of breaking it, lol

#1 - how about a / permission?  the idea being, if any user (bot) has / permission, /commands are forwarded to that bot.  when a user enters a command the server doesn't understand, the server can pass the command to the bot instead of just printing "unknown command".  so:

* !playcheckers becomes /playcheckers (host-defined commands integerate better with the room)
* commands aren't displayed on other users screens, reducing noise in the room, and allowing secrecy

hmm... i actually had something else related on my to-do list, but this might actually be a better idea than what i had planned

#2 - being able to /message user /notice (or other equivalent syntax).  this has lots of uses on its own (mostly with admin bots probably) but is especially useful in conjunction with #1.  since the server isn't printing "unknown command", the bot has to let the user know if they typed something wrong.

this was also left out for the same thing with people opening a room without bothering to set it up properly

...however don't expect my next release to be another WCS update, that has been put back up on its shelf again while i do something else

[Lagerlout666]

I hope its what i think it is

[cord73]

JoinFlood=0   i do have it disabled

[KM]

what is the AllowMulti setting set to? (if it's set above 99 it will be ignored)

[sIrMoOn]

* block colors in usernames but allow them in text

the way WCS handles the coloured text it wouldn't be possible to do, except perhaps stripping the colour codes entirely from the name (ie. removing the #c?# itself)... but i think most rooms either want colours, or don't (or don't, but have to anyway because everyone bitches if they don't allow them... heh)

i wouldn't know if i'm most people or not, but imnsho it's a terrible practice to put color codes in your username and i pretty much always disable them in fx (which works as you describe, by stripping them without interperting them).  the place for that is the user's format, don't you think?

* edit the configuration by gui (without half-ass extension programs)

but that means writing a complex GUI... i hate GUIs (in case you hadn't noticed from just about every program i've ever released... lol)

fair enough - i can't argue with that.  i've never seen that "wcs advanced" thing some people are talking about, but i do wonder why it was implemented in-proc instead of as an external program - certainly that'd be more stable across updates.  is it that difficult to configure wcs out-of-proc?  if so, perhaps you could implement a few extra windows messages as a fair compromise - WM_RELOADCONFIG, etc.  create an invisible child window of class ConfigFile with text set to the full path to the config for the server.  idk, i've never explored this in any depth - just thinking out loud.  if wcs really doesn't need any additions like this, and it was just a poor design decision on the part of the "wcs advanced" guy, feel free to ignore.

* set almost any config option using a /command - this is awesome when combined with a bot; the room almost runs itself

that's left out simply because of the number of people who open rooms without bothering to read anything about how to actually set them up... although on second thoughts perhaps those people deserve to have their rooms screwed up...

/ConfigOption NAME=VALUE
ModifyAtRunTime=0 <-- disabled by default
too easy.

* add & remove specific letters from an access instead of just replacing the whole thing

the accesses are so complex that i don't think it would really be too practical, with WCS one problem with the access system is is is so complex that it's probably best left setting it up when you set up the room, then leaving alone for risk of breaking it, lol

*cough* cop out *cough*

#1 - how about a / permission?  the idea being, if any user (bot) has / permission, /commands are forwarded to that bot.  when a user enters a command the server doesn't understand, the server can pass the command to the bot instead of just printing "unknown command".  so:

* !playcheckers becomes /playcheckers (host-defined commands integerate better with the room)
* commands aren't displayed on other users screens, reducing noise in the room, and allowing secrecy

hmm... i actually had something else related on my to-do list, but this might actually be a better idea than what i had planned

; )

#2 - being able to /message user /notice (or other equivalent syntax).  this has lots of uses on its own (mostly with admin bots probably) but is especially useful in conjunction with #1.  since the server isn't printing "unknown command", the bot has to let the user know if they typed something wrong.

this was also left out for the same thing with people opening a room without bothering to set it up properly

again, if that's the concern, you could always disable it by default...

...however don't expect my next release to be another WCS update, that has been put back up on its shelf again while i do something else

anyway it's been fun talking to you.  and by all means pick up wcs again when you feel like it, i'm not paying you enough for you to do otherwise ; )

[cord73]

i have the AllowMulti= set to 8 just like the older wcs and it works good

[Snick512]

#1 - how about a / permission?  the idea being, if any user (bot) has / permission, /commands are forwarded to that bot.  when a user enters a command the server doesn't understand, the server can pass the command to the bot instead of just printing "unknown command".  so:

* !playcheckers becomes /playcheckers (host-defined commands integerate better with the room)
* commands aren't displayed on other users screens, reducing noise in the room, and allowing secrecy

Just change some of the commands in the bot, or add multiple <in>'s to accept /playcheckers so it'll start the script. Or there is always the possible option of rcms, or ouka. any command that isnt in the server, is automaticly put out into the room. And/or If you are not admin, and you try to do an admin command, it will display it to everyone that you are trying to do it. Aswell as you can set extra commmands... so maybe like if they type /playcheckers ... Another menu will come out showsing the user how to actually type... 'eg

/playcheckers
Ouka <> Hello, the correct command is !Checkers
Ouka <> Thanks

Or something like that... that you can put in... One of the neat little features.

Now as far as i know, there has been RCMS commmands added to WCS.. i havent recentlly tested them out or anything, so I'm not sure if wcs has that feature yet or not. So those are just my ideas