Author Topic: Server_NewChat (restricted edition)  (Read 11156 times)

Damnit. Console access is FTW. :u

I'm pondering releasing a .txt with all the code that I needed to take out, that you could just copy and paste into the server.cs file.  However, Ephialtes might not like that.  I'll make a poll?

I'm pondering releasing a .txt with all the code that I needed to take out, that you could just copy and paste into the server.cs file.  However, Ephialtes might not like that.  I'll make a poll?

What are you talking about? What's so odd about this Add-On you made that Ephialtes needs to constantly monitor it? It's just a chat rewrite... o_o

What are you talking about? What's so odd about this Add-On you made that Ephialtes needs to constantly monitor it? It's just a chat rewrite... o_o

Ephi failed the one I released yesterday because it included console access for the host and host approved clients.  And giving out console access is a big thing, even bigger than giving super admin.

You mean you basically recreated Eval with this? if so, leave it out.

Ephi failed the one I released yesterday because it included console access for the host and host approved clients.  And giving out console access is a big thing, even bigger than giving super admin.

Ah, that should only be for certain servers. Giving such access is definitely a scary aspect
« Last Edit: January 09, 2011, 05:34:22 PM by MegaScientifical »

You mean you basically recreated Eval with this? if so, leave it out.

recreated?  I just made it so a user could type /console "command goes here" or say *"command goes here" and if they had the variable %client.hasAccess, then it would eval(%msg);

You can see why this can be a problem for hosts that are not careful who they give access to.  Someone with access could say "/console findclientbyname("my dumb friend").hasaccess = 1;" and it would silently give them console access, without the host knowing.

Tom

Just make it client sided. YOu might have to take out a few features, but than everyone can still have a customizable chat. Servers shouldn't force people to have a certain font size.

Well, I guess you should make it optional then through the method you stated. It would still show up in the console though, wouldn't it?

Well, I guess you should make it optional then through the method you stated. It would still show up in the console though, wouldn't it?

He already said Ephialtes failed it for including eval. There's no absolute way to prevent eval abuse, which is dangerous. The GUI downloader in RTB has to check to be sure the buttons only do certain things and can't do such things as "Quit" and "Crash." You could create text blocks to prevent these things, but there's always a bypass.

Do the names always show up in all caps?

Well, I guess you should make it optional then through the method you stated. It would still show up in the console though, wouldn't it?

Warning - while you were reading 2 new replies have been posted. You may wish to review your post.

Yes, everything is echoed in the console.

Just make it client sided. YOu might have to take out a few features, but than everyone can still have a customizable chat. Servers shouldn't force people to have a certain font size.

What is being client sided? You mean make it so people decide their own fonts to see? hmm...

Do the names always show up in all caps?

Yes, I will probably update that soon. I was annoyed when people would join with dumb alternating caps names.

Warning - while you were reading 2 new replies have been posted. You may wish to review your post.

Yes, everything is echoed in the console.

1. What is being client sided? You mean make it so people decide their own fonts to see? hmm...

2. Yes, I will probably update that soon. I was annoyed when people would join with dumb alternating caps names.

1. You'd work the code through this to make it clientside. Just change how it displays:

Code: [Select]
package chatMods {
function clientCmdChatMessage(%client,%num2,%num3,%amsg,%prefix,%name,%suffix,%msg) {
if(!$chatMods::isOff) {
stuff
}
else
Parent::clientCmdChatMessage(%client, %num2, %num3, %amsg, %prefix, %name, %suffix, %msg);
}
};
activatepackage(chatMods);

2. You can use this to check for All-Caps names:

Code: [Select]
function isAllCaps(%x) {
%x = trim(%x);
%caps = "!@#$%^&*+_<>";
for(%t=0; %t<strLen(%x); %t++) {
%s = getSubStr(%x, %t, 1);
if(strCmp( %s, strLwr(%s) ) || strStr(%caps, %s) >= 0)
%AllCaps++;
}
return ((strLen(%x) > 3) && (%AllCaps >=  mFloor( strLen(%x) / 2)));
}
« Last Edit: January 09, 2011, 06:01:58 PM by MegaScientifical »

with the clientCmdChatMessage, is that the default code for recieving a chat message?

I like the test for an all caps name, but I think I can just keep it so it only caps their name if it is enabled.

I suppose there is no way around packaging this if I make my chatmod togglable.

with the clientCmdChatMessage, is that the default code for recieving a chat message?

I like the test for an all caps name, but I think I can just keep it so it only caps their name if it is enabled.

I suppose there is no way around packaging this if I make my chatmod togglable.

Yes, that's the default method of receiving chat. It's how many of my scripts work. I nested a chatlogger in there, as well as an ignore script.

That other script I posted simply gives 1 or 0 if the text entered is considered mostly caps. This means it doesn't have to be literal all caps to activate, so less bypassing.

And yes, you should probably package it.

Can someone make a client sided add-on thats hides this and leaves original chat?