Server Help

ASSS Custom Projects - <C> ASSS Colors/Say/Voice Module
Cheese - Tue Feb 03, 2009 3:17 pm
Post subject: <C> ASSS Colors/Say/Voice Module

I have made a module
which allows anyone to send an arena message or zone message
in any color capable by continuum,
both can be either signed or anonymous.
Powers are limited by groupdef.
Source attached.

***NEW***
You can now create modules which can send colored player or arena messages!
Simply use the interface and insert color->Pink(p,"bleh") into your code!

***NEWER***
The colors module has now become 3 modules in 1!
The core of the module has changed, using less memory and all that junk n stuff.
Also, the interface has been greatly extended, allowing you to send any color to the zone, an arena, or a player.
Additionally, you can now use the ?say command, just like the old *say in subgame, and !say in mervbot (kind of), to make any player, real or fake, say whatever you want them to! (I would suggest limiting these powers by groupdef to only those who you can -truly- trust)
Also, a ?voice command has been added to change your boring old blue pub chats into a more fun color, like pink or gray!
(Disclaimer: currently an echo due to technical limitations)

***NEWEST***
The core of the module and ?say has been streamlined.
Additionally, the interface has gained freq color functionality!

***FINAL***
The core of the module has undergone a final redesign, achieving perfection.
This includes code optimization, in which the number of lines was literally cut in half.
Also, an unloading bug has been fixed.
Additionally, the interface has been changed, and is now easier to use.

***Update***
Have gone through code and cleaned a lot of things up, and updated everything to be compatible with ASSS 1.6.0
Also removed voice and xchat modules, since they are cruft and require the not yet existing chat advisor.
Seperated the modules into different files for those that only want certain parts.

lines for modules.conf:
Code: Show/Hide

colors:colors
colors:say



commands for groupdef:
Code: Show/Hide

cmd_bluea
cmd_blueaa
cmd_bluez
cmd_blueaz
cmd_yellowa
cmd_yellowaa
cmd_yellowz
cmd_yellowaz
cmd_greena
cmd_greenaa
cmd_greenz
cmd_greenaz
cmd_reda
cmd_redaa
cmd_redz
cmd_redaz
cmd_orangea
cmd_orangeaa
cmd_orangez
cmd_orangeaz
cmd_graya
cmd_grayaa
cmd_grayz
cmd_grayaz
cmd_pinka
cmd_pinkaa
cmd_pinkz
cmd_pinkaz

privcmd_say



Any comments/suggestions/ideas would be appreciated.
tcsoccerman - Tue Feb 03, 2009 3:46 pm
Post subject:
maybe more dynamic commands such as ?colora pink hello how are you, or ?colorzz blue this is the message. other than that nice work.
Dr Brain - Tue Feb 03, 2009 3:50 pm
Post subject:
Suggestion: don't call it as3.
Hakaku - Tue Feb 03, 2009 5:14 pm
Post subject:
Question: I noticed both you and Brain didn't release the playerdata interface in MM_UNLOAD. Is this intentional? Also, why are the commands being removed after the cmdman interface is released?
Dr Brain - Tue Feb 03, 2009 6:53 pm
Post subject:
Hakaku wrote:
Question: I noticed both you and Brain didn't release the playerdata interface in MM_UNLOAD. Is this intentional?
Not intentional on my part. I'll try and correct that for future releases. Not that I actually expect there to be many more for the fuchsia module.
Cheese - Tue Feb 03, 2009 7:41 pm
Post subject:
im surprised i missed that as well, i basically pirated dr brains work, and also inherited that. icon_biggrin.gif
good eyes!
it has now been fixed.
attachment updated.


--edit--
Dr Brain wrote:

fuchsia


which is why it is now referred to as 'pink' icon_wink.gif


also, whats the deal with ASSS vs AS3?
arent the terms interchangable?
ive been using AS3 because it has 25% less letters to type D:
Bak - Tue Feb 03, 2009 11:02 pm
Post subject:
if AS3 is 25% of ASSS then what is A?

also, try to see if you can cut all code that is duplicated by using arrays
tcsoccerman - Wed Feb 04, 2009 3:42 pm
Post subject:
although AS3 is less words, it's harder to type because you have to type 3 unique characters, where as ASSS is only 2 different letters. even further, AS3 has a number in it, while ASSS has no numbers, and the different characters (a and s) are right next to eachother.
Initrd.gz - Sun Feb 15, 2009 2:08 pm
Post subject:
tcsoccerman wrote:
although AS3 is less words,

ASSS and AS3 are both one word. Lol.

Looks like a very useful module. Will definitely attract player's attention when they notice there is a pink text color.

... Or maybe fake a team message to look like a public message icon_twisted.gif
tcsoccerman - Sun Feb 15, 2009 4:02 pm
Post subject:
They mean the same, but they're different words.
Initrd.gz - Sun Feb 15, 2009 5:24 pm
Post subject:
tcsoccerman wrote:
They mean the same, but they're different words.
Correction: One word long.
</ offtopic>

What would be a good idea is to use Targets. So you could do something like this:

//?blue hello
Linuxuser> hello

in team chat
Goldeye - Wed Feb 18, 2009 12:01 am
Post subject:
More importantly than commands for colors, I'd like to have the chat interface expanded to take a color enum easily.
Cheese - Wed Feb 18, 2009 1:36 am
Post subject:
what, like ?color YELLOW mehmehmeh..?

and i suppose i could add a target for v2, that way you could literally fake someone saying something...
it would be pretty cool, but i can only see it getting misused >_>
Initrd.gz - Wed Feb 18, 2009 8:19 pm
Post subject:
Well I thought that most zones would restrict colors to mods... If it becomes a problem then mods can just disable the command.

And goldeye, just look at the source code. Its not really hard to implement in other projects.
Cheese - Thu Feb 19, 2009 12:43 am
Post subject:
the commands can currently be used by whatever group you give capabilities to...
no need to disable anything...
JoWie - Thu Feb 19, 2009 6:41 am
Post subject:
Cheese wrote:
and i suppose i could add a target for v2, that way you could literally fake someone saying something...
it would be pretty cool, but i can only see it getting misused >_>


That's the reason *say got removed in subgame.


As for adding targets, with other ASSS chat commands like ?aa, the target restricts what players see the message.
For example :Player:?aa abcdefghjilk shows the arena message just for Player (You will need the privcmd_aa capability though)
Cheese - Sat Mar 14, 2009 5:31 pm
Post subject:
updated files, added load/unload log messages

also, i think im going to make an interface soon, so other mods can use fun spiffy colors >:3
Cheese - Mon Mar 16, 2009 2:26 pm
Post subject:
huge update, added that interface, you can send arena messages in any color, or to a specific player.

i also completely redesigned how the module works.

files updated
Cheese - Tue Sep 22, 2009 3:08 pm
Post subject:
yet another huge redesign of how the module works, cut the number of lines of code roughly in half, as well as added new functionality!
Cheese - Tue Sep 29, 2009 12:11 am
Post subject:
did another big redesign.
fixed this
added freq functionality.

should be 100% stable now...
Hakaku - Tue Sep 29, 2009 10:36 am
Post subject:
Cheese wrote:
fixed this

It's fine in Voice, but in both Say and Colors you repeated the same issue: using an interface after you finished unloading it (e.g. when you remove commands). Just thought I'd give you a heads up icon_wink.gif
Cheese - Tue Sep 29, 2009 11:08 am
Post subject:
zomg ;_;



forgot those, lulz
Cheese - Fri Oct 02, 2009 3:39 pm
Post subject:
fixed
Cheese - Tue Feb 23, 2010 3:23 am
Post subject:
big update



new color features



new xchat (eXtended Chat) features



since i suck at this, please look over the code and see where i screwed up, especially in regards to the chatnet parts...
fuschia was renamed to pink because #1: even its creator can not spell it correctly, and #2: color is a subjective term, meaning 'pink', 'fusha', and 'purple' are all equally acceptable.
i would like all if not most of these improvements made standard.
the bonus is that the code is already written (even if its made with duct tape and on fire)
:D
Cheese - Wed Feb 24, 2010 2:32 pm
Post subject:
idea checklist for xchat:

fix bug sending silence message to ppl with unlimitedchat cap
inform modchat of silence
add seperate limit for cmd spam, cmd=text if !defined

fixed:
rewritten chats are no longer counted for spam limits
Cheese - Fri Apr 02, 2010 4:37 pm
Post subject:
colors module has undergone a final redesign, and will most likely not be altered in the future.

if the file timestamp on your files is older than this post's timestamp, your version is outdated. grab a new copy.

there is really no reason why any zone should not have this module, all the cool kids have it...

:)
Cheese - Thu Apr 29, 2010 1:11 am
Post subject:
fixed bug in new logic that sent arena messages to zone.
files updated.
Cheese - Wed Jun 02, 2010 7:23 am
Post subject:
updated interface.
should be slightly faster, and now you arent forced to use the color constants, even if theres no real reason not to :P
files updated.
Samapico - Sun Jun 27, 2010 2:46 pm
Post subject:
What's going here? Your if/else statements do not work as the indenting would lead you to believe...
Code: Show/Hide
         if(mode == MODE_ZONE) LLAdd(&playerlist,pp);
         else
         {
            if(mode == MODE_ARENA) if(pp->arena == a) LLAdd(&playerlist,pp);
            else
            {
               if(mode == MODE_FREQ) if(pp->arena == a) if(pp->pkt.freq == freq) LLAdd(&playerlist,pp);
               else return; //wtf?
            }
         }


Correct indenting:
Code: Show/Hide

         if(mode == MODE_ZONE)
            LLAdd(&playerlist,pp);
         else
         {
            if(mode == MODE_ARENA)
               if(pp->arena == a)
                  LLAdd(&playerlist,pp);
               else
               {
                  if(mode == MODE_FREQ)
                     if(pp->arena == a)
                        if(pp->pkt.freq == freq)
                           LLAdd(&playerlist,pp);
                        else return; //wtf?
               }
         }


I don't know if that's how you intended it to work, but your indenting makes me believe otherwise...
Having 3 if's on the same line generally is a bad idea tongue.gif
Cheese - Mon Jun 28, 2010 3:52 pm
Post subject:
i think it was because i was testing something or other, and forgot to fix it...
in any case, its fixed.
files updated.
Samapico - Mon Jun 28, 2010 8:01 pm
Post subject:
Another small thing I noticed... your module logs messages using the ERROR tag when it loads and unloads correctly, you might want to change that to Information
Cheese - Tue Jun 29, 2010 3:48 am
Post subject:
all my modules do

INFO level messages are by default not sent to chat
when the zone crashes because someone attached a module to a different arena, id want to know
Samapico - Sun Jul 04, 2010 12:33 am
Post subject:
Suggestion: Would be nice to be able to use printf style format with the ColorA, ColorP, etc. functions
Samapico - Mon Jul 05, 2010 9:10 pm
Post subject:
I modified the code so the interface handles printf style formatting.

I also added interface functions to send colored messages with sounds biggrin.gif


Note that I stripped off the code of the Voice module in there, because I was lacking some constants, presumably in the xchat module, and I didn't want to bother with that... So do what you want with it tongue.gif

There are a few minor changes here and there I did while skimming through your code, mostly in code formatting (i.e. a switch (params[0]) instead of if...else if... chain).
Dr Brain - Mon Jul 05, 2010 10:09 pm
Post subject:
In matters of style, an if-else chain is generally preferred over switch statements. See the Java style for an example. The if statements are more flexible, and therefore easier to expand in the future, and of course the basic form generates the same machine code.
Samapico - Mon Jul 05, 2010 11:43 pm
Post subject:
Well it depends what is subject to change... if the input is subject to change, your if else if chain will be less flexible, since you'll need to change it all... But if the conditions might get changed or combined, then yeah.
Also if your condition is a function or some calculation, the switch avoids the need of a local variable to store the result before comparing it, which is practical.

IMHO

</offtopic>
Cheese - Tue Jul 06, 2010 10:39 am
Post subject:
Samapico wrote:
Suggestion: Would be nice to be able to use printf style format with the ColorA, ColorP, etc. functions


it was on my to do list, but i hadnt added it yet because:
#1: its extra work
#2: you can use snprintf like samapico does before SendArenaMessage before PinkA
#3: idk
#4: its easy to do, and ill add it later sometime
#5: ???
#6: PROFIT


also, i use else if chains when i dont need fall-throughs or not-1-line code

edit:
keep in mind you can use %123 to add sounds to your messages...
its very infrequent that i actually use the SendSoundMessage stuff...

also, using
if(1) a++;
on one line is better than
if(1)
..........a++;
because its on one line instead of two, and is MORE readable.
only use two lines when one becomes less readable.
Samapico - Tue Jul 06, 2010 12:59 pm
Post subject:
I personally find it less readable when the statement is on the same line as the conditon... you have to visually scroll to the end of the condition (i.e. the closing parenthesis) and then find the statement...

Anyway.... if you didn't notice, I did the printf format style functions, so you don't need to, in the post just after the one you quoted tongue.gif

Also, I know you can send the % sounds when you type a colored messages, but I'm mainly using the color module's interface from other modules and I doubt adding a %# in the message string would make a sound... the % thing is client-side.
Cheese - Tue Jul 06, 2010 5:27 pm
Post subject:
when youre getting up to 10,000 lines of code, adding extra space for no reason makes you wait a really long time while scrolling to the part youre looking for.



yes, all sounds are client side, and yes, you did copy+paste from chat.c just like i will.

:)
L.C. - Tue Jul 06, 2010 10:41 pm
Post subject:
Cheese wrote:
when youre getting up to 10,000 lines of code, adding extra space for no reason makes you wait a really long time while scrolling to the part youre looking for.
It makes sense to do it because it makes your code look cleaner, more accessible, easier to read, and easier to work with. I say this based off my XHTML/CSS experience. (Take a look at the source code for hlrse.net's webpage to see what I mean.)
Cheese - Wed Jul 07, 2010 8:19 am
Post subject:
i find them to be equally readable at best, but one is a waste of space
Cheese - Sun Jul 25, 2010 9:50 am
Post subject:
Samapico wrote:
Suggestion: Would be nice to be able to use printf style format with the ColorA, ColorP, etc. functions


I finally got around to doing this.
Enjoy.

files updated
Anonymous - Sun Jul 25, 2010 8:01 pm
Post subject:
Dr Brain wrote:
if statements are more flexible, and therefore easier to expand in the future, and of course the basic form generates the same machine code.


don't case statements generate jump tables while if statements use a series of comparisons?
Dr Brain - Sun Jul 25, 2010 9:58 pm
Post subject:
How would you generate a jump table without comparisons, exactly? A fully populated table for ints would be 4GB (assuming the relative jump could be packed into 1 byte, of course). A sparse table would require comparisons and would start to look very much like that if-else tree.

Jump tables are great for strictly defined things like interrupt handling vectors, and custom code where you can write assembly to get the very last nanosecond out.
Anonymous - Mon Jul 26, 2010 7:57 am
Post subject:
if you're dense near 0, you check the maximum range once and then after that assume the index is in bounds.

I think the compiler did it when I was learning asm and it took me a minute to figure out what was going on.
Anonymous - Mon Jul 26, 2010 7:59 am
Post subject:
Dr Brain wrote:
How would you generate a jump table without comparisons, exactly?


// done by compiler
table[0] = case0;
table[1] = case1;
table[2] = case2;
table[3] = case3;

// done at runtime
if (index > 3)
goto caseDefault;
else
goto table[index];
Dr Brain - Mon Jul 26, 2010 10:05 am
Post subject:
You're right, you can do it with one comparison if you have fully dense cases. I've never seen it done, but again, I don't work with switch statements for the style reasons stated above.

I'd like to note that I don't think CPU branch predictors are well suited to that sort of jump table (relative jump with offset held in a register instead of an immediate). Branch predictors may have improved since I last studied them, but as I don't see how this kind of dependence could be resolved while still in the pipeline. So you'll get a pipeline flush every time you do the jump, which in deeply pipelined processors can hurt performance instead of helping it (modern x86_64 are deeply pipelined). The exact penalty depends on the probability distribution of the cases and the pipeline flush penalty, but except for truly massive switch statements or processors with shallow pipelines it won't reach break-even.

But, that said, any compiler smart enough to optimize a switch statement (if indeed there is an improvement from a jump table, which I tend to doubt) is probably smart enough to check if the if-else tree can follow the same optimization. It's a simple enough comparison of the AST to see if every branch of the if-else does an integer comparison against the same variable.

Perhaps the jump table is the -O0 behavior? That would make sense, since the argument could be made that it would more closely resemble the C code. Or perhaps it's -Os, if there's a code size savings (e.g. the relative offset could fit in a byte, but the branch opcodes are one word wide).

Most of the code I write isn't x86, so I may be unaware of new developments in the processor architecture. The last x86 I studied was the Pentium 4. Most of my code is C, written for the AVR and AVR32 architectures, compiled using gcc.
Anonymous - Thu Aug 12, 2010 12:11 pm
Post subject:
it doesn't need to be fully dense, as some gaps can be filled in with the same address (jump to the default handler, or after the switch statement).

Even in the case of a very sparse switch statement, it can be implemented using a binary search which will be faster than a sequential checking using if statements alone.
Dr Brain - Thu Aug 12, 2010 12:39 pm
Post subject:
The pipeline flush from the jump table is still going to drive the performance cost on any x86 and x86_64.

And you don't think an optimizing compiler can rewrite them both into the same exact machine code? That was my original point: they'll generate the same exact binary. Therefore one should use whichever is easier to read, which for my money is the if else-if.
Cheese - Thu Aug 12, 2010 4:26 pm
Post subject:
ive always wanted an elseif switch

Code: Show/Hide

elseifswitch(num)
{
case > 3: break;
case > 2: break;
case > 1: break;
}
Dr Brain - Thu Aug 12, 2010 6:06 pm
Post subject:
Cheese wrote:
ive always wanted an elseif switch

Code: Show/Hide

elseifswitch(num)
{
case > 3: break;
case > 2: break;
case > 1: break;
}


Code: Show/Hide

if (num > 3) {}
else if (num > 2) {}
else if (num > 1) {}
Cheese - Thu Aug 12, 2010 8:36 pm
Post subject:
a switch is better
Cheese - Fri Jul 10, 2015 11:25 pm
Post subject:
went through code and cleaned a lot of things up, and updated everything to be compatible with ASSS 1.6.0
removed voice and xchat modules, since they are cruft and require the not yet existing chat advisor.
seperated the modules into different files for those that only want certain parts.

didnt include a dll because everyone builds their own stuff these days anyways

updated main post with new files
All times are -5 GMT
View topic
Powered by phpBB 2.0 .0.11 © 2001 phpBB Group