Is it possible to /play but not using a .txt file as the source? ie could I use entries in a hash table, lines in a multiline edit, or similar? Basically I have some lines of data, that I would like to be able to output in the same sort of manner as /play does, but I don't want to mess about writing it to disk to read it back from disk, and then ahve to remember to erase it at the end.

I know I can use -a to use an alias in place of /msg or /notice but I am assuming that when it's time for the next line, this line is just passed to that alias as $1- for processing and output?

You can easily answer this question yourself by taking a look at /help /play.

It states you can only play from the clipboard (-b flag) or from a file, nothing more, nothing less.

The answer then is simple: either flush your data to a file, and /play it, or don't.

Well, it was worth asking. Anyway, someone might have done something similar and had an ingenious solution. In anyone's considered opinion is it going to be more efficient to write it to a file and /play, or to write my own code to handle it, mimicing /play but using a more convenient source?

There's a misconception about efficiency and files.

It's not so bad to flush your data once and /play it, because there is only two times disk access:

once when flushing the data, and once when doing /play, because /play buffers the entire file into memory and then plays from memory. That's the reason why you can delete a file during a /play, as the contents are already buffered.

What is inefficient is if you have a script that loops through a file with $read and does multiple times disk access, because for each $read, it has to open/read/close the file. Or if you have a script like in on text, that /writes something to a file with each thing said (like a log) . Those are very inefficient.

So if you want to play the data in your hash table, save it to a file (you can choose to save it without the items, just the data with the -n flag, or in ini format etc.) and then play it to wherever you want, don't worry about it. Don't forget about the file handling commands and /filter. File handling commands are efficient because they keep the file open during your operations (like writing multiple lines to it) and then at the end you close it. Very different from using /write, which opens/writes/closes the file with each call. /filter is also very efficient, and acts similar to the file handling commands, in that it doesn't open/close the file continuously. It opens it once, does all the filtering, then closes it.

Ok well if it is buffering it then that as you say should be fine. In fact I expect that /play would work quicker than anything I could code as its presumably compiled. I was a bit concerned that it might do disk accesses for each line. Thanks for this.

Question: does that count for $readini too? Somewhere I read that when using $readini the complete ini file is loaded into memory and consecutive reads take place from there. Is that true?

Not sure where you read that, but my own experimentation with INI files would seem to indicate otherwise, since there is a record of hard drive activity when the $readini command is issued.

This is interesting, because I know of many people who use loops to flush a txt file into say a dialog listbox. Does anyone know a way to preform a simulated /play (buffering the data) to avaoid excessive hard drive accesses? Just curious...

/help /fopen
/help $fread
/help /fwrite
/help /fclose

-genius_at_work

You can use /loadbuf or /filter to load a text file into dialog controls like a listbox with one command, just look at the -o switch.

Btw you are confused about the word "flush", take a look at /flush and /flushini, loading text into a listbox is the reverse of flushing.

Unfortunately, I can't find the url anymore :S but .... A few months ago I made an AI script that recognizes phrases in sentences typed in by chatters and returns one of the possible answers belonging to that phrase. I have stored the phrases in some items in an ini file, let them read them one by one with READINI and have them checked by using "isin" and "$istok" against the sentences. At the moment, the AI bot can recognize over 400 phrases, so in the worst case (that is when it only recognizes his nickname which happens often) it has to perform $readini over 400 times. I have put this bot in 20 rooms (the maximum for that server) and experienced no significant degrade of performance. Even more, the bot contains 22 other scripts for flood protection, auto kick of blacklisted nicknames, birthday checking, on join greeting, etcetera and those scripts perform well too. Kick on join of blacklisted people is done within a second. My PC has an 1 GHz processor which is not very fast nowadays. I have justed changed the script by reading all phrases at once in a variable and do the phrase recognition from there, thus reducing the number of $readini's considerably. The AI scripts seems to be about 2 seconds slower then!
Just recently I made an MP3 player script which searches for all mp3 files on my hard disk and places the filenames in a playlist. At first I did this with $findile(...., write playlist) and it took 10 seconds for 400 MP3's to fill the playlist. I optimized the script with $findfile(....., aline @customwindow) and then flushing the window contents with /savebuf to the playlist. Now it takes less than a second to fill the playlist and it is being sorted also.
My conclusions are: $readini is efficient (enough), but /write not.

You are confusing efficiency with speed. Those are two different things, although you will find them often to be related.

$readini also does disk access for each time you issue $readini, so from an efficiency viewpoint, it is just as inefficient as $read, /write or /writeini.

This is not taking into account any possible buffering that your OS might perform, chances are that it caches the file if it notices the file is referenced a lot, I'm not knowledgeable enough to speak about that.

Also, on the computers from today and the last few years, the differences in speed are all becoming smaller, even when using inefficient methods. You can read from an ini file 1000 times in a row, and it would still only take 300 milliseconds, depending on your hardware.

The point is, you are not going to be able to make any valid conclusions about speed, since you are only doing 200 iterations on average. Yes there are 400 items, but once your script found a match, it doesn't need to continue looping. The average iterations it will do then is 200. In other words, it's not possible for you to notice any performance drawback, because 200 consequent readinis doesnt take enough time for you to even notice it.

If you want to get a real feel for speed, compare the same data in a hash table to your ini file, and do 2000+ iterations, you will quickly see which one is faster.

From an efficiency point of view, each time opening/closing the file is simply a less preferable way. Accessing data from memory is much preferred, giving you an even greater speed, and no continous disk accessing.

I have to admit that my test was inaccurate. The only excuse I have is that I did it quickly before dinner :tongue:. What was wrong was that I did'nt count for serverlag. Apparently, while I was testing $readini's the server had less lag than while I was testing without $readini's. I repeated the test, making sure the last phrase in the ini file was selected each time and making sure that the number of ticks that passed was echoed before a reply was sent to the channel. I noticed that using $readini for 400 entries takes about 110 ticks more. Not that much of a difference I would say. About efficiency and speed: technically you are right. But if I have to apply all kinds of tricks to speed up my script 110 ticks and making my script less understandable for future maintenance, then I find $readini efficient enough. In this case, the differences in the code are small, so I keep the faster version. Still I wonder about the url that said that ini files are processed in memory ... Thanks anyway for your wise words

/help /flushini