I'm now running on a Win7, 3.3 hex core with 8 GB of ram.

I think this machine may be processing some scripts too fast.

For an example, furb.cts, the one I had didn't load at all. One of my teammates sent me his copy and is runs but does not put holds on the ships.

The furb.cts script works just fine for the rest of my corp mates.

Is anyone else seeing this as well?

Yes it is possible for scripts to run too fast , the way they were coded a few years ago.
Today the scriptwriter has to take that into account and put pacing in to slow it down just enough to grab what it needs at certain prompts.

Some of the older scripts that use includes also have to be re-tailored because of the old way of scripting and the matter of pacing.

Vid

Text waits are particularly susceptible to race conditions. That's why SWATH was trying to convert to a more event-driven approach.

Is there any way to keep basic Mombot scripts viable for newer, faster processors and connections or have we began to hit the wall here?

Yes of course , I believe that is what someone is doing with the rewrite.
Keeping it up to date , fixing previous script flaws.

It's really just a matter of addressing the lack of wait's/pauses in the current script's.

I have been having this trouble for years now. I have very fast processors and a slow connection between NZ and Guam and the US.
I was in the process of emailing Vid about one of my scripts missing a trigger . I just happened upon this topic by chance. Probably explains what is happening. My problem is how to find if my ship is carrying Photons or not without using a trigger

I don't think it is. Using a trigger is fine. You probably need to slow down the script a little with a waiton if im reading this right?

It's been my experience that a properly written script is not vulnerable to pacing (speed and latency) issues. But it's also been my experience that a lot of scripts aren't written perfectly. I would say that in almost every case where there's a problem (as in it worked before or works sometimes), it's because the script used setTextTrigger instead of setTextLineTrigger, or a text trigger was set without a waitOn before it to ensure other processing has occurred.

So let me elaborate. Let's say you want to grab the density manually from a density scan. You might do something like:Remember that a line from a density scan looks something like:
Sector 792 ==> 100 Warps : 2 NavHaz : 0% Anom : No
So no problem, it looks good right? FAIL - It turns out that this code actually suffers from both of the problems that I mentioned. Since this is a text trigger, the only thing that you can be sure of is that the triggering text "Sector" has been seen. So CURRENTLINE could be "Sector 792 ==>", or maybe just "Sector". How then can you grab the 4th word using getWord? Instead, you should have used setTextLineTrigger, which ensures the entire line after the triggering text is captured. A setTextLineTrigger is kinda like a 2-part trigger: it begins firing when the text is seen, and ends when the carriage return is seen, so CURRENTLINE returns the entire line. And a faster CPU or slower connection will really bring these triggering missteps to light.

But wait, there's a second problem with that code snippet. If you were to change the send text to "dsd", it will end up triggering on the Sector display rather than the density scan since the triggering text "Sector" will be seen at the wrong time. So here the key is to limit when the trigger can fire to a point just before the desired text is displayed. I like to use a waitOn for text that is consistently displayed just before the text I'm interested in, and never seen otherwise. So in this case, the optimal way to write it would be as follows:So here the waitOn prevents the TEXTLINE trigger from becoming active until the last possible moment, and you can be sure CURRENTLINE will be complete when it fires.

So let me give you script writers 2 cardinal rules for triggers:
1. Strive to waitOn unique text before your trigger, then set your trigger.
2. Use textline triggers unless you can't. (And if you don't know, you should ask why you sometimes can't.)

+EP+