Yeah basically. In TWX scripting, we use "*" for ENTER or RETURN. * = CR (Carriage Return, or #13 in ASCII). So if I echo the following text, it shows up as 2 lines:
echo "This is line 1.*This is line 2."
If I echo that to the screen, line 1 will be followed by CRLF (Carriage Return, Line Feed), completing line 1, and line 2 will follow it on the next line with the cursor at the end of line 2. So line 2 is still going. If I start typing, it would be continued on line 2. A setTextLineTrigger will only fire once the line is completed, which by definition means it ends with CRLF (which we abbreviate * basically). So in the game of TW, I believe the only lines that aren't terminated with CRLF are some ANSI graphics and the current prompt.

Previous prompts that have already been answered are fine for setTextLineTrigger. So if you send "pt**", you can use setTextLineTrigger on the "How many holds of " line because the first "*" will complete that line, causing the setTextLineTrigger to fire. But it wouldn't fire if you just sent "pt", because the "How many holds" prompt will still be awaiting input.

Just realized I used "arrays" instead of what I meant. Ah well, posting from work, what can I say? Should have said using a "While" loop along with variables. People are slacking on not taking me to task for that.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

Besides being able to respond to different prompts, what are the advantages of setTextTrigger over waitFor (or waitOn)? Promethius, I originally had a loop, but it did not work. I guess once I saw that repeating the code did not work either I should have gone back, instead of making the same changes three times.

Vid Kid, 0.ts is my version of your test.ts. The full script is 0portUpgrader.ts and includes Singularity's nearest port trader.

Oh. Weird. I just tried Promethius's version. I think that my original was the exact same, except with waitFors instead of waitOns.

It worked.

I copied it into 0portUpgrader.ts and now I am a hundred and sixty million credits poorer.

Ouch.

Thanks guys?

By the way, I am not using my i7, I am using a public Dell running XP. Could it have been computer speed like Crosby said?

So... what is my next project? Oh, trust me, you guys will know all about it!

A waitFor trigger is disabled if any other trigger fires. I believe all of the other triggers, including waitOn, persist until they either fire or are killed.

So if you do this:
setTextTrigger fuelHolds :getHolds "How many holds of Fuel Ore"
waitFor "We'll buy them for"

The setTextTrigger will fire first, which kills any waitFor triggers if I recall correctly. But you could do this:
setTextTrigger fuelHolds :getHolds "How many holds of Fuel Ore"
setTextLineTrigger firstOffer :getOffer "We'll buy them for "
pause

When the first trigger fires, the other trigger persists. Now many people killAllTriggers and reset triggers every time a trigger fires, which is poor trigger management. What I like to do is set all of the triggers for a particular sequence, and let the triggers flow from one to the other. Observe:

Start with a waitOn that triggers on text that will always be seen just before the text we're triggering off of, like "<Port>", then all of the triggers will fire as their text is processed in. The triggers firing make our script flow from :getProduct, to :getQty, and finally to :getOffer. Notice there are no killTrigger or killAllTriggers, yet when we hit the gosub on that last line, all of the triggers have fired and are no longer active.

Let your triggers do the work.

+EP+

I had a script that would upgrade ports then go andf warp a planet to it and buy and sell.

I think I shared it a few times.

If anyone has it, fell free to share. I havent kept up with my scripts.

BTW Hi everyone