what features of the twx scripting language do you find most unique and/or compelling? to be honest, i've never written a single twx script except perhaps to hack one up. i'm not really fond of the language but i recognize that it is compelling for many non-programmer types. if you had to boil it down, what would you say are those compelling features? triggers seem to me to be one of those features. how easy is it to access database information? how easy is it to get user input? what is done wrong? what is missing?

i'm asking this question because i'm currently developing a new helper that will have LUA as it's scripting language. i'd like to build in the hooks to make it a compelling scripting experience and part of that is figuring out what twx has done right so that i can capitalize on that success.

You have hit the two main features in regard to triggers and the database. I come to really like sectoparameters after working with them. ANSI detection is also nice as an anti-spoofing measure. TWX's window system makes life easier when doing a lot of things by allowing the scripter to filter out important information that they would not otherwise see (easily). The ability to encrypt scripts to prevent changes is a plus. There are a lot of commands that I use and would be lost without.

A couple of things TWX doesn't have that I would like is the ability to build menus similar to what you do in REXX, and the ability to output to a window in color.

               / Promethius / Enigma / Wolfen /

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

yes. it will have a full plugin architecture which will be ideal for stuff like a map or a quickstats bar.

so for triggers, would something like this be ok?

setTrigger(1, "step/Express) [Y]", "N")
setAnsiTrigger(2, "Confirmed? (Y/N)?^[", "N")
clearTrigger(1)
clearTrigger(2)

what is the equivalent in TWX? do you have a way to disable a trigger and re-enable it without putting the whole trigger text in?

setTrigger(3, "step/Express) [Y]", "N")
stopTrigger(1)
startTrigger(1)
clearTrigger(1)

is there a way in TWX to have variables in your trigger response like:

setTrigger(4, "powers up", "AY%MAXFIGS%**")

You can kill individual triggers by name only, but recreating it has to be done with the full triggering text.

Yes, you can use variables when specifying the text to trigger on.

The most compelling aspect of the TWX scripting language is that it is highly readable. It sacrifices density for legibility. One line of code typically executes a single TWX command. At times this sux when writing code, but this is the key to why so many non-programmers can pick up the language. Before I knew anything about programming or scripting, I could follow what a TWX script did, and make hacks to it. After doing that a few times, it was a small step to writing scripts from scratch.

I've made a sorted list of TWX commands from what I believe are most used/useful to least. I'll dig it up for you when I get a few mins.

I personally liked the whole readability part of twx scripts. it was simple. very low learning curve for those who knew nothing of programming. at least for simple tasks.

the whole capturing key strokes was a bit plus for me, being able to have dynamic terminal menus. one of my favourite scripts was one supG wrote that appended extra stats for sectors right inline with the sector displays. like port type. alone with mcic report. and backdoors. and quick keys to go to sectors for ppt or just moving. it was a simple idea, but i found it useful.

and having multiple scripts loaded at once. some could run in the background and wouldn't get automatically killed when you stopped all scripts. you would have to manually stop the background script itself.

database access yes. nice. could use more data of course. like ship types, odds, that sort. figs. planets. traders. unless it has been implemented recently.

being like a proxy because you could use different clients with it at one time. so if you liked one thing in another program, you could still use it in conjunction with twx. some people never stray from what they know best.

and the trigger thing in twx basically just jumps to another section of code in your script. like a goto in programming. or a function call. so you can do any number of things after the trigger is executed. not just a specified keystroke with variables included. it will execute everything where it jumped to until told to do somethin else. or another trigger decides to fire too that is still active.

It would be really sweet if each script ran in it's own thread. Multicore systems would get a boost from that.

thanks for that detail tweety. i thought twx triggers were basically just automatic macros. i didn't know they were able to jump to code or call functions. fundamentally, i'm opposed to things that behave like gotos, but what i have in mind should come close to what you're used to.

the current design of my helper does this.

setTextLineTrigger trigname :trighandle "trigger text"

When "trigger text" fires, it goes to :trighandle

As for gotos, as long as you have functions and a return() command, they aren't needed.

As for triggers, how do you plan to handle calls to code and not just autotriggers? That's
vitally important, since any complex script will need that ability. You could do a callback,
setTrigger(1,$text,&callback) would trigger on $text and go to &callback, passing stuff
via some standard line.

ok here is a preliminary trigger API along the lines of what i have in mind:



here is an example of how to use it



this is somewhat different from having callbacks and direct function calls connected to triggers, but nevertheless, it is very easy to get the same basic functionality with a main loop and a waitForAnyTrigger() call. of course there will be a way to use ansi codes in triggers so that you can do spoof detection.

also, all database parsing will be done before the script handles a line of game text - so you won't have to inspect everything in each line. for example, if you set a trigger for the command prompt, your code won't have to do the leg work to get the sector number out of the command prompt - you can just check the database for your current sector because it will already be done.

would you take the parsing out of pretty much any generic message? like fig hits. or limpet active. or port data?

for example. say someone hits a fig, would you be able to quickly know who hit it and where from the database by means of a exception hit or something? or would that be something you'd code for like normally based on the kind of script you write?

maybe have things in like a try, catch block. to catch exceptions you could watch for in another case statement. now that i think of it, that might be a little stupid lol. it puts a lot of relying on the database data being current and updated.

TWXproxy already does port data now. Fighits and limpet hits would be nice. But for fighits, you'd have to have
fields for alien (boolean), trader (string), sector (int), ship (string) and event (enter, attacked by, killed, and how many)