'echo' as a log-able function
 

Can the function 'echo' be placed in the /listscriptlogfunctions as a log-able function? As a result of poor organization, there's an annoying echo of 1 or 0 that I can't seem to trace. :cry: Since era has alot of scripts using echo, it figured it would be simple and nice thing to add since sendtorc and sendtonc are already log-able functions. Ofcourse this would only be used to see where this anoying echo is coming from, then disabled afterwards when there is no use for it.

I support you

+1, tracking down this kind of stuff is practically impossible.

+2 I been trying to trace this echo down for weeks -_-

Nice support
Would it be hard to implement stefan?

yes very hard for stefan he is special

I was bored yesterday, downloaded every level, script, weapon and traced down every echo in a text file, I may or may not have gotten rid of it. Only time will tell.

Ive done the same thing @Tim, I've rounded it down to 200-250 echos, meaning un-commented, which I have looked, but can't seem to find anything that matches. This is why I created this thread, I shouldn't have needed to download every script to search for an echo...

Oh, I 100% agree with you. Have you noticed the echo happening lately?

I won't be online much during the week, so I won't be able to tell you

Update: Stefan said its on his todo list.

Also big this are coming apparently. :O

Wouldn't it be just as easy, and maybe offer more flexibility, if you made your own function to do echo's and make it also log (if conditions are true). Meaning certain things could log while others don't necessarily have to rather then just logging it all?

The problem here is that some scripter have added echos in some level or class and display some annoying output on server start, a simple scriptfunctionlog thing could help a lot for finding that.

This would not be to use 24/7 for every echo, it would be purely for debugging.
Lets say someone is echo'ing a boolean from a random test script in a random level then that staff member forgets it and decides to go on vacation for a week. That leaves us with one annoying echo we cannot find.

As Blue said, we'd only be using it if we actually needed it. Could be enabled/disabled through serverops.

Why not something like this?

echo is short and convenient, and doesn't require a DB-NPC or joining a class to use it.

I agree. Its the most useful debug function.

Like Chris Vimes, you enjoy making things harder don't you? ^^

And just logging the level the npc is in and the message it sends? You could even do npc id's or just about any other way.. you at least narrow it down to the level this way. And you don't have to wait for the Graal Engine to be updated just to save a few lines of script?

The 1 thing I notice is using something similar you could also alternatively pass a string to NewEcho() that would let you make it not log so that you don't eat up the disk space.. Which might be pretty cool. Because if there was an edit to make it optional it would probably be best to allow such flexibility rather then log everything.

Sorry if I am just horrible misunderstanding the problem :( I never had this that issue yet, knock on wood.

It'd be impossible to enforce usage of such a function. Point is: some scripter has debug output anywhere using echo(), nobody knows where, it constantly echoes to RC.

Where do you expect to put that new function? It might be alright as a wrapper function in some projects, but in general debug its not exactly needed. I like fast debugging, 'echo' is fast to type and just easy. When you need to join a class or call the function from a DBNPC like Functions.echo() it starts getting long to type... if you're echo'ing alot.

But really, echo's shouldn't be logged all the time...
Maybe more features can be added to onAllRCChat() like getting the sender (RC, Weapon script,level,npc) and message type (echo,sendtorc,sendtonc,normal chat, etc.) :p

Well, I guess I was a little confused how it would work. How you would log some, but not all? I just assumed you would need a true/false flag to tell it to log or not. And yes I was refering to similar to a wraper. just join to a class.

Didn't stefan said join() in GS3 will work similar to PHP include()?

And Im not sure if it's a good idea to include a class just for that. Maybe it could be added to a class with other useful custom functions. And yeah echo() is easy to type. I only said NewFunction() but we all know you can make it how ever you want... eecho(), echo2(), ect.. and its not much harder to type.

but yes it would be pretty hard to enforce. and that would be the only downsite to my suggestion =/ hmm would be neat if we could make it echo("", true/false) maybe?

-scriptless

That's really aside from the point that echo() should be added to scriptlogfunctions for debug use and debug use only. If you want to make a custom echo on your server, go ahead, but on already established servers with over 200 echo calls in scripts, I'm not going in to find which one is echoing a true/false.

Well that still doesn't explain how it only logs "the problem" ones, and not "everyone". You can speak to me on a very technical level you know. I am not stupid. I just cannot comprehend how the log part would determin the difference between

and

And it would be pretty cool to understand how that would work, since im not entirely familiar with "scriptlogfunctions".

scriptlogfunctions is a server option where you can add certain functions to it and it will log them to scriptfunctionslog.txt in the logs folder.

For example:
scriptlogfunctions=write player.gralats

Everytime that player variable is written to, it gets logged to the file. Ideally, you would not want this to be running 24/7, its a debug option.

If you say /listscriptlogfunctions on RC you will see
These are all the functions you can log/debug yourself if you add them to the serveroptions. Now what I'm requesting for in this thread is for the echo() function to be added to that list. I hope you understand now, because you're kinda making a fool of yourself by insisting us to create another function, thats really aside from the request.

Ohh, so it doesn't log untill you change sctiptlogfunctions, then you remove when it's done? Now that, I can completely understand. Yes I could see how that would be better. Would rep+ when I get chance.

This is from the log itself (accounts censored):

Time: Thu Apr 11 21:46:23 2013
write player.gralats by npcs[7] (in level era_shop-03_backnew.nw at pos (31, 30)) for <cname> (<account>): 224 -> 240

Time: Thu Apr 11 21:52:38 2013
write player.gralats by -System/ATM (in level era_shop-03_new.nw at pos (0, 0)) for <cname> (<account>): 513 -> 0

As you can see, it tells you the location of the call/write as-well as extra details.

bump

bump

bump

bump

call me Mr. Mc. Bumpy pants.

why not make your own echo function....

This is probably why Stefan is ignoring you. I did read
'I hope you understand now, because you're kinda making a fool of yourself by insisting us to create another function, thats really aside from the request.' but w/e

Please read the thread before posting? ... x_x

'Cause this has nothing to do with tracking your OWN echos, but tracking down the rogue echos of whatever scripter or person with access to a level manages to create and forget about.

Alternatively, have a server option that toggles echos with a stamp of the parent NPC name. As far as I know, local level NPCs are given a temporary NPC name that includes their level name?

Another option would be to add a few/couple more arguments to onAllRCChat(msg) (If that event is ever going to be extended...)

onAllRCChat(message,type,[parent script/location of the invoker?])

That would be the preferred solution imo, but a serveroption works too.

bump 4 the recent updates

ıllıllı ⓑⓤⓜⓟ ıllıllı

Dude, it's not working -_-

Gotta admire his persistence.

Could use a bit more of a direct request message though.