External scripting cannot be prevented, though could be made to be less effective, such as by establishing notification and prompt delays throughout the game itself, such as how TPW from sector to the next sector works.

As to WOW, who needs scripting: https://www.thegamesupply.net/

And I would argue that the more complicated it is to setup and maintain the programs necessary to even connect to the game the less interest or desire there will be in playing the game, e.g., SWATH to TWXProxy to the TWGS versus logging into a host through your browser or by clicking an desktop icon.

I would also argue that bots aid in evening the battlefield and generates more competition. Regardless players vary in their individual skills, some like cashing some planet building, others enjoy the thrill of capping, still others like playing solo fighting only aliens, and still others just like the companion ship of doing whatever as a corporate member, being part of the teamwork. In all respects you have players that are good at certain things and okay at other things, while certainly having a great script is advantageous above all others, there are ways to circumvent that, given to game edits, e.g., suck as head-to-head battle then invest extra energy into upgrading planets to do your dirty work for you.

(Though, I think changes need to be made to photons (e.g., controlling their operation by game settings), they have become too powerful as private scripts have gotten really good at locating a player moving through a grid, doubly true when carrying around a limpit.) Also, IG need gameop settings as well, maybe like something like a fail percentage, for example. And a reentry setting of some sort, as it is very difficult to get into a game with other players running a MSL kill script or posting a sector-1 watch.

CPA's can't or shouldn't play this time of year. I'm a bookkeeper, I know.

right on
i am watching and after we drum the hell out of this topic i will make a 1 2 3 list of all game play suggestions. I will post that summary here and if all agree, will send that list to JP.
cc bee... out

Sadly, JP is not interested in selling TW to me at this time. He did however indicate if his workload on other projects became too much, he may reconsider somewhere down the line.

I just had a thought on scripting controls in games, which ought to be an easy patch to make, but am not entirely certain it would work as I am thinking; at any rate, what about making the player setting for about on any key or not a game setting? This would not stop scripting of course, but would prevent macros and greatly slow down scripts (but not so much as to make them pointless), and another great benefit would be to prevent missing important game information, such not seeing that you were just SD because you were speed gridding or colonizing, (e.g., when set scripts would function similarly to SWATH's builtin features.) And best of all this would be a SysOp game by game preference, one edit could have it enabled, while in another it could be disabled.

There was one more toggle I wanted but could never convince JP to implement it. CN9 - remove abort display and I believe TWXProxy will be useless. I've found that TWXProxy WILL NOT work on the old HVS MBBS version, but Swath still does, except for the turbo mode, that uses abort display. I suppose, you may still be able to string together some sophisticated macros with TWXProxy, but you can with Swath as well. Just an idea I thought would work, but never got the chance to test my theory.

It might mess with a particular version of TWX or a particular script, but it wouldn't do much in general. It's entirely possible to write a single parser that would recognize v1, v2, and HVS text.

I agree, it would break a lot of scripts, but they would be easy to fix. They would also run slower, because of the time it takes for various displays (i.e. transport ship list) to be displayed.

I ran into a BBS that I couldn't script once. It used:

1. Animated prompts, so I couldn't set a trigger. When ANSI movement commands are used the prompt you see on the screen wasn't sent in the order it appears. You could still lock on to the modified order, but he had dozens of different animations chosen randomly.

2. Animated cursor, so I couldn't just wait till the session was idle. These were also chosen at random, and were an endless loop animation. The session would never become idle.

3. No key buffer, so I couldn't send commands in advance. This is a common practice in scripts (i.e. Blasting the string "F1*CD"). With no buffer, you would have to send the "F" and wait for the next prompt before sending "1*".

4. No option to disable ANSI. This is a standard Syncronet option on the settings menu, but it was removed. I tried disabling it in the client, and he didn't have any text menus configured.

If you made those changes, it would make it very difficult to script. Still not impossible though.

Not so.

The TWX internal database is the problem. HVS data display is different from TWGS in the case of intersector warps and port displays to the point that the internal database does not permit various scripts to function. It is not a case of parsing and then feeding it to TWX, there is no way to do that. I had several communications with Singularity about this some years ago. the conclusion was that the only workaround would be a rewrite of TWX source.

Some of the old helpers also have a problem with TWGS, I use Twassist, and it cannot read TWGS ZTM results, but I parse the file to put it into MBBS syntax. Cant save the data, parse it, and read it back into TWX tho.

I believe you are referring to
viewtopic.php?f=14&t=31841&start=0

It took me less than 40 minutes to crack it and I recall that one of the handicaps that you had working against you was a bug in the terminal program that you were using.

It would end up unbalancing gameplay by restoring script writers to the near "magician" status they had 20 years or so ago.

Yeah, that's the one... I think... I was able to correct the problem with the bot, but still never got a script to work...

are you sure it worked?

if (waitFor("[Pause]",100)) cPuts("^M");

There weren't any "[Pause]" prompts.

I love Sings response of blasting a macro. The BBS didn't have a key buffer, so his macro would have went straight into the big bit bucket in the sky.

Thanks god that BBS is down. I was gonna try again... lol

It was taken down within a week or two after I scripted thru it - I hated that I had had to use delayed ^Ms to break two parts of it, and wanted to do something a bit more elegant. It was gone when I went looking.

And, yes, there were a few places where "[Pause]" appeared. I ran the script at least a half dozen times on account of you had said that there were random things happening.

If you look at page 2 of that link, you posted that you got my code to work when you fixed microbot, or switched to putty.

You are correct about the buffer, altho there was a slight anomaly - ^I got me past one, probably unique tho, it was from username to password and I used it instead of ^M after username.

Nod re Sing : )

But TWX itself could be changed to recognize all the variants.

Yes.

People aren't willing to update their scripts for v2 now, or don't have the source. I highly doubt anyone would go through the trouble to rewrite TWX just to play a game that does not abort displays. That's the BIG "You're NOT Welcome" mat.