Forums Feature Suggestions modification to $line()

Ok so here is the problem. lets say you have a timer to read and remember a windows current buffer, a loop with $line(window,0) so your loop checks to see if any changes have been updated in the window. Sounds easy right? if $line(window,0) > last time, theres new data... WRONG! what if the windows buffer has reached the buffer limit, so beginning lines are trimmed to fit new lines at the end? then $line(window,0) never changes.

The closest idea I had was to store each line into a binvar and add the binvar to a hash table. construct a new binvar upon a new check and $md5(&old,1) and $md5(&new,1) so if the md5 !=, theres new data. simotaneously step thru each one, removing the first line from old, and the last line from new, until the $md5 equal then however many times you looped is how many new lines are in the windows buffer.

Even that method tho should work most of the time, still has a potential to fail. what if some jerk comes in and does a massive text flood with the same text and fills your buffer? then no matter what, unless the timestamp changed the $md5 of old and new will equal each other, thus making it fail and miss new lines.

What I would like to see, is a modification of $line() to have a prop called .ticks, since ticks is so precise it'd be very rare for two lines to have the same .ticks

if you could $line(window,x).ticks to get the time in ticks when it was added to the window, thats the only number you would need to remember for the next check, and you could loop backwards from $line(window,0) decreasing that variable until you find a line with the .ticks = last saved ticks information. so now you know say you processed 0-30, stored 30's .ticks.. next time the loop happens, it finds that 30 is now 15, so it loops 15-30 n updates the .ticks it remembered.

This seems like a very specific use case for $line; and probably the wrong one. If all you're trying to do is detect when a window has changed, maybe there's an easier way to solve this problem than you think...

If you log channels, you can simply use the following:

//echo -a $file($window($active).logfile).mtime

This will give you the modified time of the buffer, which should change whenever text is added to the buffer. It's both efficient and easy to use; just check that the mtime has changed from the last mtime for the window. Of course mtime is only accurate to 1s, but I assume you're polling every few seconds for changes at least, so this should not be an issue.

By the way, if you want a way to detect whether the window changed, I think a specific identifier to give this information (like $window().mtime maybe) would be a better feature suggestion to store ticks info with every line, since the latter is just a workaround for what you're really trying to do; not to mention storing ticks info with each line can be a sizable unnecessary overhead. Are you even going to access the ticks for every line in the window? It seems like you only need the last one.

although that does seem a valid point, there is still a couple flaws there. #1, logging MUST BE enabled, and #2, you did not cover how to effectively address which lines in the buffer in fact are new.

What I am making must soley rely on data available within mIRC, in case of options such as logging being disabled. Sure it would be extremely simple to keep track of the $line(logfile,0) and send the log files new lines when it changes, or when the .mtime changes but once again there is no garuntee that whatever mIRC the script may be running on in fact has logging enabled.

You can always enable logging, at least for the duration of the session.

Checking *which* lines in the buffer is a completely different issue. I was under the assumption that you simply need to know if the window changed, not what changed.

If you want to know which lines are new I highly suggest handling proper events like ON TEXT,ACTION,...-- this will be much more efficient than polling every window and looping over $line(#,%i) until you find the different line.

If i were to use proper events, I would miss out on critical information such as user scripts echos, or information there is no event for that happens to output to the active window so events are out of the question. Even your logging suggestion still would not work because I also need the lines default color, $line(blah,x).color which is not saved in the log file. I absolutely need to collect all the information from the windows buffer itself.

I guess another plausable solution would be a new event handler like on *:WindowUpdate: or something similar which would have identifiers to return the window, like $target, and make sure it triggers on EACH new line appended to a windows buffer, so you know when it triggers, the $line($target,0) is the ONLY new addition to the windows buffer. Then I could build a backlog of new data in like a binvar n store it to a hash table, keep appending to the binvar until a poll for the data is established, then the binvar is dumped and unset from the hash table.

some kind of ON ECHO event would indeed be a better idea, triggering every time data is appended to the buffer; with an associated $event that could not only prove as a useful way to accomplish this task but also a good way to potentially theme mIRC (since you could hook into /echo too)

I believe something like that has been suggested before, but it would be trickier to implement given how event lookups work.