I ran into an issue I really haven't seen before and one that could cause someone a lot of head scratching in the debug process.

The proGameInfo script missed the right values in the "Tin Man" ship in Big D's Wizard of Oz edit. One ship in the middle of the ship catalogue - those before it were right and those after it right. I went through the code and it looked like all was right so I decided to slow the script down with a delay trigger so I could maybe see what was going on. I didn't see anything wrong so I checked the output - problem fixed.

This issue is with using T-Edt accessing TWGS on 1.27.0.1 port 2002 and I think due to the speed information comes through sometimes. I don't know if it would exist if I was remoting in or not.

So anyway, if you run into a problem with a T-Edit script, try inserting a delay trigger to see what happens. I used a 250 ms delay since I figured that was long enough for me to see what the script was doing. Since I am not a programmer, just write barely good enough to get by, I may be completely out in left field on this one.

               / Promethius / Enigma / Wolfen /

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

I have noticed that a few times myself Prom. Dang ultra fast ping when doing it from a local machine

If a script works sometimes but breaks when the data comes through too fast, it's because you didn't use a waitOn or waitFor trigger. IM me if you want help hunting it down.

+EP+

EP,

Thanks for the offer, but what I have found is that sometimes the data is streaming so fast, that it comes back to TWX before the script can execute the WaitFor command. I have had many instances of debuging a TEDIT script where it hangs, I look at the triggers and all that is listed is a WaitFor command, and the input it is waiting for is already displayed on the screen. I know that everything matches up because when I put a small delay trigger in front of the WaitFor the script works as intended. As Prom said though, I have only observed this behavior when running a TEDIT script on a local machine.

If either of you can email me a script and describe the parameters, I could be of more help. If we can shed some light on it, maybe we can hold another script class and show others how to avoid the problem.

I remember pulling my hair out once troubleshooting a text trigger that consistently wouldn't fire, and it ended up being an ANSI code (#7 Bell I think) embedded right in the middle of the text line. Craziness, but explainable.

+EP+

If you have the CN setting w/ the bell or beep or whatever it is set to on you'll get that in a lot of places. Dunno if 2.04 fixed that or not, but it used to drive me nuts when I was writing my first torper (fighits have a bell).

So yea, definitely check the raw packet.

Exactly. That is why I wrote that ASCII code parser script on Grimy. Priceless for stuff like that.

I will get with you on the script for the game info. I am using waitfors, and I thought that would take care of any issues, but I found I had to use the delay trigger also. The delay trigger is set after reading ship data and then sending ">" to go to the next ship. I don't know if the delay trigger allows the script to store data by slowing the execution. I have also found out that the same issue existed on the planets when I ran into deleted planets.

The weird thing to me on the Wizard of Oz edit was that it got the ship name "Tin Man" correct, but the data was wrong. It came from the ship spec after that one - a non-active ship I believe that should not have even been read.

               / Promethius / Enigma / Wolfen /

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

Hey Prom. Glad to see I was able to help by causing you all this extra grief.