www.ClassicTW.com :: View topic - compelling twx script language features

the reverend wrote:

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.

the reverend wrote:

Space Ghost wrote:

Any chance this new helper will have a graphical map?

Tweety wrote:

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.

Singularity wrote:

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

the reverend wrote:

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.

Tweety wrote:

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

Author:	the reverend [ Fri May 21, 2010 3:33 pm ]
Post subject:	compelling twx script language features
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.

Author:	Promethius [ Fri May 21, 2010 4:16 pm ]
Post subject:	Re: compelling twx script language features
the reverend wrote: 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.

Author:	Space Ghost [ Fri May 21, 2010 4:47 pm ]
Post subject:	Re: compelling twx script language features
the reverend wrote: 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. Any chance this new helper will have a graphical map?

Author:	the reverend [ Fri May 21, 2010 4:59 pm ]
Post subject:	Re: compelling twx script language features
Space Ghost wrote: Any chance this new helper will have a graphical map? yes. it will have a full plugin architecture which will be ideal for stuff like a map or a quickstats bar.

Author:	the reverend [ Fri May 21, 2010 7:09 pm ]
Post subject:	Re: compelling twx script language features
so for triggers, would something like this be ok? setTrigger(1, "step/Express) [Y]", "N") setAnsiTrigger(2, "Confirmed? (Y/N)?^[[1;36m", "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%**")

www.ClassicTW.com https://mail.black-squirrel.com/

compelling twx script language features https://mail.black-squirrel.com/viewtopic.php?f=15&t=26036	Page 1 of 2

Author:	ElderProphet [ Sat May 22, 2010 10:23 am ]
Post subject:	Re: compelling twx script language features
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.

Author:	Tweety [ Sun May 23, 2010 2:11 am ]
Post subject:	Re: compelling twx script language features
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.

Author:	Tweety [ Sun May 23, 2010 2:16 am ]
Post subject:	Re: compelling twx script language features
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.

Author:	Singularity [ Sun May 23, 2010 2:30 am ]
Post subject:	Re: compelling twx script language features
It would be really sweet if each script ran in it's own thread. Multicore systems would get a boost from that.

Author:	the reverend [ Sun May 23, 2010 8:23 am ]
Post subject:	Re: compelling twx script language features
Tweety wrote: 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. 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.

Author:	Singularity [ Sun May 23, 2010 8:41 am ]
Post subject:	Re: compelling twx script language features
the reverend wrote: 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. 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.

Author:	the reverend [ Sun May 23, 2010 6:23 pm ]
Post subject:	Re: compelling twx script language features
ok here is a preliminary trigger API along the lines of what i have in mind: Code: setTrigger(num, text) <-- triggers numbers must be 1 or greater - 0 means the script is aborting setRegexTrigger(num, regex) <-- if you're not familiar with regular expressions, google it, you will like what you find clearTrigger(num) startTriggerReply(num, replyMacro) <-- macros will be able to use live data from the database, e.g. "ay%MAXFIGS%" stopTriggerReply(num) num=waitForTrigger(num) <-- wait for a specific trigger; will return 0 if script is being aborted num=waitForAnyTrigger() <-- will return 0 if script is being aborted, or the number for the trigger that just occurred text=getLastLine() <-- will return the line of text that triggered here is an example of how to use it Code:** setTrigger(1, "powers up") setTrigger(2, "[A,D,R]") setTrigger(3, "blind") startTriggerReply(3, "N") do n = waitForAnyTrigger() switch (n) case 0 : do any last things because the script is aborting case 1 : call some function to handle power ups case 2 : do something here to handle the attack prompt default : do some default logic here - trigger 3 will get caught here, even though you have a reply setup end while (n > 0) stopTriggerReply(3) // these 4 lines are not really necessary, but for completeness clearTrigger(1) clearTrigger(2) clearTrigger(3) 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.

Author:	Tweety [ Mon May 24, 2010 2:08 am ]
Post subject:	Re: compelling twx script language features
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.

Author:	Singularity [ Mon May 24, 2010 2:49 am ]
Post subject:	Re: compelling twx script language features
Tweety wrote: would you take the parsing out of pretty much any generic message? like fig hits. or limpet active. or port data? 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)

Page 1 of 2	All times are UTC - 5 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/